written by Adam El-Gerbi
Recently we began an Azure Site Recovery implementation project for a client who wanted a cloud-based disaster recovery infrastructure. For those now familiar, Azure Site Recovery allows a few options when doing V2V style migrations. Since we specialize primarily in VMware hypervisors, we opted to use the virtual appliance MS provides to facilitate this.
Once installed, you login to the appliance and complete a fairly simple web-based wizard to get your configuration server up and connected to Azure from your on-premises VMware environment. Our critical VMs that we wanted to replicate included a domain controller, remote desktop services, file server, and proprietary financial application server.
After the configuration server was setup and all the prerequisite resource and recovery vault objects are created in Azure, you must create a replication job. We created a job with the aforementioned 4 servers. After around 30 minutes, two servers showed that the mobility service (like an ASR agent) was successfully deployed.
However, two remaining servers were stuck attempting to deploy mobility service. After troubleshooting, we reviewed the VMware to Azure support matrix and determined Windows Server 2019 was not supported! Later, opening a ticket with MS confirmed that this was the case. We previously worked with this client to upgrade servers whose operating system was at or near end of life, including virtualization infrastructure and guest OS (VMware and Windows). However, it turned out that Microsoft was not supporting its own latest OS in April 2019 on Azure. Note that Windows Server 2019 was released in October 2018, 6 months before.
I was personally told by a Microsoft employee who consulted with their product team that this would not be the case until Q2 2020. We pursued other options but eventually had to notify our client that these two servers would not be protected in Azure until support was officially added. The project would be put on hold.
Recently as of May 2019, Microsoft updated their support matrix to say Windows Server 2019 was now supported on Azure using 9.22 versions of Mobility Service. I reached out to support again and this time the technician confirmed this support was added. We tried to push the mobility service agent again by re-running the replication job again, but it eventually failed. The culprit? UEFI is NOT supported in Azure, you must use BIOS.
Researching this problem extensively we came up with the following steps to migrate a Windows Server 2019 (steps likely are the same for Windows 8 through Windows 10, Servers 2012 through 2019) from UEFI to BIOS:
Warning: Before proceeding we strongly urge you have a recent backup of your server before making changes.
- Switch VM to use BIOS
- Shutdown VM you are going to convert
- Edit VM settings
- VM Options -> Disable virtualization based security
- Boot Options -> Switch firmware to use BIOS.
- Convert GPT boot drive to MBR using a disk tool.
- Download System Rescue CD
- Mount and boot the ISO in the VM
- Type fdisk -l
- Select your boot disk to be converted, typically /dev/sda, using: gdisk /dev/sda
- You will see menu prompts, use the following letters for each prompt: (r,g,p,w)
- type y to finalize
- Shutdown VM
- Rebuild boot record on MBR boot disk
- Boot into original Windows Server ISO and go to repair your computer -> troubleshoot
- Select Command prompt
- Type diskpart
- List disk
- Select disk <boot disk>, boot disk is usually 0
- List partition
- Select partition <boot partition>, look for \Windows
- Switch to boot drive, usually c:
- BCDBOOT c:\Windows
- bootrec /fixmbr
- Reboot and try to boot back into Windows again.
Thanks to tips (see comments) from Ingvarj and Dualjob for providing detailed steps to help us get to this solution, found here: https://4sysops.com/archives/how-to-convert-windows-8-from-bios-to-uefi