Windows Server November 2026 Updates Fix RD Web Access Ahead of Chrome XSLT Retirement

For administrators, the important distinction is patch the server hosting RD Web Access—not merely the browser on the employee’s PC. There is also a versioning trap: KB5131080 is the Windows Server 2025 update, not a universal package for every affected Server release. Older versions have their own updates.

What breaks—and what the update changes​

Microsoft’s advisory, KB5130994, was originally published on October 6, 2026. It covers Windows Server 2016, 2019, 2022, and 2025, and describes a failure in the classic Remote Desktop Services RD Web Access website when browser policy disables Extensible Stylesheet Language Transformations, or XSLT.

The recognizable symptom is “Unable to display RD Web Access,” followed by a message explaining that an unexpected error prevents the page from displaying correctly. The underlying problem is specific: the classic interface asks the browser to transform XML-based content into the visible portal. Without browser-side XSLT processing, that transformation cannot happen.

This is not a report that Windows Server crashes, that Remote Desktop Protocol stops working, or that every existing remote session disconnects. Microsoft’s documented failure concerns the website used to reach remote resources. That distinction matters when troubleshooting: an inaccessible portal is a serious interruption, but it is not evidence that the entire Remote Desktop Services deployment has failed.

The November update changes where the rendering happens. Microsoft’s release notes say RD Web Access pages are now rendered on the server and no longer require browser XSLT support. Rather than asking administrators to preserve an aging browser capability indefinitely, the fix removes that capability from the portal’s requirements.

The practical implication is straightforward: a successful repair should work with browser XSLT disabled. A portal that loads only while a temporary enablement policy remains active has not yet demonstrated that the dependency has been eliminated in that deployment. This is the acceptance test administrators should build around Microsoft’s stated change.

Chrome’s deadline is not Edge’s deadline​

Google’s published schedule places the Chrome 158 Stable change on November 17, 2026, seven days after the November 10 Windows security updates. XSLT stops functioning by default for users outside the Origin Trial and Enterprise Policy exceptions. That makes the date a deployment deadline to plan around, not a guarantee that every Chrome installation loses functionality simultaneously.

There is an important additional distinction for mixed-browser organizations. Microsoft’s Edge compatibility documentation lists XSLT deprecation for Edge 159, with the change appearing in Edge Canary, Dev, and Beta at version 157. Administrators should not apply Chrome’s version number and calendar date wholesale to Edge. Both browsers are affected by the same dependency, but their release boundaries differ.

Nor does a later browser rollout guarantee that an organization is unaffected today. Microsoft’s RD Web Access advisory explicitly covers environments where XSLT has already been disabled through policy. A hardened browser configuration can therefore expose the problem before a browser’s default changes.

Google describes the retirement as a browser-security measure and identifies two affected mechanisms: the XSLTProcessor JavaScript API and XSLT processing instructions. It is removing browser-native XSLT, not XML itself. The published Chrome plan also ends the temporary Origin Trial and Enterprise Policy exceptions with Chrome 176 on August 17, 2027.

The takeaway: treat policy exceptions as a bridge to a repaired application, not as a permanent compatibility strategy.

Match the update to the Windows Server version​

Microsoft’s November Server image listing provides the following cumulative-update mapping. These are OS-specific packages, not interchangeable downloads.

Microsoft’s release notes for Server 2016 and Server 2019 also explicitly describe the RD Web Access change to server-side rendering. The broader advisory names all four Server releases and directs administrators to install the November security update or a later applicable update.

Use that table to orient an inventory, not to bypass package applicability checks. The Marketplace listing includes distinct Azure Edition Hotpatch entries, so administrators managing those configurations should confirm their servicing path rather than assuming the standard image’s build is the only valid result.

For Server 2025, Microsoft lists Windows Update, Windows Update for Business, Microsoft Update Catalog, and Windows Server Update Services as delivery channels. Its standalone installation instructions also identify checkpoint cumulative-update requirements. Manual installation should therefore follow the applicable package sequence, rather than assuming that downloading one MSU always completes the job.

A practical deployment and validation plan​

The following is an operational checklist based on Microsoft’s resolution, rather than a claim of firsthand testing.

1. Identify the actual RD Web Access hosts. Record their Windows Server releases and whether the classic portal has been customized. Microsoft’s advisory covers Server 2016 through Server 2025 and separately flags customized deployments for additional attention.
2. Record existing browser workarounds. Identify where XSLT was re-enabled and where users were redirected to IE mode or an HTML5 client. Microsoft recommends installing the server update even when one of those workarounds is already keeping users connected.
3. Deploy the applicable November update or a later update. Match the package to the host OS and use the organization’s normal servicing process. KB5131080 belongs to Server 2025; it is not the package to approve indiscriminately across older Server releases.
4. Test using the managed browsers employees actually use. As an acceptance test, open the classic portal with XSLT disabled, sign in, and attempt to launch a representative published resource. The page should render without the documented error; testing a launch also checks the user journey beyond the repaired page. This is recommended validation of Microsoft’s server-side fix, not an assertion that the update repairs unrelated connection problems.
5. Retire the XSLT exception after validation. Microsoft explicitly says that administrators who re-enabled XSLT as a workaround should disable it again after installing the update. Retest afterward so that the exception is not silently masking an incomplete deployment.

A browser warning disappearing is not as useful an acceptance criterion as a working portal under the intended security configuration. The goal is compatibility without retaining the old dependency.

If patching must wait: three temporary routes​

Microsoft documents three interim approaches. Each addresses access while administrators arrange the server update; none replaces the update itself.

1. Temporarily re-enable XSLT​

On an affected Windows client, Microsoft provides these commands for an elevated Command Prompt. Run the command for the browser requiring the exception.

For Microsoft Edge:

reg add "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v XSLTEnabled /t REG_DWORD /d 1 /f

For Google Chrome:

reg add "HKLM\SOFTWARE\Policies\Google\Chrome" /v XSLTEnabled /t REG_DWORD /d 1 /f

Restart the relevant browser, reopen the portal, and confirm that it loads. Microsoft also documents Group Policy as an alternative way to configure the workaround. These are client-browser settings, whereas the lasting repair is installed on the server.

Microsoft’s Edge policy documentation names the setting Control the availability of the XSLT feature, under Administrative Templates/Microsoft Edge. It is supported on Windows beginning with Edge 147. Enabled makes XSLT available regardless of the browser default; Disabled makes it unavailable; leaving it unconfigured delegates availability to the browser default and applicable field trials.

That distinction matters when cleaning up. Removing an explicit enablement is not necessarily identical to explicitly disabling XSLT while a browser version still enables it by default. Use the organization’s intended policy state and verify the result. Microsoft labels the Edge policy temporary, and its compatibility guidance plans to end the mitigation in Edge 176.

2. Use an already-deployed HTML5 web client​

Microsoft identifies the HTML5 Remote Desktop web client as another route to remote resources. This requires an available web-client deployment; changing a bookmark does not install that service. The advisory distinguishes web-client setup from the steps users take to access it.

For an environment where it is configured:

1. Open the organization’s HTML5 client. Microsoft’s example uses the path /RDWeb/webclient/index.html.
2. Sign in.
3. Start the remote session in the browser, or choose the RDP-file download option.
4. To download, open Settings in the upper-right corner, select Download the rdp file, and select OK.
5. Locate the downloaded file in Downloads.

This is an alternative access route, not proof that the classic RD Web Access page has been fixed. Keep that distinction clear in help-desk instructions.

3. Use Microsoft Edge in Internet Explorer mode​

Microsoft’s documented fallback is to open the RD Web portal through Edge’s IE mode:

1. In Edge, open Settings and more (…) > Settings > Default browser.
2. Under Internet Explorer compatibility, set Allow sites to be reloaded in Internet Explorer mode (IE mode) to Allow.
3. Beside Internet Explorer mode pages, select Add and enter the organization’s RD Web URL.
4. Restart Edge if prompted, then open the portal.

Microsoft notes that the first visit may request ActiveX permission. For this known RD Web portal, its procedure says allowing that functionality enables single sign-on using the signed-in user’s credentials. This is specific to the documented workaround—not a general recommendation to approve ActiveX prompts on unfamiliar websites.

Customized portals and update caveats​

Customized RD Web Access installations deserve their own validation pass. Microsoft explicitly directs administrators with customizations to additional customization guidance, but the advisory does not establish that every modified page will continue working unchanged. Accordingly, do not treat a successful test of a stock portal as evidence that a customized production deployment is ready.

The sensible operational approach is to record the customizations before deployment and test the pages and resource-launch paths users depend on afterward. This is a precaution based on Microsoft’s caveat, not evidence that all customizations break or that a particular file must be replaced.

There is also a separate Server 2025 servicing consideration. Microsoft’s KB5131080 documentation identifies a known issue in which certain activation and licensing operations using slmgr.vbs can fail with error 0x80041008. The documented examples include /skms-domain and /ipk. Microsoft says already-activated devices remain activated and identifies a workaround available through Microsoft Support for business.

For administrators, that means including activation automation in the deployment review where relevant—not assuming the RD Web Access fix is defective, or that all activated servers lose their licenses.

The bottom line​

This is a targeted compatibility repair with a clear operational payoff: the classic RD Web Access portal no longer needs browser-side XSLT once the applicable server update is installed. It covers Windows Server 2016, 2019, 2022, and 2025, but requires the correct update for each release.

Prioritize the affected hosts, validate the portal with XSLT disabled, and remove temporary exceptions only after that test succeeds. Chrome’s November 17 transition supplies the immediate scheduling pressure; the better long-term outcome is a remote-access portal that no longer depends on keeping a retiring browser feature alive.