Microsoft’s remotewebaccess.com service has been a cornerstone of Windows Server Essentials going back at least to 2012 R2. It’s a free dynamic DNS service hosted by Microsoft that facilitates finding and accessing Essentials server from the Internet. Unfortunately, the remotewebaccess.com dynamic DNS updates have recently started failing again, as documented in this thread, meaning that if your public IP changes, you’ll lose easy external access to your server. Previous “tricks” to fix the service—namely updating TLS client connections with server registry hacks—no longer allow the updates to succeed.
The DNS for remotewebaccess.com is hosted by Azure DNS:
On an Essentials 2016 machine, the dynamic DNS updates are logged here:
I was able to duplicate the failure by temporarily connecting an Essentials 2016 machine to a different public IP (a cell phone hotspot). This is what the log looks like when the dynamic DNS fails:
 220507.135925.7819: ConnectivityCenter: DomainNameResolveableInfo.ExternalIP:  220507.135925.7919: ConnectivityCenter: Job finish. Result: Success  220507.135925.7919: ConnectivityCenter: Job DomainNameResolveableDiagnosticsJob complete, 100% done.  220507.135925.7999: ConnectivityCenter: DDNSUpdateAttemptionInfo.DDNSUpdateStatus: False  220507.135925.8040: ConnectivityCenter: Job finish. Result: Success  220507.135925.8040: ConnectivityCenter: Job DDNSUpdateDiagnosticsJob complete, 100% done.  220507.135925.8939: ConnectivityCenter: Microsoft.WindowsServerSolutions.Connectivity.Analyzers.DomainNameConfigAnalyzer analyze completed. 0 suggestions found.  220507.135925.8959: ConnectivityCenter: DDNSUpdateAnalyzer: DDNS update failed, should be manual fixed  220507.135925.8959: ConnectivityCenter: Microsoft.WindowsServerSolutions.Connectivity.Analyzers.DDNSUpdateAnalyzer analyze completed. 1 suggestions found.  220507.135925.8959: ConnectivityCenter: Current SQM Data is 1015807.  220507.135925.8969: ConnectivityCenter: Diagnositcs completed. Status: Success  220507.135925.9009: ConnectivityCenter: Suggestion: An error occurred while updating the dynamic DNS information for your server with the information that you gave your domain name service provider. Please try again later. If this problem continues, contact your domain name service provider for support.  220507.135925.9009: ConnectivityCenter: Overall status: Error  220507.135925.9009: ConnectivityCenter: Properties updated.  220507.135925.9099: ConnectivityCenter: DomainNameResolveableAnalyzer: Domain name could not be resolved to router's external IP address, should be manual fixed  220507.135925.9099: ConnectivityCenter: Microsoft.WindowsServerSolutions.Connectivity.Analyzers.DomainNameResolveableAnalyzer analyze completed. 1 suggestions found.  220507.135925.9099: ConnectivityCenter: Current SQM Data is 950271.  220507.135925.9099: ConnectivityCenter: Diagnositcs completed. Status: Success  220507.135925.9099: ConnectivityCenter: Suggestion: An error occurred while linking your domain name to the IP address for your server. Please try again later. If this problem continues contact your domain name service provider for support.  220507.135925.9099: ConnectivityCenter: Overall status: Error
Reading the log, you’ll see several references to “ctor called.” This is, most likely, shorthand for “constructor.” The .Net assembly doing the work has constructed (created) an instance of the relevant object.
I’ve tried to use Wireshark to reconstruct how Essentials 2016 checks for and updates dynamic DNS. Much of this is guesswork, examining a Wireshark log with roughly the same timestamps as the Essentials log. This is complicated by interspersed traffic with Windows update, monitoring software, etc.
1. Contact a site to determine the current external IP. I was unable to identify this traffic in Wireshark.
2. Send a standard DNS A-record query for mydomain.remotewebaccess.com. This returns the IP address as currently registered. You can see this in Wireshark at the same time that the server logs the line “ConnectivityCenter: DomainNameResolveableInfo.ExternalIP:”.
3. Update the DNS if necessary. Again, just a guess, but there is traffic with onedscolprdneu05.northeurope.cloudapp.azure.com. It’s interesting that when accessed with https: from a browser, this domain fails because it presents a certificate that does not include this domain. I wonder if this is the reason that updates no longer work. The current certificate was issued March 2, 2022.
That’s all I have time for at the moment. Server 2016 is supposed to receive Microsoft updates through January 2027, but the Essentials features seem increasingly like “abandonware.” I’m not sure it’s worthwhile to keep debugging the issues—it may be time to just give up on remotewebaccess.com and go back to using custom certificates and private DDNS. The Office Maven has a pretty comprehensive article on that here.
Update May 12, 2022
As of yesterday, a Microsoft employee reported that a fix had been rolled out. However initial feedback is that it didn’t work. The issue is being reported in multiple places but the first thread below is the one where Microsoft has responded:
Update May 14, 2022
Mulitple users in this thread report that the issue is now fixed. One asks the $64,000 question: “Any idea what caused the problem, and if its going to require another fix a year from now?” I added my own query along the same lines. No reply as of yet.
Note that https://onedscolprdneu05.northeurope.cloudapp.azure.com, which I suspected in my point 3 above, still does not present a valid certificate, so that wasn’t the issue.