Home azure rdp troubleshooting virtual machines

Fix Azure VM RDP Connection Problems: A Practical Guide Using Event IDs

Updated: • 0 • min read
Table of Contents

Troubleshoot Azure VM RDP Connection Problems

Applies to: ✔️ Windows VMs

This article provides a practical guide to diagnosing and resolving Remote Desktop Protocol (RDP) connection issues to Azure Virtual Machines (VMs) by leveraging Windows Event IDs. By examining specific event logs, you can pinpoint the root cause of connection failures and implement targeted solutions, ensuring seamless access to your Azure VMs. This guide is designed to empower IT professionals and system administrators to quickly restore RDP connectivity and minimize downtime.

Symptoms

When attempting to establish a Remote Desktop Protocol (RDP) session to an Azure VM, you might encounter a connection failure after entering your credentials. This failure is often accompanied by the following generic error message:

“This computer can’t connect to the remote computer. Try connecting again, if the problem continues, contact the owner of the remote computer or your network administrator.”

This error message is non-specific and doesn’t immediately reveal the underlying cause of the RDP connection problem. To effectively troubleshoot this issue, a deeper investigation into the event logs of the VM is necessary. By analyzing these logs, particularly for specific Event IDs, you can gain valuable insights into the nature of the problem and apply the appropriate fix.

Before You Troubleshoot

Before proceeding with any troubleshooting steps, it is crucial to take precautionary measures to safeguard your VM and ensure you have alternative access methods.

Create a Backup Snapshot

Creating a backup snapshot of your VM’s disk is a vital step to protect against unintended data loss or configuration changes during the troubleshooting process. A snapshot allows you to revert your VM to a previous working state if any troubleshooting steps negatively impact the system. Refer to the Azure documentation on “Snapshot a disk” for detailed instructions on creating a snapshot. This backup will serve as a safety net, allowing you to experiment with solutions without fear of permanent damage.

Connect to the VM Remotely

In situations where RDP access is unavailable, having alternative remote access methods is essential for troubleshooting. Azure offers various tools to remotely manage your VMs, even when RDP is failing. These tools include the Azure portal’s Serial Console, PowerShell Direct, and Azure Bastion. Familiarize yourself with these methods by consulting the guide on “How to use remote tools to troubleshoot Azure VM issues”. Having a working remote connection will be crucial for running diagnostic commands and implementing fixes outlined in the following scenarios.

Scenario 1

This scenario addresses RDP connection failures caused by issues with the Remote Desktop certificate, often indicated by specific event IDs in the System log.

Event Logs

To identify if certificate-related issues are preventing RDP connections, you need to check the System event log for specific Event IDs. Open a Command Prompt (CMD) instance with administrative privileges on your Azure VM (using one of the remote access methods mentioned earlier). Execute the following commands to search for Event ID 1058 or 1057 within the last 24 hours in the System log:

wevtutil qe system /c:1 /f:text /q:"Event[System[Provider[@Name='Microsoft-Windows-TerminalServices-RemoteConnectionManager'] and EventID=1058 and TimeCreated[timediff(@SystemTime) <= 86400000]]]" | more
wevtutil qe system /c:1 /f:text /q:"Event[System[Provider[@Name='Microsoft-Windows-TerminalServices-RemoteConnectionManager'] and EventID=1057 and TimeCreated[timediff(@SystemTime) <= 86400000]]]" | more

These commands query the System event log for events from the ‘Microsoft-Windows-TerminalServices-RemoteConnectionManager’ provider with Event IDs 1058 or 1057 that occurred within the last 24 hours (86400000 milliseconds). The output, if these events are present, will provide details about certificate-related errors.

Example Event Log (Event ID 1058 - Certificate Replacement Failure):

Log Name:      System
Source:        Microsoft-Windows-TerminalServices-RemoteConnectionManager
Date:          time
Event ID:      1058
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      computer
Description:
The RD Session Host Server has failed to replace the expired self signed certificate used for RD Session Host Server authentication on TLS connections. The relevant status code was Access is denied.

Example Event Log (Event ID 1058 - Certificate Creation Failure - Object Already Exists):

Log Name:      System
Source:        Microsoft-Windows-TerminalServices-RemoteConnectionManager
Date:          time
Event ID:      1058
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      computer
Description:
RD Session host server has failed to create a new self-signed certificate to be used for RD Session host server authentication on TLS connections, the relevant status code was object already exists.

Example Event Log (Event ID 1057 - Certificate Creation Failure - Keyset Does Not Exist):

Log Name:      System
Source:        Microsoft-Windows-TerminalServices-RemoteConnectionManager
Date:          time
Event ID:      1057
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      computer
Description:
The RD Session Host Server has failed to create a new self signed certificate to be used for RD Session Host Server authentication on TLS connections. The relevant status code was Keyset does not exist

In addition to these RemoteConnectionManager events, also check for SCHANNEL error events 36872 and 36870, which can also indicate certificate-related issues affecting RDP. Run these commands in CMD:

wevtutil qe system /c:1 /f:text /q:"Event[System[Provider[@Name='Schannel'] and EventID=36870 and TimeCreated[timediff(@SystemTime) <= 86400000]]]" | more
wevtutil qe system /c:1 /f:text /q:"Event[System[Provider[@Name='Schannel'] and EventID=36872 and TimeCreated[timediff(@SystemTime) <= 86400000]]]" | more

Example Event Log (Event ID 36870 - TLS Server Credential Private Key Access Error):

Log Name:      System
Source:        Schannel
Date:          —
Event ID:      36870
Task Category: None
Level:         Error
Keywords:
User:          SYSTEM
Computer:      computer
Description: A fatal error occurred when attempting to access the TLS server credential private key. The error code returned from the cryptographic module is 0x8009030D.
The internal error state is 10001.

Cause

These event logs often point to a common underlying problem: inaccessibility of local RSA encryption keys within the MachineKeys folder on the VM. This inaccessibility can stem from two primary causes:

  1. Incorrect Permissions Configuration: The permissions set on the MachineKeys folder or the individual RSA files within it might be misconfigured, preventing the Remote Desktop service from accessing the necessary cryptographic keys. This can occur due to manual permission changes or through the application of restrictive security policies.
  2. Corrupted or Missing RSA Key: The RSA key file itself, which is essential for RDP certificate operations, might be corrupted or even missing from the MachineKeys folder. This could be a result of disk errors, system corruption, or accidental deletion.

Resolution

To resolve RDP connection issues related to certificate access, you need to ensure the correct permissions are set on the RDP certificate and the associated RSA keys. The following steps guide you through this process:

Grant Permission to the MachineKeys Folder

The first step is to reset the permissions of the MachineKeys folder to the default, secure configuration. This ensures that the necessary system accounts have the required access.

  1. Create a PowerShell Script: Open a text editor and create a new file. Paste the following PowerShell script into the file:

    remove-module psreadline
icacls C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys /t /c > c:\temp\BeforeScript_permissions.txt
takeown /f "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys" /a /r
icacls C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys /t /c /grant "NT AUTHORITY\System:(F)"
icacls C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys /t /c /grant "NT AUTHORITY\NETWORK SERVICE:(R)"
icacls C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys /t /c /grant "BUILTIN\Administrators:(F)"
icacls C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys /t /c > c:\temp\AfterScript_permissions.txt
Restart-Service TermService -Force

    Save this file with a .ps1 extension, for example, ResetMachineKeysPermissions.ps1.

  2. Run the PowerShell Script: Execute the PowerShell script on your Azure VM using a remote access method. You may need to adjust PowerShell execution policies to allow script execution. This script performs the following actions:

    • Saves the current permissions of the MachineKeys folder to c:\temp\BeforeScript_permissions.txt for auditing purposes.
    • Takes ownership of the MachineKeys folder and all subfolders/files, assigning ownership to the Administrators group.
    • Grants “Full Control” (F) permissions to the “NT AUTHORITY\System” account.
    • Grants “Read” (R) permissions to the “NT AUTHORITY\NETWORK SERVICE” account.
    • Grants “Full Control” (F) permissions to the “BUILTIN\Administrators” group.
    • Saves the modified permissions to c:\temp\AfterScript_permissions.txt.
    • Restarts the TermService (Remote Desktop Services) to apply the permission changes.

  3. Attempt RDP Access: After the script execution completes and the Remote Desktop service restarts, try to connect to the VM using RDP again. Check if the connection is successful.

  4. Review Permission Changes (Optional): The script creates two text files in the c:\temp\ directory: BeforeScript_permissions.txt and AfterScript_permissions.txt. You can review these files to compare the permissions before and after running the script, which can be helpful for understanding the permission changes made.

Renew RDP Self-Signed Certificate

If granting permissions to the MachineKeys folder does not resolve the RDP connection issue, the next step is to renew the RDP self-signed certificate. This ensures that a valid certificate is being used for RDP connections.

  1. Run PowerShell Script for Certificate Renewal: Execute the following PowerShell script on your Azure VM:

    Import-Module PKI
Set-Location Cert:\LocalMachine
$RdpCertThumbprint = 'Cert:\LocalMachine\Remote Desktop\'+((Get-ChildItem -Path 'Cert:\LocalMachine\Remote Desktop\').thumbprint)
Remove-Item -Path $RdpCertThumbprint
Stop-Service -Name "SessionEnv"
Start-Service -Name "SessionEnv"

    This script performs these actions:
    * Imports the PKI module, which provides cmdlets for working with certificates.
    * Changes the current location to the local machine’s certificate store.
    * Retrieves the thumbprint of the current RDP certificate from the “Remote Desktop” certificate store.
    * Deletes the existing RDP certificate using its thumbprint.
    * Stops and restarts the “SessionEnv” service (Remote Desktop Configuration service), which triggers the generation of a new self-signed RDP certificate.

  2. Attempt RDP Access: After running the script and the services restart, try to connect to the VM using RDP again. Check if the connection is now successful.

Delete and Recreate Certificate Using MMC from Another VM (Advanced)

If renewing the certificate through PowerShell is unsuccessful, you can attempt to delete the certificate directly from the certificate store using the Microsoft Management Console (MMC) from another Azure VM within the same Virtual Network (VNET). This method provides a more direct way to manage certificates on the problematic VM.

  1. Open MMC on Another VM: On a different Azure VM within the same VNET as the problematic VM, open the Run dialog box (Windows key + R), type mmc, and press OK. This will open the Microsoft Management Console.

  2. Add Certificates Snap-in: In the MMC console, go to File > Add/Remove Snap-in.

  3. Select Certificates Snap-in: In the “Available snap-ins” list, select Certificates and click Add >.

  4. Computer Account: In the Certificates snap-in dialog, choose Computer account and click Next.

  5. Another Computer: Select Another computer and enter the internal IP address of the VM that has RDP connection problems. Using the internal IP address is recommended to avoid potential network routing issues associated with virtual IP addresses.

    MMC Certificates Snap-in Another Computer

  6. Finish and OK: Click Finish and then OK to add the Certificates snap-in for the remote VM.

  7. Delete the RDP Certificate: In the MMC console, expand Certificates (Another Computer) > Remote Desktop > Certificates. Right-click the existing RDP certificate in this folder and select Delete. Confirm the deletion when prompted.

  8. Restart Remote Desktop Configuration Service: On the problematic VM (using a remote command execution method if RDP is still down, or via Serial Console), restart the Remote Desktop Configuration service using the following commands in CMD:

    net stop SessionEnv
net start SessionEnv

    Note: If you refresh the Certificates snap-in in MMC after restarting the service, the certificate will automatically reappear as a new self-signed certificate is generated.

  9. Attempt RDP Access: Try to connect to the VM using RDP again. The new certificate should now be in place.

Verify and Correct TLS/SSL Certificate Thumbprint (If Applicable)

If your VM is configured to use a specific TLS/SSL certificate for RDP instead of the self-signed certificate, you need to verify that the correct certificate thumbprint is configured in the registry.

  1. Get Current Thumbprint from Registry: Run the following command in CMD on the VM to retrieve the currently configured certificate thumbprint from the registry:

    reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SSLCertificateSHA1Hash

    This command queries the registry for the SSLCertificateSHA1Hash value under the specified key, which stores the thumbprint of the TLS/SSL certificate used for RDP.

  2. Compare with Certificate Thumbprint: Compare the thumbprint obtained from the registry with the actual thumbprint of the TLS/SSL certificate you intend to use. Ensure they match exactly.

  3. Update Thumbprint in Registry (If Mismatched): If the thumbprints do not match, you need to update the registry with the correct thumbprint. Use the following command, replacing <CERTIFICATE THUMBPRINT> with the correct thumbprint value (in binary format, without spaces or colons):

    reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SSLCertificateSHA1Hash /t REG_BINARY /d <CERTIFICATE THUMBPRINT>

  4. Revert to Self-Signed Certificate (Optional): If you want to revert to using the self-signed RDP certificate instead of a custom TLS/SSL certificate, you can delete the SSLCertificateSHA1Hash registry value. This will force RDP to use the default self-signed certificate. Run this command in CMD:

    reg delete "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SSLCertificateSHA1Hash

  5. Restart Remote Desktop Services: After making any changes to the registry related to the certificate thumbprint, restart the Remote Desktop Services (TermService) for the changes to take effect.

  6. Attempt RDP Access: Try to connect to the VM using RDP again after verifying or correcting the certificate configuration.

Scenario 2

This scenario addresses RDP connection failures caused by issues related to the TLS protocol version, often indicated by SCHANNEL event ID 36871.

Event Log

To determine if TLS protocol issues are causing RDP failures, check the System event log for SCHANNEL error event 36871 within the last 24 hours. Run the following command in CMD:

wevtutil qe system /c:1 /f:text /q:"Event[System[Provider[@Name='Schannel'] and EventID=36871 and TimeCreated[timediff(@SystemTime) <= 86400000]]]" | more

Example Event Log (Event ID 36871 - TLS Server Credential Creation Error):

Log Name:      System
Source:        Schannel
Date:          —
Event ID:      36871
Task Category: None
Level:         Error
Keywords:
User:          SYSTEM
Computer:      computer
Description:
A fatal error occurred while creating a TLS server credential. The internal error state is 10013.

Cause

Event ID 36871, specifically with internal error state 10013, often indicates that security policies are blocking older TLS versions, such as TLS 1.0, which RDP might attempt to use by default. When older TLS versions are disabled for security reasons, RDP connections that rely on these older protocols will fail.

Resolution

While RDP traditionally uses TLS 1.0 as its default protocol, modern security best practices encourage the use of newer, more secure protocols like TLS 1.1 or TLS 1.2. To resolve TLS protocol-related RDP connection issues, you need to ensure that the VM and the client attempting to connect are configured to use compatible TLS versions.

Refer to the comprehensive guide on “Troubleshoot authentication errors when you use RDP to connect to Azure VM”, specifically the section on TLS Version Mismatches. This article provides detailed steps and registry modifications to manage TLS protocol versions for RDP connections, ensuring compatibility and security. It may involve enabling or disabling specific TLS versions, or configuring cipher suites to ensure a secure and successful RDP connection. Consider enabling TLS 1.2 as the preferred protocol for enhanced security.

Scenario 3

This scenario applies specifically to VMs that have the Remote Desktop Connection Broker role installed and addresses RDP connection problems related to Broker service issues, indicated by Event IDs 2056 and 1296.

Event Log

If your Azure VM is configured with the Remote Desktop Connection Broker role, check the event logs for Event ID 2056 or 1296 within the last 24 hours. Run the following commands in CMD:

wevtutil qe system /c:1 /f:text /q:"Event[System[Provider[@Name=' Microsoft-Windows-TerminalServices-SessionBroker '] and EventID=2056 and TimeCreated[timediff(@SystemTime) <= 86400000]]]" | more
wevtutil qe system /c:1 /f:text /q:"Event[System[Provider[@Name=' Microsoft-Windows-TerminalServices-SessionBroker-Client '] and EventID=1296 and TimeCreated[timediff(@SystemTime) <= 86400000]]]" | more

Example Event Log (Event ID 2056 - Session Broker Database Logon Failure):

Log Name:      Microsoft-Windows-TerminalServices-SessionBroker/Operational
Source:        Microsoft-Windows-TerminalServices-SessionBroker
Date:          time
Event ID:      2056
Task Category: (109)
Level:         Error
Keywords:
User:          NETWORK SERVICE
Computer:      computer fqdn
Description:
The description for Event ID 2056 from source Microsoft-Windows-TerminalServices-SessionBroker cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:
NULL
NULL
Logon to the database failed.

Example Event Log (Event ID 1296 - Session Broker RPC Communication Failure):

Log Name:      Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational
Source:        Microsoft-Windows-TerminalServices-SessionBroker-Client
Date:          time
Event ID:      1296
Task Category: (104)
Level:         Error
Keywords:
User:          NETWORK SERVICE
Computer:      computer fqdn
Description:
The description for Event ID 1296 from source Microsoft-Windows-TerminalServices-SessionBroker-Client cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:
text
text
Remote Desktop Connection Broker is not ready for RPC communication.

Cause

These event IDs, particularly in a Remote Desktop Connection Broker environment, often indicate an issue stemming from an unsupported hostname change of the Remote Desktop Connection Broker server after the Remote Desktop Services farm was initially configured.

The hostname of the Broker server is deeply integrated with the Windows Internal Database, which is essential for the proper functioning of a Remote Desktop Services farm. Changing the hostname after the farm is built can lead to inconsistencies and dependencies within the database, resulting in various errors and potentially causing the Broker server to become non-operational. This disruption in Broker service functionality directly impacts RDP connection brokering and can prevent users from connecting to session hosts.

Resolution

Due to the deep integration of the hostname with the Windows Internal Database in a Remote Desktop Connection Broker setup, simply renaming the server back to its original name is often insufficient to resolve the issue. To reliably fix this problem and restore the Broker service to a functional state, reinstallation of both the Remote Desktop Connection Broker role and the Windows Internal Database is typically required.

Unfortunately, there is no less disruptive “quick fix” for this scenario. Reinstallation ensures that the Broker role and its associated database are correctly configured with the current hostname, eliminating inconsistencies and restoring proper Broker service functionality. This process will likely involve downtime for the Broker service and potentially impact user sessions during the reinstallation. Plan accordingly and communicate any potential service interruptions to users. After reinstallation, thoroughly test RDP connection brokering to ensure the issue is fully resolved.

Next Steps

For further in-depth information and related troubleshooting resources, refer to the following Microsoft documentation and community articles:

We hope this guide has been helpful in resolving your Azure VM RDP connection problems. If you have any further questions or insights, feel free to leave a comment below!

Post a Comment