Hi Trevor,
I’m following up to check whether the issue has been resolved. Feel free to reply if you need further information. If the information provided was helpful, please click "Accept Answer" to help others in the community. Thank you!
RDS sign-in failures after installing KB5129238 on Server 2019 (17763.9247), resolved only by rollback to 17763.9121
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(201.6, 71%, 29%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ETC%3C/text%3E%3C/svg%3E)
Trevor Cobb
0
Reputation points
Environment:
- Windows Server 2019 Standard, Azure VM
- Single server with RD Session Host, RD Gateway, RD Web Access, Connection Broker and RD Licensing (Per User)
- Users connect through RD Gateway on 443 (RemoteApp via RD Web feed), about 15 concurrent users
Timeline:
- 9/18: Installed KB5122876 (17763.9245). Afterward the server intermittently became unreachable from the internet. Could only resolve (temporarily) by rebooting from Azure console.
- 10/16: Installed out-of-band update KB5129238 (17763.9247).
- 10/19: Users began failing to sign in after signing out. First sign-in works; after sign-out, the next attempt fails.
Symptoms on 17763.9247:
- Errors: “The number of connections to this computer is limited and all connections are in use right now” and “The task you are trying to do can’t be completed because Remote Desktop Services is currently busy.”
- RemoteConnectionManager shows Event 1149 (authentication succeeded) for each attempt.
- LocalSessionManager shows Event 41 (Begin session arbitration) with no matching Event 42 (End session arbitration), followed by Event 40 (disconnected, reason code 12).
- qwinsta showed only 2 active RDP sessions while the server reported the connection limit (MaxInstanceCount 10) as reached.
- Sessions could not be logged off from Task Manager or logoff.
- Reboot restored access for only a few minutes once users began signing in and out.
- Event 59 in LocalSessionManager logged unformatted strings (“%s from %S( #0x%x/0x%x )”).
What we tried:
- Raising MaxInstanceCount restored access temporarily; sign-ins eventually failed again with “Remote Desktop Services is currently busy.”
- Verified role, licensing mode and services were normal.
- Removed KB5129238, then KB5122876 via DISM. The second removal stalled in TiWorker and completed on reboot. Server is now on 17763.9121 (August, KB5120238) and stable so far.
Questions:
- Is anyone else still seeing RDS sign-in failures on Server 2019 after KB5129238, or after the October CU KB5126651? Is there a Known Issue Rollback or other workaround that applies to builds 17763.9247 / 17763.9376? Has Microsoft acknowledged the issue persisting after the out-of-band fix?
Windows for business | Windows Client for IT Pros | User experience | Remote desktop services and terminal services
2 answers
Sort by: Most helpful
-
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(172.8, 86%, 26%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJN%3C/text%3E%3C/svg%3E)
Jason Nguyen Tran 29,630 Reputation points Independent Advisor2026-10-23T16:18:28.5966667+00:00 -
Jason Nguyen Tran 29,630 Reputation points Independent Advisor
2026-10-20T22:57:02.3866667+00:00 Hi Trevor,
Based on your findings, the fact that Event ID 1149 (successful authentication) is logged while Event ID 41 (Begin session arbitration) is not followed by Event ID 42 (End session arbitration) suggests the failure is occurring during session creation rather than authentication or licensing. The behavior you described, particularly the "all connections are in use" and "Remote Desktop Services is currently busy" messages despite only a few active sessions, makes me suspect that disconnected or orphaned session objects are accumulating and preventing new sessions from being established.
The most compelling data point is that the issue disappears after rolling back to 17763.9121 and returns on 17763.9247, which indicates a strong correlation with the September/October servicing updates. I would recommend continuing to monitor the RemoteConnectionManager, LocalSessionManager, and TerminalServices-RemoteConnectionManager logs to identify whether session arbitration resources continue to become stuck over time. It would also be worthwhile to collect a User Mode dump of the TermService process and review session counts through PowerShell and
qwinstawhen the issue is actively occurring.At this time, I am not aware of a publicly documented Known Issue Rollback specifically covering the symptoms you've described, but given the reproducibility and the rollback results, I would encourage opening a support case and providing the event logs, dump files, and build comparison details. The unformatted Event ID 59 messages may also be an important clue pointing to an issue in the RDS session management components introduced in the newer builds.
For now, remaining on the last known stable build while gathering diagnostics appears to be the lowest-risk approach. Your testing has already done an excellent job of isolating the trigger.
I hope this helps provide some direction. If you find this answer helpful, please hit "accept answer" so I know it addressed your concern.
Jason