In this video, I walk through performing a Test Failover of my VMware based VMs into Azure. As I mention in the video, if you cannot RDP (Remote Desktop) to your VMs running in Azure, there are a couple things to check.
- Be sure to add a public IP address to your VM running in Azure. I walk through this in the video. This link talks about the detail.
- Be sure to add the RDP endpoint to the VM before you fail it over to Azure. If you can’t RDP to it while its on-premises, you won’t be able to from Azure either.
- Be sure that you enabled the RDP firewall rules in your VM. This article talks about the details of enabling the ports in the Windows Firewall. Remember that the VM may not “think” its on the domain network when it fails over to Azure. As the article mentions, be sure you’ve considered opening RDP for the public network as well.
- During testing, if you make changes to your on-premises VM (like opening RDP or changing the firewall), be sure to give ASR time to replicate the changes to Azure before attempting your next Test-Failover.
I believe that the ability to easily perform a test failover is a big differentiator for our partners. How many customers have a Disaster Recovery plan? Of the few customers that have a DR plan, how many actually test it? Azure makes it easy to perform a non-disruptive test failover of your customers production environment, even during the business day!
Check out this video for the details on how to make this happen:
While I had to enable the firewall rules and enable the Remote Desktop Endpoint in Azure, you may not always need to do that. If you have an established sandbox environment, maybe you don’t want to create the security risk of enabling RDP on the Internet. Maybe you can create one VM within your Virtual Network that has internet access, then check the functionality from that VM, as opposed to opening RDP for all of your VMs. I will leave the details to you and your team, but for more details on ASR, you are welcome to check out our documentation here.
One of the other things I learned while setting this up is that it is better to install the Azure Management agent on your on-premises VMs so the VMs already have the Azure Management agent when they replicate to Azure. Of course you could install it post-failover, but that is just one more thing to do, and it also changes the footprint of your VM. Why not do it now and know the agent is just part of your workloads. Here is the link to install the Azure VM agent on your on-premises VMs.
Please check out our whole series of Azure blogs & videos at http://azure.msts2.com
Until next time,