RDS Connection Broker Failed to Redirect User (Event 1306): Diagnose the Redirection Path

What Event 1306 actually tells you

Event 1306 is a redirection failure, not a complete root-cause diagnosis. Published support cases show that similar 1306 symptoms can occur at different points around broker selection and client redirection. That distinction matters: changing licensing, certificates, firewall rules and broker configuration all at once can hide the original failure.

The useful evidence is the correlated event text and hop progression. Nearby event IDs such as 1301, 801 or 1296 can be useful clues in a particular provider/log/version, but do not turn those numbers into a universal RDS state machine. Preserve their full messages and the 1306 Error field exactly; values such as The parameter is incorrect, NULL or another value require evidence from the same attempt.

Fix path #1 — test the RDP file generated by RD Web

If a manually created RDP connection fails, download the collection's RDP file from RD Web and test that file unchanged. Collection-generated files carry redirection metadata that a generic RDP file may not reproduce correctly.

Verify: If the RD Web file redirects correctly but your manually created file does not, compare the files and focus on collection/redirection properties rather than rebuilding the RDS roles.

Fix path #2 — verify the selected target from the same RDS path

From the relevant RDS infrastructure, verify that the target reported by the broker resolves to the expected address and that the Session Host is healthy/available in the collection. Test from the network context that matters to the deployment. A successful direct RDP test from an admin workstation proves only that direct path; it does not prove RD Web/Gateway/load balancer/Broker redirection is healthy.

Verify: Compare resolution with the target information recorded for the same failed attempt, then correlate whether the Session Host logged/received that attempt. Do not “fix” DNS by adding arbitrary hosts-file entries unless you understand why normal resolution is wrong.

Fix path #3 — check the collection before changing DefaultTsvUrl

Older RDS troubleshooting discussions often recommend a DefaultTsvUrl registry value. Treat that as a targeted configuration check, not a universal Event 1306 fix. First confirm that the client is intended to connect through a collection and that the collection-generated RDP file contains the expected connection hint.

Fix path #4 — trace the same attempt across Broker, Gateway/load balancer and Session Host

Use the timestamp of Event 1306 to inspect the broker and intended Session Host, plus RD Gateway/load-balancer/HA components when they are actually in the connection path. If the broker selected a target but the target has no corresponding activity, the missing hop is useful evidence. If the Session Host receives the connection and rejects it, stop treating Event 1306 as the only problem and troubleshoot that later-stage rejection.

Also separate authentication success from redirection success. A user can authenticate successfully and still fail during collection routing. In Connection Broker HA, record which broker node handled the attempt and whether the failure follows one node or the shared deployment.

Still not fixed? Capture this evidence

Why this guide targets Event 1306 specifically

Generic “Remote Desktop not working” advice is too broad for this failure. Event 1306 sits inside the RDS redirection path, so the fastest diagnosis comes from identifying how far the connection progressed. That lets you separate client/collection metadata, broker processing, name resolution and Session Host acceptance instead of treating them as one problem.

References