Migrate servers running Windows Server 2008 to Azure
This tutorial shows you how to migrate on-premises servers running Windows Server 2008 or 2008 R2 to Azure using Azure Site Recovery. In this tutorial, you learn how to:
- Prepare your on-premises environment for migration
- Set up the target environment
- Set up a replication policy
- Enable replication
- Run a test migration to make sure everything's working as expected
- Failover to Azure and complete the migration
The limitations and known issues section, lists some of limitations and workarounds for known issues that you may encounter while migrating Windows Server 2008 machines to Azure.
Supported Operating Systems and environments
|Operating System||On-premises environment|
|Windows Server 2008 SP2 - 32 bit and 64 bit(IA-32 and x86-64)
- Standard- Enterprise
|VMware VMs, Hyper-V VMs, and Physical Servers|
|Windows Server 2008 R2 SP1 - 64 bit
- Standard- Enterprise
|VMware VMs, Hyper-V VMs, and Physical Servers|
- Migration of servers running Server Core is not supported.
- Ensure that you have the latest service pack and Windows updates installed before migrating.
To migrate Hyper-V virtual machines running Windows Server 2008 or Windows Server 2008 R2, follow the steps in the migrate on-premises machines to Azure tutorial.
The rest of this tutorial shows you how you can migrate on-premises VMware virtual machines and Physical servers running Windows Server 2008 or 2008 R2.
Looking for an agentless way to migrate VMware VMs to Azure? Click here
Limitations and known issues
The Configuration Server, additional process servers, and mobility service used to migrate Windows Server 2008 SP2 servers should be running version 188.8.131.52 or later of the Azure Site Recovery software.
Application consistent recovery points and the multi-VM consistency feature are not supported for replication of servers running Windows Server 2008 SP2. Windows Server 2008 SP2 servers should be migrated to a crash consistent recovery point. Crash consistent recovery points are generated every 5 minutes by default. Using a replication policy with a configured application consistent snapshot frequency will cause replication health to turn critical due to the lack of application consistent recovery points. To avoid false positives, set the application-consistent snapshot frequency in the replication policy to "Off".
The servers being migrated should have .NET Framework 3.5 Service Pack 1 for the mobility service to work.
If your server has dynamic disks, you may notice in certain configurations, that these disks on the failed over server are marked offline or shown as foreign disks. You may also notice that the mirrored set status for mirrored volumes across dynamic disks is marked "Failed redundancy". You can fix this issue from diskmgmt.msc by manually importing these disks and reactivating them.
The servers being migrated should have the vmstorfl.sys driver. Failover may fail if the driver is not present in the server being migrated.
Check if the driver is present at "C:\Windows\system32\drivers\vmstorfl.sys" . If the driver is not found, you can workaround the issue by creating a dummy file in place.
Open command prompt (run > cmd) and run the following: "copy nul c:\Windows\system32\drivers\vmstorfl.sys"
You may be unable to RDP to Windows Server 2008 SP2 servers running the 32-bit operating system immediately after they are failed over or test failed over to Azure. Restart the failed over virtual machine from the Azure portal and try connecting again. If you are still unable to connect, check if the server is configured to allow remote desktop connections, and ensure that there are no firewall rules or network security groups blocking the connection.
A test failover is highly recommended before migrating servers. Ensure that you've performed at least one successful test failover on each server that you are migrating. As part of the test failover, connect to the test failed over machine and ensure things work as expected.
The test failover operation is non-disruptive and helps you test migrations by creating virtual machines in an isolated network of your choice. Unlike the failover operation, during the test failover operation, data replication continues to progres. You can perform as many test failovers as you like before you are ready to migrate.
Perform the following tasks to prepare the Azure subscription and on-premises VMware/Physical environment:
Create a Recovery Services vault
Sign in to the Azure portal > Recovery Services.
Click Create a resource > Management Tools > Backup and Site Recovery.
In Name, specify the friendly name W2K8-migration. If you have more than one subscription, select the appropriate one.
Create a resource group w2k8migrate.
Specify an Azure region. To check supported regions, see geographic availability in Azure Site Recovery Pricing Details.
To quickly access the vault from the dashboard, click Pin to dashboard and then click Create.
The new vault is added to the Dashboard under All resources, and on the main Recovery Services vaults page.
Prepare your on-premises environment for migration
- To migrate Windows Server 2008 virtual machines running on VMware, setup the on-premises Configuration Server on VMware.
- If the Configuration Server cannot be setup as a VMware virtual machine, setup the Configuration Server on an on-premises physical server or virtual machine.
Set up the target environment
Select and verify target resources.
- Click Prepare infrastructure > Target, and select the Azure subscription you want to use.
- Specify the Resource Manager deployment model.
- Site Recovery checks that you have one or more compatible Azure storage accounts and networks.
Set up a replication policy
- To create a new replication policy, click Site Recovery infrastructure > Replication Policies > +Replication Policy.
- In Create replication policy, specify a policy name.
- In RPO threshold, specify the recovery point objective (RPO) limit. An alert is generated if the replication RPO exceeds this limit.
- In Recovery point retention, specify how long (in hours) the retention window is for each recovery point. Replicated servers can be recovered to any point in this window. Up to 24 hours retention is supported for machines replicated to premium storage, and 72 hours for standard storage.
- In App-consistent snapshot frequency, specify Off. Click OK to create the policy.
The policy is automatically associated with the configuration server.
Ensure that you specify OFF in the App-consistent snapshot frequency setting of the replication policy. Only crash-consistent recovery points are supported while replicating servers running Windows Server 2008. Specifying any other value for the App-consistent snapshot frequency will result in false alerts by turning replication health of the server critical due to lack of App-consistent recovery points.
Enable replication for the Windows Server 2008 SP2 / Windows Server 2008 R2 SP1 server to be migrated.
Run a test migration
You can perform a test failover of replicating servers after initial replication completes and the server status turns to Protected.
Run a test failover to Azure, to make sure everything's working as expected.
Migrate to Azure
Run a failover for the machines you want to migrate.
In Settings > Replicated items click the machine > Failover.
In Failover select a Recovery Point to fail over to. Select the latest recovery point.
Select Shut down machine before beginning failover. Site Recovery will attempt to shut down the server before triggering the failover. Failover continues even if shutdown fails. You can follow the failover progress on the Jobs page.
Check that the Azure VM appears in Azure as expected.
In Replicated items, right-click the server > Complete Migration. This does the following:
- Finishes the migration process, stops replication for the server, and stops Site Recovery billing for the serve.
- This step cleans up the replication data. It doesn't delete the migrated VMs.
Don't cancel a failover in progress: Server replication is stopped before failover starts. If you cancel a failover in progress, failover stops, but the server won't continue to replicate.