Windows Server 2008 R2 Remote Desktop Connection Fails Silently During Session Configuration


2 views

When your Windows Server 2008 R2 machine suddenly stops accepting Remote Desktop connections without any error message, it can be particularly frustrating. The connection process appears normal until the "Configuring remote session" stage, then abruptly returns to the initial connection dialog. Let's examine how to diagnose and resolve this stealthy RDP issue.

First, check these critical components when facing silent RDP failures:

# Check RDP service status
sc query TermService

# Verify listening port (default 3389)
netstat -ano | findstr 3389

# Review security logs for authentication attempts
wevtutil qe Security /q:"*[System[EventID=4624 or EventID=4625]]" /f:text

Based on similar cases I've encountered, these are the most probable causes:

  • TSLicensing service stuck in a bad state
  • Corrupted RDP certificate
  • Pending Windows updates requiring reboot
  • Network Level Authentication (NLA) misconfiguration

Try this sequence when RDP fails silently:

# First attempt - reset RDP components
net stop TermService
net stop UmRdpService
del /F /Q "%windir%\system32\tsconfig\*.*"
net start TermService

# If still failing, check certificate binding
wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Get SSLCertificateSHA1Hash

# For certificate issues, recreate self-signed cert
wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting CALL SetSSLCertificateSHA1Hash ""

When basic troubleshooting doesn't reveal the issue, enable deeper logging:

# Enable RDP diagnostic logging
reg add "HKLM\SOFTWARE\Microsoft\Tracing" /v EnableFileTracing /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Microsoft\Tracing\RDP" /v EnableFileTracing /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Microsoft\Tracing\RDP" /v FileDirectory /t REG_SZ /d "%windir%\tracing" /f

# After reproducing the issue, check:
# %windir%\tracing\RDP*.log

Implement these configurations to avoid future occurrences:

# Set RDP service recovery options
sc failure TermService actions= restart/60000/restart/60000/restart/60000 reset= 86400

# Create scheduled task as fallback access
schtasks /create /tn "RDPWatchdog" /tr "powershell -command Test-NetConnection -ComputerName localhost -Port 3389" /sc hourly

When RDP fails completely, these alternatives can save your access:

  • Emergency Management Services (EMS) if configured
  • Windows Remote Management (WinRM)
  • Third-party tools like PowerShell Remoting
# Example WinRM connection setup
Enable-PSRemoting -Force
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "your_management_pc" -Force

Yesterday I encountered one of those frustrating infrastructure issues where a Windows Server 2008 R2 system suddenly stopped accepting Remote Desktop connections after a routine reboot. The session would progress through the normal connection sequence, reach the "Configuring remote session" stage, then silently drop back to the connection dialog without any error message. Here's how I diagnosed and resolved it.

The server remained operational (HTTP services were responding) and appeared to authenticate credentials (no "invalid credentials" prompt). This suggested either a Terminal Services component failure or a resource constraint preventing session initialization.

First, I checked these diagnostic sources:

# Check RDP listener status
Get-Service TermService -ComputerName SERVER01 | Select Status,StartType

# Verify port listening state
Test-NetConnection -ComputerName SERVER01 -Port 3389

# Review security event logs (filter for logon events)
Get-WinEvent -ComputerName SERVER01 -LogName Security -FilterXPath "*[System[EventID=4624]]" -MaxEvents 5

Surprisingly, all appeared normal - the service was running, port 3389 was open, and security logs showed successful logon events.

The key breakthrough came from enabling Microsoft's hidden RDP diagnostic logging:

# Enable verbose RDP logging
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server" 
-Name "EnableDiagnostics" -Value 1 -PropertyType DWORD -Force

# Configure log level (0-5, 5 being most verbose)
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\Diagnostics" 
-Name "LogLevel" -Value 5 -PropertyType DWORD -Force

After reproducing the issue, the Event Viewer revealed this smoking gun:

Log Name:      Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational
Event ID:      1061
Description:   The terminal server cannot issue a client license because 
               there are no available terminal server client access licenses 
               (TS CALs) or the temporary license period has expired.

The root cause emerged: our domain's Terminal Services License Server hadn't properly replicated its database after a recent domain controller promotion. This PowerShell confirmed it:

# Check TS License Server status
$tsLicense = Get-WmiObject -Class Win32_TSLicenseServer -ComputerName LICENSESERVER
$tsLicense | Select ServerName, @{N="LicensesIssued";E={$_.LicensesIssued.Count}}
  1. Restarted the Terminal Services Licensing service on all domain controllers
  2. Forced license database replication using:
# On primary license server
Import-Module RemoteDesktopServices
Sync-TSLicenseConfiguration -Force

To avoid recurrence, I added these monitoring checks:

# Nagios check for available TS CALs
$freeCALs = (Get-WmiObject -Class Win32_TSIssuedLicense -Filter "LicenseStatus='1'").Count
if ($freeCALs -lt 5) { Exit 2 } # CRITICAL if less than 5 available

# Scheduled task to verify license server health
$action = { 
    if (-not (Get-Service TermServLicensing).Status -eq "Running") {
        Start-Service TermServLicensing 
    }
}
Register-ScheduledTask -TaskName "TS License Monitor" -Action $action -Trigger (New-ScheduledTaskTrigger -Daily -At 3am)

The server resumed normal RDP operations after these changes, though the temporary resolution (before tech support intervention) remains unclear - possibly an automatic license server self-recovery mechanism kicked in.

  • RDP failures can occur silently when licensing infrastructure fails
  • Always check both the target server AND supporting infrastructure components
  • Microsoft's hidden RDP diagnostics provide crucial visibility
  • Implement proactive monitoring for TS licensing health