In this blog, I will discuss how you can replicate and eventually protect a client OS, e.g. Windows 7, Windows 8, or Windows 10 to Azure with the Azure Site Recovery (ASR), even if you don’t have an MSDN subscription.
Before we do so however, this blog will not go into detail on how to set up ASR. The steps are outlined on Microsoft’s Azure ASR website.
It may sound simple, and it really is, but there’s a catch into getting this done. Microsoft asks that you treat a virtualised Client OS e.g. Windows 7 as a physical machine (as explained below) in order to replicate it. The same applies for a physical Windows 7 machine.
Before you Begin – Important Notes
This blog post is for educational purposes only.
Kloud will not be and is not responsible for any issues that may occur and be a result of your own wrongdoing. Therefore it is recommended to backup your machine before proceeding.
It is also recommended to check with Microsoft regarding the legality of running a Windows Client OS in Azure.
Although Microsoft states the following, found here.
Can I protect VMs when Hyper-V is running on a client operating system?
No, VMs must be located on a Hyper-V host server that’s running on a supported Windows server machine. If you need to protect a client computer, you could replicate it as a physical machine to Azure or a secondary datacentre.
Microsoft also states the followings, about Client machines, found here.
Can customer rent Windows Client desktops on Azure or other Service providers?
No, multi-tenant hosting is restricted in the Product Use Rights of Windows Client, such as Windows 7 or Windows 8. Windows Client Desktops are not available on either Azure or on any other Service Provider such as Amazon or Rackspace. You can read more about the Microsoft Product Use Rights here.
Can customer run Microsoft Office and the Windows 7 Client on Virtual Machines using License Mobility for Software Assurance?
No. Under the Microsoft Product Use Rights (PUR), Office and Windows 7 are not licensed to run on Virtual Machines. In particular, Microsoft Office is classified in the PUR as a “Desktop Application”, which is not included in Licensing Mobility.
More information is available at the site for Microsoft Product Use Rights.
With these information in mind, it is important for you to check the attached links. As it may be illegal to run a Client OS in Azure.
I’m aware the wording from both Microsoft’s websites (ASR FAQ, and Product Use Rights) may be confusing, therefore it is recommended to check with Microsoft before proceeding with the steps outlined below.
What is Azure Site Recovery?
Azure Site Recovery is an Azure service that contributes to your BCDR strategy by orchestrating replication of on-premises physical servers and virtual machines to the cloud (Azure) or to a secondary datacentre. When outages occur in your primary location, you fail over to the secondary location to keep apps and workloads available. You fail back to your primary location when it returns to normal operations.
This isn’t a new technology per se, VMware had its own replication technology integrated with vSphere, VMware Site Recovery Manager (SRM). Microsoft has its own Hyper-V Replica, which I would like to think is the cornerstone of Azure Site Recovery.
Like VMware and Hyper-V, other vendors offered replications to a secondary site, e.g. VEEAM Backup and Replication. However, Microsoft’s own Azure Site Recovery takes it to a new level, by allowing to replicate Hyper-V hosts, VMware, and physical machines, to Azure, or a secondary site.
Why replicate Client OS to Azure?
It’s a fair question to ask, why would I need to replicate a client OS that is either running Windows 7 Windows 8, or Windows 10 to Azure? What purpose would it serve?
There are many organizations out there, that might have a business critical application that runs only on a client OS, doesn’t function if installed on a Windows Server, and it doesn’t run in compatibility mode. Some of those application, may be running on Windows XP even.
Or, simply for the sake of protecting your own machine!
How to Replicate a Client OS to Azure?
Whenever you install a Client OS, be it Windows 7, Windows 8.1, or Windows 10, Windows will automatically create a System Reserved partition.
The System Reserved partition is an important partition, in which without it your Client OS will not boot. The reason to that, is that all the booting files, and BitLocker files are installed on that partition.
If you replicate your Client OS with the System Reserved partition to Azure with ASR, your Client OS VM will not start.
Solution: Copy the Windows booting files and Windows RE (Windows 8.x, and Windows 10 only) to the Windows partition, apply the necessary BCD file corrections, and remove the System Reserved partition.
However, before doing that, I advise you to read this article from Microsoft first. The is because Windows booting files must reside on a partition with an NTFS cluster size of 4K (the default size).
Also too, if you are using a version of Windows that supports BitLocker and are currently using BitLocker, it is recommended to have it turned off before replicating the Client OS machine to Azure, that is because Azure does not support OS Disk Encryption (as of this writing) however, it does support data-at-rest encryption on Data disks.
Important article on Data Volumes Encryption in Azure.
Nevertheless, if you’re so keen on having BitLocker turned on the OS disk, you may want to consider having a look at Cloudlink, before replicating your Client OS Machine. (This is also useful for Servers).
Back to moving the booting files, there are many ways in which you could move the booting files from System Reserved partition, to the active Windows partition.
TeraByte (the company offering BootIT BM) has a thorough guideline available here.
Again, not everyone is going to replicate Client OS to Azure but as aforementioned, it really depends. And Microsoft, asks you to have an MSDN subscription if you want to run a client OS in Azure.
And if you have a business critical application that only runs on a Client OS, and you need to protect it, it is worth going through the steps above and replicate the machine through ASR.
Still, some just might find the idea intriguing, and have a machine available at your fingertips should you lose access to your own machine (theft, damage, broken, or even corrupt disk).
Hopefully you’ve found this guide informative. Please feel free to post your comments below.