First off… If you are running Windows Server 2016 (with WSEE), then how did you use the WSEE Installer there (seeing as it can only be used to install WSEE, taken from 2016, onto Windows Server 2019, 2022, or 2025)???

That being said…

The WSEE Installer has code in it that verifies (about once per hour) that the SSL certificate, which is currently bound to Essential’s “Default Web Site” (in IIS), is correctly installed for the Remote Desktop Gateway (so that Essential’s Anywhere Access/Remote Web Access features work properly). I’m not sure how that verification process could be causing your users to be disconnected from their remote connections on a regular basis unless your SSL cert is continuously being renewed or simply becoming unbound from the RD Gateway (and hence once per hour the WSEE Installer would then be making the attempt to rebind it back to the RD Gateway again).

When you look through the event logs, are you seeing those events from the WSEEInstallerProviderService getting logged over and over again (about once per hour)? If not, then I don’t think that would have anything to do with the user disconnects you are seeing.

Sorry, you are correct.  It’s server 2019 standard with the WSEE installer. The event log does show 3 events from the WSEEInstallerProviderService that occur every hour before the RD Gateway service is restarted.  I posted the 3 events that occur in order from 1 to 3. The RD Gateway service restarts after the last WSEE installer event. The server is not hosting any other websites other than the sites added when enabling the Anywhere Access service (Default, Mac Web Services and WSS Certificate Web Services) and is not configured for the VPN option in Anywhere Access.  When I browse to the manual domain name configured for Anywhere Access, the detail of the certificate states the following: “This site has a valid certificate, issued by a trusted authority.” I have removed and reissued the certificate and used the Access Anywhere wizard with the “manual” setup option to install and configure the certificate for the default IIS site and the RD gateway service. Before installing the reissued cert, I used the certificate mmc to remove the cert from the computer – Personal folder. After Anywhere Access installs the certificate, I check IIS to make sure that the cert is bound to the default site in IIS and that the cert is the correct one listed in the SSL Certificate tab of the RD Gateway Manager server properties. I have run SFC /scannow on the server to look for any corrupt or missing files and it comes back clean. It seems like the WSEEInstaller service is looking at the registry entry or a config file and it is not seeing the information that it needs to return a verification that a valid SSL certificate is installed. Any suggestions of things to try or registry entries or additional logs to look at would be greatly appreciated.

The WSEE Installer calls the built-in functionality (code) in Essentials to verify that the SSL certificate is properly configured on the server (and to configure it as well). Looking at the Essentials source code, it appears to be checking the “Win32_TSGatewayServerSettings” class in WMI to verify that the SSL certificate is configured by checking that its “CertHash” value is properly set to the IIS bound SSL cert’s thumbprint. This behavior gets logged under the “RDP” event within the “C:\ProgramData\Microsoft\Windows Server\Logs\NetworkHealthPlugin-ConnectivityFeature.log” log file. You can open that log file on your server and search for the phrase “Checking TSGateway certificate configuration” to follow along and see what’s happening there (i.e., to see why it repeatedly thinks that your SSL cert isn’t properly installed/configured).

From everything you’ve mentioned above, it appears that things are working correctly (as far as the WSEE Installer is concerned), but for whatever reason your SSL cert’s thumbprint isn’t getting (or staying) set within WMI on your server, and hence causing the SSL cert config process to be repeated over and over again.

You could also take a look in the registry under “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Server\Domain Manager” to see if the “LastInstalledCertificate” value is properly set to your SSL certificate’s thumbprint. And take a look under “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Server\RDP” to see if the “GatewayCertHash” value is being properly set there for the RD Gateway as well (which I believe it is since you’ve verified that via the RD Gateway Manager).

Lastly, you might want to check that your SSL cert remains bound to the RD Gateway (by looking in the RD Gateway Manager) after rebooting your server. I’ve seen cases (when using one of Microsoft’s personalized remotewebaccess.com domain names) where it gets unbound from the RD Gateway on every reboot due to the Go Daddy issued SSL cert being messed up and missing its private key. The only way I’ve found to resolve that issue was to set up Anywhere Access/Remote Web Access again using a completely different (new) remotewebaccess.com domain name (so that the newly issued one has its private key and stays bound to the RD Gateway after rebooting the server). For whatever reason Go Daddy seems to reissue the same remotewebaccess.com SSL cert over and over again until it has expired, and so if you happen to of gotten one that’s missing its private key, then you’re stuck with it until the cert expires and a brand new one gets issued again. BTW, you can check to see if your SSL cert has its private key by looking at it within the “Personal” store off the MMC Certificates snap-in and trying to export it (if it doesn’t give you the option to export the cert with its private key then you’ve got a bad one).