"The remote session was disconnected because there are no Terminal Server License Servers available to provide a license." A local RDS client failure on a multi-session VDA creates a critical "Black Hole" routing gap in CVAD (2507 CU1 and prior). Because the ⁠BrokerAgent⁠ remains ⁠Registered⁠ while the OS natively drops incoming sessions, the DDC relentlessly routes new user traffic to this artificially "empty" machine. Request for VDA improvement: The VDA must natively detect its local RDS stack failures and auto-isolate out-of-the-box to prevent users from continually hitting. I'm sharing this here because it's the best place to reach Citrix (vendor) people who care about it and will fix it in the next product release.

There are custom scripts to check the rds license state and if it's not green, the VDA puts in maintenance-mode. But I agree, would be nice for the future to let the vda check itself.

Where I can find it ? RDS licensing is a basic functionality for RDSH, and it really should have a native VDA health check.

How are you all handling the RDS license server as a single point of failure in 2026? Any better ways than cold standby or splitting CALs across multiple servers?

It's not about CALs, it's about non functioning RDS services after OS reboot… it works fine immediately after another reboot. 🤷‍♂️😉 (daily reboot for RDSH) Probably some kind of BUG in MS OS - it happens for me once per 2-3 months with 200 servers

It's been an issue since forever 😔

Time to fix it 😉

Just so I understand the request, are you suggesting such servers be unregistered when RDS CAL licenses expire and/or server is unavailable and gets flagged for at least one user? Just based on past experience, doing something like this is very tricky because there could be legitimate instances of RDS CAL licenses being exhausted at the time a user tries to launch a session. Marking that particular machine as unavailable could result in underutilization. For instance, say RDS CAL licenses become available because some users logged off after say a few minutes of the VDA being unregistered (made unavailable for future connections), there is no definitive way for the Broker to get it in registered state other than some form of polling mechanism/restart of desktop services on the VDA.

Adding a couple of points that strengthen the case. First: the signal isn’t missing. Director already surfaces these as Connection Failures, with reason codes per machine, and the Monitoring Service exposes them via OData (ConnectionFailureLogs). The data is being collected, persisted in the Monitor DB, and rendered in your own UI in near real-time. What’s missing is closing the loop from that telemetry back to Broker behavior. Today operators correlate Director failures to a machine and run Set-BrokerMachine -InMaintenanceMode by hand - or build a watchdog against your own OData API to do it for them, which is exactly what we ended up doing. That reframes the ask: it’s not “Broker needs new observability,” it’s “the Broker should react to telemetry the platform already produces.” That also dissolves the underutilization concern from your original reply — the trigger isn’t a single transient CAL miss, it’s a sustained failure pattern already visible to anyone with Director open. A threshold (N failures in window M, filtered by failure type) gives admins the safety margin against false positives that you were concerned about. Second, and more important: the scope is broader than RDS CAL. The pattern we’re describing recurs across multiple failure classes. In our environment (around 200 multi-session VDAs) we see roughly once every 2–3 months an OS-level fault that puts a server into a zombie state — BrokerAgent keeps heartbeating so the machine stays Registered/Available, but no session can be established via Citrix or RDP, and only a hard reboot recovers it. Different root cause from the post-reboot RDS deadlock we discussed earlier, but identical from the Broker’s perspective: machine state says Available, every launch fails, Director shows the connection failures, and the Broker keeps routing users into a black hole. The underlying issue is structural: the Broker treats registration as a proxy for “this VDA can serve sessions,” and registration only proves “BrokerAgent is alive and reachable on its IPC channel.” It says nothing about whether the OS, RDS stack, listener, profile subsystem, FSLogix mount, or any other component on the launch path actually works. That’s why every customer at scale eventually builds the same external watchdog against your Monitoring OData - we’re papering over a gap in the Broker’s health model. Closing the loop - letting Director’s connection-failure telemetry feed back into broker scheduling, with a thresholded soft-quarantine state and an explicit recovery probe - fixes both failure classes with one mechanism, and any future failure mode that manifests the same way without modelling it explicitly. That’s the version of this feature that pays back its engineering cost, and it directly addresses every concern in your earlier reply: transient vs persistent (threshold), underutilization (already-visible sustained pattern, not a single failure), and recovery without polling/service restart (positive health probe before lifting quarantine, over the channel already open).

Nicely articulated Arthur, in short put in maintenance a VDA that is showing a high number of failures. that's what we've been doing manually forever.

Time to fix it 😉

Thanks Arthur. Appreciate you elaborating on the issue and providing some clarifications. Let me relay this feedback to some folks internally.

Thanks for the details @Arthur! It certainly makes sense to put a malfunctioning VDA in maintenance mode, or some other state that would remove it from the brokering pool to avoid the "black hole". If the root cause is lack of RDS CALs, then basically every multi-session VDA would have to be put in maintenance mode since every VDA would potentially face the same problem. But if the issue is machine-specific, like an OS-level problem, RDS stack, etc., then looking at the VDA-specific launch failures and putting it in maintenance mode makes perfect sense. So I believe the two high level causes need to be treated separately. That being said... Do you have an ATS you can work with to submit an RFE for this? Saurabh and I can help with providing additional context in the ticket and explaining to the various relevant teams internally