All Answers
Microsoft doesn’t provide any way to turn off that option in the server Dashboard. The only way you can turn off the option is to either wait for another update of the add-in to be released (and then turn it off it when installing the update), or by performing an uninstall/reinstall cycle of the add-in (which I don’t really recommend doing with WSE RemoteApp seeing as uninstalling it will remove all of your published RemoteApp programs and settings and you’ll need to set it back up from scratch again).
That being said, we strongly advise that our customers always choose the “***On the server and on all of the computers on the network***” option when installing/updating WSE RemoteApp. The reason for that is because installing WSE RemoteApp’s client-side connector software (i.e. its “Launchpad” components) is the only way to connect to the add-in over your local network (which is the fastest and most secure way for your users to connect to your published RemoteApp programs).
In fact, we feel so strongly about turning on the option that WSE RemoteApp will actually add a health alert in the Dashboard, as well as prompt you when first starting the server Dashboard, if the option is not enabled. Of course you can always tell the Dashboard to simply ignore the health alert, and check the “*Do not show this again*” checkbox within the Dashboard prompt, if you really do not want to use that option and don’t want WSE RemoteApp’s client-side connector software installed on all of your network client computers.
Personally, it would be better for you to enable the option, and then just uninstall WSE RemnoteApp’s client-side connector software from the one or two client computers that you don’t want/need it installed on (via the Control Panel’s “*Programs and Features*” applet).
- Mike answered 10 years ago
- last active 10 years ago
Tried to register but keeps failing, so I remain a guest.. and purchased the product. Anyways- I understand the limitations put forth by Microsoft. I followed your answer, and since I didn’t feel like I needed the connector on my exchange server I uninstalled as suggested. No I have an alert in the health monitor dashboard as follows:
*Can only partially assess the health of this computer. The failing components are: WSE RemoteApp\Definition.xml*
- Brian answered 10 years ago
- last active 10 years ago
The [Questions & Answers][1] forum is brand new, and so we’re experiencing a few growing pains with it I’m afraid. Sorry that you haven’t been able to register. I’ve just taken a look, and your user account is indeed now registered and active. Can you please try logging in again and see what happens. If you don’t recall your password, just use the “*Lost your password?*” link that’s listed at the bottom of the log in page in order to reset your password.
As for the health alert… I’m not seeing that behavior here on any of our in-house test servers/clients. Since you have just uninstalled the add-in’s client connector from your client computer(s), please try manually deleting the health alert (by right clicking on it and selecting “*Delete this alert*”), and see if it comes back the next time your server runs a health evaluation. If it doesn’t, then you’re golden.
If it does come back, then in order to help us figure out what is causing that “*computer monitoring error*” health alert to appear for your server/client computer(s), you can send us the health alert update log file from the server and client computer(s) that are experiencing the issue. To do so:
1) On both your server AND your client computer(s) open the following folder:
*C:\ProgramData\Microsoft\Windows Server\Logs*
**NOTE:** The ProgramData folder is a hidden system folder, and so you’ll need to make sure that you’ve enabled the showing of hidden files and folders in order for you to be able to see it. To do that, simply open the Control Panel, make sure its “*View by*” setting is on “*Large icons*”, and then run the “*Folder Options*” applet. On the “*View*” tab of the Folder Options dialog box, make sure that “*Show hidden files, folders, and drives*” is selected under Advanced settings. Note that you may also want to uncheck the “*Hide extensions for known file types*” checkbox as well.
2) Locate the log file with the following name:
*RunTask-Health Definition Update.log*
3) Zip up that log file and email it to us (using the [Email Support][2] page).
We’ll then examine the log file to see if we can track down the reason you’re seeing the computer monitoring error health alert.
In the meantime, you can safely ignore the computer monitoring errors by opening the server’s Dashboard application, going to the “*Health Monitoring*” subtab of the “*HOME*” page, and then right-clicking on each of the alerts and selecting “*Ignore the alert*” from the popup menu that appears.
[1]: https://www.TheOfficeMaven.com/questions
[2]: https://www.TheOfficeMaven.com/support/email
- Mike answered 10 years ago
- last active 10 years ago
Please take a look in the following Registry key over on your server:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Server\Domain Manager\ActiveConfiguration
If the “ManualModeEnabled” value is set to “False“, then go ahead and make sure that a “DomainName” (string) value exists, and that it is set to your domain name EXACTLY as it is specified on your SSL certificate (e.g. “remote.xyz.com”; and not missing/empty or set to some other incorrect value such as just “xyz.com”).
Otherwise, if the “ManualModeEnabled” value is set to “True“, then look in the following Registry key on your server:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Server\Domain Manager\Settings
And make sure that a “DomainNameInManualMode” (string) value exists, and that it is set to your domain name EXACTLY as it is specified on your SSL certificate (e.g. “remote.xyz.com”; and not missing/empty or set to some other incorrect value such as just “xyz.com”).
- Mike answered 10 years ago
- last active 2 years ago
As per our [privacy statement][1], we do not collect our customer’s email addresses for contact purposes (not even to notify them of available updates).
However, in the latest versions of all of our products, users now receive a subtle notification whenever an update is available for the product via the addition of a blue exclamation point/mark overlayed onto the product’s existing notification area icon (for example: ![WSE RemoteApp’s update available notification][2]). There’s also an “***Update available!***” item that gets added to the notification area icon’s right-click context menu (clicking on the menu item allows you to download the update). This way, you always get notified of new updates without ever needing to actually open and sign in to the server Dashboard application.
In addition, any user that has been granted permission to see network health alerts will receive a prompt alerting them that an update is available whenever they first sign in to the product (locally via the Launchpad). The “*see network health alerts*” permission is granted to a user by opening the server Dashboard, going to the “*USERS*” page, double-clicking on the user, and then checking the “*User can view network health alerts*” checkbox located on the “*General*” tab of the “*Properties for User*” window that appears.
[1]: https://www.TheOfficeMaven.com/privacystatement
[2]: https://www.TheOfficeMaven.com/images/wsera16_tray_info.ico
- Mike answered 10 years ago
- last active 10 years ago
All of our products support printing to a client computer’s local printer using Microsoft’s built in Remote Desktop printer redirection functionality. It can be a bit finicky to get set up (initially), but it does seem to work quite well after that. The trick is that you need to install the printer’s drivers on **BOTH** the client computer **AND** on the server itself, as well as enable printer redirection within all of your RemoteApp sessions.
There is a Knowledge Base (FAQ) article posted over on our website that walks you through getting it all working (it contains pretty much everything I know about getting printing redirection working in RemoteApp sessions without needing to resort to using expensive 3rd party RDS printing software). You can find the KB article here:
[Enable Printing To Local Computer’s Printer (WSE)][1]
[Enable Printing To Local Computer’s Printer (WHS)][2]
[1]: https://www.TheOfficeMaven.com/faq/enable-printing-to-local-computers-printer-wse
[2]: https://www.TheOfficeMaven.com/faq/enable-printing-to-local-computers-printer
- Mike answered 10 years ago
- last active 10 years ago
The installer program for the WSE RemoteApp 2012 R2 add-in’s client-side connector installs a completely different set of files on newer Windows 10 client computers than it does on older Windows 7 or Windows 8 client computers. Therefore, if you have upgraded your Windows 7/8 client computers to Windows 10, while the WSE RemoteApp 2012 R2 client-side connector was installed on them, then you will need to uninstall the client-side connector from those client computers, and then reinstall it again in order to get the proper set of files installed for use with Windows 10.
You can do that using the client computer’s “*Programs and Features*” Control Panel applet to uninstall the “Client Connector for WSE RemoteApp 2012 R2” (or “WSE RemoteApp 2012 R2 32-bit/64-bit Add-in Deployment“) program (and repeating the uninstall process on all of your newly upgraded Windows 10 client computers), and then opening the server’s Dashboard application, going to the “APPLICATIONS” page, clicking on the “WSE RemoteApp” add-in, and running its “Install the add-in on network computers” task in order to reinstall its client-side connector software on the Windows 10 client computer(s) that it was uninstalled from.
- Mike answered 10 years ago
- last active 10 years ago
You will need to install the latest version of WSE RemoteApp in order to correct the issue.
EXPLANATION:
On January 1st, 2016 Microsoft changed the way that digitally signed files are handled in Windows. Before that date, Windows allowed the use of “SHA-1 code signing certificates“. After that date, Windows began enforcing the use of stronger (more secure) “SHA-256 code signing certificates“. For more information see:
Windows Enforcement of Authenticode Code Signing and Timestamping
Due to this change in Windows, we had our existing SHA-1 code signing certificate replaced with a stronger SHA-256 variant. An unfortunate side effect of the replacement process was that our existing SHA-1 code signing certificate was revoked by its issuing certificate authority (effective February 5th, 2016). Which, in turn, caused all files that were digitally signed with our older (and now revoked) SHA-1 code signing certificate to no longer be trusted by our products, causing them to display “An error occurred while validating your license!” (“Cannot validate digital signature!” or “Digital signature not valid!“) error messages.
New versions of our products, that have their files digitally signed with our SHA-256 code signing certificate, have been released (versions 1.232.1232.1232 or greater). Installing the latest release of our products will remove the license validation error messages that you have been experiencing. If you haven’t already done so, you can download and install the latest version from within your server Dashboard.
NOTE: If the “Updates and Support” option on your license has expired, you will need to renew your license in order to be able to install the latest version.
I hope that explains things for you, and I’m sorry for the hassle you’re having on this one.
- Mike answered 10 years ago
- last active 9 years ago
Yes, they sure will.
As long as you “disconnect” the WSE RemoteApp session (and not “sign out” of it completely), and you don’t restart the server (to install updates, etc.), then any programs that are running in the disconnected session will be available (just as you left them) the very next time you reconnect a WSE RemoteApp session (even if it’s days or months later, and even if it’s reconnected from a completely different computer/device).
Note that this also assumes that you haven’t enabled the “Sign out disconnected sessions after …” setting via the add-in’s “Remote Desktop Session Settings” task.
- Mike answered 10 years ago
If you have kept a copy of the installation program (i.e. the .wssx and/or exe’s) for the version of WHS RemoteApp 2011 that you were last using, then you can reinstall the add-in using that older version of the installer without needing to renew your license. Otherwise, you would need to renew your license in order to be able to install the latest version of the add-in.
- Mike answered 10 years ago
That sounds brilliant…
Is it needed to allow Launchpad Access and Remote Web Access to start a WSE RemoteApp session? – I only allowed Launchpad Access during trial period and a connection is not possible.
Thanks again for your advice!
- Michael answered 10 years ago
- last active 10 years ago
If you publish an application (.exe) directly, then you can indeed set/edit its command-line parameters from within the RemoteApp Properties wizard. However, if you publish a shortcut (.lnk) to an application (which is the default/suggested RemoteApp publication method), then you will not be able to do so (as the command-line parameters textbox will be greyed out).
Instead, you simply need to click on the “Properties” button (located in the upper right-hand corner of the RemoteApp Properties wizard) and then set/edit the shortcut’s command-line parameters from there instead (i.e. by appending the command-line parameters that you want to use onto the “Target” of the shortcut). Once you’ve closed the shortcut properties window, the command-line parameter you added will then automatically appear within the RemoteApp Properties wizard.
- Mike answered 10 years ago
- last active 10 years ago
Alas, I’m afraid not. Without building a custom Terminal Services/Remote Desktop Services virtual channel add-in, there is no way for an application installed on the server to communicate with an application that is installed on a client computer over a Remote Desktop connection. Pretty much the best that you can do here is to install an email application (such as Outlook) directly onto the server and then let QuickBooks interact with it for emailing invoices, quotes, etc.
- Mike answered 10 years ago
- last active 10 years ago
Alternatively, if you have a web mail account, then you should be able to set it up in QuickBooks as per:
Set up your email service in QuickBooks Desktop
Switch from Outlook, Outlook Express, Windows Mail to web mail or QuickBooks E-mail
- Mike answered 10 years ago
- last active 10 years ago
I am not familiar with MYOB, but if it is a regular Windows desktop application that can be successfully run from a standard Remote Desktop connection, then it should work just fine when published as a RemoteApp program via WSE RemoteApp 2012 R2.
Additionally, WSE RemoteApp has a fully functional 21-day evaluation period, and so you can always install it on your server, and try it out just to make sure that it works as you want it to/expect it to before you commit to purchasing the add-in.
I’m sorry that I don’t have a better answer for you on this one.
- Mike answered 10 years ago
- last active 10 years ago
I am not familiar with VMware Unity Mode, and so I have no idea if what you are proposing will work or not. Personally, it seems overly complex to be attempting something like that with an Essentials server (just to run an old Windows XP application???) seeing as you would most likely need to install VMWare onto your Essentials box (eek!).
That being said, WSE RemoteApp has a fully functional 21-day evaluation period, and so you can always install it on your Essentials server, and try it out just to make sure that it works as you want it to/expect it to before you commit to purchasing the add-in. However, I’d definitely set up a test server (and not use your production server) if you are going to be attempting to install VMware on it (seeing as I have absolutely no idea what the consequences of doing so would be on an Essentials server).
I’m sorry that I don’t have a better answer for you on this one.
- Mike answered 10 years ago
- last active 10 years ago
I’m not exactly sure what service it is that you are referring to here, but none of our products require a server or client restart after installing updates (critical, important, or otherwise).
You may receive a notification on your client computers after installing an update telling you that the computer needs to be restarted in order to finish installing the add-in, but you can safely ignore that notification. I have no idea why the Windows Server Essentials Connector software thinks that one is required here. Most likely it is just a generic notification that gets displayed after the server updates any client-side add-in.
- Mike answered 10 years ago
This is most likely caused by your Windows 10 client computer having the older v10.0.10240.16384 “Windows Server Essentials Connector” software installed on it (i.e. the older version that gets installed as a Windows Update instead of as a standard program). The problem does not occur when the newer v10.0.14393.0 “Client Connector for Windows Server Essentials” software is installed (i.e. the newer version that gets installed as a standard program instead of as a Windows Update and can survive Windows 10 feature upgrades).
That being said… The issue has since been resolved in the latest version of WSE RemoteApp 2012 R2 (i.e. Version 1.255.1261.0 or greater). You can download the latest update from within the server Dashboard application. Just install it over the top of your existing install, and you “should” be good to go.
Alternatively, you can uninstall the older Connector software from your Windows 10 client computer, and install the newest version as follows:
1) Make sure that your server has KB3172614 installed on it (which has the updated “inbox component” for delivering the newer Connector software to your Windows 10 client computers). I believe that this is now a mandatory update, and so as long as your server has all of the latest Windows Updates installed, you should already have it.
2) On your Windows 10 client computer, open the “Programs and Features” Control Panel applet.
3) Locate the “WSE RemoteApp 2012 R2 (32-bit/64-bit) Launchpad Add-in Deployment” (or “Client Connector for WSE RemoteApp 2012 R2“) program and uninstall it.
4) In the “Programs and Features” Control Panel applet, click on the “View installed updates” link (which is located in the top left-hand corner of the window), and then search for the “Windows Server Essentials Connector” update and uninstall it.
5) Reconnect your Windows 10 client computer to the server by going to:
Doing that will download the latest version of the Connector software (which is v10.0.14393.0 as of this writing), and install it on your Windows 10 client computer.
6) Reinstall the WSE RemoteApp 2012 R2 client-side connector software on your Windows 10 client computer(s) by opening the server Dashboard application, going to the “APPLICATIONS” page, selecting the “WSE RemoteApp” add-in, and clicking on the “Install the add-in on network computers” task.
Obviously, it’s far easier/faster to just install the latest version of WSE RemoteApp 2012 R2, but if you’d like to make sure that you have the latest Connector software on your Windows 10 client computer(s) (so that you don’t run into any issues down the road when additional Windows 10 feature upgrades are released by Microsoft), then you can take the harder/longer route mentioned above.
- Mike answered 10 years ago
- last active 10 years ago
Hi Mike,
Unfortunately this is not the issue. This issue that you described is something that I found out a long time ago. Meanwhile have implemented the procedure described by you already some months ago.
My issue happened after I had already implemented several updates on Win 10 without having to reconnect everything again.
The exact cause I don’t know but I do know for sure that this problem occurred while I was doing an update on the sever and some other application started to give me some pop-up windows at the same time. I must have clicked the wrong button in the wrong window somehow (fingers faster than the mind…).
Anyway, the situation corrected itself. Yesterday I installed a new update on the sever and automatically this update was distributed to the clients. Once this update was installed on my win 10 client system the issue was solved. I assume that the access code to the application on the sever got corrupted or was still the old code. After the upgrade this code was replaced by the new, correct code and everything was back to normal.
Thank you for your time.
- Bart Pen answered 10 years ago
- last active 6 years ago
I’m glad to hear that the latest release of WSE RemoteApp 2012 R2 resolved the issue for you. A whole lot of work went into this new version in order to enhance the client-side connector (WSERA.Client.exe).
Previous versions of WSE RemoteApp 2012 R2 distributed some of the Essentials SDK assemblies in order to work around a bug that exists in version 10.0.10240.16384 of the Essentials client Connector software. Microsoft (somewhat) resolved the issue with their newest release of the Connector software (i.e. version 10.0.10586.63, 10.0.14393.0, or later), and so I decided to go ahead and remove the extraneous SDK assemblies from the later versions of WSE RemoteApp. However, I quickly found out that many users still have the older Connector software installed on their Windows 10 client computers because Microsoft doesn’t actually offer an upgrade path to the newest version of the Connector software (rather you have to manually go through the whole mess of making sure that you have the July update rollup installed on your server, uninstalling WSE RemoteApp and the older Connector software from your Windows 10 clients, and then reconnecting all of the clients with the server again).
Anyway… One of the additional enhancements I made to WSERA.Client.exe was to make it so that it now shows details about the client computer within its “About” dialog box (including the version of the Connector software that you have installed on your client computer). Thus, I’d be interest to hear what version it reports for the Connector software installed on your Windows 10 client computer. My guess it that it will show the older (and problematic) 10.0.10240.16384 version. To check, simply click on the “WSE RemoteApp Launcher” shortcut on your Windows 10 client computer’s desktop, and then click on the “About” link. Once the “About WSE RemoteApp 2012 R2 Client Connector” window appears, click on its (new) “Show client details” button, and then note the “Launchpad version” information that’s shown there.
Regardless, at least you’re back up and running again.
- Mike answered 10 years ago
- last active 10 years ago
