Bug with Essentials Integration for Azure Site Recovery

Back to Blog

Bug with Essentials Integration for Azure Site Recovery

Awhile back, I had written a series on all the neat integrations available with Windows Server Essentials (or Essentials Experience, if installing it on top of Standard as a role).  You may have noticed that I never published an article regarding one of the most exciting features–integration with Azure Site Recovery (ASR).

Azure Site Recovery is a Microsoft cloud service that allows you to replicate your on-premises virtual machines into the Azure cloud. The idea is, if you ever have an issue with the on-premises server, or lose the site due to some other disaster, then you can bring your virtual machines back online in the Microsoft cloud, with just a few clicks.  I have written about the Azure Virtual Network configuration that would be required for this before, in my series on Azure Site Recovery.

Well, I never finished the Essentials integration article for ASR, because it seemed like the integration wasn’t working. There were two problems to overcome, and now I think we have officially identified a bug in the integration.*  Here were the problems we ran into:

  1. When you enable the integration in the Dashboard, nothing shows up in the VM list–it’s just empty
  2. Once you overcome issue #1, then you are not able to enable replication on the VM’s with the error “Install provider on the VM host failed. Please try again.” Or it might say, “Download provider from Internet failed. Please check your network connection and try again.

Both of these issues have been solved.

The first one, it turns out, is not actually a problem–it’s just a matter of meeting the design requirements.  MOST small businesses only have a single Hyper-V host, and usually that host is located in a workgroup (not joined to the domain). This is according to best practices when the only domain controller(s) in the environment are virtual machines, on top of that Hyper-V server. However, if you want the Essentials integration with ASR to work, then you must join the host to the domain.

I know, mind = blown. Right?

In fact, it is necessary to meet all the following requirements (from Microsoft support):

The Essential [sic] will only list the following VMs in that list for you to start the VM protection –

  • The Hyper-V HOST has to be Windows Server 2012 R2 or 2016
  • The Hyper-V Host has to join the same domain as Essentials server does.
  • There is at least one VM under the Hyper-V Host which meets the above two requirements.

Okay cool, so with the host joined to the domain, your VM list will now populate, provided the host is 2012 R2 or newer, and there is at least one “protect-able” virtual machine.

The second problem is a bit different than the first, in that there is a legitimate software bug with the integration. When you go to enable replication on your virtual machines, you will get an error similar to the following:

So what’s the problem?  Well, for this process to complete successfully, the Hyper-V host & the Essentials virtual machine have to be able to communicate properly, to get the Microsoft Azure Recovery Services (MARS) agent installed, and then reporting information back to the Essentials Dashboard. But it is unable to get there.

It seems that enabling the integration feature should open certain Windows firewall ports related to Windows Management Instrumentation (WMI), but it doesn’t. Therefore it will be necessary to enable these rules manually on the Essentials server, like so:

This will need to be completed, before you can successfully replicate virtual machines as described in their documentation.  Once it’s working, the process is very simple:

Click Enable Replication to Azure.

If this is your first time setting up, you will need to sign into Azure using your credentials, and assign a storage account that you can use for storing the replicas.

After that is done, choose whether this is a Windows or Linux VM (I did also test Linux, it works!) and then Next.

Click on Finish.

Bam! Couldn’t be easier. Note: time to replicate can be very long, especially over slower links. So just be patient. You can watch the replication percent complete in the Hyper-V management console.

I have to give a shout-out also to my friend Daniel, who lives and works in Brazil. He was having the same issue as me, and got me involved along with a few of his other friends (they are all MVP’s), on this Microsoft support case. I will include some links to their blogs here as well.  Thanks everyone for keeping us focused on solving this issue!

Comments (9)

  • Craig Franklin Reply

    Well done team for solving this and many thanks for sharing the resolution!

    April 6, 2017 at 6:36 pm
  • Craig Franklin Reply

    My understanding is that the firewall rules need to be opened on the Hyper-V host – is that correct?

    April 6, 2017 at 6:38 pm
    • Alexander Reply

      Actually no–strangely enough these have to be enabled on the VM where the Essentials integration lives.

      April 6, 2017 at 6:55 pm
  • Pete Mahar Reply

    I’d really love to be able to virtualize Essentials so that I can use Azure for disaster recovery. I have a physical copy of Essentials and a virtual copy of essentials installed on my sever. I understand that the licensing allows this. But I cannot get the VM to replicate. Is it just not possible? Do I need to purchase Windows Server 2012 R2 or 2016? Thanks!

    October 30, 2017 at 8:57 am
    • Alex Reply

      Have you followed the tutorial to replicate the VM to Azure?

      October 30, 2017 at 10:06 am
  • Rob Reply

    I’ve got replication to Azure working properly on 2 of my 4 Hyper-V hosts. 3 are clustered, one is stand alone. One of the 3 in the cluster allowed me to enable Azure replication, as did the stand alone Hyper-V host. The other two keep failing with a similar message that Alex reported in this article. The exact message is “Unable to start VM replication – Register VM Host to Azure Recovery Service failed.” Then the same URL as in Alex’s screen shot. I’ve tried to pick apart the log in C:\Program Files\Microsoft Azure Recovery Services Agent\Temp\CbEngineCurr.log on the problem hosts, but I’m not really versed enough to understand what is failing. Has anyone experienced anything similar?

    January 15, 2018 at 11:36 am
  • Rob Reply

    It just dawned me… perhaps Server Essentials has a limit on how many Hyper-V hosts it can enable for Azure Site Recovery? I wonder if that is my problem. I haven’t found a published limit anywhere, but it would not surprise me since server essentials have other limitations.

    btw, my firewalls are disabled on all hosts, so that’s not it.

    January 15, 2018 at 11:43 am
    • Alex Reply

      This is a good point, and if so, it is also not documented anywhere. I have installed it on 2-server/SAN environments with HA/failover, and standalone, single hosts. So I’ve never enabled more than 2 at a time myself. I have also seen that message happen several times, and then just suddenly work, even on standalone hosts. I assumed there was a timing or delay issue causing it. Not sure if that is the case or not, however.

      January 15, 2018 at 3:17 pm
      • Rob Reply

        Well, I’ve confirmed it’s not limited to two hosts. After digging through MS documentation for MARS agent and the Azure Site Recovery Provider docs, it seems their official recommendation is to manually install MARS and or the Azure Site Recovery Provider manually and then register it manually. This was successful for me, albeit a bit tricky. I now have 4 Hyper-V hosts in the same domain all enabled for site recovery from Essentials Dashboard. I got most of my information from: https://docs.microsoft.com/en-us/azure/backup/

        I guess there are still some quirks with Essentials and the official troubleshooting documentation for it is rather spares.

        January 16, 2018 at 12:14 pm

Leave a Reply

Back to Blog

Helping IT Consultants Succeed in the Microsoft Cloud

Have a Question? Contact me today.