Although Windows Server 2003 is long since been supported officially by Microsoft, and everyone should really be off the platform, there are some legacy applications still used in production that rely on these legacy operating systems.
To my knowledge, Microsoft has never supported Server 2003 on Azure, since its inception, and they pulled support for Server 2008 a good few years ago. It is, however, possible to run “unsupported” versions of Windows inside Azure IaaS VM’s, provided you don’t whine to Microsoft if they don’t work correctly. As Azure runs a flavour of Hyper-V, generally any specialised VHD you upload will run. You can prove this by using boot diagnostic screenshots, however the most frustrating thing to follow this is being unable to access the VM once you know it has booted.
This can even be the case if you follow the official guidance on preparing VHD’s for Azure
The above article walks you through ensuring the VM is configured correctly to support incoming RDP connections etc. It is however all done in PowerShell, most of the commands don’t run successfully on Server 2003 so you have to decipher and perform most of the changes manually using either the registry or CMD.
If you are going to run Server 2003 on Azure, you must ensure the Hyper-V Integration Services are installed inside the VM. One of the annoying things, if you are coming from VMware, is that the Integration Tools will fail to install if the setup does not detect Hyper-V. When I’m moving VMware VM’s I usually have a Hyper-V host available to do some testing, you can now run nested Hyper-V 2016 on Azure if you use certain instance types.
Full details on nested Hyper-V on Azure
It’s very simple to get nested Hyper-V going, you simply deploy a Server 2016 instance using one of the instance types that support nested virtualization. You then just install Hyper-V normally, after a few reboots you will have a nested Hyper-V server.
As tools such as ASR are out of the question if you are dealing with unsupported operating systems, I use the following method;
- · Ensure you have the local admin password available.
- · Prepare VM using checklist provided by MS.
- · Install the Azure VM Agent/Hyper-V Integration Services (2008 R2 onwards)
- · Use Disk2Vhd to convert the VM to VHDs (not VHDX).
- · Use Hyper-V to convert the dynamic VHD’s to fixed size VHD’s
- · Move the VHD’s to Azure Storage using Storage Explorer
- · Use nested Hyper-V to test the converted VM’s boot to Windows
o Even if you are coming from on premise you can use nested Hyper-V in Azure, I usually make use of the high bandwidth available in Azure. If you have uploaded VHD’s to Azure Storage it is possible to download the VHD’s into your nested Hyper-V instance (at 100mbp/s ~), the upload speed is quick as well.
o Only the newest versions of VMware support nested Hyper-V so it might be a good method if you cannot get a HV host up and going. The Azure route also helps if you do not have enough capacity to deploy a nested Hyper-V server.
o When you run a VM inside the nested Hyper-V you will then have the ability to run the Hyper-V Integration Services, in my experience, these are required as a minimum for a VM to be reachable inside Azure (NIC drivers required). Even if your VM does not support the Azure VM Agent, you can get a VM connected if the Hyper-V integration services are installed.
o Server 2016 does not provide the Integration Services ISO in the usual place C:\Windows\System32\vmguest.iso. However, you can get the ISO from Server 2012 R2.
· Use predefined ARM templates to deploy a specialised VM from a VHD.
o https://github.com/Azure/azure-quickstart-templates/tree/master/201-vm-specialized-vhd-existing-vnet
