Chromium Will Break Windows Server RD Web Access in November 2026 — And Your Monitoring Won't See It Coming

Microsoft has confirmed that a mid-November 2026 change to Chromium — the engine behind Google Chrome and Microsoft Edge — will stop the classic RD Web Access portal on Windows Server from rendering. Users open the same URL they use every morning to launch RemoteApps and remote desktops, and the page comes up blank or broken.

Here's what makes this one nasty: nothing on the server actually breaks. IIS serves the page. The TLS handshake completes. The RD Web Access role and its app pool are running. Ping is green. The failure happens in the browser, rolled out silently via auto-update to your endpoints — and your current monitoring stack is structurally incapable of catching it.

This is exactly the class of incident that separates monitoring that watches green lights from monitoring that watches what users actually experience.

What's Actually Happening

The classic RD Web Access role (RDS-Web-Access) renders its portal pages using XSLT — XSL transformations executed in the browser by the XSLTProcessor API. Chromium has been deprecating XSLT for years; it's a legacy API with minimal modern usage and real security baggage. With the mid-November 2026 release cycle, Edge and Chrome drop it.

The moment a user's browser updates past that build, the RDWeb portal stops rendering. The server logs show success. HTTP returns 200. Nothing in any server-side log, event viewer entry, or service state says anything is wrong — because on the server, nothing is wrong.

Microsoft's mitigations, covered in detail over at 4sysops:

1. Re-enable XSLT via enterprise policy in Edge/Chrome (a lifeline, not a destination)
2. Move to Microsoft's modern HTML5 web client
3. Configure Edge's Internet Explorer mode for the portal URL

Why Your Current Tools Will Miss It

Picture a Monday in mid-November 2026, 8:12 AM. The first users hit the portal.

• Your RMM — ConnectWise, Ninja, Datto, pick one — checks that IIS is running, that the RD Web Access app pool isn't stopped, that w3wp.exe is alive. All green.
• Your standalone uptime tool does an HTTP check against https://rds.company.com/RDWeb and expects a 200. It gets a 200. Green.
• Your classic monitor pings the server and checks port 443. Green.
• Nowhere in that stack does anything assert the only thing that matters here: does this page actually render the app list a human needs?

Then the helpdesk fills up. "The remote apps page is blank." A tech remotes into a user's machine, opens the portal: blank. Checks the server: everything green. Escalates. Someone suspects DNS. Someone suspects the certificate. Someone reboots the collection server. Two to four hours later, someone opens the portal in Firefox — which still supports XSLT, for now — and the page renders. Now you're in "works on my machine" purgatory, because Chrome and Edge roll the update out across your fleet over several days. Ticket #14: "It works on my laptop but not my desktop." That's not a bug. That's a client-side platform change masquerading as an intermittent fault.

Why the gaps exist:

• Siloed architecture. The RMM owns "services." The uptime tool owns "URL up." The helpdesk owns tickets. None of them share state, so nobody correlates "all server checks green + sudden spike in blank-page tickets for rds.company.com."
• Legacy availability assumptions. HTTP 200 meant "it works" in 2010. In 2026, availability means the page renders the Work Resources list in the browsers your users actually use.
• No client-side visibility. The breaking change ships through Chrome and Edge auto-updates on endpoints. If you don't track browser versions across your estate — or your clients' estates — you can't even see the countdown.
• No deadline awareness. This breakage has a date on it: mid-November 2026. A known, dated change is the most preventable category of incident there is — but only if your tooling tracks changes and deadlines instead of just current state.

The business impact, for an org running RemoteApps for a few hundred users: the portal going blank is functionally a full outage of app delivery, even though "the server is up." Two to four hours of detection by user ticket, another hour or two of misdiagnosis, an SLA breach on every session-based workload, and a helpdesk that's burned for the day. For an MSP, multiply by every client with an RDS deployment — and be honest, do you have a clean inventory of which clients still run classic RDWeb versus the HTML5 client? Most don't.

How AlertMonitor Closes the Gap

Content-aware application checks, not just port checks. In AlertMonitor, an application/URL monitor asserts on page content — the RDWeb work-resources page must contain a known marker string. When Chromium eats XSLT and the page blanks out, the content assertion fails at the next check interval and the on-call tech is paged with the exact URL and the exact assertion that failed. Detection in minutes, not after 30 tickets.

One alert stream, correlated. The RDWeb content check, the IIS app pool state, the RD Web Access service, and the portal's TLS certificate expiry all live in the same platform and the same alert stream. When the content check fails while every service check stays green, the correlation itself is the diagnosis: server fine, rendering broken — look at browsers, not the server.

Endpoint and browser visibility. AlertMonitor's RMM inventory tracks Edge and Chrome versions across workstations and servers, per site and per client. When a Chromium build with XSLT removed starts landing, you see the version drift and know the clock has started — instead of discovering it through ticket volume.

Helpdesk in the loop. When a user still files "portal blank," the ticket links to the failing check and its history. The tech sees "content assertion failing since 08:05, server checks green, runbook attached," and resolves in minutes. Detection, diagnosis, and remediation in one product instead of five tabs.

MSP reality check. Clone the synthetic check per client, and every client's RDWeb URL shows on one NOC dashboard. Answering "which of my 40 clients is exposed in November 2026" becomes a filter, not a research project.

The old way versus the AlertMonitor way, concretely:

• Old: 08:12 first blank page → 08:40 enough tickets to notice → 10:30 someone figures out it's browser-side → 13:00 mitigation deployed. That's nearly five hours of downtime, most of it diagnostic.
• AlertMonitor: 08:05 scheduled content check fails → 08:06 on-call paged with runbook → 08:25 IE-mode policy pushed or HTML5 client URL communicated. Most users never notice.

Practical Steps You Can Take This Week

1. Inventory where classic RD Web Access actually runs

# Find servers with the classic RD Web Access role installed
Get-WindowsFeature -Name RDS-Web-Access |
    Where-Object { $_.Installed } |
    Select-Object Name, DisplayName, PSComputerName

Run this across your estate — or per client, if you're an MSP. That output is your blast radius for November 2026.

2. Establish what a "good" portal page looks like

You can't alert on a broken render without knowing what a healthy one contains. Capture a stable marker string from the page your users land on:

$response = Invoke-WebRequest -Uri "https://rds.company.com/RDWeb/Pages/en-US/login.aspx" -UseBasicParsing
$response.StatusCode
# Pick a stable marker string from the rendered portal (e.g. the app-list heading)
$response.Content -match "Work Resources"

Note: the page that actually breaks is the post-login app list, so your production check should be an authenticated one. In AlertMonitor, turn this into a content assertion on a five-minute schedule: URL reachable AND body contains marker. A 200 with a blank render fails the assertion and pages someone.

3. Track the Chromium countdown across your endpoints

# Report installed Edge/Chrome versions — push via RMM to every endpoint
$exePaths = @(
    "$env:ProgramFiles\Microsoft\Edge\Application\msedge.exe",
    "${env:ProgramFiles(x86)}\Microsoft\Edge\Application\msedge.exe",
    "$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
    "${env:ProgramFiles(x86)}\Google\Chrome\Application\chrome.exe"
)
foreach ($exe in $exePaths) {
    if (Test-Path $exe) {
        [PSCustomObject]@{
            Computer = $env:COMPUTERNAME
            Browser  = Split-Path $exe -Leaf
            Version  = (Get-Item $exe).VersionInfo.ProductVersion
        }
    }
}

Feed the results into your patch and inventory view, and flag when any fleet segment hits a Chromium build with XSLT removed. That's your early-warning system — the difference between a planned migration and an outage.

4. Deploy the HTML5 web client — the real fix

On the RD Connection Broker:

Install-Module -Name RDWebClientManagement
Install-RDWebClientPackage
Import-RDWebClientBrokerCert "C:\RDWebClient\RDWebClientBrokerCert.cer"
Publish-RDWebClientPackage -Type Production -Latest

The HTML5 client at /RDWeb/webclient doesn't depend on XSLT and is Microsoft's strategic path. Pilot with a test group first, then communicate the new URL before November, not after.

5. Bridge tactics if you must stay on classic RDWeb

Re-enable XSLT via enterprise policy for your managed browsers — check the current Microsoft and Chromium enterprise documentation for the exact policy name and its expiry window, because it's a lifeline, not a destination. Or put the portal into Edge IE mode via your site list:

xml IE11

6. Put the check into AlertMonitor before the deadline, not after the outage

• Application/URL check: RDWeb login and work-resources URL, content assertion, five-minute interval
• Service checks: W3SVC, IIS admin service, RD Web Access app pool
• Certificate expiry alerting on the portal cert — don't trade one browser-blocking surprise for another
• Alert routing with escalation and a runbook link attached to the check
• If you're an MSP: clone per client, one NOC view, done

The Bigger Lesson

The most dangerous failures of 2026 aren't servers dying — they're green lights lying. Platform changes land on the client while the server side stays spotless, and legacy monitoring that equates "HTTP 200" with "it works" reports everything as healthy while your users stare at a blank page.

The fix is structural, not tactical: monitor what users actually experience (page content, not just status codes), watch the endpoint changes — like browser auto-updates — that detonate these failures, and run server state, user-facing state, and tickets through one alert stream so correlation happens in seconds instead of hours. That's the entire thesis behind unified monitoring: when something breaks at 08:05, the right person knows by 08:06 — before the first ticket, not forty minutes and thirty tickets later.

Mid-November 2026 is coming either way. The only question is whether you find out from a dashboard or from an angry user.

Related Resources

AlertMonitor Infrastructure & Server Monitoring AlertMonitor Platform Overview Book a Demo Infrastructure & Server Monitoring Resources