Don’t Let UEFI Get in Your Way of Free Extended Support for 2008 or 2008 R2 Versions of Windows and SQL Server
Ok, so I admit it, the title of this blog is a mouthful! But it was intriguing enough to get you to this point, so why not read on…
Why are we even talking about Server 2008?
I am not one to recommend staying on legacy systems by any means. I’m a full-steam ahead guy! There are cases, however, where a legacy system is better off staying as is and there isn’t much you can do about that. Consider the following cases:
- A line of business application is no longer supported by the developer and was never upgraded to run on newer OS’s.
- An application is highly customised or even home-grown and support for those customizations is not readily available.
- The legacy system is in a run-off state, slated to be replaced by a modern system.
- The legacy system has been replaced by a modern system, however, the old system needs to remain for historical reference.
Bad news and good news …
Assuming for a minute we are talking about 2008 or 2008 R2 versions of Windows and SQL Server, then I have bad news and good news. The bad news (which you must know by now unless you are living under a rock), is SQL 2008 support ends on July 9th 2019 and Windows 2008 Support ends on January14th 2020. The good news, which you may not know, is when you migrate these servers to Microsoft Azure, you receive an extra 3 years of Extended Security Updates! In Azure: Customers running 2008 or 2008 R2 versions of SQL Server and Windows Server in Azure virtual machines get Extended Security Updates for free.
What if you can’t migrate them to Azure in time? If you have active Software Assurance or subscription licenses, you can purchase Extended Security Updates annually for 75 percent of the full license cost of the latest version of SQL Server or Windows Server. You only pay for only the servers you need to cover, enabling the annual reduction of costs as you upgrade parts of your environment.
Bad news and good news …
Moving these systems to Azure may be a good option and will allow you to:
- Get them out of your datacenter to free up resources
- Protect and retain it with Azure Backup and not have to worry about including it in your backups anymore
- Shut down systems not needed 24×7, enabling the reduction of Azure costs since you only pay for servers while they are running
- Receive free extended support for 3 years! Woohoo!
Ok, so … How exactly do we move these severs to Azure?
That’s simple, Azure Site Recovery (ASR) the versatile Disaster Recovery (DR) as a Service (DRaaS) tool! ASR allows you to replicate servers to Azure and to fail over to them (DR capability) or just to fail over to them as your new production servers now in Azure! When a server is eligible to migrate with ASR, the process is quite easy and there are tons of how-to’s out there to guide you, so I won’t recreate the wheel here.
There are some conditions, however, which will make a server ineligible for migration. If you have one of these cases, you may face challenges in getting your workloads migrated easily.
1. Size matters.
Your server may have a disk bigger than the currently largest ASR supported disk (4TB as of this writing). The only work around for this scenario is to find a way to shrink the disk or migrate the data to a smaller disk under the limit, then remove the original oversized disk.
Before you start thinking about partition tools, there is a big distinction here – we aren’t talking about the “volume” size, we’re talking about the underlying disk size since ASR is a block-based replication tool, not file based. So, if you have a 4.5TB disk with a 1TB volume 3.5TB unallocated space, it doesn’t matter… you are not able to migrate this server. A popular solution to this scenario is to perform a physical to virtual (P2V) or virtual to virtual (V2V) conversion during which you can then shrink the virtual disk drive of the target.
2. OS matters.
Your servers must be running at least Windows 2008 SP2 to be supported by Azure Site Recovery. If they are running 2008 R2 it’s pretty straight forward, however, if they are 2008 SP2, then you should read this article.
3. UEFI matters.
I promised to mention UEFI! UEFI or Unified Extensible Firmware Interface replaces the older BIOS or Basic Input Output System (the older crowd will remember BIOS). Azure Site Recovery will support migrating UEFI systems into Azure if they are running Server 2012 or later (think Generation 2 Hyper V). But in the case of a 2008 server with UEFI, ASR will not allow you to migrate since the VM will not boot in Azure!
This is a scenario I recently found myself in. Of course, the server in question was the mission critical Server 2008 R2 Oracle server that nobody wanted to touch, let alone upgrade! For this we had to roll up our sleeves and try to figure out how to make this migration happen. There are plenty of articles out there on how to get servers from legacy BIOS to UEFI but a very limited amount of info out there to go in the other direction! So how do you do it?
First things first, I would HIGHLY recommend doing this on a virtual machine (VM) and taking a snapshot before starting just in case. This is the kind of stuff that could leave you with an unbootable system if something goes wrong!
If the server is physical, I would recommend performing a P2V conversion and performing these steps on the VM. From there you can use ASR to replicate the VM directly to Azure. You can do this with both Hyper-V and VMWare, however, the VMWare process is much simpler.
A. VMWare process:
If your system is physical, you can perform a P2V with the free VMWare Converter tool.
Here is the process…
Note: I did this on 2008R2 so I cannot guarantee it will work in 2008 SP2 but it should and if you take a snapshot you are safe to try since you can always revert. Also, I apologise for the lack of screenshots, but I promise it’s straightforward:
- With the VM off, take a snapshot!
- Make sure you took a snapshot!
- I used this tool from Easus, called Partition Manager, to convert the boot disk from GPT partition to MBR. You will need a server license, which was priced at $160 USD at the time of this writing. Other partition management tools can do this as well and the prices are all very similar based on my brief research.
- Run the software directly from the server and choose to convert the disk that contains the boot drive C, from GPT to MBR.
- Once you click apply to commit the changes, the server will tell you it must reboot to perform the conversion. Click Ok.
- It will reboot and begin the conversion which shouldn’t take more than a couple of minutes. Then it will tell you it needs to reboot again. Click Ok.
- Now, once the machine begins rebooting the second time you need to stop the virtual machine from VMWare and edit the VM properties.
- Edit the boot settings of the VM and change from UEFI to BIOS, click Ok and start your VM.
Your system should now boot up, no longer be running UEFI and be eligible to migrate to Azure! You will know eligible for Azure because you will be able to enable protection or manually install the Azure Site Recovery Mobility Service.
B. Hyper-V process:
This process is quite a bit more complicated since you must create a Generation 2 VM from a UEFI source, however, Hyper-V Generation 2 doesn’t support Server 2008 (reminds me of my dog when he chases his tail). There is a great YouTube video about how to convert a GPT partition to MBR on Hyper-V by Robert McMillen which you can find here. This process would be the same to get a Hyper-V VM ready for ASR. Thanks, Robert, for that great video!
That’s it for now, happy migrating of those old ball-and-chain servers that you’re stuck with!
