For this post I will refer to the following Microsoft article here. I didn’t was to just regurgitate the lab, so I will refer to it and add comments where i had issues/difficulties.
This was a large lab, it took me 3-4 days in my spare time. Total Azure spend about $15 (turning servers off at night time automatically see my previous post here).
What servers are required for this lab? Refer here
The only servers that I used were in my lab were the following (all servers were in Azure)
|Component||My Server Name|
|Master Target Server||WinMasterTarget|
I did not require domain membership for this lab.
Before you start refer to these requirements here.
Step 1: The first step was to create a vault as outlined here.
Step 2: Deploy the configuration server as outlined here.
Please note that the following VPN selection cannot be changed once set, so choose wisely.
When you come to step 10 of Registering the configuration server in the vault, DO NOT just click ok on the dialog box without recording the Configuration Server Connection Passphrase.
When I went to add an account to Site Recovery I successfully used the following credential format as I had not added my machines to a domain. .\aaron.whittaker
Step 3: Deploy the master target server as outlined here with a Windows operating system. You are forced to use certain size virtual machines. My plan was to turn them off and change to smaller machines (to save money) for my lab, but as yet I have not tested this.
Here I used a private IP address as this was all within my Azure network.
Step 4: Deploy an on-premise process server here.
I selected no to protecting VMWare virtual Machines.
I initially configured my On Premise process server to use a public IP address, but as all my lab was within Azure, this would not work, so later I changed this setting to an internal IP address.
I ignored the message regarding disk space as this will use compression and defragmentation.
Step 5: I downloaded and installed the latest updates here.
Step 6: My on-premise servers were treated as physicals so skipped the step to add vCenter/ESXi hosts here. My on-premise servers were actually in Azure as I did not have an on-premise lab to use.
Step 7: I created a protection group here.
Step 8: I installed the mobility service on the Virtual Machine that I wanted to protect here.
Step 9: I Set up the machines that I wanted to protect (OP-Source-Svr) here.
Initially I used public IP addresses (below) before switching to internal (see diagnosing suggestions below).
When I attempted to enable protection here, it took me a few goes to get it to work.
Try the following if this fails: Disable all firewalls, check the public ports endpoints on the incoming servers in Azure, check the user account, check the ip addresses and the ports that you have used within your lab and the also within the Host Agent Config, if you are using a VPN, or a lab all in Azure instead of using the public ip address you can use the private ip addresses. This is how I got my lab to work.
The server then syncronised automatically (1 hour for a 127 gig vanilla server).
After my first syncronisation occured then I made some configuration settings. By default the replicated virtual machines in Azure aren’t connected to an Azure network. I went ahead and set my Virtual Machine to my Azure network.
Step 10: Create a recover plan and perform a failover here.
I selected failover.
Here you can check the progress of the job.
From here your new server should show up in Azure with the same name that you originally gave it. Go to Cloud Services to confirm it has worked correctly. You shall see a new cloud service.
The server should also be on the network that you assigned. The name remains the same, DHCP will most likely issue a different IP address to your IP address that you have assigned. As always, recovery from failure or failover is only half the battle, how will existing machines still on premise know that your machine has recovered and is now in a new location with a new IP address? Much planning needs to go into a recovery plan and this will be external to the work shown here in this blog.
My thoughts: Azure Site recovery is great if you recover an entire site or service at once into Azure, if all machines refer to hostnames. Perhaps you could add a host file that is commented out, after the recovery enable the host file until you sort out DNS. Or perhaps you can use Site Recovery to migrate to Azure as a long term plan, when you decommission hardware. Only add complementing machines to the same recovery plan, for example, a financial system and a financial database running on SQL. Here is a great time to remind you to please remember to check your Microsoft licensing mobility restrictions before you start any work (eg. SharePoint and Biztalk).
The steps to fail back from Azure to original Datacenter are here, but if you are at this point with a production workload running on Azure I suggest you contact a Microsoft partner or your friendly Microsoft account manager to discuss your options.
I would appreciate any feedback/suggestions on this article.