Category: Site Recovery

VMware & Azure Site Recovery – Part 3: Replicating VM’s

This is the third instalment of my VMware and Azure Site Recovery series. In the last two posts I covered how to prepare for the service and installing the components within the cloud and private infrastructure to setup ready to make magic happen!

In this post, I’m going to go through client installation for a Windows and Linux box and setup replication jobs via the ASR interface online.

This process can be achieved in a number of ways: the Process Server can push out the client to servers you want to protect, you can install centrally (SCCM, GPO, Puppet, etc) or you can install manually. I decided to install it via the Process Server for the Windows server (this requires an account with local admin) and for the Linux server I installed manually as I didn’t trust the automated mechanism and the permissions model I have for Linux at work isn’t easy to have an account that isn’t root install things. (Easy life).

Windows Client:

1. Within the online ASR portal, via Site Recovery. Select a source of replication (vCenter Server and Process Server already configured).


2. For target, set the right accounts and then select the network that you want to fail-over into (as created previously).

3. Select a VM that you want to replicate from your inventory list. This is pulled directly from the vCenter Serve via the Process Server.

4. On the configuration properties, select the account that has permissions. In my case, the “AD VC PoC Account” is an account with vCenter permission and is also configured as local admin via GPO for this box. Purely for PoC purposes.


5. Select your replication policy for the VM. For me this was the default policy I created earlier.


6. Important! Before you proceed to step 7. Make sure the firewall on your server is set to allow traffic through from the process server or the next steps will fail! You need: Firewall & Print Sharing,



7. Last step is to enable replication.


8. Now the Process Server will contact the server and install the right components (agent) and enable replication.


9. After about 15 minutes, the installation should be complete! Replication should now start up.


Linux Client:

The Linux client requires two installs. One is the agent that talks/registers to the Process Server on site, the other is the replication agent.

1. On the process server get the appropriate Linux Agent file from: F:\Program Files (x86)\Microsoft Azure Site Recovery\home\svsystems\pushinstallsvc\repository and SCP it to the Linux box.


2. Navigate to your Process Server C:\ProgramData\Microsoft Azure Site Recovery\private. Open the “connection” file and copy the phrase down.


3. Unzip the installer and also create a “passphrase.txt” file and insert your passphrase.


4. Install/Register the agent from the zip file:


5. Download the latest “WALinuxAgent” for replication to your Linux Box.


6. Unzip the file


7. Install and register the replication service:


8. Check that services are running:


After some private->cloud replication time (process server refresh) it should be possible to select the Linux VM from your inventory and replicate it, similar to how the Windows Server above was configured – minus the agent push.

I’m going to stop the post here and leave the replication/test fail-over for another post which should be the final one. The good thing about ASR is that once configured correctly it provide a “Test DR/Fail-over” option where you can run multiple simulations whilst maintaining replication!

Until next time!

VMware & Azure Site Recovery – Part 2: Infrastructure Configuration

Following on from my previous post about VMware and Microsoft ASR, I’m going to run through some more of the technical configuration which is required to get your VMware VM’s protected in the Microsoft Cloud. This section will mainly deal with setting up the on-site configuration server and the connectivity to the Azure Site Recovery Subscription.

Preparing Infrastructure

To create the link between cloud components and on-site you need to cover a Recovery Services Vault.

1. From your azure portal, under Monitoring + Management, select Backup & Site Recovery (OMS)

2. Create a Recovery Services Vault similar to above. I heavily recommend pinning this to your Dashboard to make it easily accessible later!

3. Once created, head to Site Recovery and Prepare Infrastructure. Select your goals (in this case, replicate to Azure from VMware).

4. The on-site configuration server and pre-req’s are required here (as mentioned in part 1). Download the installer and registration key to your server.

5. On your 2012 R2 server, run the installer.

6. Accept the EULA

7. Import the reg key as downloaded in step 4.

8. Select Proxy Server options.

9. Run the Prequisite checks (I had a warning of 500Gb secondary disk, not an issue as this is purely testing).

10. Enter the details of your MySQL passwords (interesting MySQL is used).

11. Agree to VMware virtual machine protection and validation of PowerCLI 6.0 takes place. It must be 6.0! I tried with the latest 6.5 and validation fails

12. Select your ASR install directory

13. Select the NIC on your box you want for replication traffic.

14. Hit Install!

15. Hopefully all goes well and you have some nice green ticks!

16. You will be given a passphrase for your configuration server. This is needed when you connect agents on protected VM’s to this server to be replicated. (It can be obtained later).

17. The Config Server admin opens for you automatically. Shortcut is also placed on Desktop. Enter in an account that has sufficient Administrator Privilege over your vCenter account.

18. Back in the portal you can add in the new source configuration server and AD account, select OK.


Note:- Sometimes changes on the config server are not available on the portal straight away. To fix this, you can find your Server from the pinned shortcut and perform a manual refresh!

19. Select your subscription, deployment model, storage account and network as a Target.

20. Create a default replication policy. I left mine as the defaults and came back and tweaked policies later.

21. Complete the infrastructure preparation by running the capacity planner and confirming. I have not done this as I’m only testing a few VM’s in the first instance.

This is a good place to stop here. The next post will detail adding some machines to be replicated, but in order to do that you need to either: install manually, push centrally or have the configuration server do it. Obviously the deployment method needs to be considered for your organisation (via GPO, DSC, Puppet, etc).

VMware & Azure Site Recovery – Part 1: Pre-Requisites

I’ve had the opportunity of investigating Disaster Recovery in my role recently. I have been looking at costs and methods of bringing our critical systems online in the event of a primary data center outage.

Without going into too much detail on my existing employer, there are many things to review and architecting DR into the existing infrastructure isn’t the easiest thing to do. Given our relationship with Microsoft, I was asked to investigate Azure Site Recovery to see if it was a viable option to provide us with a DR site in the cloud.

I’m going to be blogging in a small series on the technical implementation required to achieve VMware VM’s failing over from an on-site VMware cluster to an Azure Site Recovery instance. Hopefully if all goes well I’ll add to the series as I go, but for now I’m going to keep it simple with basic deployment.


The entire process that I am following has been documented by Microsoft and gives some good detail on how to achieve VM replication into the cloud.

It is important to read through the checklist of required items before starting the setup. This can be done beforehand or during the actual implementation. I surmised it down to the following:


1) An Azure account, free trial possible (I have MSDN sub)
2) Azure Storage, somewhere to put your data.
3) Azure Network, VM’s location after fail over.


1) Build a new 2012 R2 Process/Management Server with necessary specification (Ready for installing ASR components)
2) External network connectivity to cloud services.
3) VMware vCenter + ESXi 5.5 or greater.
4) Guest machines that do not exceed certain limitations of the service (e.g. – No disks larger than 1TB)

Once the pre-steps are complete, it was on to configuring the magic….

1) Signed in to my MSDN subscription and setup the Azure Free trial ($150 a month)

2) Login to

3) Navigate to the market place, Networking, Virtual Network.

4) If this is all new, it’s best to stick with the Resource Manager deployment model as that is the latest and greatest. Click Create.

5) Create your virtual network by filling in your requirements. I went for the large default address space, naming it and then a small subnet within that for testing. In this instance I also created a new Resource Group for


NB:- A handy tip is to pin certain objects to the dashboard so you can see them on your main screen. I found this useful for the on-site Process/Management server.

6) Navigate to the market place, Storage, Storage account.

7) Create a storage account as instructed. I opted for standard performance and keeping the data geographically local as I’m only performing a PoC. Maintaining the resource in the previously created group.

8) Navigate to the market place, Monitoring + management, Backup and Site Recovery. Create a recovery vault to group resources together.


The next thing worth doing is creating an account in your Directory Services that VMware and ASR can use.

1) Create AD Service account
2) Add to vCenter/Datacenter object where VM’s will be replicated from.
3) Create a role for “Azure Site Recovery” and give it the following permissions:


Here is a good place to stop with this part of the guide. The hard part of this post was making sure all the pre-configuration bits are done and that you are ready to proceed.

In the next post I’ll run through configuring the actual Site Recovery and making the components communicate. The most notable comment I’d have for all of this is that Microsoft have gone quite a distance in making this process as easy as possible. That doesn’t mean, however, that it goes completely without technical caveats which I’ll cover later on in the series.
Until next time!