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. Microsoft Q&A reports show it can appear after successful authentication and even after the Connection Broker has selected a target Session Host. That distinction matters: changing licensing, certificates, firewall rules and broker configuration all at once can hide the original failure.

The useful evidence is the sequence around the event. Event 1301 can show that a redirection request was received, Event 801 can show that the broker processed it and selected a target, while 1296 or 1306 identifies a later failure in obtaining or applying the redirection information. The Error field is also worth preserving exactly: live SERP cases include both The parameter is incorrect and NULL, so do not assume every Event 1306 is the same failure.

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 DNS and target Session Host reachability

From the relevant RDS servers, verify that the target host reported by the broker resolves to the expected address and that the Session Host is available in the deployment. A successful broker decision is not enough if the target name resolves incorrectly or the endpoint is unavailable.

Verify: Compare the returned address with the target information recorded in the broker event. 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 — correlate Broker and Session Host logs

Use the timestamp of Event 1306 to inspect the broker and the intended Session Host. If the broker logs a successful processing event but the target host has no corresponding connection activity, the gap itself is useful evidence. If the Session Host receives the connection and rejects it, troubleshoot that later stage instead.

Also separate authentication success from redirection success. A user can authenticate successfully and still fail during collection routing.

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