Overcast » July 2, 2014

Daily Archives: July 2, 2014

Azure Recovery Services Uncategorized

Configuring Azure Recovery Services – Premises to Azure – Part II

Published by:

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: http://azure.microsoft.com/en-us/documentation/articles/hyper-v-recovery-manager-configure-vault/

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!