Azure Site Recovery & InMage Scout – And Bad Decision Making

Microsoft announced last week that they had acquired InMage, a company that specialises in replication to the cloud. Microsoft is adding InMage to Azure Site Recovery (ASR) to enable replication to Azure. ASR enables you to use Hyper-V Replica (HVR) to replicate VMs to Azure IaaS. So what does InMage Scout (the product) add?

The key piece of the list of features is:

Support for major enterprise platforms, including Windows, AIX, Linux, VMware, Solaris, XenServer and Hyper-V

Imagine being able to replicate not just Hyper-V, but also vSphere and physical (Windows and Linux) workloads to Azure. Potentially, this is a much bigger solution. Potentially.

And potential is … lost opportunity.

That’s because the decision makers in ASR are, in my opinion, disconnected from reality living way too nicely in the Microsoft ivory tower. Why?

  • ASR can only be used by customers that manage Hyper-V using SCVMM. SCVMM can only be bought as a part of the System Center SML. The SML is cheap for larger businesses, but it’s way too expensive for most SMEs.
  • Only EA customers (large businesses) can get access to InMage:

The Azure Site Recovery subscription license will be available through the Microsoft Enterprise Agreement beginning August 1, 2014 and is the only offer through which InMage Scout usage may currently be purchased.

So, SME’s cannot use ASR or the cool new features that are coming. Large enterprises typically already own or want to own their own DR. And the sweet spot market for a hosted virtual DR (DRaaS) is the SME … the market that cannot afford or get access to ASR.

Oh, the madness continues.

Creating a VNet-to-VNet VPN in Microsoft Azure

A while ago I read about how to connect VMs between two VNets and it was nasty: before we could create a VPN tunnel we had to open Endpoints (punch holes through firewalls) and hope for the best!

Since TechEd NA 2014, we have had new functionality where we can connect two VNets, in the same or different data centers, in the same or different regions, or in the same or different subscriptions, via an encrypted & secure VPN tunnel.

As usual, this stuff is announced normally via blogs (it was mentioned in the TechEd keynote I think) and finding instructions can be fun. The first few guides I found were messy, involving exporting VNet configs, editing XML files, and importing configs.

You do not need to do this to set up a simple configuration to connect two VNets. I looked at the instructions, used by experience from site-to-site VPNs with Azure, and tried out a method that uses a temporary local network to enable you to create the VPN gateway and gateway VIPs for each vNet – these are required to create a local network for each VNet. We use local networks to define the details (public VPN IP address and routable private network IP address) of the network that will connect to a VNet.

I tried my method and it worked. And then I found instructions on MSDN that are similar to the method that I used. My method:

  1. Create the two VNets
  2. Create a temporary local network with made up gateway IP address (public VPN IP) and address space (private network address that will route to the VNet subnets)
  3. Configure each VNet to allow site-to-site VPN connections from the temporary local network
  4. Enable the gateway with dynamic routing on each VNet. This can take 15-20+ minutes for Azure to do for you. Plan other work or a break for this step.
  5. Record the address space and gateway IP address of both VNets
  6. Create a local network for each VNet – use the Gateway IP Address and Address Space of the VNet for the details of its local network
  7. Modify the site-to-site VPN configuration of each VNet to dump the temporary local network and use the local network of the other VNet – you’re telling the VNet the details of the other VNet for connection and routing
  8. Use Azure PowerShell cmdlets to run Set-AzureVNetGatewayKey. This will be used to configure a common VPN shared key for both VNets.
  9. Wait … the VPN connection will start automatically … there might be a failure before or just after you st the shared key. Be patient, and one VNet might show a connected status before the other. Be patient!

And that’s it. There is a FAQ on this topic. I’ll be publishing some deeper articles on the subject on in the next few weeks.

My AidanFinn.Com Blog Has Moved To Microsoft Azure

Tonight I completed the migration of this WordPress blog to Windows Azure.



I was having performance and health issues with the VM that I was renting from a local hosting company. The admin portal was proving to be a nightmare. I had upgrade the VM but the VM wasn’t upgraded. The hard disk was filling frequently and killing MySQL, and therefore killing the WordPress blog.

Why was I on a VM? Because I needed more processor & bandwidth capacity.

A failure last week led me to look at my options. I’ve grown comfortable with Microsoft Azure so this was the place that I decided to move to. My free €75 credit per month thanks to my MSDN account doesn’t hurt either!

I looked at the website hosting options but they provide too little disk space. The VMs, even the smaller ones, give you loads of disk space. I decided to fire up a cloud service, blob, virtual network and a small VM instance just for my new web server VM. I installed IIS, added the sites, installed PHP, WordPress, MySQL, and a few other bits and bobs and started the laborious process of migrating from the old VM.

I could have cheated but I decided to do a fresh install. It was more time consuming, especially when I had to split the WordPress export file into 40 smaller export files (the import of 2MB files was timing out). I added and configured all the plugins. And then the final steps:

  • After some tests I configured the website to bind to and
  • I changed the DNS A records for those two URLs to switch to the public IP of the Azure cloud service.

My next steps will be:

  • Configure MySQL automated export
  • Deploy Windows Azure Online Backup to backup the IIS Inetpub folder and the MySQL export

And maybe I’ll configure the endpoint monitoring option in the Azure portal Smile

Set A Static IP Address For An Azure VM

Windows Azure (errr Microsoft Azure) has a weird system for assigning IP addresses to VMs in virtual networks. Like VMM, it uses a pool of IP addresses. And that’s where the similarities end. Azure’s method appears to be more like DHCP.

For example:

  • When you log into the guest OS, the VM is configured to use DHCP
  • The address is not reserved like with DHCP. It is possible that a VM could be offline, come back, and get a new IP address.

The latter bit is bad, especially for services such as Active Directory and DNS where a predictable IP address is required.

Note: The first step in configuring a valid network configuration is to set the DNS servers and subnet masks for your virtual network in the Azure portal.

There is no nice GUI method for reserving an IP address. There is a PowerShell method, which gives you a clue as to how this stuff works under the hood.

The first step is to get your VM:

$VM=Get-AzureVM -ServiceName “Demo-MWH-A” -Name “Azure-DC1”

As you can see above, I am configuring a static IP address for a domain controller. Next, I set the static IP. Note that we are configuring a static virtual network IP for the VM.

Set-AzureStaticVNetIP -VM $VM -IPAddress “” | Update-AzureVM

Also note, that in my tests, most of the time that I run Update-AzureVM, the VM is restarted. It doesn’t happen all of the time with these two cmdlets, but it happens most of the time.

Armed with these two cmdlets, you could set up a CSV file with Service/VM names and IP addresses, and run a loop to configure lots of VMs at once.


To be clear, the above steps do not configure a static IP inside the guest OS – you should not do that. The above steps simply configure the virtual network to assign the same IP to your VM’s vNIC every time the VM starts up. You are manipulating the system to get the results you need.

Technorati Tags: ,,