I’ve recently been tinkering with Azure Virtual Machines as I am doing some prep-work for some great sessions I have planned for community events that require a number of VM’s not practical to spin-up on a laptop.

Some of you know that I have access to Private Cloud resources and so you may be wondering why I’m looking at Azure?

Simple answer is that I feel that my knowledge is lagging behind reality and so I want to use this “evaluation” as a learning experience. Simples.

Anyway, this post is not about the why, it’s about the “doh!”…

I have a bunch of scripts that I use in various ways to prep environments ready for building out platforms in controlled ways. All sorts of stuff is manipulated; IE settings, UAC, PoSh stuff and firewall settings.

You can probably see what’s coming.

One of the scripts that I often run sets up Windows Firewall. Opening a few ports, closing a few ports and generally tee’ing things up for running a workload in a secure way, the proper way to use Windows Firewall, right? Yep, the correct way to use Windows Firewall, but also the correct way to close up the RDP port and disconnect yourself sweetly from the Azure VM.


Being comfortable with PoSh and PoSh remoting, I was not really fretting. PoSh remoting would let me slide in, and monkey about to open up the port again (perhaps another post) unless, of course, PoSh remoting was not enabled.

Which it wasn’t.


Now, I’m screwed. No way to get back to the VM. Back to the Azure portal to delete. Bummer.

Good news was that the VM was new and being used for testing so deleting would not give me any real drama, but I thought about what the impact would have been if the VM was established and being used, therefore expensive (in cost, resource and time) to re-build/re-create.

So what are the options?

I thought about how I would solve this given on-prem scenarios:

  • physical machine = not a problem, log on locally
  • virtual machine = not a problem, log on via virtual host console

Neither of these options were available to me so some left-field thinking was needed which came as a result of me playing with storage containers and noticing that I could download the VHD associated to the VM. If I could download it then surely I can mount it and start it on a Hyper-V 2012 host, right?

Yep, right!

It took a while to pull down the download via the portal:

> storage > <storage account> (choose your acct.) > containers (in the tab) > VHDs > <vhd name>

Note to self – I should have used Save-AzureVHD cmdlet which is optimised to be “smart” and not bring down all of the “air” that is contained within the 127GB image which only held 15GB or so of actual data – but this is a learning experience after all.

Once I had the VHD locally I was able to copy it to a Hyper-V host, attach it to a fresh VM and boot the OS like any normal VHD attach. Once booted I was able to switch off the firewall (for all profiles) shutdown the VM and then prepare for the moment of truth.

Using CSUpload (with the Add-Disk option) I was able to upload the VHD back into my storage account and then spin it up into a VM thus making it re-accessable and usable.

Long winded, but nice. Would you actually do this in the real world? Probably not, but it’s nice to know it’s possible.

If I get a chance, I may well upload a step-by-step of this but as I did it, I didn’t scree-shot. Rookie.

Lessons learned:

  • enable PoSh remoting before changing firewall settings/rules in my scripts
  • change my least priv/high security scripts to take into account Azure
  • measure twice, cut once
  • always use PowerShell and not the UI (!)

more to follow…