How to upload a custom image to Azure

Share this:

If you developed your standard Windows or Linux operating system image for installation on on-premises computers, you might want to use the same image to deploy Azure virtual machines. This provides consistency of your hybrid environment, helping to ensure that the computers you manage comply with your standards, regardless of their location.

Follow these steps to use custom, on-premises operating system images to deploy Azure virtual machines:

  1. Ensure that the custom image configuration does not conflict with the Azure virtual machine requirements, including:

o    Virtual machine generation. Azure virtual machines support only Generation 1. If you are running a Generation 2 virtual machine, you must reinstall it or use Azure Site Recovery to migrate it to Azure.

o    Virtual machine disk size. Azure virtual machine disks cannot exceed 1,023 GB.

  1. Generalize the image. Start with an existing computer running your custom-configured operating system. If this is a Windows computer, run the Sysprep.exe utility with the /generalize, /oobe, and /shutdown switches. Sysprep.exe is one of the operating system files and resides in the %windir%\system32\sysprep folder. If this is a Linux computer, the process depends on the Linux distribution.
  2. Capture and prepare the disks for upload to Azure Storage. If you have a physical computer running Windows that you want to use as the image source, use the Disk2vhd utility. This utility allows you to convert individual physical disks into .vhd files, which you can subsequently upload to Azure Storage. If your source virtual machines reside on the VMware virtualization platform, use Microsoft Virtual Machine Converter 3.0, which supports converting .vmdk files to the .vhd format. If you use the Hyper‑V virtualization platform but your virtual disk files are in the .vhdx format, convert them to the .vhd format directly from the Hyper‑V Manager console. To streamline the conversion process, run the Convert-VHD Windows PowerShell cmdlet. In the case of a physical server running Linux, you must use third-party utilities.
  3. Additionally, you must ensure that the disk size in megabytes (MB) is a whole number. To accomplish this, use the Resize-VHD Windows PowerShell cmdlet.
  4. Create an Azure storage account. Choose the same deployment model that you intend to use to create Azure virtual machines based on your custom image. Classic Azure virtual machines cannot access the content of Azure storage accounts created with the Azure Resource Manager deployment model, and conversely, virtual machines created with the Azure Resource Manager deployment model cannot access classic Azure storage accounts.
  5. Upload the .vhd file to an Azure storage account. I recommend running the Add-AzureRmVhd cmdlet.
  6. When you create an Azure virtual machine, use the location of the uploaded .vhd file containing the image as the value of the –SourceImageUri parameter of the Set-AzureRmVMOSDisk Windows PowerShell cmdlet. Make sure to include the ‑CreateOption parameter with the fromImage value as part of the same cmdlet. You should also install the Azure virtual machine agent as part of the virtual machine provisioning. To accomplish this, include the –ProvisionVMAgent parameter when running the Set-AzureRmVMOperatingSystem Windows PowerShell cmdlet.

Note: When uploading images of on-premises virtual machines to Azure, ensure that the paging file is configured to reside on the D: drive. This way, you can automatically use the temporary disk that Azure provides for Azure virtual machines. This temporary disk maps to local storage on the Hyper‑V hosts rather than to Azure Storage. By using the local Hyper‑V storage, you avoid transactional charges for Azure Storage whenever the operating system that runs in the Azure virtual machine accesses the paging file.

Note: When deploying custom-image-based retail or volume licensed editions of Windows to Azure virtual machines, consider using the Azure Key Management Service (KMS). Set up the Windows installation with the Generic Volume License Key and ensure that resolves to the Azure public IP address rather than your on-premises KMS instance.


Marcos Nogueira
Twitter: @mdnoga

Written by Marcos Nogueira

Marcos Nogueira

With more than 18 years experience in Datacenter Architectures, Marcos Nogueira is currently working as a Principal Cloud Solution Architect. He is an expert in Private and Hybrid Cloud, with a focus on Microsoft Azure, Virtualization and System Center. He has worked in several industries, including Aerospace, Transportation, Energy, Manufacturing, Financial Services, Government, Health Care, Telecoms, IT Services, and Gas & Oil in different countries and continents.

Marcos was a Canadian MVP in System Center Cloud & Datacenter Managenment and he has +14 years as Microsoft Certified, with more than 100+ certifications (MCT, MCSE, and MCITP, among others). Marcos is also certified in VMware, CompTIA and ITIL v3. He assisted Microsoft in the development of workshops and special events on Private & Hybrid Cloud, Azure, System Center, Windows Server, Hyper-V and as a speaker at several Microsoft TechEd/Ignite and communities events around the world.

Related Post

Managing Hyper-V Server remotely through PowerShel... Working with PowerShell can be very common for daily tasks and Hyper-V Server management. However, as there is more than one server to be managed, som...
Windows Azure and Office365 – Preparing the enviro... Before starting the integration process with Windows Azure a couple of settings are required on both environments: on-premises and Windows Azure Activ...
Automating the process to join a server to a domai... In this Tutorial we are going to optimize a simple task that in larger environments may take some time from the service desk/operations team which is ...
Hyper-V 2012 Hotfixes: Where I can find it and how... After my session at TechEd about Best Practices for Virtualizing and Managing Microsoft SharePoint 2013 with Microsoft System Center 2012 R2 and Windo...