Historical note on how RD Connection Broker redirection worked in Windows Server 2012 VDI deployments and why direct RDP behaviour changed once the broker was tied to a virtual desktop pool.
This post was originally far too thin. The underlying point is still worth preserving for administrators reading old RDS designs or supporting the final wave of Windows Server 2012 ESU environments.
Beginning: what changed in RDS 2012
In Windows Server 2008 R2, redirection logic in many RDS designs was closely associated with the session host layer. In Windows Server 2012, Microsoft pushed more of that behaviour into the RD Connection Broker. That mattered most in VDI-style deployments where the broker needed to steer users into the correct virtual desktop pool.
Middle: how the redirection setting worked
The historical configuration point was the DefaultTsvUrl value under:
HKLM\SYSTEM\CurrentControlSet\Control\TerminalServer\ClusterSettings
An example value looked like this:
tsv://VMResource.1.Virtualpool1
That setting told the broker which VDI resource to use when a matching connection arrived. In other words, the broker stopped being just a management component and became part of the user-routing path.
The operational side effect was easy to miss. Once the broker was configured for pool redirection, an ordinary RDP session to the broker name could redirect you into the virtual desktop pool instead of landing you on the broker server itself.
End: the practical admin takeaway
If you needed to administer the broker directly after enabling this behaviour, the usual workaround was to open the connection with:
mstsc /admin
That avoided the normal redirection path and let you reach the broker for maintenance.
Closing thoughts
This is no longer current design guidance, but it is a useful historical note because it explains a behaviour that confused a lot of administrators at the time. The redirection was not random. It was a consequence of tying the broker to the pool.
