Azure Migrate – Part 4 Tips, Tricks and Troubleshooting

Date

This is Part 4 of the Diaxion blog series focusing on the Azure Migrate service to Discover, Assess, Replicate and Migrate workloads from an on-premises location to Azure.

Part 1 was focused on Discovery and Assessment and can be found here – Azure
Migrate – Discovery and Assessment

Part 2 was focused on the Replication component of Azure Migrate and can be found here – Azure Migrate – Replication

Part 3 was focused on the Migration component of Azure Migrate and can be found here – Azure Migrate – Migration

By now we have successfully discovered, replicated and migrated our on-premises servers to Azure. This has been a work in progress and has involved many different components including the configuration of our on-premises hosting environment and our Azure tenancy to support Azure Migrate.
As you work through the Azure Migrate process, there a couple of things to look out for. We will try and highlight these to give you a headstart if you run into any issues along the way. Microsoft Support is generally available and the Azure Portal offers an easy way to log a support ticket with pre-filled options as you step through the Migrate process if you need support from Microsoft.

Replication Error #1

Replication may fail during an ongoing replication or may fail to start at all if there is a low disk space condition on a Hyper-V C:. You may get an error message in the CBengine logs (replication logs) such as “Failed to export VM config for VM *** with hr:8079002c”. If you receive this error message, check the Hyper-V host C: that your VM is attached to for sufficient disk space. There is no specific limit as it is dependent on the VM being migrated. If you cannot free up sufficient disk space, you can edit the registry to change the default path from C:\Windows\TEMP\ with the following

reg add “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Azure Backup\Replication” /v ConfigExportLocation/t Reg_Sz/d<TargetfolderPath>

Replace <TargetFolderPath> with the location which should be used for exporting the VM. It should be an existing location. After this, the MARS agent should use the target folder to export the VM, for any fresh enable-Protection scenarios.

 
Replication Error #2

You may experience issues replicating data from Hyper-V hosts if the MARS (Microsoft Azure Recovery Service Agent) agent doesn’t match the ASR (Azure Site Recovery) Provider version. These two critical pieces of software need to be aligned to ensure the data can be replicated into your Azure tenancy successfully.
 
You may find errors in the MARS Agent logs such as InitializeAgent In Progress: device is not registered.
 
Microsoft is constantly updating Azure Site Recovery with rollups where the version of the software might be changed. The best way to check the current version of the software is on the What’s New page –

https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-whats-new

 

Ensuring your agents are supported is crucial to the success of your migration project. Microsoft recommend keeping your versions at N-4, anything below that will limit your support options. 

Migration Error #1

A server may not be migrated from the on-premises Hyper-V host environment if the disk size cannot be obtained. An error message should appear within the Azure Migrate service in the Azure Portal similar to –

This may be an issue with the Hyper-V host, an easy resolution is to migrate the VM to another Hyper-V host in the cluster if at all possible.

Migration Error #2

You may use Windows Firewall to protect your on-premises servers with a specific set of rules to enable RDP, generally this is configured with specific network profiles. Depending on your network and supporting configuration in Azure, the server that is being migrated may alter its network profile post-migration unexpectedly causing RDP to be disallowed. You will generally not receive an error if this is the case and will encounter a black screen when trying to RDP to the server. A potential fix for this situation is to change the Windows Firewall Advanced setting prior to the migration to enable RDP across all network profiles.

And that is it for this Azure Migrate blog series. Hopefully, this has been helpful and if you have any questions about the migration of workloads to Azure, please contact the team at Diaxion and we’ll be happy to assist with any questions you may have.

Part 1 – Discovery and Assessment

Part 2 – Replication

Part 3 – Migration

Part 4 – Tips, Tricks and Troubleshooting

More
ARTICLES