Admins must prepare their workloads for the Windows Server 2008 and 2008 R2 end of support. Otherwise, they risk the possibility of significant security breaches.
With Windows Server 2008 and 2008 R2 end of support on Jan. 14, 2020, virtualization administrators must come up with a plan for their Windows Server 2008 VMs. Unfortunately, continuing to run Windows Server 2008 or 2008 R2 on VMs isn't a viable option.
Although the OSes will continue to function after Windows Server 2008 end of life, Microsoft will no longer provide security updates, leaving VMs vulnerable. There are two main options available to those who currently have Windows Server 2008 or 2008 R2 VMs running in their data centers. They can migrate to Azure cloud or upgrade the Windows OS.
Migrate to Azure cloud
One way of coping with the impending Windows Server 2008 end of life is to migrate VMs to Azure cloud. Microsoft is incentivizing this option by enabling migrated VMs to run Windows Server 2008 or 2008 R2. Admins who migrate their Windows Server 2008 or 2008 R2 VMs to Microsoft Azure will receive three additional years' worth of security updates. These updates aren't available for VMs that run on premises.
Migrating Windows Server 2008 or 2008 R2 VMs to Azure is a relatively easy process. First, admins must make sure that their VMs are running Windows Server 2008 SP2 or later. Next, admins must configure VMs to enable remote management -- from any version of Remote Desktop Services -- and they must open port 3389 in the Windows firewall. Once admins complete this, they must set the VM's passwords to never expire. Finally, admins can upload the VM's virtual hard disk file to Microsoft Azure. Microsoft provides step-by-step instructions for the entire process.
Upgrade the Windows OS
If admins want to keep their VMs running on premises, then their best option is to upgrade to a newer OS. When it comes to OS upgrades, Microsoft generally recommends that admins create a new VM that runs the new OS, and then migrate their workloads from the old VM to the new VM.
This approach helps to ensure security and stability because the workload is running on top of an OS that admins cleanly install. Transitioning workloads to a new VM also gives admins the option of using a different storage configuration or adopting the Resilient File System.
Admins who migrate their Windows Server 2008 or 2008 R2 VMs to Microsoft Azure will receive three additional years' worth of security updates.
It's sometimes necessary to perform an in-place OS upgrade on an existing VM, rather than creating a new VM and migrating the workloads. This is especially true when an application that is running on a legacy VM can't be easily reinstalled on a new VM. For example, admins might require an in-place upgrade if they no longer have access to an application's installation files or if they used up all of the application's license activations.
If admins decide to perform an in-place upgrade, then their upgrade path might vary depending on the version of Windows Server they adopt. For example, admins can't upgrade directly from Windows Server 2008 to Windows Server 2016. However, admins can upgrade to Windows Server 2012 R2 and then to Windows Server 2016.
Admins also can't change system architectures such as 32-bit and 64-bit during an in-place upgrade, nor can they change the OS's language.
Admins should understand that Microsoft removed the option to switch from Server Core to the full GUI experience in Windows Server 2016. This means that if a VM is currently running Server Core and admins want to switch to GUI mode -- or the other way around -- they must upgrade the VM to Windows Server 2012 R2, switch to the mode they want to use and then continue on with an upgrade to Windows Server 2016 or later.
Regardless of whether admins decide to migrate their Windows Server 2008 and 2008 R2 VMs to the Azure cloud or perform an in-place upgrade, it's critical to make a backup of the VMs beforehand. This gives admins a way of putting everything back the way that it was in the event that something goes wrong. When possible, it's also a good idea to rehearse upgrades in a sandboxed environment prior to attempting a production VM upgrade.
