Unable to Connect to Azure VM using Remote Desktop

Recommended steps

To resolve common issues, try one or more of the following steps.

  • Review your VM's console screenshot to correct boot problems
  • Reset Remote Access to address remote server issues 
  • Reset remote access using PowerShell or CLI
  • Restart the Virtual Machine to address startup issues by clicking 'Restart' at the top of the VM resource blade
  • RDP to your VM from Internet may not work with forced tunneling enabled. Review effective routes. With forced tunneling, all outbound traffic destined to Internet will be redirected to on-premises
  • To connect to your VM via RDP, please review effective security group rules to ensure inbound “Allow” NSG rule exists for RDP port(3389)
  • Address Azure host issues by redeploying, which will migrate the VM to a new Azure host
  • If you're getting an RDP license error, use 'mstsc/admin' as a work around. If needed, uninstall or buy an RDS license. 
  • Address Remote Desktop License Server error
  • Recommended documents

 

Troubleshoot Remote Desktop connections to an Azure virtual machine running Windows

 

The Remote Desktop Protocol (RDP) connection to your Windows-based Azure virtual machine (VM) can fail for various reasons, leaving you unable to access your VM. The issue can be with the Remote Desktop service on the VM, the network connection, or the Remote Desktop client on your host computer. This article guides you through some of the most common methods to resolve RDP connection issues. If your issue isn't listed here or you still can't connect to your VM via RDP, you can read more detailed RDP troubleshooting concepts and steps.

If you need more help at any point in this article, you can contact the Azure experts on the MSDN Azure and Stack Overflow forums. Alternatively, you can file an Azure support incident. Go to theAzure support site and select Get Support.

 

Quick troubleshooting steps

After each troubleshooting step, try reconnecting to the VM:

  1. Reset remote access using the Azure portal or Azure PowerShell
  2. Restart the VM
  3. Redeploy the VM
  4. Check Network Security Group / Cloud Services endpoint rules
  5. Review VM console logs in the Azure portal or Azure PowerShell
  6. Check the VM Resource Health in the Azure portal
  7. Reset your VM password

Continue reading if you need more detailed steps and explanations for both Resource Manager and Classic deployment models.

 

Troubleshoot VMs created by using the Resource Manager deployment model

After each troubleshooting step, try reconnecting to the VM.

Tip:

If the 'Connect' button in the portal is grayed out and you are not connected to Azure via anExpress Route or Site-to-Site VPN connection, you need to create and assign your VM a public IP address before you can use RDP. You can read more about public IP addresses in Azure.

  1. Reset remote access by using PowerShell.

    • If you haven't already, install and configure the latest Azure PowerShell.
    • Reset your RDP connection by using either of the following PowerShell commands. Replace the myRG, myVM, myVMAccessExtension, and location with values that are relevant to your setup.
    Copy
    Set-AzureRmVMExtension -ResourceGroupName "myRG" -VMName "myVM" `
        -Name "myVMAccessExtension" -ExtensionType "VMAccessAgent" `
        -Publisher "Microsoft.Compute" -typeHandlerVersion "2.0" `
        -Location Westus

    OR

    Copy
    Set-AzureRmVMAccessExtension -ResourceGroupName "myRG" `
        -VMName "myVM" -Name "myVMAccess" -Location Westus
    Note:

    In the preceding examples, myVMAccessExtension or MyVMAccess is a name that you specify for the new extension to install as part of the process. This is often set to the name of the VM. If you have previously worked with the VMAccessAgent, you can get the name of the existing extension by using Get-AzureRmVM -ResourceGroupName "myRG" -Name "myVM" to check the properties of the VM. Look under the 'Extensions' section of the output to view the name. Since only one VMAccessAgent can exist on a VM, you also need to add the -ForceReRun True parameter when using Set-AzureRmVMExtension to re-register the agent.

  2. Restart your VM to address other startup issues. Select Browse > Virtual machines > your VM >Restart.

  3. Redeploy VM to a new Azure node.

    After this operation finishes, ephemeral disk data is lost and dynamic IP addresses that are associated with the virtual machine are updated.

  4. Verify that your Network Security Group rules allow RDP traffic (TCP port 3389).

  5. Review your VM's console log or screenshot to correct boot problems. Select Browse > Virtual machines > your Windows virtual machine > Support + Troubleshooting > Boot diagnostics.

  6. Reset your VM's password.

If you are still encountering RDP issues, you can open a support request or read more detailed RDP troubleshooting concepts and steps.

Troubleshoot VMs created by using the Classic deployment model

After each troubleshooting step, try reconnecting to the VM.

  1. Reset the Remote Desktop service from the Azure portal. Select Browse > Virtual machines (classic) > your VM > Reset Remote....

  2. Restart your VM to address other startup issues. Select Browse > Virtual machines (classic) >your VM > Restart.

  3. Redeploy VM to a new Azure node.

    After this operation finishes, ephemeral disk data is lost and dynamic IP addresses that are associated with the virtual machine are updated.

  4. Verify that your Cloud Services endpoint allow RDP traffic.

  5. Review your VM’s console log or screenshot to correct boot problems. Select Browse > Virtual machines (classic) > your VM > Settings > Boot diagnostics.

  6. Check your VM's Resource Health for any platform issues. Select Browse > Virtual machines (classic) > your VM > Settings > Check Health.

  7. Reset your VM's password.

If you are still encountering RDP issues, you can open a support request or read more detailed RDP troubleshooting concepts and steps.

Troubleshoot specific Remote Desktop connection errors

You may receive a specific error when trying to connect to your VM via RDP. The following are the most common error messages:

 

The remote session was disconnected because there are no Remote Desktop License Servers available to provide a license.

Cause: The 120-day licensing grace period for the Remote Desktop Server role has expired and you need to install licenses.

As a workaround, save a local copy of the RDP file from the portal and run this command at a PowerShell command prompt to connect. This disables licensing for just that connection:

Copy
    mstsc <File name>.RDP /admin

If you don't actually need more than two simultaneous Remote Desktop connections to the VM, you can use Server Manager to remove the Remote Desktop Server role.

For more information, see the blog post Azure VM fails with "No Remote Desktop License Servers available".

 

Remote Desktop can't find the computer "name".

Cause: The Remote Desktop client on your computer can't resolve the name of the computer in the settings of the RDP file.

Possible solutions:

  • If you're on an organization's intranet, make sure that your computer has access to the proxy server and can send HTTPS traffic to it.

  • If you're using a locally stored RDP file, try using the one that's generated by the portal. This ensures that you have the correct DNS name for the virtual machine, or the cloud service and the endpoint port of the VM. Here is a sample RDP file generated by the portal:

    Copy
    full address:s:tailspin-azdatatier.cloudapp.net:55919
    prompt for credentials:i:1

The address portion of this RDP file has: - The fully qualified domain name of the cloud service that contains the VM ("tailspin-azdatatier.cloudapp.net" in this example).

  • The external TCP port of the endpoint for Remote Desktop traffic (55919).

 

An authentication error has occurred. The Local Security Authority cannot be contacted.

Cause: The target VM can't locate the security authority in the user name portion of your credentials.

When your user name is in the form SecurityAuthority\UserName (example: CORP\User1), theSecurityAuthority portion is either the VM's computer name (for the local security authority) or an Active Directory domain name.

Possible solutions:

  • If the account is local to the VM, make sure that the VM name is spelled correctly.

  • If the account is on an Active Directory domain, check the spelling of the domain name.

  • If it is an Active Directory domain account and the domain name is spelled correctly, verify that a domain controller is available in that domain. It's a common issue in Azure virtual networks that contain domain controllers that a domain controller is unavailable because it hasn't been started. As a workaround, you can use a local administrator account instead of a domain account.

 

Windows Security error: Your credentials did not work.

Cause: The target VM can't validate your account name and password.

A Windows-based computer can validate the credentials of either a local account or a domain account.

  • For local accounts, use the ComputerName\UserName syntax (example: SQL1\Admin4798).
  • For domain accounts, use the DomainName\UserName syntax (example: CONTOSO\peterodman).

If you have promoted your VM to a domain controller in a new Active Directory forest, the local administrator account that you signed in with is converted to an equivalent account with the same password in the new forest and domain. The local account is then deleted.

For example, if you signed in with the local account DC1\DCAdmin, and then promoted the virtual machine as a domain controller in a new forest for the corp.contoso.com domain, the DC1\DCAdmin local account gets deleted and a new domain account (CORP\DCAdmin) is created with the same password.

Make sure that the account name is a name that the virtual machine can verify as a valid account, and that the password is correct.

If you need to change the password of the local administrator account, see How to reset a password or the Remote Desktop service for Windows virtual machines.

 

This computer can't connect to the remote computer.

Cause: The account that's used to connect does not have Remote Desktop sign-in rights.

Every Windows computer has a Remote Desktop users local group, which contains the accounts and groups that can sign into it remotely. Members of the local administrators group also have access, even though those accounts are not listed in the Remote Desktop users local group. For domain-joined machines, the local administrators group also contains the domain administrators for the domain.

Make sure that the account you're using to connect with has Remote Desktop sign-in rights. As a workaround, use a domain or local administrator account to connect over Remote Desktop. To add the desired account to the Remote Desktop users local group, use the Microsoft Management Console snap-in (System Tools > Local Users and Groups > Groups > Remote Desktop Users).

Troubleshoot Remote Desktop connections to an Azure virtual machine running Windows

Troubleshoot Remote Desktop connections to an Azure virtual machine running Windows

Updated: 09/01/2016
Contributors:
  • +2
Edit on GitHub

The Remote Desktop Protocol (RDP) connection to your Windows-based Azure virtual machine (VM) can fail for various reasons, leaving you unable to access your VM. The issue can be with the Remote Desktop service on the VM, the network connection, or the Remote Desktop client on your host computer. This article guides you through some of the most common methods to resolve RDP connection issues. If your issue isn't listed here or you still can't connect to your VM via RDP, you can read more detailed RDP troubleshooting concepts and steps.

If you need more help at any point in this article, you can contact the Azure experts on the MSDN Azure and Stack Overflow forums. Alternatively, you can file an Azure support incident. Go to theAzure support site and select Get Support.

 

Quick troubleshooting steps

After each troubleshooting step, try reconnecting to the VM:

  1. Reset remote access using the Azure portal or Azure PowerShell
  2. Restart the VM
  3. Redeploy the VM
  4. Check Network Security Group / Cloud Services endpoint rules
  5. Review VM console logs in the Azure portal or Azure PowerShell
  6. Check the VM Resource Health in the Azure portal
  7. Reset your VM password

Continue reading if you need more detailed steps and explanations for both Resource Manager and Classic deployment models.

 

Troubleshoot VMs created by using the Resource Manager deployment model

After each troubleshooting step, try reconnecting to the VM.

Tip:

If the 'Connect' button in the portal is grayed out and you are not connected to Azure via anExpress Route or Site-to-Site VPN connection, you need to create and assign your VM a public IP address before you can use RDP. You can read more about public IP addresses in Azure.

  1. Reset remote access by using PowerShell.

    • If you haven't already, install and configure the latest Azure PowerShell.
    • Reset your RDP connection by using either of the following PowerShell commands. Replace the myRG, myVM, myVMAccessExtension, and location with values that are relevant to your setup.
    Copy
    Set-AzureRmVMExtension -ResourceGroupName "myRG" -VMName "myVM" `
        -Name "myVMAccessExtension" -ExtensionType "VMAccessAgent" `
        -Publisher "Microsoft.Compute" -typeHandlerVersion "2.0" `
        -Location Westus

    OR

    Copy
    Set-AzureRmVMAccessExtension -ResourceGroupName "myRG" `
        -VMName "myVM" -Name "myVMAccess" -Location Westus
    Note:

    In the preceding examples, myVMAccessExtension or MyVMAccess is a name that you specify for the new extension to install as part of the process. This is often set to the name of the VM. If you have previously worked with the VMAccessAgent, you can get the name of the existing extension by using Get-AzureRmVM -ResourceGroupName "myRG" -Name "myVM" to check the properties of the VM. Look under the 'Extensions' section of the output to view the name. Since only one VMAccessAgent can exist on a VM, you also need to add the -ForceReRun True parameter when using Set-AzureRmVMExtension to re-register the agent.

  2. Restart your VM to address other startup issues. Select Browse > Virtual machines > your VM >Restart.

  3. Redeploy VM to a new Azure node.

    After this operation finishes, ephemeral disk data is lost and dynamic IP addresses that are associated with the virtual machine are updated.

  4. Verify that your Network Security Group rules allow RDP traffic (TCP port 3389).

  5. Review your VM's console log or screenshot to correct boot problems. Select Browse > Virtual machines > your Windows virtual machine > Support + Troubleshooting > Boot diagnostics.

  6. Reset your VM's password.

If you are still encountering RDP issues, you can open a support request or read more detailed RDP troubleshooting concepts and steps.

Troubleshoot VMs created by using the Classic deployment model

After each troubleshooting step, try reconnecting to the VM.

  1. Reset the Remote Desktop service from the Azure portal. Select Browse > Virtual machines (classic) > your VM > Reset Remote....

  2. Restart your VM to address other startup issues. Select Browse > Virtual machines (classic) >your VM > Restart.

  3. Redeploy VM to a new Azure node.

    After this operation finishes, ephemeral disk data is lost and dynamic IP addresses that are associated with the virtual machine are updated.

  4. Verify that your Cloud Services endpoint allow RDP traffic.

  5. Review your VM’s console log or screenshot to correct boot problems. Select Browse > Virtual machines (classic) > your VM > Settings > Boot diagnostics.

  6. Check your VM's Resource Health for any platform issues. Select Browse > Virtual machines (classic) > your VM > Settings > Check Health.

  7. Reset your VM's password.

If you are still encountering RDP issues, you can open a support request or read more detailed RDP troubleshooting concepts and steps.

Troubleshoot specific Remote Desktop connection errors

You may receive a specific error when trying to connect to your VM via RDP. The following are the most common error messages:

 

The remote session was disconnected because there are no Remote Desktop License Servers available to provide a license.

Cause: The 120-day licensing grace period for the Remote Desktop Server role has expired and you need to install licenses.

As a workaround, save a local copy of the RDP file from the portal and run this command at a PowerShell command prompt to connect. This disables licensing for just that connection:

Copy
    mstsc <File name>.RDP /admin

If you don't actually need more than two simultaneous Remote Desktop connections to the VM, you can use Server Manager to remove the Remote Desktop Server role.

For more information, see the blog post Azure VM fails with "No Remote Desktop License Servers available".

 

Remote Desktop can't find the computer "name".

Cause: The Remote Desktop client on your computer can't resolve the name of the computer in the settings of the RDP file.

Possible solutions:

  • If you're on an organization's intranet, make sure that your computer has access to the proxy server and can send HTTPS traffic to it.

  • If you're using a locally stored RDP file, try using the one that's generated by the portal. This ensures that you have the correct DNS name for the virtual machine, or the cloud service and the endpoint port of the VM. Here is a sample RDP file generated by the portal:

    Copy
    full address:s:tailspin-azdatatier.cloudapp.net:55919
    prompt for credentials:i:1

The address portion of this RDP file has: - The fully qualified domain name of the cloud service that contains the VM ("tailspin-azdatatier.cloudapp.net" in this example).

  • The external TCP port of the endpoint for Remote Desktop traffic (55919).

 

An authentication error has occurred. The Local Security Authority cannot be contacted.

Cause: The target VM can't locate the security authority in the user name portion of your credentials.

When your user name is in the form SecurityAuthority\UserName (example: CORP\User1), theSecurityAuthority portion is either the VM's computer name (for the local security authority) or an Active Directory domain name.

Possible solutions:

  • If the account is local to the VM, make sure that the VM name is spelled correctly.

  • If the account is on an Active Directory domain, check the spelling of the domain name.

  • If it is an Active Directory domain account and the domain name is spelled correctly, verify that a domain controller is available in that domain. It's a common issue in Azure virtual networks that contain domain controllers that a domain controller is unavailable because it hasn't been started. As a workaround, you can use a local administrator account instead of a domain account.

 

Windows Security error: Your credentials did not work.

Cause: The target VM can't validate your account name and password.

A Windows-based computer can validate the credentials of either a local account or a domain account.

  • For local accounts, use the ComputerName\UserName syntax (example: SQL1\Admin4798).
  • For domain accounts, use the DomainName\UserName syntax (example: CONTOSO\peterodman).

If you have promoted your VM to a domain controller in a new Active Directory forest, the local administrator account that you signed in with is converted to an equivalent account with the same password in the new forest and domain. The local account is then deleted.

For example, if you signed in with the local account DC1\DCAdmin, and then promoted the virtual machine as a domain controller in a new forest for the corp.contoso.com domain, the DC1\DCAdmin local account gets deleted and a new domain account (CORP\DCAdmin) is created with the same password.

Make sure that the account name is a name that the virtual machine can verify as a valid account, and that the password is correct.

If you need to change the password of the local administrator account, see How to reset a password or the Remote Desktop service for Windows virtual machines.

 

This computer can't connect to the remote computer.

Cause: The account that's used to connect does not have Remote Desktop sign-in rights.

Every Windows computer has a Remote Desktop users local group, which contains the accounts and groups that can sign into it remotely. Members of the local administrators group also have access, even though those accounts are not listed in the Remote Desktop users local group. For domain-joined machines, the local administrators group also contains the domain administrators for the domain.

Make sure that the account you're using to connect with has Remote Desktop sign-in rights. As a workaround, use a domain or local administrator account to connect over Remote Desktop. To add the desired account to the Remote Desktop users local group, use the Microsoft Management Console snap-in (System Tools > Local Users and Groups > Groups > Remote Desktop Users).