Microsoft’s October 6 support notice explains that RD Web Access relies on browser-side XSLT to render its interface. When that functionality is disabled in Edge or Chrome, the page can fail to display. The notice applies to Windows Server 2016, 2019, 2022 and 2025.
The company lists temporary alternatives, including its HTML5 web client, and says a fix is being developed. Restoring a browser capability is also described as a workaround, not a permanent resolution. The documented failure concerns the web interface; it is not evidence that every remote desktop service has stopped operating.
NAOAT analysis
This distinction matters during incident triage. If the portal fails, support staff should establish whether the problem is finding the published resource, authenticating, or opening the remote session itself. Those stages can involve different components and owners. Treating every symptom as a server outage can lead a team to change a functioning service while overlooking a client-side dependency.
A useful compatibility exercise would start from a managed employee device with the intended future browser configuration. The tester would sign in, locate an authorized application and complete an ordinary task through the supported access route. Repeating the exercise with representative user roles would reveal whether the alternative works beyond an administrator’s account.
Any temporary exception should have a named owner and a removal condition tied to the eventual resolution. Otherwise, a short-term compatibility measure can become an undocumented part of the environment. The employee-facing instructions should identify the approved route and the precise point at which to contact support, without asking staff to alter browser security settings themselves. For technology teams, the broader lesson is to include the access experience in service testing: a healthy backend is not enough if users cannot reach it through their supported tools.