Configuring an Azure VM From a Sysprepped Source Image using ARM PowerShell.

While working on an Azure IaaS deployment, I was required to configure an Azure VM using a generalized image in a different resourcegroup.In this post, I want to document my experience using Azure Resource Manager Powershell cmdlets to achieve the related tasks.

The Sysprep tool in the C:\Windows\System32 directory of the windows Azure virtual machine shuts down the vm after the process.

Use the Set-AzureRmVM -Name APPVM0 -Generalized cmdlet with the Generalized parameter to mark the virtual machine as generalized.

The Generalized source image was captured using the Save-AzureRmVMImage cmdlet. Following the cmdlet run, the image was saved to an auto created “system” container/folder in the Storage account.In the following section, the set of ARM (Azure Resource Manager) PowerShell scripts perform the operations on the source Storage account that create the objects and variables required to copy the source vhd blob between containers in storage accounts residing in different Azure Resource Groups.

#Creating an Azure Virtual Machine from a Captured Image .
#Charles Chukwudozie

#Login to the ARM Portal.

#Retrieve and save the source ResourceGroupName in a variable.
$srcresourcegroupname = (Get-AzureRmResourceGroup -Name rgJsonTest -Location centralus).ResourceGroupName

#Get a list of the Resource group resources and note the storage account name.
Get-AzureRmResource  |?{$_.ResourceGroupName -eq "$srcresourcegroupname"} | ft Name

#Get the storage account name and save it in a variable.
$srcstorageaccountname = (Get-AzureRmStorageAccount -ResourceGroupName $srcresourcegroupname -Name rgjsonstorage).StorageAccountName

#Get the storage account access key pair, extract one of the keys and save it to a variable.
$srckeys = Get-AzureRmStorageAccountKey -ResourceGroupName $srcresourcegroupname -Name $srcstorageaccountname
$srckey = $srckeys.Value[0]

#Create a storage context for authorization to the storage account and it's containers/folders.
$srccontext = New-AzureStorageContext -StorageAccountName $srcstorageaccountname -StorageAccountKey $srckey

#Retrieve the current containers in the storage account and select the system container.
Get-AzureStorageContainer -Context $srccontext

#Retrieve the captured source vhd blob container absoluteuri from the system container and assign it to a variable.System container was autocreated during the Save-AzureRmVMImage task.
$absoluteuri = (((Get-AzureStorageContainer -Context $srccontext -Name system).CloudBlobContainer).Uri).AbsoluteUri

#Retrieve the captured source blobs' path from the name property in the system(captured image location) container. Assign it to a variable.
$srcblobspath = (Get-AzureStorageBlob -Container system -Context $srccontext).Name

#Retrieve the vhd blob path from the array.
$srcvhdblobpath = $srcblobspath[0]

#Use the Split() method with the forward slash as seperator,number of element count argument and array position to isolate the source vhd blob only.
$srcvhdblob = $srcvhdblobpath.Split('/',4)[3]

#Concatenate the $absoluteuri and $srcblob variables to build the $srcvhduri variable.
$srcvhduri = $absoluteuri + "/" + $srcvhdblobpath

In the next section, the PowerShell scripts create the destination Azure Resource Groups and performs the operations required to initiate the source vhd blob copy between the source and destination Azure storage accounts in different Resource resource groups.

#Create destination ResourceGroup.

#Save the ResourceGroupName to a variable.
New-AzureRmResourceGroup -Name rgNewImageVMs -Location centralus
$destresourcegroupname = (Get-AzureRmResourceGroup -Name rgNewImageVMs).ResourceGroupName

#Create destination storage account and save the storage account name to a variable. Retrieve the storage account key and create acontext for authorization.
New-AzureRmStorageAccount -ResourceGroupName $destresourcegroupname -Name capimgstorageaccount -SkuName Standard_LRS -Location centralus -Kind Storage
$deststorageacctname = (Get-AzureRmStorageAccount -ResourceGroupName $destresourcegroupname -Name capimgstorageaccount).StorageAccountName
$destkey = (Get-AzureRmStorageAccountKey -ResourceGroupName $destresourcegroupname -Name $deststorageacctname).Value[0]
$destcontext = New-AzureStorageContext -StorageAccountName $deststorageacctname -StorageAccountKey $destkey

#Create a storage container as a copy target for the source image from above.
New-AzureStorageContainer -Name vhds -Permission Blob -Context $destcontext
$destcontainer = (Get-AzureStorageContainer -Name vhds -Context $destcontext).Name

#Initiate the copy of the source image to the destination storage account.
Start-AzureStorageBlobCopy -AbsoluteUri $srcvhduri -DestContainer $destcontainer -DestBlob $srcvhdblob -Context $srccontext -DestContext $destcontext
Get-AzureStorageBlobCopyState -Blob $srcvhdblob -Container $destcontainer -Context $destcontext 

In the third and final section of the script, the Azure VM configuration object is created using the copied source image.

#Create an Azure VM from the captured sysprepped image.

#Set the parameters and variables required to configure the new Azure VMConfig.
$credential = Get-Credential -UserName "localuser"  -Message "Type the username and password of the VM local administrator account."
$timezone = "Central Standard Time"

#Create a storage container for the new VM os disk location.
New-AzureStorageContainer -Name osdisks -Permission Blob -Context $destcontext

#Get the new os disk container name and save to a variable.
$vmcontainer = (Get-AzureStorageContainer -Name osdisks -Context $destcontext).Name

#Get the absolute uri of the source image and save the object to a variable.
$srcimgpreuri = (((Get-AzureStorageContainer -Context $destcontext -Name $destcontainer).CloudBlobContainer).Uri).AbsoluteUri

#Get the source image vhd blob path and save to a variable.
$srcimgblob = (Get-AzureStorageBlob -Container $destcontainer -Context $destcontext).Name

#Concatenate the source image uri and source vhd blob variables to build the source image uri variable.
$srcimageuri = $srcimgpreuri + "/" + $srcimgblob

#Get the new VM OS disk absolute uri.
$osuri = (((Get-AzureStorageContainer -Name osdisks -Context $destcontext).CloudBlobContainer).Uri).AbsoluteUri

#Concatenate the new VM OS disk absolute uri and it's corresponding vhd to build the new VM vhduri variable.
$vhduri = $osuri + "/" + "os.vhd"

#Create an Azure Public IP Address for the new VM.
$vmpip = New-AzureRmPublicIpAddress -Name vmpip -ResourceGroupName $destresourcegroupname -Location centralus -AllocationMethod Dynamic

#Create an Azure Subnet for the VM
New-AzureRmVirtualNetworkSubnetConfig -Name Subnet1 -AddressPrefix ""

#Create an Azure VNet for the VM.
New-AzureRmVirtualNetwork -Name VNET1 -ResourceGroupName $destresourcegroupname -Location centralus -AddressPrefix "" -Subnet $vmsubnetconfig
#Save the new vNet and subnet objects in variables for later use.
$vNet1 = Get-AzureRmVirtualNetwork -Name vNET1 -ResourceGroupName $destresourcegroupname
$subnet1 = Get-AzureRmVirtualNetworkSubnetConfig -Name Subnet1 -VirtualNetwork $vNet1

#Create the new VM network interface.
New-AzureRmNetworkInterface -Name vmNic1 -ResourceGroupName $destresourcegroupname -Location centralus -SubnetId $subnet1.Id -PublicIpAddressId $vmpip.Id
$vmNic1 = Get-AzureRmNetworkInterface -Name vmNic1 -ResourceGroupName $destresourcegroupname

#Create the new VM config object
$sysprepvm = New-AzureRmVMConfig -VMName "sysprepvm" -VMSize "Standard_A1_v2"
$sysprepvm = Set-AzureRmVMOSDisk -VM $sysprepvm -Name "os.vhd" -SourceImageUri $srcimageuri -VhdUri $vhduri -Windows -CreateOption FromImage
$sysprepvm = Set-AzureRmVMOperatingSystem -VM $sysprepvm -Windows -ComputerName $sysprepvm.Name -Credential $credential -EnableAutoUpdate -ProvisionVMAgent -TimeZone $timezone
$sysprepvm = Add-AzureRmVMNetworkInterface -VM $sysprepvm -Id $vmNic1.Id

#Instantiate the VM Object.
New-AzureRmVM -ResourceGroupName $destresourcegroupname -Location centralus -VM $sysprepvm

The following screen shot shows the final result of the Azure VM creation script.


Posted in Azure, Azure Resource Manager, Azure Windows PowerShell | Tagged , , , , , , , , | Leave a comment

Deploy WS2012R2 AD Domain Controller in Azure-OnPrem Hybrid Environment using Resource Manager (IaaS) Virtual Machine.

As part of the process of extending my on premise infrastructure environment to Microsoft Azure, I have configured the Azure S2S VPN, an Azure Virtual network and other Azure based components within an ARM resource group to facilitate the implementation of the hybrid infrastructure.

In a recent post, I wrote about the steps to design and configure the Azure virtual networks and services required to make this possible. The following steps describe the process of installing and configuring the Active Directory Domain Services on the Azure VM to enable DC resilience for the on premise environment.

1) Login to the Azure VM with the local admin account and join the machine to my on premise domain. After the restart, login with an user account with domain admin and enterprise admin group membership. Before installing Active Directory Domain Services, use the Get-WindowsFeature -Name *ad* cmdlet to verify the correct feature name.


2) Install the ADDS feature:

Install-WindowsFeature -Name AD-Domain-Services -IncludeAllSubFeature -IncludeManagementTools


3) Use the Test-ADDSDomainControllerInstallation cmdlet to determine the domain environment’s readiness to accept the new Windows Server 2012 R2 Domain Controller installation. The cmdlet accepts the SafeModeAdministratorPassword and DomainName as required parameters:

PS C:\Windows\system32> $password = ConvertTo-SecureString -String 'password' -AsPlainText -Force
PS C:\Windows\system32> Test-ADDSDomainControllerInstallation -DomainName -SafeModeAdministratorPass
word $password | fl


4) Based on the Test results, the VM needs to be assigned a static IP Address as a requirement of functioning as a Domain Controller with DNS installed. This VM sits on Microsoft Azure. Using the Azure Resource Manager, I’ll make the current dynamic IP Address configuration static on the Network Interfaces blade of the Azure virtual manager.




5) After successfully setting the Azure VM IP Address assignment to Static. I’ll login to the VM via internal rdp, configure the IPv4 address as static and run the Test-ADDSDomainControllerInstallation cmdlet again to confirm the error has been resolved.

6) Use the Install-ADDSDomainController -DomainName -SafeModeAdministratorPassword $password -InstallDns -Verbose cmdlet with the the specified parameters to promote the machine to a Domain Controller.


7) After the system restart, I set about configuring a new Azure-Lab Active Directory Site and Subnet using the Active Directory Sites and Services console to reflect the Azure virtual network subnet/location. I added the the new subnet to the Azure-Lab Site. This will enable the new Azure-Lab site handle any login and authentication originating from my Azure Virtual Network.


Posted in Active Directory Domain Services, AD Forest, Azure, Azure VPN | Leave a comment

Copying an Azure Cloud Blob (VHD) between different Storage Accounts and Resource Groups with ARM PowerShell.

While working with Azure, I came across a situation where I needed to quickly provision an Azure Virtual Machine from an existing sysprepped VHD in a different storage account and resource group using the Azure Resource Manager deployment model. This can be achieved using Azure Resource Manager PowerShell cmdlets. It is worth noting that an Azure storage account has two authentication keys: a primary and a secondary. Either of these can be used for any operation. There are two keys to allow occasional rollover of the keys to enhance security.The storage account context is used for authentication against the storage account.

The key Azure Resource Manager resources and components to consider for this operation are:

1) The URI of the source vhd or blob. This resource will be assigned a variable: $srcvhduri.
2) The source Storage Account name : $srcstoraccountname.
3) The Access key of the source Storage Account: $srckey1.
4) The security context of the source storage environment: $srccontext.
5) The destination Storage account name: $deststoraccountname.
6) The Access key of the destination storage account: $destkey1.
7) The security context of the destination Storage account: $destcontext.

We’ll start this operation by initiating a login to the Azure Cloud subscription using PowerShell:

1) Use the PS C:\Scripts> Login-AzureRmAccount cmdlet to login the Azure subscription:


2) Confirm and verify the resources in the source resource group using the following Azure PowerShell script:
PS C:\Scripts> Get-AzureRmResource | ?{$_.ResourceGroupName -eq 'rgXtine'} | ft Name


3) Verify the source storage account key using the following Azure Resource Manager PowerShell script:
PS C:\Scripts> Get-AzureRmStorageAccountKey -ResourceGroupName rgXtine -Name vhdstoragexfqygzi2vdtwo


The storage account access keys come in pairs and can be regenerated at anytime. I’m interested in using just one of the access keys.

4) In the next script, I’ll retrieve one of the keys and save it in a variable.

$srckey1 = (Get-AzureRmStorageAccountKey -ResourceGroupName rgXtine -Name vhdstoragexfqygzi2vdtwo).Value[0]


5) Next, I’ll copy the blob/vhd url from the Azure portal or Azure Storage Explorer and assign the string to a variable.


6) Get the source storage account and save it in a variable:
$srcstoraccount = Get-AzureRmStorageAccount -ResourceGroupName rgXtine . Retreive the source storage account name and save in a variable: $srcstoraccountname = $srcstoraccount.StorageAccountName

7) Get the source storage account context and assign to a variable:
$srccontext = New-AzureStorageContext -StorageAccountName $srcstoraccountname -StorageAccountKey $srckey1

8) Run the same steps as above for the destination/target storage account of the copy operation:

a) Destination Storage account:

$deststoraccount=Get-AzureRmStorageAccount -ResourceGroupName rgCapturedImage -Name newcapimgstoracct2016

b) Retrieve the destination storage account name:

$deststoraccountname = $deststoraccount.StorageAccountName

c) Retrieve the destination storage account access key and assign it to variable:

PS$destkey1 = (Get-AzureRmStorageAccountKey -ResourceGroupName rgcapturedimage -Name newcapimgstoracct2016)

d) Get the authentication context for the destination storage account:

$destcontext=New-AzureStorageContext -StorageAccountName $deststoraccountname -StorageAccountKey $destkey1

9) Create a destination storage container for the copied vhd/blob object:

PS C:\Scripts> New-AzureStorageContainer -Name images2 -Permission Blob -Context $destcontext


10) Confirm the name of the Azure blob or vhd file object to be copied.


11) Use the Start-AzureStorageBlobCopy cmdlet to copy the Azure blob to the target container.


I can check the copy status by using the Get-AzureStorageBlobCopyState cmdlet. This cmdlet displays the status of the copy task, source blob, completion time and total bytes.


I could also confirm the blob is in the target container using the Azure Storage Explorer:


Posted in Azure, Azure Windows PowerShell | Tagged , , , , , , , | Leave a comment

Enable Hyper-V Server 2012 R2 Core Virtual Machine Protection using existing Azure Site Replication Policy.

In this post, I’ll be writing about my steps for enabling on premise Virtual Machine protection to Azure Site Recovery using an existing Hyper-V Site Replication policy. In this deployment, I’ll be adding and registering a Hyper-V Core Server 2012 R2 to Azure Site Recovery. The process differs from the steps in registering a full Windows Server 2012 R2 host in Azure Site Recovery.

1) Login to Azure Resource Manager portal.

2) Under the default Dashboard, select All Resources and select the already existing Recovery Services Vault. My current vault is the LabVaultASR.


3) On the current vault page, navigate to Settings, Manage, Site Recovery Infrastructure and select the recovery infrastructure that works best for you. In my scenario for this post, I’m working with non SCVMM Hyper-V hosts. I’ll select Hyper-V Hosts under the Hyper-V sites section.


4) Use the +Server button to add another Hyper-V host.


5) On the Add Server page, ensure that Hyper-V is selected. Download and install the installer for Azure Site Recovery Provider. This will install both the Provider and Agent services on the on premise Hyper-V host. I’ll also download the vault registration key to register the host with my Hyper-V site.

I’m running the Hyper-V core 2012 R2 on my on premise Hyper-V host. I login to the server, start a PowerShell console as Administrator and run the Provider file from the PowerShell prompt. This starts the installation GUI. I selected to enable Microsoft Update, click next and finish the installation. Click next to Register the server with Azure.


I encountered an error trying to register the Hyper-V host with my Azure vault.


The error occurred because I can’t register the server with the GUI on a Hyper-V core server. I need the command line tool and switches to properly register a Hyper-V Server 2012 R2 core with Azure vault. After downloading the key, I made sure to unblock the vault key file by right clicking on the file, selecting properties and using the “Unblock” button on the General tab to unblock the file. Then I ran the following command to register the server:

C:\Program Files\Microsoft Azure Site Recovery Provider>DRConfigurator.exe /r /friendlyname /Credentials "c:\ASR\LabVaultASR_LabHyper-V-Site_Wed Sep 21 2016.VaultCredentials"


Confirm that the registration was successful in Azure.


6) To configure and enable protection for Virtual Machines, navigate to the Recovery Services Vault(LabVaultASR in my deployment), Settings, Protected Items and select Replicated Items.

7) On the Replicated Items page, select the +Replicate button to start the VM protection/replication process.


8) On the Enable Replication page, select the Source Hyper-V site and click Ok. On the Target page, select ensure that Azure is selected as the Target.Select the subscription. Select the Post-failover deployment model, in my deployment, I’ll be using the Azure Classic model. Select the Storage account. I want to Configure now for selected machines. And I also selected my already configure Azure Virtual Network.Click Ok.


9) Select a VM to enable for protection on the Select VM page. Click Ok.


10) Select the relevant values on the VM properties page.Click Ok.


11) On the Replication settings page, select the existing Replication Policy. Click Ok.


12) Click on the Enable Replication button to enable protection for the configured VM.

13) After successfully enabling protection of the VM, click the refresh button to display the newly protected VM on the Replicated Items page.


After completing the Replication and Protection steps, I can view and monitor the status and health of my replica virtual machines in Azure Site Recovery by clicking on my Recovery Services Vault name.

I can view and assess the status of the Site Recovery provider on my registered Hyper-V host/servers. I can check out the properties and health of my replicated items, recovery plans and Site Recovery jobs.


Posted in Azure, Azure Site Recovery, Failover Cluster, Failover Cluster Manager, Hyper-v, Hyper-v 2012 R2, Hyper-v Manager, Microsoft Hyper-v | Tagged , , , , , , , , , , , | Leave a comment

Implementing Azure Site Recovery Protection for my non-SCVMM Hyper-V Virtual Machines.

BCDR (Business Continuity and Disaster Recovery options) is a big deal for any I.T. Pro. My decision to go with with Microsoft Azure Site Recovery cloud service was easy after considering other options available to me, cost and the specific needs of my infrastructure environment. It was by far a better solution in terms of CapEx, OpEx, and geographical redundancy and flexibility. Other options require an upfront cost that includes but is not limited to: renting a location, cost of buying or renting physical servers in addition to telecoms cost.

According to Microsoft, Site Recovery is an Azure service that contributes to your BCDR strategy by orchestrating replication of on-premises physical servers and virtual machines to the cloud (Azure) or to a secondary datacenter. When outages occur in your primary location, you fail over to the secondary location to keep apps and workloads available. You fail back to your primary location when it returns to normal operations.

Azure Site Recovery can be deployed in two scenarios. In an environment with System Center Virtual Machine Manager 2012R2 (SCVMM2012R2) or an environment without SCVMM2012R2, with just Hyper-V Manager. In this post, I attempt to document and outline my steps in deploying and configuring Site Recovery protection for my virtual workloads in a Hyper-V Manager environment.

The steps are are as follows:

1) Login to the Azure portal : (assuming you already have a subscription and account. if not, you can create an account and pay-as-you-go subscription). Expand on the “More Services” link and navigate to “Recovery Services Vault” , click on Add to create a new Vault:


I made sure to create the new Recovery Vault resource in the same location as my Virtual Network. Click Create after filling the fields as shown in the screen shot above.

2) Click on the newly created Vault resource to view the available configuration options. If this is your first Site Recovery deployment, navigate to the Settings,Getting Started, Site Recovery, Step 1: Prepare Infrastructure, Protection goal.These options will quickly walk you through the deployment steps and scenarios that best suit your protection goals. In Protection goal select To Azure, and select Yes, with Hyper-V. Select No to confirm you’re not using VMM. Then click OK.


3) Select the Step 2: Prepare Infrastructure, Source. To add a new Hyper-V site as a container for your Hyper-V hosts or clusters, click +Hyper-V Site.


On the Create Hyper-V site page specify a name for the site. Then click OK. Select the newly created site and click +Hyper-V Server to add a server to the site.


On the Add Server page, for the Server type field, verify that Hyper-V server is displayed.Click the download link to download the Azure Site Recovery Provider installation file. Run this file to install both the Provider and the Recovery Services agent on each Hyper-V host. I’ll use the “Download” button to download the vault registration key to register my host in the newly created Hyper-V site. The key is valid for 5 days after it is generated.


Run the Provider setup file on each host you added to the Hyper-V site. If you’re installing on a Hyper-V cluster, run setup on each cluster node. Installing and registering each Hyper-V Cluster nodes ensures that virtual machines remain protected even if they migrate across nodes.

4) Run the Provider setup file. Choose to use Microsoft Update to update the software unless SCCM is in place to serve the same objective.Click install on the Provider Installation window.


5) After installation, click on the “Register” button to register with the ASR vault in Azure.On Vault Settings page, click Browse to select the vault key file that was downloaded previously. Selecting the Vault key will automatically fill the remaining vault settings field.


6) I don’t have a proxy server in my environment, so I’ll select the option to connect to ASR directly. Click next to complete the registration process with ASR. After registration completes, metadata from the Hyper-V server host is retrieved by Azure Site Recovery. I’ll hold off on the on premise configuration and move back to the Azure portal. After a page refresh, I can see Hyper-V host server is displayed on the Settings, Site Recovery Infrastructure, Hyper-V Hosts page. Click Ok to save the changes on the Azure Prepare Source page.


7) Click Prepare infrastructure, Target and select the Azure subscription you want to use. In step 2, I’ll select Classic as the deployment model to be used for my VMs after failover. This will enable me take advantage of my already existing storage account and virtual network (created in the Azure classic portal). If the Resource Manager deployment model is selected, I’ll use the +Storage Account button to create the Azure storage account to be used for replication.


I’ll create a test storage account using ARM. On the Create Storage Account page, enter a name for the storage account in lower case letters (required). Select Geo-redundant storage under the Replication field. Click OK.


I’ve chosen to use the Classic deployment model, I’ll confirm my storage accounts and virtual network and click OK on the Target configuration page.


8) The next step is to configure replication settings.To create a new replication policy click Prepare infrastructure, Replication Settings, +Create and associate.

9) In Create and associate policy specify a policy name.

10) In Copy frequency specify how often you want to replicate delta data after the initial replication (every 30 seconds, 5 or 15 minutes).

11) In Recovery point retention, specify in hours how long the retention window will be for each recovery point. Protected machines can be recovered to any point within the window.

12) In App-consistent snapshot frequency specify how frequently (1-12 hours) recovery points containing application-consistent snapshots will be created. Hyper-V uses two types of snapshots — a standard snapshot that provides an incremental snapshot of the entire virtual machine, and an application-consistent snapshot that takes a point-in-time snapshot of the application data inside the virtual machine. Application-consistent snapshots use Volume Shadow Copy Service (VSS) to ensure that applications are in a consistent state when the snapshot is taken. Note that if you enable application-consistent snapshots, it will affect the performance of applications running on source virtual machines. Ensure that the value you set is less than the number of additional recovery points you configure.

13) In Initial replication start time specify when to start the initial replication. The replication occurs over your internet bandwidth so it is recommended to schedule it outside of busy hours. I want to start my replication immediately since this is a test environment. Then click OK.


When you create a new policy it’s automatically associated with the Hyper-V site. Click OK. You can associate a Hyper-V site (and the VMs in it) with multiple replication policies in Settings, Replication, policy name, Associate Hyper-V Site.


14) I’ve chosen to download and run the Capacity planner for Hyper-V replica at a later date.

15) After Prepping the Infrastructure, we’ll go ahead and Enable Replication using the “Replicate Application” step. Click Step 2: Replicate application, Source. In the Source blade, select the Hyper-V site. Then click OK. After enabling replication for the first time, click +Replicate in the vault to enable replication for additional machines.


16) In Target I selected the vault subscription, and the failover model I want to use in Azure (classic, because I created my initial storage account and network in classic) after failover. I selected my Classic storage account. If you want to use a different storage account than those you have you can create one. To create a storage account using the ARM model click Create new. If you want to create a storage account using the classic model you’ll do that in the Azure portal. Then click OK. Select the Azure network and subnet to which Azure VMs will connect when they’re spun up after failover. Select Configure now for selected machines to apply the network setting to all machines you select for protection. Select Configure later to select the Azure network per machine. If you want to use a different network from those you have you can create one. To create a network using the ARM model click Create new.If you want to create a network using the classic model you’ll do that in the Azure portal. Select a subnet if applicable. Then click OK.


17) In Virtual Machines > Select virtual machines click and select each machine you want to replicate. You can only select machines for which replication can be enabled. I selected to replicate just one virtual machine from my Hyper-V host: W81. Click OK.


18) In Properties, Configure properties, select the operating system for the selected VMs, and the OS disk. Verify that the Azure VM name (Target Name) complies with Azure virtual machine requirements and modify it if you need to. Then click OK. You can set additional properties later.


19) In Replication settings, Configure replication settings, select the replication policy you want to apply for the protected VMs. Then click OK. You can modify the replication policy in Settings > Replication policies > policy name > Edit Settings. Changes you apply will be used for machines that are already replicating, and new machines. Click the Enable Replication button after completing the Replicate Applications tasks.


You can track progress of the Enable Protection job in Settings, Jobs, Site Recovery jobs. After the Finalize Protection job runs the machine is ready for failover.


View and manage VM properties.

1) It is recommend to verify the properties of the source machine. Click Settings, Protected Items, Replicated Items and select the machine.


2) In Properties you can view replication and failover information for the VM.


3) In Compute and Network, Compute properties you can specify the Azure VM name and target size. Modify the name to comply with Azure requirements if you need to. You can also view and modify information about the target network, subnet, and IP address that will be assigned to the Azure VM. Note the following:

You can set the target IP address. If you don’t provide an address, the failed over machine will use DHCP. If you set an address that isn’t available at failover, the failover will fail. The same target IP address can be used for test failover if the address is available in the test failover network.

The number of network adapters is dictated by the size you specify for the target virtual machine, as follows:
If the number of network adapters on the source machine is less than or equal to the number of adapters allowed for the target machine size, then the target will have the same number of adapters as the source.
If the number of adapters for the source virtual machine exceeds the number allowed for the target size then the target size maximum will be used.
For example if a source machine has two network adapters and the target machine size supports four, the target machine will have two adapters. If the source machine has two adapters but the supported target size only supports one then the target machine will have only one adapter.
If the VM has multiple network adapters they will all connect to the same network.


4) In Disks you can see the operating system and data disks on the VM that will be replicated.

5) At this time, the Azure Replicated Items synchronization status is at 31%. After it’s complete, I will test failover to my virtual network. I initially tried to enable Azure Site Recovery protection on a replica virtual machine. The task failed with the following error: “Avoid enabling Microsoft Azure Site Recovery protection for a virtual machine that already has replication enabled.” More details are displayed in the screen shot below.



The following screen shot displays the current status of the VM replication to the Azure Recovery Vault at the on premise Hyper-V manager.


Test Failover.

1) With the Replicated virtual machine fully synchronized to Azure, I’ll go ahead and Test Failover. As a first step, I’ll install the Azure VM Agent. This is recommended by Microsoft. It gets the best performance from the VM, makes booting faster and helps with troubleshooting. I installed the agent from the PowerShell console as Administrator.

2) To test the failover of my virtual machine, I’ll login to the Azure portal, navigate to the Recovery Services Vault, Settings, Protected Items, Replicated Items, select the virtual machine and select the Test Failover button.


3) On the Test Failover page, I’ll select the Azure network to which the Azure VM will be connected after failover occurs. At this point, I will verify that the on premise Primary virtual Machine is set to DHCP before shutting it down.


4) Click OK to begin the failover. I can track the progress of the failover by clicking on the VM to open its properies, or navigate to the Test Failover job in Settings, Site Recovery jobs.


5) When the failover reaches the Complete testing phase as shown below, I navigated to the Azure Portal Virtual Machine page to verify that the VM started successfully, view the properties of the Azure test VM and retrieve it’s private IP Address based on my Azure virtual Network. I already setup Azure Site to Site VPN to my on premise infrastructure as described in an earlier post, so I’m able to internally RDP into the test Azure VM. The below screen shot shows the internal DHCP IP Address of the Azure test VM.



6) I disabled the windows firewall on the on premise primary VM before shutdown, so I’m able to successfully ping the Azure test VM. RDP into the Azure test VM using it’s internal IP Address.


7) I am able to successfully ping my on premise WS 2012 r2 domain controller. I successfully verified the settings and state of the Azure test VM W81-test. I verified that the VM disk is the right size. There’s also a temporary disk attached by Azure. There is a Data Loss warning file on this disk with message : Any data stored on this drive is SUBJECT TO LOSS and THERE IS NO WAY TO RECOVER IT.Please do not use this disk for storing any personal or application data.


8) Click Complete the test on the Site Recovery Jobs page to finish it. Click Notes to record and save any observations associated with the test failover. Click “The test failover is complete . Clean up the test environment” check box to automatically power off and delete the test virtual machine. Click Ok. At this stage any elements or VMs created automatically by Site Recovery during the test failover are deleted. Any additional elements you’ve created for test failover aren’t deleted. If a test failover continues longer than two weeks it’s completed by force.


9) After successfully cleaning up the test failove environment, I will turn on my primary on prem VM. Please note that I did not have to turn off the primary VM for the failover testing. This is a testing environment, so I can afford to shutdown theh VM. In my production environment, I would isolate the Azure virtual network preferrably to run this test successfully and avoid any conflict between the on premise primary VM and the Azure test replica. At anytime, I could also pause the replication from the on premise primary VM.


Posted in Azure Site Recovery, BCDR, Business Continuity, Disaster Recovery | Tagged , , , , , , , , , , , , , , , , , | 1 Comment