It worked all month. Then Windows updated on Tuesday night, and by morning the extra RDP sessions were dead and the office was queuing at one desk. This monthly cycle is the real price of patch-based multi-session setups — here is the mechanism, and the maths that ends it.
Ask any office running a patched multi-session setup about their worst recurring IT moment and you will hear the same story with the same date: the morning after Patch Tuesday. This is not rotten luck or a bad update. It is the predictable collision between how Windows is serviced and how the patch works — and it repeats on a schedule Microsoft publishes in advance.
The cycle, as offices live it. Every element of the timeline is structural, not accidental.
Modern Windows updates are cumulative: one package services the whole operating system, including the Remote Desktop stack. When an update ships a new build of termsrv.dll — the component that enforces the session limit — the file on disk changes. Patch tools like RDP Wrapper depend on a configuration matched to the exact previous build: new build, no match, and the setup reports the version as unsupported, the listener misbehaves, or sessions quietly revert to one.
Microsoft is not sabotaging anyone; it is servicing its own component. The patch chose to live inside that servicing path.
The failure announces itself at the worst time, in recognisable shapes:
Recovery waits on volunteers publishing a configuration for the new build. That wait is measured in days on good months, and it is not a service level any business should accept for the machine it runs on.
Faced with monthly breakage, offices drift into the worst available bargain: postponing or blocking Windows updates to protect the patch. Understand what is being traded away. Remote Desktop has a history of severe, remotely exploitable flaws — the BlueKeep era taught the whole industry what an unpatched RDP service invites. An office that freezes updates on its most important PC is not avoiding a cost; it is swapping a known, scheduled inconvenience for an unknown, unscheduled breach, and quietly accumulating every other unpatched flaw in the OS at the same time.
Put rough numbers on a year of the cycle:
Against a one-time purchase of Windows Server plus RDS CALs, sized to your actual headcount. For a growing office the crossover usually arrives inside the first year. The licensing guide in this series shows exactly what that purchase consists of.
Sometimes the patch is inherited and the budget lands next quarter. Until then: control the calendar instead of letting it control you. Apply updates manually at a chosen hour (end of a working day, never the night before month-end), keep a tested backup of the machine's data that exists independently of that PC, warn staff that the morning after update day may start single-session, and keep the Server migration paperwork moving. A patch with an exit plan is a bridge; a patch without one is a landlord.
Watch the video walkthrough of multi-user RDP, then weigh its patch route against the monthly reality described here.
▶️ Watch Full VideoNo — not in any supported way. Windows updates are cumulative: the serviced components arrive as one package, and picking pieces out is not offered. You either take the update and re-break the patch, or delay the update and carry the security risk.
It depends on volunteers publishing a configuration for the new Windows build — commonly days, sometimes weeks, and for unusual builds possibly never. There is no schedule and nobody to call.
No. On Windows Server, multiple sessions are the licensed, tested feature, so updates are built and validated around them. Patch Tuesday on an RDS server is routine maintenance, not a monthly outage.