Renaming an Azure Windows VM (Managed Disks)

In Azure, the renaming of resources (such as a VM) isn’t allowed.  That is, you can rename the OS/FQDN name of the VM at any time, but the display name in Azure is locked in at creation time.  If this bugs you, vote up the feature request here: https://feedback.azure.com/forums/216843-virtual-machines/suggestions/6132055-rename-vm

In the meantime, by tweaking a Microsoft provided script we can easily rename a VM by deleting the VM object (keeping all disks, NICs, IPs, etc.) and then recreating the VM using those existing objects.  The whole process should take ~10min (although it will vary based on the number of disks and NICs attached).

The below PowerShell script will work as-is for Windows VMs using managed disks and can easily be tweaked to run with Linux VMs or those using storage accounts.

# Nicole Welch, 10 January 2019 
# Rename existing Windows VM in Azure Portal (resource name)
# Based on https://docs.microsoft.com/en-us/azure/virtual-machines/windows/change-availability-set

Add-AzureRmAccount

# Set variables
     $resourceGroup = "Demo"
     $oldvmName = "myVM"
     $newvmName = "newVM"

# Get the details of the VM to be renamed
     $originalVM = Get-AzureRmVM `
        -ResourceGroupName $resourceGroup `
        -Name $oldvmName

# Remove the original VM
     Remove-AzureRmVM -ResourceGroupName $resourceGroup -Name $oldvmName    

# Create the basic configuration for the replacement VM
    $newVM = New-AzureRmVMConfig -VMName $newvmName -VMSize $originalVM.HardwareProfile.VmSize
    Set-AzureRmVMOSDisk -VM $newVM -CreateOption Attach -ManagedDiskId $originalVM.StorageProfile.OsDisk.ManagedDisk.Id -Name $originalVM.StorageProfile.OsDisk.Name -Windows

# Add Data Disks
     foreach ($disk in $originalVM.StorageProfile.DataDisks) { 
     Add-AzureRmVMDataDisk -VM $newVM `
        -Name $disk.Name `
        -ManagedDiskId $disk.ManagedDisk.Id `
        -Caching $disk.Caching `
        -Lun $disk.Lun `
        -DiskSizeInGB $disk.DiskSizeGB `
        -CreateOption Attach
     }

# Add NIC(s)
     foreach ($nic in $originalVM.NetworkProfile.NetworkInterfaces) {
         Add-AzureRmVMNetworkInterface `
            -VM $newVM `
            -Id $nic.Id
     }

# Recreate the VM
     New-AzureRmVM `
        -ResourceGroupName $resourceGroup `
        -Location $originalVM.Location `
        -VM $newVM `
        -DisableBginfoExtension

Azure IaaS VMs and the Three (now Four!) R’s

When you have a problematic IaaS VM (won’t start, won’t stop, can’t RDP even though it worked just yesterday….) and you’ve exhausted your usual tricks, turn to the Three Four R’s (the “did you reboot?” of Azure).

  1. Restart – Most users will think of this, just be sure you restart (and I mean a stop and start, not the restart button) from Azure (portal or PS) and not from the VM.  The Azure restart will give the fabric a chance to look for issues and self-heal.  Note: If you have a classic VMs (old portal) this also applies to your cloud service.  I’ve seen VMs acting up due to issues with their cloud service.  You can try restarting the cloud service….but keep in mind all hosted VMs by the cloud service will be restarted as well!
  2. Resize – Resizing (esp. if you increase the VM size to the largest possible), it will recreate certain elements of the VM <-> Fabric connection and could even move you to a new cluster node on the backend.   Resize, test to confirm it’s working, and then size back to your original size.  You will get charged at the higher VM size rate, but if it’s only for 15min that’s a minimal cost.  *Note: if you’re in ARM (VMs deployed via the new portal, not a classic VM) you can directly redeploy to a new cluster node using Azure powershell: https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-redeploy-to-new-node/ (step 4 below)
  3. Recreate – This one sounds scary, but if you make a note of your current configuration FIRST the recreation is quick (generally <20min) and relatively painless.  If you need to move your VM to a new cloud service, VNet, etc. or are having those “it’s just acting up” issues this is a good troubleshooting step to try out.   You basically are removing the Azure components and then recreating the Azure components (modifying if needed) — all while leaving your disks untouched.  See https://www.petri.com/recreate-virtual-machine-in-microsoft-azure  for step-by-step instructions.  *Note: The link is specific to ASM (classic portal) but the premise works for both classic and ARM VMs.
  4. Redeploy – Available in the new portal only for ARM VMs (not classic).  Effectively the same as a resize, only guaranteed that you change nodes.  https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-redeploy-to-new-node/

If these all fail, and you already confirmed there are no outages that could impact you (https://azure.microsoft.com/en-us/status/), it may be time to engage Microsoft.

See also https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-windows-allocation-failure/

*previously posted at https://blogs.msdn.microsoft.com/nicole_welch/2016/05/azure-iaas-vms-and-the-three-rs/

Azure VMs need Internet Access

When customers move into the cloud, they tend to mimic their setup on-prem.  Not a bad thing, but when it comes to blocking internet access for servers this can create some unusual problems.

If you are using network security groups (NSGs), user defined routing (UDR), or forced-tunneling be sure to put in an exception for your Azure data center IP ranges, as lack of connectivity will impact many services including these:

  1. VM Extensions see https://blogs.msdn.microsoft.com/mast/2016/04/27/vm-stuck-in-updating-when-nsg-rule-restricts-outbound-internet-connectivity/
  2. Azure Backup see https://azure.microsoft.com/en-us/documentation/articles/backup-azure-vms-prepare/#network-connectivity
  3. Monitoring Agent/Extension see https://docs.microsoft.com/en-us/azure/log-analytics/log-analytics-proxy-firewall#configure-settings-with-the-microsoft-monitoring-agent
  4. KMShttps://docs.microsoft.com/en-us/azure/virtual-machines/troubleshooting/custom-routes-enable-kms-activation

Update 16 Aug 2018 – The use of service endpoints will limit the damage of blocking internet access.  Ensure all services you use/require are covered by service endpoints before blocking internet access.  https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-service-endpoints-overview

*previously posted at https://blogs.msdn.microsoft.com/nicole_welch/2016/08/azure-vms-need-internet-access/

Working with Azure ARM VMs, Images, and Unmanaged Disk (Storage Accounts)

A lot of the pre-managed disk documentation has become hard to find.  Below is a cheat-sheet on where to find the documents you need to work with Azure ARM VMs, images, and storage accounts.

Create an Azure VM from custom image (VHD) – https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sa-upload-generalized

Create an Azure VM from existing VHD – https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sa-create-vm-specialized

Create an Azure VM Image (and VM) from existing Azure VM – https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sa-copy-generalized

*previously posted at https://blogs.msdn.microsoft.com/nicole_welch/2017/07/working-with-vms-images-and-unmanaged-disk-storage-accounts/