Note that there are specific Remote Desktop Connection errors returned that are indicative of specific issues, while others are more general and can be a result of a variety of issues.
One specific error to be aware of is:
The remote session was disconnected because there are no Remote Desktop License Servers available to provide a license.
Please contact the server administrator.
That error indicates the 120-day RDS licensing grace period has expired and you need to install RDS licenses. In that scenario, you can run mstsc /admin to connect, since that disables licensing for that current connection only. Then once you are logged on to the VM you can install RDS licenses. Or, if you don't actually need more than two simultaneous RDP connections to the VM, you can use Server Manager to remove the RDS role.
General troubleshooting steps when unable to RDP to an Azure VM:
- Restart VM
- Recreate endpoint
- Connect from different location
- Resize VM
- Recreate VM
- In the management portal, go to Virtual Machines, select the problem VM, select
Dashboard, and make note of the following information under
Quick Glance on the right side of the page:
Status (should be "Running")
DNS (<name>.cloudapp.net, this is what the RDP file from clicking "Connect" will try using)
Host Name (should be computer name/host name, "Retrieving..." may indicate a problem)
Public Virtual IP (VIP) Address - external IP address, can try connecting to this or DNS name
Internal IP Address - can try this from another VM in same cloud service/virtual network
If Status is not Running, that narrows it down to the VM not being fully started, so there is no network issue to troubleshoot, just the issue of getting it started.
If Status is Provisioning (Timed Out) this is commonly see with VMs created from a custom image or disk. If created from a custom image, the VHD used for the image must have been generalized with sysprep (Windows) or the provisioning agent installed (Linux). If created from a custom disk, the VHD used for the disk must NOT have been generalized with sysprep or prepared for provisioning (Linux).
Host Name of Retrieving... means Azure was not able to get the host name via DHCP yet. It could be the VM hasn't fully booted, but also that a static IP has been set, network adapter disabled,
- Restart VM - assuming the Status is
Running, but you are unable to connect, try restarting the VM using the management portal. Go to
Virtual Machines, select the problem VM, select Dashboard, then click
Restart at the bottom of the page. Wait until it gets back to
Status of Running, then try connecting again.
- Recreate Endpoint - external access to the VM is only available through endpoints that control which specific TCP/UDP ports are open to it. By default, endpoints for RDP (TCP 3389) and PowerShell (TCP 5986) are created for Windows
VMs and for Linux VMs an endpoint for SSH (TCP 22).
To recreate the endpoint for the service you are trying to access (RDP/SSH/HTTP, etc.), in the management portal, select Virtual Machines, select the problem VM, select Endpoints at the top, select the desired endpoint, then click Delete Endpoint at the bottom of the page. After the endpoint is deleted, click Add Endpoint, leave the radio button on Add Endpoint, click Next, then specify the name (just a display name, doesn't need to be the same as it was, i.e. can use "RDP" instead of "RemoteDesktop"), the protocol (TCP or UDP), the public port and the private port, then click Next to create the endpoint.
Since connectivity issues can be a result of outbound traffic to specific ports being blocked at corporate firewalls, as a test, you can try setting the public port to the same thing as the private port (so 3389 and 3389 for RDP, or 22 and 22 for Linux) instead of the random ephemeral port in the 49152-65365 range that is used by default when the VM is created. Though keep in mind that having the public port be on a random ephemeral port may keep it off the radar of someone who is port scanning the Azure IP ranges. So ultimately you may want to put it back on an ephemeral port after working things out with your firewall administrator (if that was in fact the issue).
- Connect from different network - to rule out the possibility that traffic is being blocked from the network you are on (i.e. behind corporate firewall), try connecting to the VM from a different network (like from public wifi, or from home,
etc.). If connecting from a different network succeeds, this indicates a problem connecting from the original location, so possibly the port is blocked outbound by your corporate firewall and you should verify with your network administrator if this is the
case. You may need proxy client software or have them open the outbound port.
- Resize VM - changing the virtual machine size (i.e. Medium to Large) will usually result in the VM being moved to run on a different host server. So if there is a problem specific to the host where the VM is currently running, changing
the size will usually move it to a different host server. Though commonly just resizing once will get the VM on a different host, there is the chance that the VM can be resized in-place on the same host. Since there is no customer-exposed way to tell if the
VM ended up on a different host, this means it is prudent if the first resize doesn't help, to just resize it back to the original size to help rule out the possibility that it didn't have to move to a different host on the first resize.
***WARNING*** All data on the D: drive will be lost when changing the virtual machine size and the VM ends up on a different host. This is why the volume label for D: is TEMPORARY STORAGE. All other drives (C: drive and any data disks attached) are persistent as they are backed by VHDs that reside in your storage account. The D: drive resides on the host server itself locally, and is only used for the page file. So if you have data on D: that you care about losing, move it to C: or to a data disk (F:, etc.) before changing the virtual machine size.
Note that the internal IP address of the VM will change if the resize results in the VM running on a different host, because the new host server will present a virtual network adapter with a different hardware ID, which will be detected as a new network adapter in Windows and it will get a different IP from Azure's DHCP. If the VM is in a virtual network, the internal IP address will not change after resizing, because the internal IP is mapped to that VM after it is first provisioned, and it will keep getting that same IP regardless of the host it runs on.
To resize the VM, in the management portal, go to Virtual Machines, select the problem VM, select Configure at the top, then change Virtual Machine Size to something different. Resizing it up or down will work, although resizing it up gives a better chance of it moving to a different host. Whether or not this resolves the connectivity issue, you can resize it back to the original size after temporarily changing it.
- Recreate VM - in some situations, removing the VM and deploying it again from the same VHD will resolve an issue.
Recreate the VM using the management portal
To recreate the VM in the management portal, select Virtual Machines, select the problem VM, and click Delete at the bottom of the page. Note that this does not delete the VHD for the VM.
Now go to Cloud Services (on the left, instead of Virtual Machines), and you will see the now-empty cloud service for the VM. Though it may seem as if the VM has moved to Cloud Services, that is because doing a Quick Create will always give the VM and the cloud service the same name. So it isn't that the VM moved to Cloud Services, it is that the cloud service was hidden by the portal while there was a VM in it. Currently it is not possible to redeploy a VM back into that empty cloud service using the portal (though this is possible with Import-AzureVM in Azure PowerShell). So if you want the same DNS name as before, you must delete the cloud service.
***WARNING*** The cloud service is what reserves the DNS name and external IP. When you delete the cloud service, you can get the same DNS name back (there is that slight chance that someone could use it between the time you deleted it and tried using it again yourself). But you cannot get the same external IP address back, as these are randomly assigned. So if you have dependencies on the external IP staying the same, know that this step will change it. To delete the cloud service, select it and click Delete at the bottom of the page.
Note that if you have more than one VM in the cloud service, there is no need to recreate the cloud service since the portal does allow redeploying to the same cloud service if it is not empty (by selecting Connect to an existing virtual machine on the Virtual Machine Mode page when creating the VM).
Give it a few minutes (no more than 5 min.) after it says the VM was deleted to make sure the disk no longer shows up as being attached to the VM that was removed. Then click New at the very bottom left of the management portal, select Compute, Virtual Machine, From Gallery. Select My Disks and select the disk for the VM that was just removed (can take a few minutes for it to show up here). Enter a VM name (can be the same as before) and choose the size, then on the Virtual Machine Mode page, select Stand-alone Virtual Machine if you had deleted the cloud service, and enter the same (or a different) DNS Name as before. If you had more than one VM in the cloud service, you can deploy it back into that same cloud service (and get the same DNS name and external IP address as before) by selecting Connect to an existing virtual machine and choose the relevant cloud service). Then complete the rest of the VM create wizard.
Recreate the VM using Azure PowerShell (Export-AzureVM/Import-AzureVM)
Recreating with Azure PowerShell can be simpler because it will use the same settings without having to specify them again, but also it allows you to deploy back into an empty cloud service (so the VM will get the same DNS name and external IP). The portal does not currently allow deploying back into the same cloud service if it is empty.
Install Azure PowerShell from http://go.microsoft.com/?linkid=9811175&clcid=0x409
Run Export-AzureVM to export the VM configuration to an XML file. The example below will write the XML file to your temp folder (%temp%). The -ServiceName value will be the name of the cloud service. The name of the cloud service is the first label of the DNS name of the VM. For example, if the DNS name is myvm.cloudapp.net, the cloud service name is myvm. In the example below, the DNS name of the VM is clcs1.cloudapp.net, so the cloud service name is clscs1.
Export-AzureVM -Path $env:TEMP\vm.xml -ServiceName clcs1 -Name DC01
If it worked, the last line of the result output will be OperationStatus:Succeeded.
Run Remove-AzureVM to remove the VM. This does not delete the VHD.
Remove-AzureVM -ServiceName clcs1 -Name DC01
If it worked, the output will show Succeeded under OperationStatus.
Give it a few minutes (no more than 5 min.) to make sure the disk is no longer attached to the VM that you just removed. Then run Import-AzureVm to recreate the VM from the same disk into the same cloud service (so same DNS name and external IP).
Import-AzureVM -Path $env:TEMP\vm.xml | New-AzureVM -ServiceName clcs1
If the VM was in a virtual network, you must also specify the virtual network name with the -VNetName parameter.
Import-AzureVM -Path $env:TEMP\vm.xml | New-AzureVM -ServiceName clcs1 -VNetName clvnet1
If it worked, the output will show Succeeded under OperationStatus. Common failures are when you have not waited long enough for the disk to be freed up after removing the VM, the VM was in a virtual network and you did not specify the virtual network name with the -VNetName parameter, and when the cloud service has already been removed.
If the cloud service was removed, you can still do the import after recreating the cloud service first:
New-AzureService -ServiceName clcs1 -Location "East US"
Or to create the cloud service in an affinity group:
New-AzureService -ServiceName clcs1 -AffinityGroup clag1
If it worked, the output will show Succeeded under OperationStatus.
If the above steps do not resolve the issue, please provide all of the following information when posting to the forum or opening a support case:
- Copy/paste of Quick Glance section for the problem VM (only when opening a support incident,
do not post to forum) - To get to Quick Glance for a VM, select Virtual Machines, select the problem VM, select the Dashboard tab, and the Quick Glance is at the far right side of the page.
- What is the VM Status (Running, Provisioning, etc.)?
- Does Host Name show Retrieving...?
- What port are you trying to connect to and how are you trying to connect (i.e., I am clicking Connect in the portal and trying to RDP to the VM, or I am trying to access the HTTP endpoint using my browser)
- What is the exact error message and/or symptom? Always include verbatim error messages.
- What output do you get from a
Psping to the port (Psping does not work with UDP ports, only TCP). If testing from a Mac or Linux machine, what output do you get from telnet or nmap to the port?
psping <dns name>:<port>
psping <external IP>:<port>
For example if you can't RDP to a VM with DNS name clcs1.cloudapp.net, and you look in Endpoints and see the RemoteDesktop endpoint is using public port 54321:
- Did you try restarting the VM in the portal?
- Did you try recreating the endpoint?
- Did you try connecting from a different network (public wifi, home, etc.)?
- Did you try resizing the VM?
- Did you try recreating the VM (from same VHD)?
- Edited by Craig LandisMicrosoft employee, Moderator Tuesday, January 21, 2014 8:06 PM
We use a custom imagine and experience this quite alot. Usually host name is missing and we have to redeploy.
Seems to have gotten worse as we add more vms.
Should we not sysprep when capturing a vm?
Orginal vm came from the gallary and we've simply resized os to 30gb.
Main role for our vms is job processing so stop deallocate when finish to keep costs down buts prooving to be more trooblesome that expected due vms dieing.
We have a number which we don't shut down which are problem free. so I suspect the stop deallocate and self heal are still early days.My monitor has reported issues with 40+ vms this evening. Are there issues or updates going on in western europe?