Skip to content

Est. 2011·Microsoft Partner 7033487·Delivery under 3 min·Support 7 days a week

Your vault is empty.

License Error Event ID 1306

Event ID 1306 and 1296: Connection Broker cannot redirect users to a host

11 min read Updated October 5, 2026 Windows Server: RDS, Hyper-V & Clustering

Fix it now

A session host asked the Connection Broker where to send this user and never got a usable answer, so the connection drops seconds after the credentials are accepted. Confirm the host is still a recognised member of the deployment and that it can reach the broker over RPC before you touch anything else.

Elevated PowerShell on the affected session host, not on the broker

Get-RDServer -ConnectionBroker broker.contoso.local
Get-RDUserSession -ConnectionBroker broker.contoso.local
Resolve-DnsName broker.contoso.local
Test-NetConnection broker.contoso.local -Port 135
  1. On the broker, confirm the Remote Desktop Connection Broker service and the Remote Desktop Management service are both running. On the session host, confirm Remote Desktop Services and Remote Desktop Configuration are running.
  2. Compare the Get-RDServer output against the servers you expect. A host missing from it, or listed without the session host role, is the whole answer.
  3. Look through Get-RDUserSession for a session pointing at a host that no longer exists. One orphaned record breaks one user everywhere while everyone else is fine.
  4. Retry a logon and read the TerminalServices-SessionBroker log on the broker and the TerminalServices-SessionBroker-Client log on the host. Entries on the host with nothing on the broker means the two never spoke.

Restarting the Connection Broker service drops logons in flight and stops all redirection across the farm while it restarts. It is not a first reflex.

If sessions land on a host again, stop here. If the broker answers and still sends nobody anywhere, the next section covers the three things it needs to produce an answer.

Why it happens

In a Remote Desktop Services deployment the machine a client first reaches is rarely the machine it ends up on. The client lands on an entry point, which may be a session host in a DNS round robin, the RD Web Access feed or an RD Gateway, and that machine’s broker client asks the Connection Broker where this user belongs. The broker answers with a redirection naming the target host, the client reconnects there, and the session opens. Everything the user sees happens after that handoff.

To produce an answer the broker needs three things at once. Its own database, which is Windows Internal Database on a single-broker deployment and SQL Server once the role is made highly available. Current collection membership, so it knows which hosts are candidates. And knowledge of any disconnected session this user already owns, because reconnecting an existing session takes priority over load balancing to a fresh one. Any of the three being unavailable produces the same symptom from the user’s side.

The pairing of what appears where is the fastest diagnostic you have. Entries on the session host with nothing on the broker at the same moment means the RPC conversation never happened, which puts you on the network and name resolution. Entries on both means they did talk and the broker could not answer, which puts you on the database or the collection. Neither number is published by Microsoft, so read the text of the entries rather than looking the numbers up.

The host is no longer a recognised member of the deployment

You have this one if Only one host is affected and Get-RDServer does not list it, or lists it without the session host role.

  1. Run Get-RDServer -ConnectionBroker broker.contoso.local and compare it with the servers you expect.
  2. On the broker, open Computer Management, Local Users and Groups, Groups, and confirm the host’s computer account is in the RDS Endpoint Servers and RDS Management Servers groups. The deployment adds these and a rebuilt server loses them.
  3. Re-add the server through Server Manager, Remote Desktop Services, Overview, or with Add-RDServer.
  4. Restart Remote Desktop Services and Remote Desktop Configuration on the host, then retry.

A server removed from the domain and re-joined keeps its name and gets a new security identifier, which is exactly what empties those local groups without anyone noticing.

RPC or name resolution between host and broker is broken

You have this one if Test-NetConnection to port 135 fails from the host, or the broker name resolves to an address that is no longer right.

  1. Test the path from the host with Test-NetConnection broker.contoso.local -Port 135.
  2. Check for a stale DNS record after a broker rebuild and flush the host’s resolver with ipconfig /flushdns.
  3. Confirm the firewall allows the RPC endpoint mapper and the dynamic RPC port range between the two machines, not only 3389.

The broker cannot reach its database

You have this one if Every host fails at once, the management console throws errors, and the broker service starts and then stops.

  1. On a single-broker deployment, confirm the Windows Internal Database service is running and that it starts before the broker service.
  2. On a highly available deployment, confirm the SQL Server instance is reachable and read the configuration with Get-RDConnectionBrokerHighAvailability.
  3. Confirm each broker’s computer account still holds rights on the deployment database. A database restored or moved to a new instance usually loses them.

An orphaned session record points at a host that is gone

You have this one if One user fails every time, from every client, while everyone else connects normally.

  1. Run Get-RDUserSession -ConnectionBroker broker.contoso.local and find the user’s session and the host it names.
  2. If that host has been decommissioned or rebuilt, end the session with Invoke-RDUserLogoff -HostServer <fqdn> -UnifiedSessionID <id> -Force, taking both values from the previous command.
  3. Have the user connect again. The broker places them on a live host.

Logging off a disconnected session discards anything unsaved inside it. Tell the user before you do it, not afterwards.

Every candidate host is drained or in the wrong collection

You have this one if The broker is healthy and answering, and has no host it is willing to send anyone to.

  1. List the hosts in the collection with Get-RDSessionHost -CollectionName "Desktops" -ConnectionBroker broker.contoso.local and read whether new connections are allowed.
  2. Re-enable a host with Set-RDSessionHost -SessionHost host.contoso.local -NewConnectionAllowed Yes -ConnectionBroker broker.contoso.local.
  3. Confirm the hosts are in the collection users are actually being sent to, particularly after a collection was rebuilt.

Set-RDSessionHost takes the host, not a collection. Its parameters are -SessionHost, -NewConnectionAllowed and -ConnectionBroker, and -NewConnectionAllowed accepts Yes, NotUntilReboot or No.

Full reference

Narrowing it down before you change anything

Pattern Most likely area
Every user on every host, starting at one moment The broker service or its database
One host fails and the rest of the collection is fine That host’s deployment membership, or its RPC path to the broker
One user fails everywhere and everyone else is fine An orphaned session record pointing at a host that no longer exists
Administrators are fine and users are not Administrators connect to a named host directly and bypass redirection entirely
The broker answers and sends nobody anywhere Collection membership, or every host drained

The cmdlets worth knowing, with their real parameters

Cmdlet Key parameters What it answers
Get-RDServer -ConnectionBroker Which servers the deployment believes it has, and in what roles
Get-RDSessionHost -CollectionName, -ConnectionBroker The hosts in one collection and whether they accept new connections
Set-RDSessionHost -SessionHost, -NewConnectionAllowed, -ConnectionBroker Drains a host or puts it back in service
Get-RDUserSession -ConnectionBroker Live and disconnected sessions, with the host and unified session id
Invoke-RDUserLogoff -HostServer, -UnifiedSessionID, -Force Ends one session, including an orphaned one
Get-RDConnectionBrokerHighAvailability none required Whether the role is highly available and where its database lives

Set-RDSessionHost has no collection parameter. A command written with one fails outright, which is worth knowing before you type it into a farm at eight in the morning.

Where the logs are

  • On the session host: Applications and Services Logs, Microsoft, Windows, TerminalServices-SessionBroker-Client, Operational.
  • On the broker: the same branch, TerminalServices-SessionBroker, Operational.
  • Read both around the same timestamp. The pairing is the diagnostic; either log alone tells you half a story.
  • Microsoft does not publish meanings for the numbers in either log, so work from the text of the entries and from the pairing.

Restarting the broker without making it worse

Restarting the Connection Broker service stops redirection across the whole farm for as long as it takes to come back, and drops any logon in flight. Users already in sessions keep them, because their sessions live on the hosts, but nobody new gets placed. Do it in a maintenance window, or at least tell people first. If the broker is highly available, check which node holds the role before restarting anything, or you will restart the healthy one.

When to stop investigating and rebuild

Rarely. A rebuild loses collection settings, published RemoteApp programmes and personal desktop assignments, and it fixes the symptom by accident rather than telling you what was wrong. Work through deployment membership, the RPC path, database access and orphaned sessions first; between them they account for nearly every case, and each is a five-minute check.

When a licence is the actual fix

Nothing above needs a purchase, and on an intact deployment the fix is configuration only. Two situations turn into a licensing question. If the broker still runs on a Windows Server release that no longer receives updates, moving the role onto a current build is the durable answer. And if you are adding a second broker node so that one failure stops taking the farm down, that node needs its own Windows Server licence: Windows Server 2025 Standard allows two virtual operating system environments per licensed host and Datacenter allows an unlimited number, so the shape of your host matters as much as the count. Arco supplies both and can work out which fits the hardware you are putting it on. RDS CALs are a separate purchase and are not what causes a redirection failure.

Every code this article covers

Code What it points at Source
Event ID 1306 Not published by Microsoft. It appears in the SessionBroker-Client operational log on the session host when obtaining a redirection from the broker fails not published by the vendor
Event ID 1296 Not published by Microsoft. It appears in the same log against a redirection that could not be completed not published by the vendor
Event ID 802 Not published by Microsoft. It appears on the broker rather than the host, which is what makes it useful for pairing not published by the vendor
Event ID 1301 Not published by Microsoft. It appears where the handoff to the chosen target host failed; read the entry’s own text not published by the vendor

Confirm the fix worked

  1. A test user connecting through the same entry point your users are given lands on a host in the collection.
  2. Get-RDServer lists every host you expect, with the session host role against each.
  3. Get-RDUserSession shows the new session against the host you expect, and no orphaned records remain.
  4. Test-NetConnection broker -Port 135 succeeds from every session host, not only the one you were testing.
  5. No new entries appear in the SessionBroker-Client log on the host for that attempt.

Questions people ask about this

Is this an RDS CAL problem?

No. Licence exhaustion and grace period expiry produce their own events, which name licensing explicitly and affect everyone at once. A redirection failure happens just as readily on a fully licensed farm.

Do I need the broker if I only have one session host?

No. A single host answers connections directly. The broker earns its place once you have more than one host, need session reconnection to work, or publish RemoteApp programmes.

Why does it work for me as an administrator but not for users?

Because you almost certainly connect to a named host directly, which bypasses redirection entirely. Test with the same connection settings your users have.

My Set-RDSessionHost command is being rejected. What is wrong with it?

Almost always a collection parameter that does not exist on that cmdlet. Set-RDSessionHost takes -SessionHost, -NewConnectionAllowed and -ConnectionBroker. Get-RDSessionHost is the one that takes -CollectionName.

Should I rebuild the deployment to clear this?

Rarely. A rebuild loses collection settings, published applications and personal desktop assignments. Work through membership, RPC, database access and orphaned sessions first.

Related error codes

Was this article helpful?

Your feedback helps us improve our documentation.

Related articles

Free Fix Event ID 56 and 50 from TermDD: a certificate or security-layer fault is dropping RDP sessions Free Fix 0xC0370102: virtual machines will not start because the hypervisor is not running Free Fix HTTP 401.1, 401.2 and 401.3: IIS keeps rejecting perfectly valid logons License Error Event ID 7024 and 7031: the RD Licensing service dies and CALs stop issuing
← Back to Knowledge Base