Debugging remotewebaccess.com

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.

Some Analysis

The DNS for remotewebaccess.com is hosted by Azure DNS:

remotewebaccess 1

On an Essentials 2016 machine, the dynamic DNS updates are logged here:

C:\ProgramData\Microsoft\Windows Server\Logs\NetworkHealthPlugin-DomainManagementFeature.log

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:

[61048] 220507.135925.7819: ConnectivityCenter: DomainNameResolveableInfo.ExternalIP: 
[61500] 220507.135925.7919: ConnectivityCenter: Job finish. Result: Success
[61500] 220507.135925.7919: ConnectivityCenter: Job DomainNameResolveableDiagnosticsJob complete, 100% done.
 [61960] 220507.135925.7999: ConnectivityCenter: DDNSUpdateAttemptionInfo.DDNSUpdateStatus: False
 [62456] 220507.135925.8040: ConnectivityCenter: Job finish. Result: Success
 [62456] 220507.135925.8040: ConnectivityCenter: Job DDNSUpdateDiagnosticsJob complete, 100% done.
 [62264] 220507.135925.8939: ConnectivityCenter: Microsoft.WindowsServerSolutions.Connectivity.Analyzers.DomainNameConfigAnalyzer analyze completed. 0 suggestions found.
 [62104] 220507.135925.8959: ConnectivityCenter: DDNSUpdateAnalyzer: DDNS update failed, should be manual fixed
 [62104] 220507.135925.8959: ConnectivityCenter: Microsoft.WindowsServerSolutions.Connectivity.Analyzers.DDNSUpdateAnalyzer analyze completed. 1 suggestions found.
 [62104] 220507.135925.8959: ConnectivityCenter: Current SQM Data is 1015807.
 [62104] 220507.135925.8969: ConnectivityCenter: Diagnositcs completed. Status: Success
 [62104] 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.
 [62104] 220507.135925.9009: ConnectivityCenter: Overall status: Error
 [62104] 220507.135925.9009: ConnectivityCenter: Properties updated.
 [62264] 220507.135925.9099: ConnectivityCenter: DomainNameResolveableAnalyzer: Domain name could not be resolved to router's external IP address, should be manual fixed
 [62264] 220507.135925.9099: ConnectivityCenter: Microsoft.WindowsServerSolutions.Connectivity.Analyzers.DomainNameResolveableAnalyzer analyze completed. 1 suggestions found.
 [62264] 220507.135925.9099: ConnectivityCenter: Current SQM Data is 950271.
 [62264] 220507.135925.9099: ConnectivityCenter: Diagnositcs completed. Status: Success
 [62264] 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.
 [62264] 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:

https://docs.microsoft.com/en-us/answers/questions/836775/

https://docs.microsoft.com/en-us/answers/questions/318584/

https://sbsland.me/2021/03/18/windows-sbe-remotewebaccess-com-update-schlgt-fehlt/

https://www.askwoody.com/forums/topic/server-essentials-dynamic-dns-failing-again-remotewebaccess-com/

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.

4 thoughts on “Debugging remotewebaccess.com

  1. Jesse Flintoff

    Hi there

    Looks like the free Microsoft dynamic dns service in Essentials 2012 and 2016 has stopped working after recent windows update KB5020690 and KB5020023.

    Any fixes?

    Kind regards

  2. Mark Berry Post author

    Thanks Jesse. Yes I’ve been getting notices from the German forum for a couple of days (https://sbsland.me/2021/03/18/windows-sbe-remotewebaccess-com-update-schlgt-fehlt/).

    I posted this comment in the new thread you linked:

    This would appear to be the core issue: “There was no endpoint listening at https://dyndns.domains.live.com/service/livedyndns.asmx that could accept the message.” The domain does resolve, but if you try to connect to that address, it times out:
    C:\>nslookup dyndns.domains.live.com
    Non-authoritative answer:
    Name: wssddnsservice.cloudapp.net
    Address: 70.37.77.92
    Aliases: dyndns.domains.live.com

    C:\>curl https://dyndns.domains.live.com/service/livedyndns.asmx
    curl: (28) Failed to connect to dyndns.domains.live.com port 443 after 21091 ms: Timed out

Leave a Reply

Your email address will not be published. Required fields are marked *

Notify me of followup comments via e-mail. You can also subscribe without commenting.

This site uses Akismet to reduce spam. Learn how your comment data is processed.