All Answers

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”).

In order to work its magic, WSE RemoteApp utilizes the underlying “Essentials” functionality that is built into the Essentials server itself (or that is installed as part of the Windows Server Essentials Experience server role under Server Standard, Datacenter, etc.). WSE RemoteApp does not install any of the Remote Desktop Services (RDS) server roles onto your server (nor does it change the out-of-box Essentials configuration in any way), and so there isn’t any place to enter in CALs even if you wanted to (and WSE RemoteApp will actually refuse to run if the full gamut of RDS server roles have been installed on the server seeing as doing so wreaks havoc with the default Essentials configuration).

That being said, if someone wants to purchase user and/or RDS CALs (and keep them tucked away in a desk drawer) in order to satisfy licensing requirements, then that is certainly their prerogative, and we would never discourage them from doing so. It is simply left up to the end user to determine the licensing needs of their server and installed/published applications.

As for your other question… The out-of-box configuration of an Essentials server only allows two concurrent remote sessions with the server. If you do not want to use the provided ‘multiple simultaneous connections’ feature, then the only other way for you to get around that limitation would be for you to setup a completely separate application server that is running the full gamut of RDS server roles (and deal with all of the extra hassle and expense that goes along with it).

All of our RemoteApp-based add-ins (WHS/WSE RemoteApp, etc.) include a feature called “Shell Locker” that blocks standard users from being able to access their full server desktop on the Essentials server (unless they can provide admin sign in credentials in order to continue). The Shell Locker feature is enabled by default seeing as most server admins see having standard users access their full server desktop as a security risk to their server. However, the Shell Locker feature can be disabled for all standard users (or just bypassed for select standard users) if desired by the server admin.

To disable or enable the Shell Locker feature:

1. Open the server Dashboard and go to the add-in’s main page (“WSE RemoteApp“, etc.).

2. Click on the “Server Access Settings” task.

3. Under the “Access Restrictions” section of the Server Access Settings dialog box that opens, check the “Block remote connections to the desktop” checkbox in order to enable the Shell Locker feature (or uncheck it in order to disable the feature).

4. Click the “Select Users” button to allow select standard users to bypass the enabled Shell Locker feature and be able to sign in to their Essentials server desktop.

5. Click on the “Save” button (in both dialog boxes) in order to save any changes you’ve made.

Lastly, please note that WHS/WSE RemoteApp also has a feature that allows the admin to publish the Essentials server’s desktop as a RemoteApp program so that their users can access it (as a nested session) from within the main WHS/WSE RemoteApp Launcher window. When enabling this feature for your users, you also allow them to bypass the Shell Locker feature (which is a requirement in order for them to be able to sign in to their Essentials server desktop).

To publish (or unpublish) the server desktop as a RemoteApp program for your standard users:

1. Open the server Dashboard and go to the add-in’s main page (“WSE RemoteApp“, etc.).

2. Click on the “RemoteApp Programs” sub-tab.

3. Click on the “Publish server desktop” task.

4. Check the boxes next to the standard users who you want to publish the server desktop for (and bypass the Shell Locker feature).

5. Click on the “Save” button in order to save any changes you’ve made.

Can you please provide a screenshot of the error message you are getting so that I can get a better idea of what’s going on there?

Also, in situations such as this, it’s best if you take WSE RemoteApp completely out of the picture when making a remote connection to the server (via its Remote Desktop Gateway). That way you can easily tell if the problem you are having is directly related to WSE RemoteApp, or if it is simply a problem with the standard/default configuration of your Essentials server.

You can do that by attempting to connect to the server Dashboard from the Essentials server’s built-in Remote Web Access (RWA) website. Since WSE RemoteApp uses the exact same underlying functionality of the Essentials server in order to make its connections, this means that if you’re not able to successfully connect to the server Dashboard from your Essentials server’s built-in RWA website, then the issue is with your Essentials server’s Anywhere Access/Remote Web Access configuration (etc.), and not with WSE RemoteApp.

To connect to the server Dashboard from your server RWA website:

1. Open the server Dashboard and go to the “USERS” page.

2. Double-click on one of your standard users in order to view the user’s properties.

3. In the user properties window that appears, click on the “Anywhere Access” tab, and make sure that the “Allow Remote Web Access and access to web services applications” AND “Server Dashboard (administrator required)” check boxes are checked, and then click on the “OK” button in order to save your changes.

4. Go to your server’s RWA website (e.g. https://YourDomainPrefix.remotewebaccess.com/remote or https://YourDomainPrefix.YourCustomDomain.com/remote) and sign in as the same user from steps 2 & 3 above.

5. Once the user is signed in, click on the tile with the name of your server that’s located within the “Devices” widget.

6. When prompted, open the [servername].rdp file, and then attempt to remotely connect to the Essentials server’s Dashboard by signing in using your admin credentials (and NOT the standard user’s credentials!).

Are you able to successfully remote connect to your Essentials server’s Dashboard this way?

If not, then that’s your problem… i.e. You won’t be able to remotely connect to WSE RemoteApp until you can first successfully remote connect to the server Dashboard from your server’s RWA website since they use the exact same underlying functionality. You’ll need to figure out what is causing the problem, and your best bet there is to run the Anywhere Access setup wizard again (i.e. from within the server Dashboard, click on the “Settings” link that’s located in the upper right-hand corner, click on the “Anywhere Access” tab/link, and then click on the “Repair” button. Note that you might also need to click on the “Set up…” button in the Domain name section and set up your domain name again).

For additional help please see:

Successful Connections Require Secure Remote Web Access Setup!

Manage Remote Web Access in Windows Server Essentials

When a user signs in to WSE RemoteApp and opens up its main “WSE RemoteApp Launcher” window, they should only ever see their very own list of published RemoteApp programs.

Unfortunately, there is no way to prevent individual published RemoteApp programs from showing up within the Launchpad (or on the Desktop or Start menu/screen) for a specific user. However, that being said, if a user attempts to run one of the published RemoteApp programs that isn’t theirs, then WSE RemoteApp will not allow them to do so (i.e. it will alert them that they have not been granted permission to use that particular published RemoteApp program).

The reason it works like this is because there can be multiple users signing in to WSE RemoteApp from a single client computer (and not just the user that is currently signed in to Windows at the time – i.e. it acts like a kiosk). Since WSE RemoteApp always prompts the user for sign in credentials when they first launch a published RemoteApp program from the client computer, it will accept any “allowed” user’s credentials. Therefore, WSE RemoteApp cannot hide any of the published RemoteApp programs on the client computer (on a per-user basis) seeing as it never knows which user will be signing in.

If you don’t want this happening, then the best way to approach it is as follows:

1. Open the server Dashboard, go to the “WSE REMOTEAPP” page, and click on the “RemoteApp Programs” subtab.

2. Click on the “RemoteApp program client settings” task.

3. Under the “Launchpad” section, uncheck the “Add RemoteApp programs to Launchpad” checkbox.

4. Under the “Shortcuts” section, uncheck the “Add RemoteApp programs to Start menu/screen” checkbox (which will also automatically uncheck the “Add RemoteApp programs to Desktop” checkbox).

5. Click on the “Save” button in order to save your changes.

Now, the very next time a user signs in to WSE RemoteApp from the client PC, all of the published RemoteApp programs will be removed from the Launchpad, Desktop, and Start menu/screen.

From then on, they can just use the main “WSE RemoteApp Launcher” (or “Launcher“) item in order to sign in to WSE RemoteApp. Then, when the main Launcher window appears, they will only ever see their very own specific RemoteApp programs, and they can open them directly from there instead.

I hope that helps you out some.

BTW, if anyone has a better way to approach this one, I’m all ears.

It is indeed downloading an additional install file from the cloud however there’s a workaround if for some reason the download fails. I found this out while trouble-shooting a client connector install fail.

According to the install log file at %ProgramData%\Microsoft\Windows Server\Logs\Computerconnector.log

it was trying to download a file linked to by http://go.microsoft.com/fwlink/?LinkId=789477 but failing (for unknown reasons.) However using a browser session the link works and it successfully downloads WSEClient-x64.msi

If you now copy this file into the temp installation folder C:\Windows\Temp\ClientDeploymentTempFiles\ and repeat the installation, then the connector installation then completes. Presumably the download still fails however it then finds that the file it needs is strangely already where it should be and carries on with the install.

(Whether that install in my case was successful is another matter. From the dashboard it shows that Backup is “Not Supported” however I suspect that’s because I’ve added in a server running Windows Server 2022 as a client which I suspect isn’t supported. In any case my point is that there is a potential workaround here.)

If the client computer is still successfully connected up to the Essentials server, then I’m not exactly sure why those backup related items/tasks would be missing from the Dashboard??? I am aware of an issue where Essentials does not properly set the DeviceIdentity status for certain clients/servers, and thus wrongly reports them as having a disabled status, which results in their backup related tasks/items not appearing within the server Dashboard. I have absolutely no idea why it happens (other than it simply being a bug in Essentials), but I seem to have managed to correct the issue by doing the following:

1. Exit the server Dashboard application if it happens to be running.

2. Sign in to your Essentials server as an administrator.

3. From the administrator’s desktop, open File Explorer and go to the following folder:

C:\ProgramData\Microsoft\Windows Server\Data

NOTE: The ProgramData folder is a hidden system folder and so you will need to check the “Hidden items” checkbox located on File Explorer’s “View” tab if you cannot see the folder.

4. Locate the “DevicesInfo.xml” file in that folder and copy (not move) it to the desktop.

5. Right-click on the desktop copy of “DevicesInfo.xml” and choose Open with -> Notepad (or Open with -> Choose another app -> Notepad).

6. Once it’s open in Notepad, choose Edit -> Find and search for the following text:

<d3p1:PropertyName>IdentityStatus</d3p1:PropertyName>

7. For each found instance, look directly underneath it for the following text:

<d3p1:Status>Disabled</d3p1:Status>

If you find it, then change it to (i.e. just change the device’s Status from Disabled to Active as required):

<d3p1:Status>Active</d3p1:Status>

Repeat this for each IdentityStatus found within the file.

8. When you’re finished, save the changes you’ve just made (via File -> Save), and then copy the changed “DevicesInfo.xml” file back into the Data folder (overwriting the existing copy).

9. Open the Services applet (via Run -> Services.msc), and restart the “Windows Server Essentials Management Service” service (or reboot the server).

10. Open the server Dashboard and go to the “DEVICES” page, and you should now see the “Start a backup for the computer“, “Customize backup for the computer“, etc. tasks for each of your connected client computers.

Doing that seems to have corrected the issue for us over here, but I have no idea if it will return again at some later point or not.

The WSEE Installer is only made available (at no additional charge) to purchasers of our software products. It is not made available as a stand-alone offering since we do not officially offer support for it, and since the components it installs are not ours to sell (i.e. they belong to Microsoft). Therefore, you will need to purchase a copy of WSE RemoteApp or WSE WorkFolders (even if you do not intend to ever use the add-in) in order to gain access to the WSEE Installer. Once you’ve made your purchase, you can contact us with the “User Name” from the license of your purchased product and request access to the WSEE Installer.

See here for my thoughts on CALs.

In place upgrades from prior versions of Windows Server, where the Windows Server Essentials Experience (WSEE) has been installed by the WSEE Installer, are fully supported by the WSEE Installer. However, during the in place upgrade, Microsoft will forcefully remove all of the Windows Server Essentials assemblies, services, etc. (just as they do during a Windows Server 2016 to Windows Server 2019/2022/2025 in place upgrade) leaving you with an orphaned Windows Server Essentials Experience instance. When you attempt to run the WSEE Installer again, it will refuse to run because another version of the product is already installed. To remedy this, I have built a small “WSEE Zapper” program that you can run in order to remove the orphaned WSEE instance from the server, and thereby allowing you to be able to run the WSEE Installer again.

IMHO, setting any of the services to delay start is not the proper way to work around these issues (bugs) in Windows Server 2025.

I believe that all of the issues (bugs) are related to the Volume Shadow Copy Service (VSS) and the limit user access functionality of the Windows Server 2025 operating system. I’ve just implemented a fix (i.e. kludge) for the problem in the latest release of the WSEE Installer/WSEE Updater that will hopefully work around the issues in Windows Server 2025 until such time as Microsoft finally figures out what the actual problem is and releases a Windows Update for it (at which time I’ll then go ahead and reverse the kludge with another update).

You can download a copy of the latest WSEE Updater (with the fix) from here.

The Windows Server Essentials Connector software works just fine at connecting Windows 11 (24H2, etc.) client computers to the server. We have dozens of them successfully connected up to various versions of Windows Server Essentials (2016, 2019, 2022, and 2025) over here without issue.

So long as you’re not attempting to remote domain join your client computers to the server (i.e. connecting them to the server remotely via https://YourRWADomainName.com/connect rather than locally connecting them using http://YourServerName/connect), then the SSL certificate that you’re using in Anywhere Access/Remote Web Access (RWA) doesn’t matter in the least (seeing as Anywhere Access/Remote Web Access doesn’t even need to be configured on the server in order to locally join client computers to the server).

I cannot speak directly to why your specific client computers are having trouble locating the server (with all of the steps that you took/mentioned), but in order to successfully connect client computers to the Essentials server all that is required is for you to:

1. Ensure that the “SchUseStrongCrypto” and “SystemDefaultTlsVersions” .NET Framework security settings have been added to ALL of your client computers as well as to the server (and that they have been restarted afterwards).

2. Ensure that the server has been configured with a static IP address.

3. Ensure that the preferred IPv4 DNS server address of your server is set to the default 127.0.0.1 localhost/loopback address, and that the alternate IPv4 DNS server address is set to the IP address of your network router (e.g. 192.168.1.1) or other “known” DNS server (e.g. 8.8.8.8, etc.).

NOTE: IPv6 should also be enabled on the server, and its preferred IPv6 DNS server address should be set to the default ::1 (loopback) value.

4. Ensure that the preferred IPv4 DNS server address on ALL of your client computers has been set to the static IP address of the server, and that the alternate IPv4 DNS server address is set to the IP address of your network router (e.g. 192.168.1.1) or other “known” DNS server (e.g. 8.8.8.8, etc.).

EDIT (2/2/2026): If your client computers are running Windows 11 24H2 (or greater) and you are having trouble connecting to them (via the Windows Server Essentials Connector software, or via RDP, etc.), then it appears that Microsoft has disabled NTLM authentication on these newer clients and you may need to re-enable it to get them connected. For further details on how to do that see this Q&A thread.

After performing all of the steps above, the connector software should then be able to successfully locate (and communicate with) the server (assuming that you don’t have any other firewall, anti-virus, proxy, DNS, etc. settings that are interfering with the connection that is).

Also, if you don’t want to join your client computers to the domain, then be sure to use Microsoft’s SkipDomainJoin connection method BEFORE running the connector software on the client computers.

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).

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

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

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.

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.