Removing ASR Protection (V2 in the new Azure Portal)

Once you are done with your ASR pilot, there is a certain order you should take to properly disconnect your on-premises Hyper-V host.

The first general rule is: do not remove the agent before cleaning up things in the portal. It is going to be harder. Start by deleting the configuration in this order.

– Unprotect any VMs you may be protecting:

1. Go to Replicated items in the Azure portal:


Click on the machine, them More Commands, then Delete:


Select as below:


This will disable the protection only but if needed, this machine will be still manageable later.

Wait until the protection is disabled:



Now for the Hyper-V server. Click on Site Recovery server:


Then select your Hyper-V server:


Click Delete and OK.


This will remove the configuration from the local Hyper-V host.

Now you would be ready to reconfigure your host, but I will go all the way and remove the agents from it:




And the second one:


And you are in the clear! Hope this helps!

Azure Site Recovery–Onboarding in the New Azure portal–PREVIEW

As many Azure features that come out, you just stumble upon it while casually browsing the (extensive) Azure portal. This was the case with the preview of Azure Site Recovery. Previously, you could see a reference to the ASM version, but it would through you back (in time) to the old portal.

Now a real interface to configure the service has been made available. Not this is a preview and shouldn’t be used in production.

It starts with creating a Vault:


(isn’t the little alien guy funny?)

Next you need to pick which scenario you want to use:


I’m going with Hyper-V Stand alone, since that’s all I can do at this time.

Next, create a Site:


Now you will need to install the bits to your Hyper-V hosts and use the credentials file as suggested:


Install the provider:



Register the Vault:




Now, to the portal! And there it is:


Add a Replication policy:


I’ve noticed the naming is more consistent with the PowerShell commands:


Create a Compute configuration. This is new:




Now moving to a different blade and option:


Enable replication through these steps:


Picking my usual suspect: CoreOS


Select storage account and OS:


And Replication policies:


[tense music plays]


Job completed:


And here is my VM being synchronized:


Hope this helps. I will be back with the testing procedures and how to set this up using PowerShell!

Configuring Azure Recovery Services – Premises to Azure – Part II

In my latest posts, I have covered how to create the vault and configure the basics of the Azure Recovery Services – On Premises to Azure. Now we need the final part in order to make it work: a recovery plan. A recovery plan gathers virtual machines into groups and specifies the order in which the groups fail over.

I can see that my initial replication was completed (and it took 9 hours in my poor 2Mb upload plan):

You can see the events on the Hyper-V server that hosts the machine:

Cool. Now, let’s try the recovery plan ear, like I do. However, you should check the steps here:

Seems simple, right?

Should we just try to failover to azure? I will first try to start the VM, make some configurations and see what happens.

Let’s start it ‘On prem’:

It seems to work fine:

If my network mapping is correct, I should get an IP on the other side, in the mapped network. (See previous article).

Let’s test it!

Well, for a test it seems you will need an extra network. Let’s do it:

Let Azure take care of the DNS part in this case:

Cool, now we have a network. Let’s hit it!

It seems to be moving…

It seems the machine started. Let’s take a peek:

There you go.

But funny enough, I can’t connect to it.

No endpoints. Let’s try and create one:

Now the Connect option is enabled. Let’s try it…not that simple. If the original machine didn’t have the option for RDP enabled, it won’t magically work. Let’s take a look.

Dang it!

I will enable it and for the sake of simplicity, disable the firewall.

After doing that, I will end the test, wait for the replication to work and will try again.

Now, I have waited more than 30 minutes, to make sure that my 15 minutes cycles were covered. You can also check on Hyper-V manager:

Let’s test the failover again. So, it worked but I couldn’t log in. The account Administrator was the only account I had and not only that, but it also had a silly unsupported password.

I have created a new Local Azure Admin user and will try the failover test again once replication finishes. Let’s go!

Cool! First try! 😉 I’m in! Just got this screen, since the machine was being replicated and just booted up from the VHD:

And I’ve got the IP in the right network:

Now, the final FailOver test:

I’m going with planned.

Wow, it just stopped my VM on Hyper-V:

And started a “Planned Fail-over”

On the Azure side:

And after 7 minutes or so:

And there is our machine:

No endpoint though, which can be a good thing.

Let’s try internally:

Love it!


Ok! Now, do you think we should fail it back?

I think we should!

But let’s try to trick it:

I’ve created a file on the desktop:

I will commit it:

Now I can failover back:

Will pick this one:

Now, on the VMM side:

This is taking a little longer than I expected, since there were no major changes:

 And after 46 minutes…

My VM is back On Premises:

So, summary of Lessons learned:

– Configure another admin account, other than Administrator, to manage the machine

– Don’t use silly/unsupported passwords for those accounts

-Add an Endpoint after failing over, in order to access it (assuming you won’t be able to route through your VPN connection)

Hope this helps!