Azure Site Recovery is a very effective service that is offered by Microsoft in the purview of Disaster Recovery as a Service (DRaaS). While being able to migrate workloads from On-premises environments be it virtual or physical, if you want to move from one data center to another data center where Azure Site Recovery would act as a DR orchestrator or from your data center to the cloud and vice versa. The whole point being that you push the downtime in your businesses to near zero or zero if everything pans out very well.
It is not uncommon for anyone who is trying or testing ASR and run into errors. In this article I give you a glimpse at few common errors that you might see and how to handle them in general. So, this article assumes that you have some knowledge of how Azure Site Recovery works.
One of the several issues you might face after setting up the management server on your on-premises setup is with the IP address. The IP address changes can be pesky and each time the IP address changes (if it does) you will have to change a few settings in Azure and restart a couple of services from within the management server.
The IP address change will lead to the disconnection of the server with Azure and then stop protection of the virtual machines as it will see that the on-premises workloads are not in sync with Azure. To avoid that, if the IP address changes in any case the first thing you want to do is look for a file names “amethyst.conf” and edit a couple of lines by changing the IP address to the current one.
The “amethyst.conf” file should be located in
If you have deployed the process server on a separate server, the PS_IP will change respectively. Also the IP address should be changed in the host config tool. By default, it should be placed on the server desktop, it is also placed in [ASR install location]\ Microsoft Azure Site Recovery\agent\hostconfigwxcommon.exe. You can also modify the passphrase from this place. The same tool would be placed on all the virtual machines that you would like to protect using Azure Site Recovery. Hence, you will also have to replicate the same changes in all the virtual machines too.
You will also have to restart these two service running on the management server, “InMage Scout Application Service” and “Microsoft Azure Site Recovery Service” for the recovery service vault in Azure to quickly recognize and list out all the machines.
Another reason why the management server would not be connected consistently is if the hardware requirements are not matching the pre-requisites. Make sure the hardware is even with the requirements, otherwise the CPU utilization, memory usage etc might reach their maximum resulting in a disconnection.
Another common problem that is encountered is when you need to install a new master target server on a new machine. The setup requires you to enter the connection passphrase that is generated at the time of installing the config/process server (management server). If you have forgotten the password, then you can find the connection passphrase located by default under “C:\ProgramData\Microsoft Azure Site Recovery\private” in a file named “connection.passphrase”.
A few times, I have seen that the machines I have already protected are suddenly no longer protected, this could be due to the fact that the services related to master target server are not up and running or require a restart. The first step to trouble shoot this issue is to check the Site Recovery infrastructure in the recovery services vault in Azure.
If the master target server is either disconnected or down, try refreshing the server. If that does not resolve the issue, you can try restarting the “csprocessserver”, “InMage Scout FX Agent”, “InMage Scout VX Agent – Sentinel/Outpost” services.
Sometimes, everything runs fine until you notice that the automatic push installation of the mobility service does not happen as it is supposed to. The automatic push is meant to install the mobility service on all of those machines you intend to protect and failover.
For example, if it is a windows machine that you intend to protect, there are a few steps you will have to make sure are adhered to before you can failover. Make sure an account with administrator privileges is used.
The first step would be to check if the “file and printer sharing” and “WMI” features are enabled on the windows firewall. If you are not using an account that is not part of a domain, then you will have to disable Remote user access. Only then will the
The error messages are pretty straight forward and provide sufficient information to solve the issue. You can find more of the common issues and solutions here. The error messages with respect to Azure Site Recovery are located in the Jobs section of the Recovery Services Vault.
If you cannot find any resolution and what you have tried has not worked out, try raising a support ticket to see if Microsoft can help you out. If you do not know how to raise a support ticket, you can find the instructions on how to raise a support ticket here.
I will be putting out several articles on Azure Site Recovery on how to at a detailed length. So keep checking back.
This article covers a couple of common issues while setting up/using the Azure Site recovery service. While it is not very difficult to prepare your workloads against disasters it is not really easy too as the initial setup is a lengthy process and one can often make a few mistakes. The best way to resolve is to go through the error messages go through the ASR logs and a few other methods to iron out the issue. Raising a support ticket for help from Microsoft should be a last resort.