Setting up a test lab with Azure (part 1)

I keep creating and destroying my virtual lab in Azure, I figure it’s time to script it so I can easily copy paste and have a template in hand. Previously I was doing some parts via the Web UI, some parts via PowerShell. 

These are mostly notes to myself, keep that in mind as you go through them …

Also, I am writing these on the small screen of my Notion Ink Cain laptop/ tablet so parts of it are not as elegant as I’d like them to be. My initial plan was to write a script that would setup a lab and some DCs and servers. Now the plan is to write that in a later post (once I get this adapter I’ve ordered to connect the Cain to my regular monitor). What follows are the overall steps and cmdlets, not a concise scripted version. 

Step 1: Create an affinity group

This would be a one time thing (unless you delete the affinity group too when starting afresh or want a new one). I want to create one in SouthEast Asia as that’s closest for me. 

Note: the name cannot contain any spaces. And if you are curious about affinity groups check out this TechNet post. 

Step 2: Set up the network

Let’s start with a configuration file like this. It defines three sites – London, Muscat, Dubai – with separate address spaces. Note that I am using address spaces – this means the three sites will not be able to talk to each other until I set up site-to-site connectivity between them. 

Within each address space I also create two subnets – one for the servers, another for clients. Not strictly needed, I just like to keep them separate. 

Note that all three networks are in the same affinity group. Again, it doesn’t matter, but since this is a test lab I’d like for them to be together. 

Save this XML file someplace and push it to Azure:

That’s it!

Step 3: Create a storage account

Note: the name has to be unique in Azure and must be all small letters. A locally redundant storage account is sufficient for test lab purposes. 

Associate this storage account with my subscription. 

That’s it!

Step 4: Create a VM

This is similar to an earlier post but slightly different. 

Get a list of Server 2012 images:

The last one is what I want. I create a variable to which I add the provisioning info for this new server. For convenience I use the server name as the variable. 

Assign this server to a subnet and set a static IP address (the latter is optional; also, remember the first 3 IP addresses in a subnet are reserved by Azure). 

Next, create a cloud service associated with this VM, and create a new VM associating it with this service and a Virtual Network. 

Note to self: add the -WaitForBoot switch to New-AzureVM so it waits until the VM is ready (or provisioning fails). By default the cmdlet does not wait, and the VM will be in the Provisioning status for a few minutes before it’s ready. 

Step 5: Set up self-signed certificate for PowerShell remoting

I want to remotely connect to this machine – via PowerShell – and set it up as a DC. 

By default PowerShell remoting is enabled on the VM over HTTPS and a self-signed certificate is installed in its certificate store. Since the machine we are connecting to the VM from does not know of this certificate, we must export this from the VM and add to the certificate store of this machine. 

Here’s how you can view the self-signed certificate:

As an aside, it is possible to request a certificate with a specific fingerprint/ thumbprint with the above cmdlet. For that, you need to get the thumbprint of the certificate associated with the VM and specify that thumbprint via the -Thumbprint switch. The following cmdlet pipe is an example of how to get the thumbprint associated with a VM:

The output of the Get-AzureCertificate cmdlet contains the certificate in the Data property. From my Linux days I know this is a Base64 encoded certificate. To import it into our certificate store let’s save this in a file (I chose the file extension cer because that’s the sort of certificate this is):

Then I import it into my Trusted Certificates store:

Finally, to test whether I can remotely connect to the VM via PowerShell, get the port number and try connecting to it:

To summarize this step, here’s all the above cmdlets in one concise block (the last cmdlet is optional, it is for testing):

Update: While writing this post I discovered a cmdlet Get-AzureWinRMUri which can be used to easily the WinRM end point URI. 

Thus I can replace the above cmdlets like this:

Or start a remote session:

Neat!

Step 6: Create a domain and promote this machine to DC

If I had started a remote session to the Azure VM, I can install the AD role onto it and create a domain. 

Alternatively I could put the above into a scriptblock and use the Invoke-Command cmdlet. 

Note that once the VM is promoted to a DC it gets reboot automatically. 

We now have three sites in Azure, and a VM in one of these sites that is also the DC for a newly created domain. There’s more stuff to be done, which I’ll return to in a later post. 

Meanwhile, the other day I came across a  blog post on securing Azure machines. Turns out it is common to probe all open ports of Azure VMs and try connecting to them via RDP and brute-forcing the password. The Azure VM created above does not use the default “administrator” username, but as a precaution I will remote the Remote Desktop endpoint now. When needed, I can add the endpoint later.

To remove the endpoint:

To add the endpoint (port 11111 will be the Remote Desktop port):

Check out that post for more ways of securing Azure VMs. Some day I’ll follow their suggestion of disabling Remote Desktop entirely and using VPN tunnels from my local machine to the Azure network.