Previous Post in Series: Part 1: ASR Deployment Planner Tool
Overview
Welcome back folks. In the last post we looked at the ASR Deployment Planner Tool, used it to profile our VMware environment and provide a report of what that environment may look like/cost in Azure. In this post we’ll be preparing our VMware and Azure environments for enabling disaster recovery to Azure.
Our first task will be to take care of a couple of requirements in our Azure subscription, namely the deployment of an Azure Recovery Services Vault and a Virtual Network…so let’s do that.
Prepare Azure Environment
From here on out, I’m assuming you are logged into the Azure portal and have the permissions required to do the following tasks on your subscription:
- Create a VM in the selected resource group.
- Create a VM in the selected virtual network.
- Write to an Azure storage account.
- Write to an Azure managed disk.
With that out of the way, the first thing we’ll want to do is create a Resource Group in the region we want to replicate to:
From the Azure portal Dashboard:
- Click “+ Create a resource”
- Type “Resource Group” into the search box and press “Enter”
- Click the “Create” button
- Confirm you’re about to deploy to the correct subscription (if you have multiple)
- Type a sensible name for your Resource Group into the “Resource group” field
- Select the “Region” you want to replicate to
- Click “Review + Create” and then “Create”
- Once the deployment has completed, click “Go to Resource” on the pop-up notification in the top right.
Now we’ll go ahead and deploy our Recovery Services Vault (RSV).
- Click “+ Add” on the “Overview” blade of the Resource Group
- Type “Backup” into the search bar and hit “Enter”
- Select “Backup and Site Recovery (OMS)” from the resulting menu
- Then click “Create”
- Enter a “Name” for your RSV, in my case “ASR-RSV”.
- Make sure you have the correct “Subscription” selected.
- Select the “Resource Group” you created above.
- The “Location” should populate based on your Resource Group selection, but confirm this.
- Click “Create”
The vault should only take 30 seconds or so to deploy.
By default, and RSV is set to use “GRS (Geo-Redundant Storage Accounts)”, if you’re happy with this then skip the next steps, otherwise continue to set LRS (Locally-Redundant Storage Accounts) instead.
Change Vault Storage Replication Type
- Click “All Services” and type “Recovery” into the search bar
- Select “Recovery Services Vaults”
- Select the vault you deployed above
- Click the “Properties” blade
- Under “Backup Configuration”, select “Update”
- Select “Locally-Redundant” and click “Save”
Deploy Virtual Network
Next we want to deploy a Virtual Network (VNET) into the same Resource Group.
- Click “+ Create a Resource”
- Type “Virtual Network” into the search bar and press “Enter”
- Click “Create”
- Enter a “Name” for your VNET
- Enter an appropriate “Address space” I went with a /16
- Confirm you have the correct “Subscription” selected
- Select the “Resource Group” we deployed earlier
- The “Location” should populate based on your Resource Group selection, but confirm this.
- Leave the default value for “Subnet”
- Confirm your subnet “Address range” is within the address space you entered above
- Leave “Basic” for “DDoS protection”
- Leave “Service endpoints” as “Disabled”
- Leave “Firewall” as “Disabled”
- Click “Next”
NOTE: Although the screenshot doesn’t show it, make sure your address space and subnet configuration leaves room for at least a /28 as you’ll potentially need it later if/when deploying a VPN Gateway
Deploy a Network Security Group
We’ll also want to deploy an NSG and attach it to the “default” subnet for the VNET we created above.
- Click “+ Create a Resource”
- Type “Network Security Group” into the search bar and press “Enter”
- Click “Create”
- Enter a “Name” for your new NSG
- Make sure you have the correct “Subscription” selected
- Select the “Resource Group” you deployed the above VNET into
- Select the same “Region” you deployed the above VNET into
- Click “Create”
For my environment, I’m going to allow RDP into the “default” subnet but only from my IP address
- Navigate to the NSG you just created
- Select the “Inbound security rules” blade
- Click “+ Add”
- For “Source”, select “IP Addresses”
- For source “IP addresses, CIDR ranges”, enter your IP address or addresses
NOTE: Multiple IPs can be entered here, separated by a comma, you can also add ranges or a combination of both, e.g. 90.90.90.10, 90.90.100.0/24, 90.90.101.10/32
- For “Destination port ranges”, enter “3389”
- For “Priority”, enter a sensible number, I usually start with “1000” to give myself plenty of breathing room
- For “Name” enter something descriptive
- Click “Add”
Now we’ll want to associate the NSG with our “default” subnet
- Navigate to the “Subnets” blade and click “Associate”
- Select the “Virtual Network” and “Subnet” you created above
- Click “OK”
Prepare VMware Environment
VMware Account Requirements
The first thing we’ll need to do is provision a user account in our VMware environment that was the required permissions to do the following:
- Automatically discover VMs – Read-Only will do for this
- Orchestrate replication, failover and failback – Requires additional rights to do this
As I’m working in a lab I’ll be using the Administrator account, so am sorted. In a production environment you’d want to create a dedicated account for replication tasks, you can find full details on how to do that HERE
Mobility Service
All VMs that we plan to replicate need to have the “Mobility Service” installed on them, this can be done in two different ways:
- Manual Installation – The installation files are located on the ASR Configuration Server, the location differs depending on the OS, details HERE
- Push Installation – ASR will push the files to the VMs automatically and install the agent.
When using the push method, there are a few additional requirements we need to implement:
- If you’re using a domain account for all your Windows VMs, things should be pretty straightforward
- If you’re using a non-domain account for Windows VMs, you’ll have to disable “Remote User Access Control” on the machines
This is done by opening “Regedit” and adding a “DWORD” entry named “LocalAccountTokenFilterPolicy” with a value of “1” to:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
You can add this manually or run the following from an elevated Command prompt
REG ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1
- For Linux VMs you’ll need to prepare a root account
In this guide I’m going to try and cover both methods if possible, but we’ll cover this later in the guide, I’ll also likely go over that registry change in more detail too as it always makes more sense in context.
Protected VM Preparations
There are a few things we’ll want to do attend to in advance of enabling protection of our VMs, these are as follows:
Make sure the relevant firewall rules for RDP, File and Print Services and WMI are enabled in the VM:
NOTE: The UI example below only covers enabling the RDP rule, just repeat the process for the other rules, alternative, the PowerShell at the end of this section covers them all
- Launch the “Windows Defender Firewall” MSC
- Select “Allow an app or feature through Windows Defender Firewall”
- If required, click “Change Settings”
- Scroll down to “Remote Desktop” and enable it for “Domain”, “Private”, “Public” profiles
- Now click “OK”
NOTE: The above screenshot should also show the “Public” profile as we’ll be RDPing to these replicated VMs in Azure. If you’re connecting via a VPN gateway though, feel free to leave it off, this is a lab after all 🙂
If the above is all just a bit clicky, fire up an elevated PowerShell console and run the following command instead:
PowerShell
Set-NetFirewallRule -DisplayGroup 'Remote Desktop', 'File And Printer Sharing' -Profile Domain, Private, Public -Enabled True
Set-NetFirewallRule -Name 'WMI-WINMGMT-In-TCP','WMI-RPCSS-In-TCP' -Profile Domain, Private -Enabled True
Confirm OS SAN Policy
When machines are deployed into Azure they’re assigned temporary disk carved from SSD on the VM host machine. This disk is home to the OS page file and users can place any files on there they want accepting the fact they’ll likely be lost if the machine is powered down/rebooted. By default with temp disk is given the drive letter “D”. As we’ll be enabling protection on VMs and these VMs may already be making use of that drive letter, we can make changes to the OS SAN policy to make sure Azure assigns the next available drive letter instead of trying to steal “D”.
- Launch an elevate Command Prompt
- Type “diskpart”
- Type “SAN”
Chances are that it’s already set correctly, but if it’s set to “Offline All” or “Offline Shared”, do the following:
- Type “SAN POLICY=ONLINEALL”
Windows Update
Check for and install any outstanding Windows Updates before triggering a VM failover as you won’t be able to successfully connect to the Azure VM until those updates have finished installing.
Anti-Virus Exclusions
For smooth operation of the ASR service, Microsoft recommend that appropriate exclusions are put in place for the following part of the source infrastructure:
- VMs to be protected/replicated
- ASR Configuration server
- ASR Scale-Out Process servers
- ASR Master Target server
Rather than include all the specific paths to be excluded here, I’ll link to them instead as it’s possible they’ll change over time and the official documentation would be updated to capture this. You can find the exclusions lists HERE
There is only a single folder that needs to be excluded on the VMs to be replicated, so here’s the PowerShell command for adding it:
PowerShell
Add-MpPreference -ExclusionPath "C:\ProgramData\ASR\agent"
That’s us for this section folks, join me in the next one where we’ll be deploying our Configuration Server