Posted on by David Fleming

Part 3: ASR Deploy a Configuration Server

Previous Post in Series: Part 2: ASR VMware – Azure Environment Prep

Overview

Welcome back folks. In this section we’ll be running through a step-by-step process for deploying an ASR Configuration Server. This server is vitally important within an ASR deployment as it not only handles the comms between your on-premises VMware environment and Azure but is also responsible for handling data replication. If you’ve been following the whole series thus far, great, but if not I’d suggest you have a look back at the Azure Site Recovery page before continuing. With no further ado let’s crack on.

Prerequisites

Configuration Server Requirements

We’ll be deploying the configuration server from an OVA (Open Virtualization Application), this OVA will meet the requirements detailed below, however it’s likely that I’ll modify these slightly as my ASR deployment is a small one and my lab has limited resources.

As in earlier section of the guide, I’ll link out to the requirement listed on the official documentation as it may be subject to change and this way you’ll remain properly informed 🙂

You can find the required information HERE

Key points of note are:

  • The resources required by the Configuration Server will change depending on the rate of data change within your VMware environment, guidance below:
Azure AD Requirements

During the setup of the Configuration Server we’ll need to register it with Azure AD, specifically Recovery Services. As such, whichever Azure AD user is completing that registration will need to have the “Application Developer” RBAC role assigned. You can check if the user has the role by logging into https://portal.azure.com either as that user or as an admin. The admin would also have the benefit of being able to add the role if it’s missing.

  • Log into https://portal.azure.com
  • Navigate to “Azure Active Directory”, then “Roles and Administrators”
  • Now select “Application Developer”

As you can see on the screenshot, the user I’m logged in is a Global Admin but we’ll go ahead and add the new role anyway to show the process:

  • Click “+ Add member”
  • Type the name of the user you want to add into the search bar and click it
  • Now click “Select”

NOTE: ADFS is not supported, therefore you must use an Azure AD managed user for this.

Deploy the OVA Template

First we’ll want to download the OVA from Microsoft and onto your vCenter server, you can grab it HERE, FYI it should be roughly 22 GB.

Alternatively, and as we’re going to do now is have vCenter download the OVA during the deployment process:

  • Log into your vCenter server, either via the vSphere client or web client
  • Navigate to “Hosts and Clusters”

NOTE: I’m using the Flash web client as I’m not sure you can deploy from OVA using the HTML5 client…truth be told though, I only had a quick look.

  • Right-click your Cluster object and select “Deploy OVA Template…”
  • Make sure the “URL” radio button is selected
  • Paste in the link to the OVA, you’ll find it above
  • Click “Next”
  • Enter a name for the OVA, there is a default value but it was a little long for my liking
  • Choose where to the place the OVA and click “Next”
  • Select where you want to run the OVA and click “Next”

The OVA will now be validated and you’ll be shown the details of the template.

  • Review and click “Next” to continue
  • Select a datastore for the OVA and click “Next”

NOTE: I’ve Thin Provisioned the storage as my lab environment doesn’t have anything like the 1.3 TB required to Thick Provision it 🙂
NOTE: Ideally in a production environment you’d select “Thick Provisioned Eager Zeroed” as thin may have an impact on performance.
NOTE: A good middle ground may be “Thick Provision Lazy Zeroed” as you won’t have to wait 14 years for the disks to deploy.

  • Keep the defaults for “Select Networks” and click “Next”
  • Review and click “Finish” to deploy

NOTE:  My first two attempts at deploying the OVA failed.  I was connecting to vCenter in a browser from a different server so I thought it might be a browser issue.  Chrome failed, IE failed.
NOTE: I switched to Firefox for the 3rd attempt and it deployed without issue. I get the feeling it was an issue with the transfer and had I been running the deployment on the vCenter server itself, it would have worked fine.

FYI, the error I was seeing was:

It’s 10 minutes later and the OVA has been deployed successfully:

NOTE: I’ve ran through a few ASR deployments now and depending on the version of vCenter, the browser you’re using or certificate issues, the above error seems to happen quite often…often enough to try and work around it.

With that in mind, I decided to use PowerCLI to import the template from now on, which has yet to fail me…so that’s good.

Before trying to import the OVA, I use 7-Zip (or an equivalent tool) to extract all files from the archive. Where the Config server OVA is concerned, they should look something like this:

With that done, launch PowerCLI and run the following code (edited as required for your environment):

PowerCLI
$VMName = "ASR-ConfigSVR"
$OVFFile = "Path to the extracted .OVF file"
$OVFConfig = Get-OvfConfiguration $OVFFile

$VMCluster = Get-Cluster -Name "Name of your VMware cluster"

# This will get the host in the cluster with the most available memory
$VMHost = Get-Cluster -Name $VMCluster.Name | Get-VMHost | Sort MemoryGB | Select -First 1

# This will output all datastores accessible by the cluster to the screen
$VMCluster | Get-Datastore
$VMDatastore = Get-Datastore -Name "Name of datastore selected from above command"

# This will output all Virtual Port Groups on the cluster to the screen
$Network = Get-VirtualPortGroup -Name "Name of the network selected from above command" -VMHost $VMHost

# This command updates the OVFConfig object with the network we selected above
$OVFConfig.NetworkMapping.VM_Network.Value = $Network

# Import the OVF template using above information
Import-VApp -Source $OVFFile -OvfConfiguration $OVFConfig -Name $VMName -VMHost $VMHost -Datastore $VMDataStore -DiskStorageFormat thin

How long this takes to deploy will depend on your environment…in my lab it was about 60 minutes as my storage sucks.

As I said above, I’ve had the most success with this method and plan to use a modified version of the above to script my Config Server deployments going forward.

NOTE: In a production environment you may want to add an additional Network Adapter to the VM and dedicate it to replication traffic. I only mention this because you have to do it BEFORE you register the Configuration Server with your Azure Recovery Service Vault. Adding one after the fact IS NOT supported.

I won’t be adding a second NIC in my lab deployment, but here’s the process anyway, feel free to skip this step:

  • Right-click the VM and select “Edit Settings…”
  • Select “Network Adapter” from the “New Device” drop-down
  • Click “Add”
  • Expand the new “New Network” and do the following:
    • Place it on an appropriate network – I’m in a lab, so not too important here
    • Make sure “Connect at Power On” is checked
    • Change the “Adapter Type” to “VMXNET 3”
    • Click “OK”

OK, let’s power on our Configuration Server VM. From here on out, I’ll be using the VMware console to manage it.

When the VM boots up, you’ll be presented with a license agreement screen, accept it…or don’t, I’m not your dad 🙂

  • Enter a password for the Administrator account
  • Now log in with those credentials

After logon, the ASR Configuration Tool will launch, we’ll be asked for some details:

  • Enter a “Computer Name” for the Configuration Server and click “Next”

The wizard will now check your connection to the internet and assuming all is well you’ll be asked to enter Azure AD credentials:

NOTE: This HAS to be an Azure AD user and proper credentials, none of those PIN shenanigans.

NOTE: As IEESC is still enabled when the Configuration Tool was launched, you’ll have to click “Add” a bunch of times.

NOTE: I’m going to disable this for Admins now to save me issues later on, it’s entirely up to you if you follow suit here:

  • Launch “Server Manager” and select “Local Server” on the left
  • Click “On” next to “IE Enhanced Security Configuration”
  • Under “Administrators”, select “Off”
  • Click “OK”

NOTE: These changes won’t be applied until you next open a browser session, in other words, you’re still clicking add for the time being.

Now back to the Configuration Tool. Once you’ve entered your Azure AD credentials and assuming all went well, you’ll be asked to choose a tenant in the user account you used has access to multiple:

  • Select a tenant from the drop-down and click “Next”

The following 3 tasks should now complete and VM will reboot in 30 seconds. Alternatively, click “Reboot now” if you’re in a massive hurry 🙂

OK, the VM is now back up and running, let’s log back in – but over RDP this time as the web console was being a laggy mess:

The Configuration Management Wizard should automatically launch upon login. The first thing we have to do is select a Network Adapter but before we do that, let’s make sure the IP assigned to our NIC is statically assigned and if not change that.

The following PowerShell will:

  • Get the VM Network Adapter

NOTE: Scope down the first command if your VM has more than one NIC (suggestion in code comments)

  • Get and store existing network information
  • Remove existing IP address and Default Gateway
  • Add same IP Address and Default Gateway statically
  • If you’re connect to the VM over RDP, the connection will drop for a couple of pings but should reconnect without issue
PowerShell
# Get NIC and existing IP configuration
$NetAdapter = Get-NetAdapter # Scope this command if you have more than 1 NIC attached e.g. $NetAdapter = Get-NetAdapter -Name "Ethernet"
$IPDetails = Get-NetIPConfiguration -InterfaceIndex $NetAdapter.ifIndex

# Remove the existing dynamically configured IP and Gateway
$NetAdapter | Remove-NetIPAddress -Confirm:$false
$NetAdapter | Remove-NetRoute -AddressFamily IPv4 -Confirm:$false

# Reapply same IP address and Gateway statically
New-NetIPAddress -IPAddress $IPDetails.IPv4Address.IPAddress `
    -InterfaceIndex $IPDetails.IPv4Address.InterfaceIndex `
    -DefaultGateway $IPDetails.IPv4DefaultGateway.NextHop `
    -AddressFamily IPv4 `
    -PrefixLength $IPDetails.IPv4Address.PrefixLength

# Configure DNS Servers
$NetAdapter | Set-DnsClientServerAddress -ServerAddresses $IPDetails.DNSServer.ServerAddresses

Now we can get back to the Wizard:

  • Click “Select NIC” if you have more than one NIC on the VM
  • Check the details of “Select network interface card”
  • Assuming all is good, click “Save” then “Continue”

With Connectivity sorted, let’s plumb in our Recovery Services Vault:

  • First log into Azure using “Click to Sign-In”
    • Enter the credentials you configured earlier
  • When signing in you’ll be asked to agree to certain permissions, click “Accept” to continue

You should now be signed into your Azure tenant and have access to the resources we deployed earlier in the guide, see HERE

  • Choose the “Subscription”, “Resource Group” and “Recovery Services Vault” we deployed earlier

NOTE: Remember that you cannot change which Recovery Services Vault your Configuration Server is connected to later. You’d have to disassociate and start again.

  • Click “Continue”

Next we’re going to install MySQL and in my case I’m going to let the wizard handle the download and installation for me. If you want to do it manually though you click the “Install MySQL” link on the top right of the wizard.

  • Accept the license agreement
  • Click “Download and Install”
  • Once installed, click “Continue”

Next, the wizard runs through a system check to make sure everything is all good before continuing. It actually errored for me and likely will for anyone that’s not based Pacific Standard Time Zone.

Here’s the error it displayed:

So this is likely happening because VMWare tools is running on the machine and it’ll be getting it’s time from the NTP server running on the host, which for me is GMT…hence the error.

With that in mind, I’m just going to update the time zone on the VM:

  • Search for “Time zone” from the Start Menu
  • Select “Change the time zone”
  • Select the correct time zone from the drop-down

NOTE: You may also have to set the time manually if it ends up wildly out of sync, you can then put it back to automatic.

Let’s see if that resolve the issue:

  • Click “Check again”

Yup, everything is green:

  • Click “Continue”

Now it’s time to configure our vCenter server so dig out those credentials from earlier in the guide

  • Click “Add vCenter Server/vSphere ESXi server”
  • Populate fields as required
  • Click “Add”

NOTE: The port should be auto-populated as 443 – update if you’ve changed your vCenter config

  • With your vCenter server added, click “Continue”

Next we’ll be giving the wizard a set of VM credentials. These credentials will be used for automatically installing the “Mobility Service” that is a requirement for VM replication to Azure.

As my machines aren’t domain joined, these credentials will be created locally on each VM and must be local admins. There are also a couple of additional steps required in this scenario, you can read up on them HERE.

NOTE: You can add multiple credentials here and will be able to pick from them at the point of enabling replication of your VMs.
NOTE: You also have the option to manually install the Mobility Service on each VM or use another automated approach, SCCM for example.
NOTE: When creating a set of credentials on the VMs, they’ll need installation privileges (local admin).

With the credentials and registry key added to our VMs, let’s continue:

  • Click “Add virtual machine credentials”
  • Populate all fields
  • Click “Add”
  • Click “Continue”

NOTE: You can also add a set of credentials for Linux machines here too, just expand the section again and repeat the above process.

Now you’re hopefully looking at a sea of green 🙂

  • Click “Finalize configuration”

Now we play the squeaky bum waiting game…

And as is typical when putting together a guide, we’ve got a failure:

Pretty sure that’s the time zone thing coming back to bite us in the ass. I’ll jump back a few steps and log out/into Azure again and see if that sorts it:

WOOHOO, that was it…sooo much green over here:

So to confirm, all I did there was expand the “Select Recovery Service Vault” section, click “Sign out” in the top right and log into Azure again.

Let’s log into the Azure portal and check to see if everything is looking good from that end

  • From within our Recovery Vault, navigate to “Site Recovery Infrastructure”, then “Configuration Servers”

Yup, we’re looking good.

Clicking on the server will provide you with a good deal on information on the server and its current state:

Prepare Site Recovery Infrastructure

With our configuration server deployed, we can prepare our target environment.

  • Select “All services” from the dashboard
  • Type “Recovery” into the search bar
  • Select “Recovery Services vaults”
  • Select the RSV you deployed above
  • Select the “Site Recovery” blade under “Getting Started”
  • Select “Prepare Infrastructure”

On the “Protection Goal” blade

  • For “Where are your machines located?”, select “On-premises”
  • For “Where do you want to replicate your machines to?”, select “To Azure”
  • For “Are your machines virtualized?”, select “Yes, with VMware vSphere Hypervisor”
  • Click “OK”

On the “Deployment Planning” blade

  • For “Have you completed deployment planning?”, select “Yes, I have done it”
  • Click “OK”

For the “Source” blade

  • “Step 1” and “Step 2” should have been auto-populated, confirm and click “OK”

On the “Target” blade

  • Make sure you have the correct subscription selected.
  • Confirm “Resource Manager” is selected
  • Click “OK”

Now we’ll need to create a replication policy.

  • Click “Create and Associate”
  • Give your policy a “Name”
  • Enter a value between “15” and “240” for “RPO threshold in mins”
  • Enter a value between “0” and “72” for “Recovery point retention in hours”
  • Select a value between “1” and “12” for “App-consistent snapshot frequency in hours”
  • Click “OK”

NOTE: A failback policy will be created automatically using the same settings you specified above.

Assuming that all went off without a hitch, you should be looking at something similar to below:

  • Click “OK” twice

We should now be in a place to enable replication, we’ll cover that in the next guide, hop e to see you there.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.