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.

16 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

  3. Jesse Flintoff

    Morning Mark!

    I hope you’re well.

    Seems to be down again for my sites. How about yours?

  4. The Office Maven

    Can anyone confirm if this is broken once again?

    On a brand new/clean Windows Server 2016 Essentials install (with the “SystemDefaultTlsVersions” and “SchUseStrongCrypto” .NET Framework registry settings set to 1) I’m consistently getting an unknown timeout error when attempting to configure a Microsoft personalized domain name within Anywhere Access.

    These are the events that are logged in the server’s Dashboard.log file:

    ###########################
    [4316] 240225.082530.7179: DomainManagerObjectModel: InvokeAsync: action resulted in exception: System.ServiceModel.FaultException`1[Microsoft.WindowsServerSolutions.RemoteAccess.Domains.DomainManagerFault]: The creator of this fault did not specify a Reason. (Fault Detail is equal to DomainManagerFault:[Reason:CommunicationFailure, Message:SubmitCertificateRequest failed, Detail:The request channel timed out while waiting for a reply after 00:01:00. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout. ]).
    [4316] 240225.082530.7179: DomainManagerObjectModel: InvokeAsync: handling exception by transferring to eventArgs
    [4192] 240225.082530.7179: DomainConfigWizard: Error occurred in Domain Manager Object Model operations: System.ServiceModel.FaultException`1[Microsoft.WindowsServerSolutions.RemoteAccess.Domains.DomainManagerFault]: The creator of this fault did not specify a Reason. (Fault Detail is equal to DomainManagerFault:[Reason:CommunicationFailure, Message:SubmitCertificateRequest failed, Detail:The request channel timed out while waiting for a reply after 00:01:00. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout. ]).
    [4192] 240225.082530.7179: DomainConfigWizard: FailReason from Domain Manager Object Model operations: CommunicationFailure
    ###########################

    It appears that the Anywhere Access config wizard is able to successfully sign in to the Microsoft Live account, but then times out with a “CommunicationFailure” error when calling the “SubmitCertificateRequest” method.

    Looks to me like it’s an issue occurring over on Microsoft’s backend (quelle surprise !).

  5. Mark Berry Post author

    @Maven, I only have one 2016 Essential box left and its remotewebaccess is still working, but the name and IP haven’t changed in years. Sounds like your failure is earlier in the process. A couple thoughts:

    – Check whether your (new?) subdomain is registered with public DNS. If so, the GoDaddy part is working.
    – I see this line in the article above: “On an Essentials 2016 machine, the dynamic DNS updates are logged here: C:\ProgramData\Microsoft\Windows Server\Logs\NetworkHealthPlugin-DomainManagementFeature.log”. Any clues in that log?
    – If that log reveals where the connection is failing, try connecting directly from a browser or curl. Check the certificate of the failing site.

    If you figure it out, let us know what happened!

  6. The Office Maven

    @Mark Thanks for the response.

    I get that same generic timeout error even on a 2016 Essentials box where RWA is already configured with a Microsoft personalized domain name (i.e. open Settings, go to the Anywhere Access tab, click the Set up button under the domain name section, in the domain name set up wizard that appears click Next -> choose “Use another domain name or domain name service provider” (do not choose the release option or you may loose your existing domain prefix) -> choose “I want to set up a new domain name” -> click Next -> Next -> sign in to your Live account -> choose “Choose a registered name” and select your existing domain prefix from the drop-down list -> click Next -> timeout error happens every time after about 30 seconds or so). Basically, it’s failing to acquire a new personalized domain name or even update an existing one for me.

    The NetworkHealthPlugin-DomainManagementFeature.log file doesn’t show anything remarkable that I can see (status entries show as “Success”, “Good”, etc.). It also seems to be failing before the GoDaddy part ever gets to kick in (i.e. the wizard is failing to initially communicate with Microsoft’s webserver as far as I can tell).

    I’ll keep digging into this one, and will indeed let you know. I fear that it’s an issue over on Microsoft’s end. Pretty much just wanted to know if anyone else is having the same problem so that I at least know if I’m barking up the right tree is all. ;-)

  7. Mark Berry Post author

    Seems like there are a lot of moving pieces to keep this handy function working properly! Hope someone else has some insight. It looks like only one other person subscribes to comments on this post. I’d post on some of the more broadly-viewed forums (like those linked above) if you haven’t already.

  8. The Office Maven

    Yeah, I posted my original question under that same Microsoft thread that you have listed as the first link under your May 12, 2022 update above so we’ll see is anything comes in on that (BTW, Microsoft sure did a number on their Q&A forums – it’s really hard to find anything on them anymore LOL). Take care and thanks again for your insight.

  9. Jesse Flintoff

    Howdy fellas!

    I had same issue with a 2012r2 server just before end of life.

    Ended up making my own solution which I now use for new 2022 servers:
    – Setup a dynamic dns server using my own domain name. Install the client on the server.
    – Install/use ‘certify the web’ for ssl creation and deployment on server.

    All the best.

  10. The Office Maven

    @Jesse Appreciate your input.

    Yeah, there’s lots of ways around the issue if you want to move away from using a remotewebaccess.com Microsoft personalized domain name. In fact, I have a detailed, step-by-step, article that talks about doing that (using a free Let’s Encrypt SSL certificate) for those folks still wanting to use a Windows Server Essentials server. See:

    How To Manually Set Up A Custom / Vanity Domain Name In Windows Server Essentials
    https://www.TheOfficeMaven.com/news/how-to-manually-set-up-a-custom-vanity-domain-name-in-essentials

    However, I’m more looking for conformation on whether or not anyone else is currently able to configure a remotewebaccess.com domain name via Anywhere Access under Windows Server 2016 Essentials at the moment (i.e. is it just me, or are others encountering the same issue).

    Thank you! ;-)

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.