remotewebaccess.com Anywhere access broken on Server 2016 Again?

I did a fresh install of Server 2016 in a VM to test and even an out of the box non-updated version has the same issue so I don't think this has to do with a recent update, it seems some endpoint the feature depends on has changed.

Same here in Germany. But 2 servers are ok (2012R2 Essentials) and another has the problems described. All Updates installed on all servers

Perhaps you can nudge this guy to come up with a new fix like they did last year haha

https://sbsland.me/category/computers-and-internet/troubleshooting/

i sent him a massage.

Same issue here. Service when down after a router reboot and public IP address change.
If I ping my old domain (domain).remotewebaccess.com it returns the OLD public address I had before.

Very strange.

So the .Net update didn't have any effect, I suspected it wouldn't but it was worth a shot.

same here in Bermuda, started this morning when one of my isp's went down. I have tried everything

Any update on this? I cant repair or release the domain. This is going to be a nightmare for me.

what i did: I switch to dyndns and a free certifcate. This helps for a moment.

Isn't it great when you spend lots of money on an enterprise level product to provision for a customer buying in that the product will at least function until the end of life date only for the company to leave you hanging in the wind half way though it's total shelf life?

Same here. The kicker is I'm a military member and it's going to be at least 6 weeks before I can physically get in front of the machine.

Hope nothing requires attention between now and then....

This is what I ended up doing as well. Hopefully it can be fixed, and I can switch back.

This changes the domain name url correct?

Yes it will

Like Thomas said, Yes. I would have replied earlier, but the reply button was not available on my phone.

Same here in Budapest, Hungary. The regedit workaround did not help, still old IP is shown.
I added the dinamic IP to the host file of the endpoint client and that helped but this is not a solution, as every time IP changes, I need to edit host file on the endpoints.
Let me know if there is a solution.

Blog post about the issue

https://www.mcbsys.com/blog/2022/05/debugging-remotewebaccess-com/

some on my side :-(

Hi
We have made some changes and changes and expect the issue to go away.
Can you please verify at your end/setups ?

Hi
We have made some changes and changes and expect the issue to go away.
Can you please verify at your end/setups ?

Still seeing the same issue. Made sure all updates were applies and rebooted. I attached my dashboard.log with the sensitive data covered in x's. I had to convert it to a pdf as the forum wasn't allowing me to upload it as a .log or .txt file. The server is still trying to update remotewebaccess using my old ip address not my current public ip.201203-dashboard.pdf

We were able to get things working on our local test setups.
Can you please verify your setups and see if the issue went away for you.

Thanks and Regards
Samriddhi

We were able to get things working on our local test setups.
Can you please verify your setups and see if the issue went away for you.

Thanks and Regards
Samriddhi

We were able to get things working on our local test setups.
Can you please verify your setups and see if the issue went away for you.

Thanks and Regards
Samriddhi

We were able to get things working on our local test setups.
Can you please verify your setups and see if the issue went away for you.

Thanks and Regards
Samriddhi

We were able to get things working on our local test setups.
Can you please verify your setups and see if the issue went away for you.

Thanks and Regards
Samriddhi

Hooray, working again here! Thank you so much, greatly appreciated. Windows Server 2012 R2 Standard with Essentials Role. :)

Mine just came back online on its own. Thank you for taking care of this!!!

@Samriddhi Chaturvedi I want to ask though. How likely is this issue to return? Will we be good until the 2027 EOL date?

It seems to be resolved for our domain as well

We were able to get things working on our local test setups.
Can you please verify your setups and see if the issue went away for you.

Thanks and Regards
Samriddhi

No issue is not likely to come back !

Regards
Samriddhi

Thank you @Samriddhi Chaturvedi for your hard work on this. I wish I had your ear several years ago when I reported that the mac client connector was (and still is) broken due to a dependency on Objective-C Garbage collection that Sierra+ doesn't allow but at this point I doubt that will ever be fixed.

Hi everyone.

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

I did a fresh install of Server 2016 E and still see the same so it's not just those updates. I made a new thread here:

https://learn.microsoft.com/en-us/answers/questions/1088241/domain-register-and-update-for-remotewebaccesscom.html

Seeing related issues again now :( . Made a new thread

https://learn.microsoft.com/en-us/answers/questions/1088241/domain-register-and-update-for-remotewebaccesscom.html

Every Windows Server 2012 R2 and 2016 Essentials I get health reports on, are all reporting "The dynamic DNS information cannot be updated" both yesterday 11/13 and today 11/14. All are fully patched and up to date from 11/08, doubtful patch Tuesday updates are the cause as they updated fine from 11/9-12.

Same here. One 2012 essentials. Wrong ip address after company move. Cannot remove domain, cannot repair.

Just been reading about TLS 1.2 issue. Could this be related?

I have the TLS 1.2 fix applied on my machine, but it's still broken for me.

Looks like the information on the previous post about https://dyndns.domains.live.com/service/livedyndns.asmx being down is the cause this time.

I wonder what the number of affected people is? Or the actual cost, both to business and I.T support? Happened too many times, always been slow to respond. Took a private guy and a reg hack last time. Actually shameful MS.

October 17, 2022—KB5020435 (OS Builds 19042.2132, 19043.2132, and 19044.2132) Out-of-band - Microsoft Support

Install that and see if it fixes the issue?
October 17, 2022—KB5020435 (OS Builds 19042.2132, 19043.2132, and 19044.2132) Out-of-band - support.microsoft.com
Windows 10, version 20H2 and Windows Server, version 20H2 update history; October 28, 2022—KB5020953 (OS Builds 19042.2194, 19043.2194, and 19044.2194) Out-of-band
support.microsoft.com

If this fixes it, that was slid into the PREVIEW update of 9/20

New! Turns off Transport Layer Security (TLS) 1.0 and 1.1 by default in Microsoft browsers and applications. For more information, see KB5017811.

So the side effect for the October security update was really a kinda security feature that was slid into the preview release

September 20, 2022—KB5017380 (OS Builds 19042.2075, 19043.2075, and 19044.2075) Preview - Microsoft Support
September 20, 2022—KB5017380 (OS Builds 19042.2075, 19043.2075, and 19044.2075) Preview - Microsoft Support - support.microsoft.com
Windows 10, version 1909 and Windows Server, version 1909 update history; End of service statement; May 10, 2022—KB5013945 (OS Build 18363.2274)
support.microsoft.com

Can you guys see if that helps?

That's a Windows 10 update.

This issue is specific to Windows Server Essentials 2012 and 2016.

Try it on the workstations accessing it if they don't have the October updates installed?

https://support.microsoft.com/en-us/topic/october-18-2022-kb5020439-os-build-14393-5429-out-of-band-f9840376-4f36-45c3-8dd8-f366c4b884dd

That one for Server 2016

https://support.microsoft.com/en-us/topic/kb5020449-out-of-band-update-for-windows-server-2012-october-17-2022-6910b46a-261c-499e-8e6c-45d7daa053d7 that for 2012

No. This is a server-side issue, not a client or workstation issue.

Try the links to the server patches - they are the server versions of the TLS fixes.

KB5020439 came inside the KB5017396 SSU.

Yes, it's already installed on my machine.

No, it did not help.

That wouldn't be inside the SSU, it would be included in the October security update if you've installed that already.

https://support.microsoft.com/en-us/topic/october-18-2022-kb5020439-os-build-14393-5429-out-of-band-f9840376-4f36-45c3-8dd8-f366c4b884dd
Actually it would be in the November updates. It's not included in the October security updates. It's a specific out of band update that isn't in KB5017396 SSU

And I'm not certain for sure it works, but just saying it may be related as it does fix TLS issues and has impacted other legacy products.

According to the description, "It addresses an issue that might affect some types of Secure Sockets Layer (SSL) and Transport Layer Security (TLS) connections. These connections might have handshake failures. For developers, the affected connections are likely to receive one or more records followed by a partial record with a size of less than 5 bytes within a single input buffer. If the connection fails, your app will receive the error, “SEC_E_ILLEGAL_MESSAGE”."

So even without the patch, I would think curl https://dyndns.domains.live.com/service/livedyndns.asmx would receive something, no? It's just timing out.

Also keep in mind that from the reports I've seen, this broke for everyone on the same day, 11/11 or thereabouts, which would not seem to correspond to a patch release.

Seems to be down again

https://downforeveryoneorjustme.com/remotewebaccess.com

Typically it may take some time for someone at MS to resolve this. I would honestly move away from this as a solution for remote access if this is what your firm relies on.

I'm pretty sure that the downforeveryoenorjustme site is trying to resolve the "root" domain [www.]remotewebaccess.com, which should not necessarily resolve.

I have customername.remotewebaccess.com resolving fine at three sites.

Can you please provide the error logs from the repro setups ?

When do you get this error ?

Can you please provide the error logs from the repro setups ?

When do you get this error ?

We have the same error on two Server 2016 Essentials after installing the September updates.

@Samriddhi Chaturvedi Glancing through my blog post on this issue, I commented on 11/14/2022 that there was an issue with https://dyndns.domains.live.com/service/livedyndns.asmx. When I visit that domain today, it shows that its certificate expired 9/16/2023. I suspect that is related, perhaps the cause.

I tested 4 Server 2016 Essentials I have running this morning, all resolve fine currently. But all 4 have been displaying "The dynamic DNS information cannot be updated" error in their daily reports since Saturday. (the domain name provider cannot be contacted). If you have a dynamic IP address I'd refrain from rebooting your modem or in some cases router unless absolutely necessary. It will break your xxx.remotewebaccess.com getting its updated IP address info if your ISP changes your IP address until this issue is fixed. With Comcast for example, you may or may not get a new IP address. I have CenturyLink fiber and I get a new IP address every single time my router is rebooted.

As mcbsys mentioned, I believe this is the culprit with an expired cert.. https://dyndns.domains.live.com/service/livedyndns.asmx

We re actively looking into this.

Thanks a lot for the pointers. We are actively looking into this issue.

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.

I haven't tried to set up a new WSE 16 box but my existing remotewebaccess domains still seem to be working, though I also pay for no-ip to have a backup dynamic dns.

I have this note I made to myself from Sept of 2022 (the last time I installed WSE16) to add these values via PowerShell but not sure if that would fix it for you.

# PowerShell
New-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v2.0.50727" -Name "SystemDefaultTlsVersions" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v2.0.50727" -Name "SchUseStrongCrypto" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "SystemDefaultTlsVersions" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value 1 -PropertyType DWORD -Force

New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" -Name "SystemDefaultTlsVersions" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" -Name "SchUseStrongCrypto" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name "SystemDefaultTlsVersions" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value 1 -PropertyType DWORD -Force

Also found this post of mine where it looks like I reported a similar inability to register in Nov '22 and Samriddhi Chaturvedi from Microsoft responded resolving it internally:

https://learn.microsoft.com/en-us/answers/questions/1088241/domain-register-and-update-for-remotewebaccess-com?page=2#answers

@ChrisWY27 Thank you for your responses.

Yes, I've already added all of the required .NET Framework registry keys that you've mentioned (and restarted the server), but that makes no difference here. The registry keys do allow the Microsoft (Live) Account to be successfully signed into, but they do not prevent the timeout error from occurring when the domain name setup wizard attempts to communicate with the Microsoft personalized domain name provider service.

For me, the timeout issue appears any time I try to either set up a remotewebaccess.com domain name for the very first time (on a newly setup 2016 Essentials server), or whenever I attempt to change an existing remotewebaccess.com domain name when one has already been set up previously on the Essentials server (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).

Thus, it definitely appears to be an issue taking place over on Microsoft's (back)end to me. I'm just wondering if others are able to reproduce the issue. I have lots of customers running Windows Server 2016 Essentials that are reporting the issue to me, but I'm not seeing anyone else reporting it over here on these Microsoft forums (which seems a bit odd). Thanks again for your input.

My best guess is either not many are changing domains, or there are few users like us freshly installing WSE '16. Perhaps I can spin up a VM later and try to verify the same is happening on my end, though if multiple customers are reporting it to you it's most likely an issue on the Microsoft end. Perhaps @Samriddhi Chaturvedi can chime in if they still work there.

@The Office Maven I found a VM with WSE already installed and attempted to set up a domain name unfortunately also seeing the following:

The error in the Dashboard.log was "The request channel timed out while waiting for a reply".

@ChrisWY27 Yes, that's the (generic timeout) error I'm seeing as well... So it's definitely reproducible by others. Hopefully someone from Microsoft sees this thread and can get the issue resolved for everyone. Thanks again.

Hello Yes, Essentials also stopped working on my Server 2016Essentials since April 4th, 2024. All Netframework registry settings are present

With (Get-ItemProperty "HKLM:SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full").Version the currently installed version is displayed from .net version 4 onwards. With (Get-ItemProperty "HKLM:SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5").Version the currently installed version is displayed from .net version 3.5 onwards. # PowerShell New-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft.NETFramework\v2.0.50727" -Name "SystemDefaultTlsVersions" -Value 1 -PropertyType DWORD -Force New-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft.NETFramework\v2.0.50727" -Name "SchUseStrongCrypto" -Value 1 -PropertyType DWORD -Force New-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft.NETFramework\v4.0.30319" -Name "SystemDefaultTlsVersions" -Value 1 -PropertyType DWORD -Force New-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value 1 -PropertyType DWORD -Force New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft.NETFramework\v2.0.50727" -Name "SystemDefaultTlsVersions" -Value 1 -PropertyType DWORD -Force New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft.NETFramework\v2.0.50727" -Name "SchUseStrongCrypto" -Value 1 -PropertyType DWORD -Force New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft.NETFramework\v4.0.30319" -Name "SystemDefaultTlsVersions" -Value 1 -PropertyType DWORD -Force New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value 1 -PropertyType DWORD -Force v4.5.23026 v4.5.1 -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- ------------ New-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft.NETFramework\v4.5.1" -Name "SystemDefaultTlsVersions" -Value 1 -PropertyType DWORD -Force New-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft.NETFramework\v4.5.1" -Name "SchUseStrongCrypto" -Value 1 -PropertyType DWORD -Force New-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft.NETFramework\v4.5.23026" -Name "SystemDefaultTlsVersions" -Value 1 -PropertyType DWORD -Force New-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft.NETFramework\v4.5.23026" -Name "SchUseStrongCrypto" -Value 1 -PropertyType DWORD -Force

TLS 1.0., 1.1, 1.2 on

The DNS information for the server cannot be updated because it cannot connect to the domain name provider. Contact the domain name provider

Domain Name Provider pleas help Thanks

Still not working its desolating , what a service microsoft gives , shame on microsoft

Samriddhi will look after us.

We are still actively investigating this. Thanks for your patience.

@Samriddhi Chaturvedi apparently the ability to set up a remotewebaccess.com Microsoft personalized domain name is once again broken in the Anywhere Access feature of Windows Server 2016 Essentials. I'm absolutely flabbergasted that you guys cannot keep this feature working. It gets broken (by Microsoft) every few months, and then it takes multiple months to get you guys to become aware of the issue and then finally resolve it again. I've never seen anything like it in all my years of computer programming. It really is quite maddening. I realize that it's not your fault, but you do have to admit that it's more than a bit ridiculous.

Anyway... Attempting to set up a remotewebaccess.com domain name in Essentials is once again producing the generic "unknown error occurred" error message. Looking in the server's Dashboard.log file shows the following error getting logged:

[10188] 241016.081932.7557: 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:System.Web.Services.Protocols.SoapException: Live Dynamic DNS has encountered an internal error.  This error has been logged. ---> System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.

I assume that this has something to do with the fact that Microsoft has now disabled the use of basic authentication in their Live accounts as is mentioned here (although I cannot be sure):

Modern Authentication Methods now needed to continue syncing Outlook Email in non-Microsoft email apps

My understanding is that Windows Server 2016 Essentials is supported until January 12, 2027 and so it would be really nice if this issue could be resolved (again).

Thank you!

Susan,

For the LiveID, isn't there is a modern auth popup when in the wizard?

"Could not establish trust relationship for the SSL/TLS secure channel" sounds to me like an expired certificate or possibly the old TLS version issue. Does the https address appear in the dashboard log? You could also check

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

I even resorted to Wireshark at one time to try to get the failing URL. If you can get the URL, then you could try it in a browser or with curl to get more details on the failure.

None of which is your job! One does wonder why Microsoft can't keep this working as promised.

Hi Mark. Hi Susan. Are you still having issue? I haven't checked my servers yet. There is a good MS tech in this thread that has helped us multiple times in the past. Shall I bring him in?

Hi @Jesse Flintoff and @mcbsys ...

I'm not sure where Susan fits into all of this, but if you guys are referring to me (The Office Maven) then my name is actually Mike. ;-)

Anyway... Yes, it is indeed still broken (and probably will be over and over and over again). I've tried to bring @Samriddhi Chaturvedi in on this thread (again), but if you happen to know of a different MS tech that may be able to help folks out then by all means please do bring them in.

@mcbsys I didn't mean to infer that the disabling of basic authentication was the direct cause for the issue, but rather that it is awful coincidental that the remotewebaccess.com Microsoft personalized domain name configuration process broke in Anywhere Access at nearly the same time as when Microsoft switched off basic auth on their Live accounts (i.e. right around September 16th, 2024 or so) and so it may have something to do with that was all (as it has certainly caused other issues to pop up in Essentials such as the breaking of the emailing of health reports, etc.). Additionally, I do not see the https address listed within any of the Essentials log files. I suppose that I could go interrogate the source code in order to find the address, but I'm not sure that doing so is a good use of my time seeing as even if I do find it there's probably nothing that I can do with it anyway seeing as it would most definitely be something that needs to be corrected over on Microsoft's backend server and not within Essentials itself. I do appreciate your response though.

Lastly, I'll just mention that with the frequency that Microsoft keep busting the remotewebaccess.com Microsoft personalized domain name feature in Essentials, folks should avoid using them like the plague now and just switch over to using their very own custom/vanity domain name instead. I have a step-by-step writeup on how to do just that in Windows Server Essentials (using either a user-purchased SSL certificate or a free Let's Encrypt SSL certificate) posted on my website over here:

How To Manually Set Up A Custom / Vanity Domain Name In Windows Server Essentials

When you manually set up your own domain in Anywhere Access, you are in full control of it, and so you no longer need to worry about things going down over on Microsoft's backend (as you do when relying on a remotewebaccess.com Microsoft personalized domain name). ;-)

Mike, thanks for the follow-up and I apologize for the name mixup. Susan Bradley posted a link to your 10/17 post here and I mistakenly assumed she was the one who had made the post. But she's The Patch Lady and you're The Office Maven. I knew that, honest!

I agree that it's not worth wasting much time on Essentials 2016 features. Fortunately established dynamic DNS still seems to be working. I haven't tried to set it up again. I still have one customer on that, but I'm planning to replace the server as soon as Essentials 2025 is released in the next month or two. Router-based Wireguard for VPN (remote files and RDP), Synology for backup, manual DC configuration... no longer all in one dashboard but hopefully more robust.

Lol sorry Mike.

I get emails but i dont see the latest comments here.

It's like the threads from OfficeMaven have been moved.

You have to sort by newest and not by helpful and then it shows up. OfficeMaven said:

@Samriddhi Chaturvedi apparently the ability to set up a remotewebaccess.com Microsoft personalized domain name is once again broken in the Anywhere Access feature of Windows Server 2016 Essentials. I'm absolutely flabbergasted that you guys cannot keep this feature working. It gets broken (by Microsoft) every few months, and then it takes multiple months to get you guys to become aware of the issue and then finally resolve it again. I've never seen anything like it in all my years of computer programming. It really is quite maddening. I realize that it's not your fault, but you do have to admit that it's more than a bit ridiculous.

Anyway... Attempting to set up a remotewebaccess.com domain name in Essentials is once again producing the generic "unknown error occurred" error message. Looking in the server's Dashboard.log file shows the following error getting logged:

YAMLCopy

[10188]

I assume that this has something to do with the fact that Microsoft has now disabled the use of basic authentication in their Live accounts as is mentioned here (although I cannot be sure):

Modern Authentication Methods now needed to continue syncing Outlook Email in non-Microsoft email apps

My understanding is that Windows Server 2016 Essentials is supported until January 12, 2027 and so it would be really nice if this issue could be resolved (again).

Thank you!

@Jesse Flintoff @m

@mcbsys We are investigating. I totally understand the customer's concern, but we do have lots of internal changes going on and anything which is not security complaint is getting impacted. Server Essentials and Remote Web Access workflows are one of them due to the legacy nature.

Also, we have a contract with GoDaddy to host the remotewebaccess domain and anything going off on that side also impacts us.

That being said, this is being investigated and I very sorry for the bad experience.

But it definitely is good idea for costumers to start exploring other alternatives for the RemoteWebAccess as its super legacy, almost in the end-of-life state with just some minimal extended support.

@mcbsys @Jesse Flintoff : Hi again.

I am very sorry for the poor customer experience. I understand the pain and we are looking into this on priority.

There are lots of moving parts around this workflow and anything going wrong anywhere causes the issues we encounter. We have internal security compliances and if they don't get met, the service gets impacted. We have dependency on external parties like GoDaddy and anything going wrong with that flow could cause an issue.

That being said, WSE and RWA are legacy components and under limited extended end-of-life state with minimal maintenance support. So, it would really be a good idea for customers to start moving to newer and more secured and robust alternatives that Microsoft offers.

Thank you Samriddhi. Very grateful.

Kindest regards

@Samriddhi Chaturvedi Thank you for stepping in here once again. I do want to clarify your advice, though. My understanding is that the only thing that keeps breaking is the remotewebaccess.com process. Sometimes obtaining a certificate fails; sometimes dynamic DNS forwarding fails. The simple solution for that is to buy and install a custom certificate and set up third-party DDNS.

However your comments seem to imply that Remote Web Access itself is unstable? Are we at risk of losing the ability to use the RWA web site for file access? What about the RDS Gateway?

Thank you for your input.

Hi @mcbsys

Sorry if my previous message implied that entire Remote Web Access is unstable.

You are right.

The only problematic workflows are around remotewebaccess.com.

As I mentioned before, there are few parts around this workflow and we do have external dependencies too which we are trying to fix.

But even with that, the WSE product itself is under limited support so moving to alternatives is a wise choice.

Hello @Samriddhi Chaturvedi, unfortunately it seems to be down again.Windows Server 2016. Our Dashboard.log reports:

[9096] 241129.122823.6490: DomainConfigWizard: Next Page: progressPage [5676] 241129.122827.3279: DomainManagerObjectModel: InvokeAsync: action resulted in exception: System.ServiceModel.FaultException1[Microsoft.WindowsServerSolutions.RemoteAccess.Domains.DomainManagerFault]: Il creatore dell'errore non ha specificato Reason. (Dettaglio errore è uguale a DomainManagerFault:[Reason:CommunicationFailure, Message:SubmitCertificateRequest failed, Detail:System.Web.Services.Protocols.SoapException: Live Dynamic DNS has encountered an internal error. This error has been logged. ---> System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure. at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, Exception exception) at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.Check...). [5676] 241129.122827.3279: DomainManagerObjectModel: InvokeAsync: handling exception by transferring to eventArgs [9096] 241129.122827.3299: DomainConfigWizard: Error occurred in Domain Manager Object Model operations: System.ServiceModel.FaultException1[Microsoft.WindowsServerSolutions.RemoteAccess.Domains.DomainManagerFault]: Il creatore dell'errore non ha specificato Reason. (Dettaglio errore è uguale a DomainManagerFault:[Reason:CommunicationFailure, Message:SubmitCertificateRequest failed, Detail:System.Web.Services.Protocols.SoapException: Live Dynamic DNS has encountered an internal error. This error has been logged. ---> System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure. at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, Exception exception) at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.Check...). [9096] 241129.122827.3299: DomainConfigWizard: FailReason from Domain Manager Object Model operations: CommunicationFailure

Could you help us to solve this issue?

Thank you so much

Same for me

The DynDNS service seems to be borked.

It is December 20th, and I'm having the same problem.

Client's SSL certificate apparently expired, which broke adding a machine to the domain and broke remote access. I've been trying for days to get the remote access working. I have a client's certificate expiring in 17 days and another in 42 days.

I am able to register a domain and release a domain (although it throws an error)

What is happening now is that anywhere access quits working after the SSL certificate dies.

I tried a repair and got this:

RetrievedWholeOfferingList:True

[15112] 241220.180941.4855: DomainConfigWizard: Next Page: progressPage

[15112] 241220.180941.4978: DomainConfigWizard: GetAvailableDomainRootsCompleted, Result:remotewebaccess.com

[15112] 241220.180941.4978: DomainConfigWizard: GotoNextPage: from Live_SelectLiveDomainPage to Live_TypeDomainNamePage

[15112] 241220.180948.5958: DomainConfigWizard: CheckDomainAvailabilityCompleted, Result:True

[15112] 241220.180950.9037: DomainConfigWizard: Leaving Page: Live_TypeDomainNamePage

[15112] 241220.180950.9047: DomainConfigWizard: Wizard Model Value: Wizard Model dictionary[CertNotRequired]:False

Wizard Model dictionary[DomainConfigured]:True

Wizard Model dictionary[ConnectedToInternet]:True

Wizard Model dictionary[CertToExpire]:False

Wizard Model dictionary[ReleaseDomain]:False

Wizard Model dictionary[ReconfigWarning]:False

Wizard Model dictionary[OnTransferWarning]:False

Wizard Model dictionary[LiveFlowSignInCancelled]:False

Wizard Model dictionary[DomainNotSupported]:False

Wizard Model dictionary[GitMeFlow]:False

Wizard Model dictionary[LiveFlow]:True

Wizard Model dictionary[OemFlow]:False

Wizard Model dictionary[CreateANewDomain]:True

Wizard Model dictionary[CreateANewDomainForO365]:False

Wizard Model dictionary[ManualConfig]:False

Wizard Model dictionary[OemFlowWithOneProvider]:False

Wizard Model dictionary[IsValidLiveCredential]:True

Wizard Model dictionary[UseExistingButNoDomainRegistered]:False

Wizard Model dictionary[UserOwnsLiveDomains]:True

Wizard Model dictionary[PrivacyAgreed]:True

Wizard Model dictionary[ReachQuota]:False

CurrentOffering:Offering: [Name:Microsoft personalized domain name,Provider:15f4c1c4-44c9-4218-822f-6fe3ca60a262]

DomainRoots:

remotewebaccess.com

DomainNameSuggestions:

UserLiveDomainNames:

********.remotewebaccess.com

****.remotewebaccess.com

****t.remotewebaccess.com

***s.remotewebaccess.com

***i.remotewebaccess.com

***e.remotewebaccess.com

RetrievedWholeOfferingList:True

[15112] 241220.180950.9099: DomainConfigWizard: Next Page: progressPage

[9156] 241220.180954.7965: 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:System.Web.Services.Protocols.SoapException: Live Dynamic DNS has encountered an internal error. This error has been logged. ---> System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.

at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, Exception exception)

at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)

at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)

at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)

at System.Net.Security.SslState.Check...).

[9156] 241220.180954.7965: DomainManagerObjectModel: InvokeAsync: handling exception by transferring to eventArgs

[15112] 241220.180954.8052: 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:System.Web.Services.Protocols.SoapException: Live Dynamic DNS has encountered an internal error. This error has been logged. ---> System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.

at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, Exception exception)

at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)

at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)

at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)

at System.Net.Security.SslState.Check...).

[15112] 241220.180954.8062: DomainConfigWizard: FailReason from Domain Manager Object Model operations: CommunicationFailure

[16240] 241220.181025.1090: DomainManagerObjectModel: Calling KeepAlive for instanceID=1

[16240] 241220.181025.1090: DomainManagerObjectModel: KeepAlive succeeded for instanceID=1

[11304] 241220.181125.1094: DomainManagerObjectModel: Calling KeepAlive for instanceID=1

[11304] 241220.181125.1094: DomainManagerObjectModel: KeepAlive succeeded for instanceID=1

Has been failing since August 2024. Can we somehow escalate this?

We have deployed some changes and see positive results in our test setups. Please give a try and see if RWA looks better on your setups.