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!

My Favorite Azure New Features

On May 12, Microsoft has announced a whole bunch of new Azure features (here). If you try, like myself, to be up to date with them, you will realize how hard that is. These ones, however, are major and worth a word about. I was asked to pick my favorites, so, here you go.

Well, before you go, please spend some time getting to know Azure. A wonderful resource is the Microsoft Virtual Academy, which has plenty of information to keep you busy for a long time. This training (, that is an very good starting point (don’t be afraid of the sales side of it, it is pretty technical). And if you don’t have a trial account yet, stop everything you are doing and please go here NOW!

Ok, for the main course: my favorite new features.

First, Networking. All the new features in that are very good, but I want to talk about my favorites among them.

  • Multiple Site-to-Site VPNs – prior to this feature, you were not able to reach an Azure virtual network directly from multiple on premises networks. Only one connection was allows per Azure Virtual Network. Now, one virtual Azure network allows for multiple connections to it (actually, to its gateway). That is great because from an application connectivity perspective, you were limited to a single pipe and all the traffic to your cloud and applications needed to be routed through a main hub. Now secondary datacenters and even branches can reach out directly to the servers in the cloud. The details are here, but be ready to deal with configuration files, since this release won’t allow for the configuration to be done in the portal.
  • VNET-to-VNET Secure Connectivity – now Azure can route between two Azure virtual networks and even between different subscriptions. This is also great, since before, you had to make that traffic go back to your premises and then go back up if those networks were completely unrelated. Now you can save traffic and bandwidth in your pipe. You can find details here and a good article on how it is done here.
  • Reserved IPs – I love this one, since it will answer a big question users had: what if my IP changes. Still today, there are many applications that will need to rely on a static IP, so, there you have it. You can reserve up to 5 IPs per subscription. Only PowerShell for now, but will come to the portal soon.
  • Premises-to-Azure Recovery Services – I don’t think this feature is mentioned in the original post, but I believe it is worth mentioning. You can now replicate your machines and orchestrate the recovery not only between two On-Premises deployments, but also between premises and Azure! This awesome, since you can leverage storage, computing and availability in Azure without having to deploy a secondary location of you own. The setup is relatively simple (I don’t like the word ‘hard’) and there is a great step by step guide here.

Second, Virtual Machines: lots of goods stuff here.

  • Capturing : one thing I really like the new capturing capabilities. You can capture VMs now when they are started or stopped and create your new images for testing in the blink of an eye. And not only that: you can now capture VMs with data drives! Actually multiple data drivers! And no sysprep! Can you ask for anything more? Development and testing scenarios can take a lot of advantage from these new features.
  • The new VM Agent is also worth mentioning. Not sure though how many people will use the available Antivirus extensions, but the agent will allow for future installations and who knows what kind of interesting and useful stuff will come out. Although there may be some security concerns, being able to inject them into your VMs is a very nice to have feature. Now, the AWESOME part is this small comment: “This week we’ve also enabled a new “Custom Script” extension that enables you to specify a PowerShell script file (.ps1 extension) to run in the VM immediately after it’s created.  This provides another way to customize your VM on creation without having to RDP in.” Can you see the potential for automation? Adding certificates, monitoring agents, special configurations…I can! Take a look here for some detailed explanation on how it is implemented.

On the Storage front:

  • SMB: I like the idea of being able to use SMB file sharing and making it simpler between VMs to share files and exchange data between applications. SMB is the Microsoft standard for network file share and it is about time for it to be available in azure. Implementation details here!

The rest of the features are sure great, but these are my favorites. Note that as infrastructure consultant, naturally, the infrastructure related stuff will be on the top of my mind. Make sure to spend some time in the Azure portal and I guarantee you will love all the other offers and features that can’t stop popping up!

Hope this inspires you to go and get your trial subscription right now!

If you are in Toronto, please take some time to check our user group page out! Toronto Azure Group: Infrastructure Focus

SCOM and Azure – Monitoring your Cloud infrastructure

I have been asked to think about how to extend an existing datacenter monitoring infrastructure into Azure. I like to see the extended datacenter as a transparent entity,so, my approach is to ignore the fact that the remote servers are in the (for now).

If I had a remote datacenter, the first think to take in account is the number of agents. If I have just a couple of machines there, I would let them report directly to the SCOM Server at the main DC. Bandwidth shouldn’t be an issue. If you have more thought, it would make sense to try and optimize the bandwidth usage.

Since all the SCOM 2012 Management servers have to talk to the database directly, it doesn’t help a lot to have a remote management server. You will basically change the type of traffic from port 5723 to SQL server data. If you have some way to optimize the traffic, maybe you could think about. The answer for that is to use a Gateway server in the remote DC (Azure, in our case).

For our lab purposes, I already have a connection to my remote network and a server deployed there (see a previous article for that). Now, I will deploy a SCOM gateway server, connect it to my main location (home, sweet home) and allow for my remote DC to report to the gateway server.

Let’s get to work!

First, let’s review the configuration:

Now, let’s create the SCOM gateway in Azure:

Basic configuration:


Now let’s wait.

Ok, the VM is ready. I can connect (RDP) internally to the VM, so I will join it to the domain, and install SCOM SW

Note: you normally can’t ping the VM. You have to enable the proper rules in the firewall to allow that.

Now you should see it here:

Reject it!

Now approve the gateway:

Now that we have the Gateway, let’s deploy the DC agent:

Here’s a trick: usually, things behind a gateway are not directly manageable and therefore, the agent is normally installed manually. However, we CAN manage the remote DC and I’m using the GW just to reduce traffic. So, I will install the agent from the console, and then redirect the management to the gateway. Behold:

Once you have the DC and the gateway reporting properly, we can just switch the management server for the Azure DC:



And ther eyou have it. The Gateway will serve as concentraition point in azure, to avoid external traffic.

Hope this helps!

Extending your DataCenter to Azure using Cisco SMB Router (RV042G)

A while ago, I started playing with Azure and always wanted to extend my humble lab to the Cloud, just so I could expand and contract when needed. I could do it with a Microsoft RRAS, but decided to go for a real VPN router. I still intend to post about RRAS. Stay tuned.

Here’s my quick scenario:

Local Network:

Remote Azure Network:

The interesting part of this post is that Microsoft will give you a configuration script for some well-known platforms, like RRAS, Cisco IOS and Juniper, but not for anything else. So, it is up to you to figure out the VPN parameters. Didn’t take long for me, but it is always an interesting task!

Let’s start with the Azure configuration.

Once you are logged in to the portal…wait, you don’t have an Azure subscription? Ok, go here and get you free trial subscription and get yourself a cloud to play!

So, you have your account and is logged on to the portal, right? Now, go to the Network menu:

I have a Local Network created already, that looks like this:

13* is the address of my Cisco VPN host. I know that since I’m using a dynamic IP, I will need to reconfigure the local network once it changes.

And the next screen looks like this:

Let’s create our network. Hit Create Virtual Network and complete the fields:

If you know one of your remote servers will be a DNS, add it here. Otherwise, let Azure provide you with one.

Now, select the Site-to-Site VPN and pick the Local Network you created before:

You will need to work out the proper Address Space for you network. I have tried to keep it to a Class C (256 IPs),but you have to create a subnet in order to accommodate the Gateway subnet:

Success! Here’s our virtual network. And we are…almost there. Note the screen below:

It is right there: THE GATEWAY WAS NOT CREATED. So, what should I do…not sure…well, let’s try creating the gateway!

Note again the bar below…yeah, down there, you almost missed it…and you will also notice that it mutates. Try to remember it exists and your life will be much easier. Here:

Hit it. I have picked static, since I don’t have any routing protocols running. NOTE: a gateway in a virtual network means a mini-VM is running to provide that, and therefore, there is cost!

Once the gateway is created (that can take a while), let’s try to connect to our Cisco host. First, get the script from the Dashboard screen:

That’s what I need:

Wait! Didn’t I say that I didn’t have a Cisco High end router? True. I don’t, but the cisco file will help us figure out some VPN parameters in the RV042G.

This will save a local file: VpnDeviceScript.cfg. In our case, it is a cisco configuration file:


Should look something like this:

Let’s try now that the GW is ready:


Here’s the RV042G configuration, as it ended up being:

Most of the settings below can be figured out from the cisco config file:

And more:


Now, save it and try to connect:

If you did it right, you should be something like this:

On the azure size, it should look like this:

If you ping from a local machine to, you will get something back:

To test it fully, I have deployed a machine to the new virtual network:


The machine the IP and you should be able to RDP to it:

From here, everything is awesome! I mean, everything is normal! It is your first machine on a remote lab!

Have fun!

Guides to deploy SMA and Azure integration

Have recently being in touch with SMA and Azure for some project that are coming soon and stumbled upon these two guides that I believe are worth mentioning:

First one on how to install and do a basic configuration of the SMA piece (or multiple pieces, I should say):

Great job there. There is one entry that I would clarify in case you do the same mistake I did: although I read you had to enable mixed mode authentication, I didn’t. So, I had to enable it after the fact and hence the sa account is disabled, so, when I got to the step 23, I had to create a sysadmin account for that.

The second is in regards of managing windows Azure from SMA:

A few impressions on that part: after the initial SMA install ended, everything looked fine with the portal. After I deployed the WAP, the automation and the Users sections got broken (Red Exclamation mark). To fix that, I had to log on as smasvc (or sma_svc in the original tutorial), configure azure as smasvc and then everything became fine with the portal.

Hope this helps!