This page addresses some of the common issues encountered when using the Windows Azure Virtual Machines feature (IaaS). 

1. VM removed unexpectedly from management portal
   
   When you reach the usage limit on your Windows Azure subscription, for example when using a 90-day trial subscription or the Azure access benefit of an MSDN subscription, your storage accounts are changed to be read-only, the VHD files for your VMs remain in the storage account as-is, but any deployed VMs are removed. This is done because deployed VMs reserve capacity even when stopped. Trial account users can enable pay-as-you-go, and for accounts with monthly limits like with an MSDN subscription, you will be able to deploy VMs from the existing VHDs when the next month’s billing cycle begins and your next month of usage is available. For more information see this blog post.
   
   Note: The limits on a 90-day trial subscription are documented here. After a specific limit is reached, you will not be able to use the related services unless you change your subscription to pay-as-you-go. Depending on your usage of the trial subscription, you may reach one of these limits in less than 90 days. For example, the 90-day trial comes with 750 small compute hours. That means you can run a single small VM for 750 hours. Since a small VM uses one core, a medium VM uses two cores, etc. you can run a single medium VM for 375 hours, a single Large VM for 187.5 hours, or a single Extra Large VM for 93.75 hours before they are remove because the limit was reached on compute hours.
   
   
2. VHD files not deleted when VM is removed
   
   VHD files for Windows Azure Virtual Machines are blobs in your Azure storage account that are registered as disk objects and attached to a VM when the VM is created (in the case of the OS disk) or when you manually add one (in the case of data disks). Removing a VM only makes it so the disk objects (the metadata that allows the VM to use the VHD) are no longer attached to the a VM, but the disk objects still remain as do the physical VHD files in your storage account (which will continue to incur billing fees for storage capacity usage).
   
   To delete virtual machines along with related resources, you need to: Delete virtual machines, Delete Disks, Delete VHDs
   
   To remove disk objects and if desired, the physical VHD also, select Virtual Machines, then Disks, highlight the relevant disk and click Delete Disk which will then show you two options – Delete the associated VHD and Retain the associated VHD.
   
   To remove both the disk object and the physical VHD in your storage account, select Delete the associated VHD.
   If you want to keep the physical VHD file but just remove the disk object, select Retain the associated VHD.
   
   Screenshot showing the Delete the associated VHD and Retain the associated VHD options that are displayed when clicking Delete Disk in the Disks section within Virtual Machines.
   
   
   
   Note: Deleting VHDs may result in errors and may require you to break the lease to recover from the issue. Refer to item 7 below for more details.
   
   
3. D: drive is for temporary storage only
   
   The Temporary Storage (D:) drive is not persisted to Windows Azure storage as OS disks and data disks are. Data on the D: drive will be lost when the VM is moved to a different host server, when the host is updated or if it experiences a hardware failure. The D: drive is only intended for storing temporary data (as indicated by the Temporary Storage volume label on the drive). Do not use the D: drive to store any data that you are not willing to lose. One key benefit that may motivate developers to use temporary disk is performance. I/O performance for temporary disks in some scenarios can be higher than the I/O performance of OS disks or data disks.
   
   When using the D: drive for SQL TEMPDB, you will need to recreate the target folder when the VM is migrated to a different host, otherwise SQL may fail to start. For more information see the following article on the TechNet wiki: Change TEMPDB to Temporary Drive on Azure SQL IaaS
   
   Screenshots showing the temporary drive Temporary Storage (D:)
   
   
   
   
   
   
   
4. Uploading VHD files
   
   There are several methods available to upload VHD files to your Windows Azure storage account. We recommend uploading VHDs with the Add-AzureVHD cmdlet from Windows Azure PowerShell. Note that while you can still use Csupload.exe (1.7 or later) from the Azure SDK, that tool will not be maintained further now that Add-AzureVHD is available.
   
   Considerations when uploading VHD files for use with the Windows Azure Virtual Machines feature:
   
   If you intend to use the VHD as a base template/image that you will use to create multiple VMs, it must be generalized. For Windows, you generalize with the sysprep tool. For Linux you generalize with the Windows Azure Linux Agent (waagent). Provisioning will fail if you upload a VHD as an image that has not been generalized.
   
   If you intend to use the VHD for a single VM (not as a base template/image), you must not generalized it. Provisioning will fail if you upload a VHD as a disk that has generalized.
   
   When using third-party storage tools for the upload make sure to upload the VHD as a page blob (provisioning will fail if the VHD was uploaded as a block blob). Add-AzureVHD and Csupload handle this for you automatically. But with other tools you could inadvertently upload the VHD as a block blob instead of a page blob.
   
   Upload only fixed VHDs (not dynamic, and not VHDX). Windows Azure Virtual Machines do not support dynamic disks or the VHDX format. Add-AzureVHD and CSUpload automatically convert dynamic VHDs to fixed VHDs before uploading them, but many other tools do not.
   
   The maximum VHD size is 127 GB for OS disks and 1023 GB for data disks.
   
   The VM must be configured for DHCP and not assigned a static IP address. Windows Azure Virtual Machines do not support static IP addresses.
   
   This forum post contains workarounds for common issues experienced while uploading VHDs. A list of storage tools is available here.
   
   
5. DNS name still in use after VM is removed
   
   Deleting a VM does not remove the associated cloud service automatically and hence you are unable to reuse the same DNS name until you delete the cloud service. To reuse the DNS name, delete the cloud service in the Cloud Services section of the management portal, using Remove-AzureService from Azure PowerShell, Azure Service Delete from the Azure CLI tool, or the Delete Hosted Service API (the terms Cloud Service and Hosted Service are synonymous in this scenario).
   
   When you create an Azure VM, a cloud service is created automatically with the DNS name you’ve provided for the VM. The management portal does not list this cloud service under "Cloud Services” section if it contains only a single VM. You will see the cloud service there if it contains no VMs (is empty) or multiple VMs. You can check the cloud service by using the Azure PowerShell Get-AzureService cmdlet. You can group or connect up to 50 virtual machines under a single cloud service (which is to say, behind the same external IP address and DNS name).
   
   
6. Securing Windows Azure Virtual Machines
   
   Refer to the following articles for information on reducing the attack surface of your VMs.
   
   http://fabriccontroller.net/blog/posts/securing-access-to-your-windows-azure-virtual-machines/
   
   http://social.msdn.microsoft.com/Forums/en-US/WAVirtualMachinesforWindows/thread/15ddae2b-1d44-45c4-a6e7-f80dad4db7c6 

   Below is another great resource related to cloud security and covers various security aspects. Though it is not directly targeted to virtual machines, it has tons of great information that will help windows azure virtual machines users to understand various security issues.

   http://blogs.msdn.com/b/jmeier/archive/2010/08/03/now-available-azure-security-notes-pdf.aspx 

    

7. Difference between capturing a VM and creating a snapshot
   
   Capturing a VM creates an image (not meant for backup) that can be used to create multiple VMs based on that same image. You can capture a VM using the Capture option in the portal, the Save-AzureVMImage Azure PowerShell cmdlet, using azure vm capture in the Azure CLI tool, or the Capture Role API.
   
   For VM backups, there is no equivalent to the Hyper-V snapshot feature for Azure VMs. However Azure storage has a blob snapshot feature that allows you to create a backup of the VHD blob in Azure storage. Microsoft does not currently provide a tool for creating blob snapshots, though third-party storage tools such as CloudXplorer include this feature. And you can write custom code to call the Snapshot Blob API to create a blob snapshot.
   
   You can also create a copy of a VHD using Azure storage tools. If the tool uses the 2012-02-12 version or later of the Copy Blob API, it will allow for fast cross-account blob copies, for example to move a VHD between different storage accounts. Most of the commonly used Azure storage tools also allow you to download files to on-premises. This forum post has steps to download the VHD using CloudXplorer. You can use any similar storage tools to perform the same task.
   

8. How to break the lease on VHD files
   
   The Windows Azure platform holds an infinite lease on all the page blobs that it considers disks in your storage account so that you do not accidently delete the underlying page blob, container, or storage account while the VHD is in use by the VM. If you want to delete the underlying page blob, the container where it resides, or the storage account, you will need to detach the disk from the VM first or delete the VM and associated disk object.
   
   In a few scenarios, you may end up getting errors while deleting VHDs even though there are no disks/VMs referring to the VHD. In such cases you can manually break the lease using the powershell script. Craig Landis has a detailed forum post describing these errors, workarounds along with the script.
   
   

9. RDP connectivity issues
   
   RDP connectivity issues can be caused by many different factors ranging from simple client firewall issue to a platform issue. You should start eliminating all client side issues first.
   
   Investigate client-side firewall issues by pinging the TCP port for the RDP endpoint using tools such as PsPing, PortQry, Telnet, or Nmap. See if your machine allows outbound communication to the RDP endpoint (TCP port 3389 for the first VM deployed to a cloud service, a random ephemeral port between 49152-65535 for additional VMs in the same cloud service). Verify the port on the Endpoints section for the VM in the portal. Since corporate firewalls often block 3389 and/or the ephemeral range (49152-65535), try connecting to the VM from a different network – from home, a wifi hotspot, or a mobile broadband connection.
   
   Drew McDaniel has  a forum sticky post with common issue like cache credentials, endpoint related issues.
   
   If you none of the above resolved connectivity issue, you can quickly try restarting/resizing the VMs to see if the problem goes away. If the problem persists you can reach out to the support forum. 
   
   

10. Platform updates to VM, restarts, shutdowns.
    
    Windows Azure updates the host OS approximately once every 1-3 months to keep the environment secure for all applications, virtual machines running on the platform. This update process may result in your VM to restart. You can use availability sets to ensure high availability for your applications running on virtual machines. Managing the high availability is detailed here. Mark Russinovich has posted a great blog post which explains Windows Azure Host updates in detail.
    
    In addition to platform updates, Windows Azure service healing occurs automatically when the Windows Azure detects problematic nodes and moves these VMs to new nodes. When this occurs, you loose connectivity to VM during the service healing process and after the service healing process is completed, when you connect to VM, you will likely to find a event log entry indicating VM restart/shutdown (either gracefully or unexpected).
    
    

11. VM activations
    
    While activating the OS on Windows Azure Virtual Machines, you may run into an error message stating the “A problem occurred when Windows tried to activate” Error Code 0xC004F074 with below details
    
    Code:
    0xC004F074
    Description:
    "The software licensing service reported that the computer could not be activated. No key management service could be contacted"
    
    Usually this is a transient issue the resolves itself over a short period of time. Please note that the inability to activate does not impact the services running on the server. While you will see notifications reminding you to activate the server if it is not yet activated, services and remote administration are not affected.
    
    Refer to forum post for more details.
    
    

12. Availability Sets, Affinity groups, Connecting VMs – Three different, distinct purposes
    
    An availability set is a way to achieve high availability for your virtual machines. An availability set is a group of virtual machines that are deployed across fault domains and update domains. An availability set makes sure that your application is not affected by single points of failure, like the network switch or the power unit of a rack of servers. Guidance for managing availability using availability sets can be found here.
    
    Affinity groups are the way to group the services in your Windows Azure subscription that need to work together in order to achieve optimal performance.
    
    When you create an affinity group, it lets Windows Azure know to keep all of the services that belong to your affinity group running at the same data center cluster. For example, if you want to keep the services running your data and your code together, you would specify the same affinity group for those services. That way, when you deploy those services, Windows Azure will locate them in a data center as close to each other as possible. This reduces latency and increases performance, while potentially lowering costs. Importance of affinity groups is described here.
    
    Connecting VMs – Load balancing
    
    You group multiple VMs together under a single cloud service to distribute the load to multiple VMs. The way you group is during the second VM creation, you choose “Connect to Existing Virtual Machine” and then select the cloud service under which you wanted to group the VMs. This article details how to load balance virtual machines.