RDP Locked Out? Solving the "Ghost" Connection Broker Error (7A)

If you’ve tried to RDP into a server and were met with Error Code 3 and Extended Error 7A, you aren't looking at a network glitch. You are looking at a Service Dependency Deadlock. This happens when a server "remembers" a configuration it is no longer supposed to have.

Executive Summary

If this server has the "Remote Desktop Server" role installed then you need to ensure the Windows Internal Database (WID) service is running and not disabled, then check the "Remote Desktop Service Connection Broker Service" status, if this is stopped start it (ensure you start WID before this service)

If this server is in "Administration Mode" where you only require 2x simultaneous sessions using RDP then the "Connection Broker" is not used in this configuration.

Ensure you get the server requirements correct before making changes, this requires you to understand what the server should be doing!

What are "Ghost Settings"?

"Ghosting" occurs when the Remote Desktop Services (RDS) Role is uninstalled, but the uninstaller fails to clean up the registry.

In a full RDS deployment, the server operates in Farm Mode. It refuses to log anyone in until it talks to a Connection Broker. The Broker, in turn, cannot function without its dependant service —the Windows Internal Database (WID).

When you uninstall the RDS roles:

1. The Services are Disabled: Windows sets the Broker and Database services to Disabled to save resources.
2. The Registry is Forgotten: The uninstaller can also fail to flip the "Farm Mode" switch back to 0.

The Result: The RDP listener is still waiting for a "Go" signal from a Connection Broker that is turned off and has no database. This "Ghost" configuration is what triggers the 7A error.

Phase 1: The Investigation (Don't Blindly Run Code)

Before fixing anything, we need to verify if the server is actually "haunted" by old settings. Since you can't RDP in, run these via PowerShell from your workstation to confirm the state:

1. Check if the RDS Roles are actually gone:

Get-WindowsFeature -ComputerName <server> -Name RDS-RD-Server, RDS-Connection-Broker

If these show as Available (not Installed), but you're still getting errors, the server is incorrectly trying to use a Broker that shouldn't exist.

2. Check the "Farm Mode" Registry Flag:

Invoke-Command -ComputerName <server> -ScriptBlock {Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\ClusterSettings" -Name "SessionDirectoryActive"}

If SessionDirectoryActive is 1, the ghost is present. The server thinks it is still part of a cluster/farm.

Phase 2: Emergency Recovery (The "Resuscitation" Fix)

Option A: The PowerShell One-Liner (WinRM)

Invoke-Command -ComputerName <server> -ScriptBlock {
    # 1. Start the Database
    Set-Service -Name "MSSQL$MICROSOFT##WID" -StartupType Manual
    Start-Service -Name "MSSQL$MICROSOFT##WID"
    # 2. Start the Connection Broker
    Set-Service -Name "Tssdis" -StartupType Manual
    Start-Service -Name "Tssdis"
}

Option B: The sc.exe Method (If WinRM is Disabled)

To get back into the server immediately, you must manually revive the dependency chain. If you can't use PowerShell Remoting, use the "sc" command which works via RPC.

:: Set services to manual (demand) and start them
sc \\<server> config "MSSQL$MICROSOFT##WID" start= demand
sc \\<server> start "MSSQL$MICROSOFT##WID"
sc \\<server> config Tssdis start= demand
sc \\<server> start Tssdis

Phase 3: The Permanent Cure

Once you have logged in and confirmed that the server should be a standalone server (not a farm member), you must delete the Ghost Setting. This tells the RDP listener to stop looking for a Broker entirely and prevents the issue from returning after a reboot.

Invoke-Command -ComputerName <server> -ScriptBlock {
    $path = "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\ClusterSettings"
    # This disables the "I need a Broker" check permanently
    Set-ItemProperty -Path $path -Name "SessionDirectoryActive" -Value 0
    Write-Host "Ghost configuration cleared. Direct RDP is now restored." -ForegroundColor Green
}

Conclusion

The 7A error is the sound of an RDP listener shouting into a void because its Broker is dead. By verifying the roles first, then reviving the WID -> Broker chain, you can fix the configuration for good.