More Azure Site Recovery bugs in Windows Server Essentials?Alex Fields
Previously, I wrote about the Azure Site Recovery plugin for Windows Server Essentials Dashboard. One might say that it hasn’t been the best product so far, in that getting it to work without hiccups is apparently luck of the draw. Microsoft Support hasn’t been able to reproduce the issues that we have been running into out in the field, and they are still working on ironing out what the problem is (but we have reproduced the issues in the United States, the UK and Brazil–so I think it is safe to say this is a legitimate bug).
If Microsoft does get this working smoothly, then I think it has a lot of potential, across SMB and Enterprise departments (because it would make setting up an Azure Site Recovery / DR solution in the cloud so damn easy). But so far, it is not easy. It would be much easier in fact to just set it up yourself via the portal, the old fashioned way.
Another “bug” in the Essentials Dashboard?
Once you are able to get your VM’s replicating, you might wonder, “So now what about actually failing one over?”
Well, wouldn’t you know it, that isn’t quite as easy as advertised just yet, either. You might see this error, if you try failing over (or you might not, depending–we’ll get to that in a minute).
There is no AVN available. Failover… fail.
So what is the deal with that? To correct this issue, all you really need to do is ensure that you do in fact have an Azure Virtual Network setup in the Azure Portal. Ah-ha, “But Alex, I set one up earlier using the Essentials Dashboard, I am looking at in now and it reads Connected, so what gives?!”
I’ll tell you what. When you create any kind of resource in Azure, you need to associate it to a given region (e.g. West US, Central US, West EU, etc., etc.). The key to remember is, that you cannot have separate datacenters managing different aspects of a single deployment. So if you wanted to create a virtual network where you could deploy VM’s out of a particular Azure Site Recovery vault, you better make sure they are in the right spot! Why did I get the error above? This is why:
The solution is simply to re-deploy, ensuring that the same region is selected in both cases. So maybe it isn’t fair to classify this as a “bug” in the proper sense of the term. But, it is fairly annoying. What I think would be ideal for this Essentials product: make it idiot-proof / me-proof. So for example, if I use the Dashboard to create any kind of Azure resource, make sure it goes into the same region/datacenter, so that this could not happen, even by accident.
The problem is, some people may have a different use-case for Azure VNet. For example, they need a production VM for a line of business app. For their DR strategy, they may want recovery to a different region in the US than their production services. I think that having the option is great, but by default, 95% of customers using the Essentials plugin probably just need one datacenter region–to opt out of that should be an extra step, in my opinion.
What it comes down to is that there just isn’t very much support for this product–very little documentation, etc. Also it seems to have been released to manufacturing before it was fully baked, or I don’t think we’d be running into as many hiccups with it. For example, there is yet another bug I haven’t told you about yet, where you may be unable to connect to a VM once it has failed over. We’re still working through that one, and I’ll probably have another write up on it, later.
Some day, this ASR plugin could be really awesome–and maybe it will even become the defacto tool for deploying Azure Site Recovery, but right now this product basically feels like it is in beta. I could be wrong, and that wouldn’t be the worst thing ever. And maybe my friends from around the world are just running into the same errors and issues by happenstance, while it is working perfectly for most of the rest of you out there, as it seems to for Microsoft… But I don’t know about that. Maybe you can let me know, just in case.