rakhesh.com

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. 

Spent a bit of time today and and yesterday with Azure. It’s all new stuff to me so here are some notes to my future self. 

• You can not move VMs between VNets (Virtual Nets) or Cloud Services. Only option is to delete the VM – keeping the disk – and recreate the VM. That feels so weird to me! Deleting and recreating VMs via the GUI is a PITA. Thankfully PowerShell makes it easier. 
  
  # get the VM details PS> Get-AzureVM 'vmname' # note the ServiceName, we need that below # also, be sure to specify the full path below; relative paths silently don't work PS> Export-AzureVM -ServiceName 'svcname' -Name 'vmname' Path '\full\path\to\somefile.xml' # remove the VM (this does not remove the VHD files) PS> Remove-AzureVM -ServiceName 'svcname' -Name 'vmname' # now modify the XML file with your changes PS> notepad '\full\path\to\somefile.xml' # import the VM and create it afresh PS> Import-AzureVM '\full\path\to\somefile.xml' | New-AzureVM -ServiceName "vmname" -VNetName "vmnet"

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

  # get the VM details PS> Get-AzureVM 'vmname'   # note the ServiceName, we need that below # also, be sure to specify the full path below; relative paths silently don't work PS> Export-AzureVM -ServiceName 'svcname' -Name 'vmname' Path '\full\path\to\somefile.xml'   # remove the VM (this does not remove the VHD files) PS> Remove-AzureVM -ServiceName 'svcname' -Name 'vmname'   # now modify the XML file with your changes PS> notepad '\full\path\to\somefile.xml'   # import the VM and create it afresh PS> Import-AzureVM '\full\path\to\somefile.xml' | New-AzureVM -ServiceName "vmname" -VNetName "vmnet"

• To rename a virtual net I’ll have to remove all the VMs assigned to it (as above), then export the VNet config, change it with the new name, import it, and then import the VMs as above. Yeah, not a simple rename as you’d expect …
  
  # get the current VNet config PS> Get-AzureVNetConfig -ExportToFile \full\path\to\network.xml # make changes PS> notepad \full\path\to\network.xml # remember this file contains your WHOLE configuration; by renaming the entry there to the new one you are actually telling Azure to create a new VNet with that entry and remove the old one (coz it doesn't exist in the file any more) # set it back PS> Set-AzureVNetConfig -ConfigurationPath \full\path\to\network.xml

  1 2 3 4 5 6 7 8 9 10

  # get the current VNet config PS> Get-AzureVNetConfig -ExportToFile \full\path\to\network.xml   # make changes PS> notepad \full\path\to\network.xml   # remember this file contains your WHOLE configuration; by renaming the entry there to the new one you are actually telling Azure to create a new VNet with that entry and remove the old one (coz it doesn't exist in the file any more)   # set it back PS> Set-AzureVNetConfig -ConfigurationPath \full\path\to\network.xml

• Remember, the virtual networks configuration file states the entire configuration of your Virtual Networks. There’s no concept of add/ remove. What you import gets set as the new one. 
• The first three IPs in a subnet are reserved. Also see this post. 
• You cannot assign static IPs to VMs as you’d normally expect.
  • Every VM is assigned an IP automatically from the subnet you define in the virtual network. Sure you’d think you can go into the OS and manually set a static IP – but nope, do that and your VM is unaccessible because then the Azure fabric does not know the VM has this new IP.
  • Worse, say you have two VMs with addresses xxx.5 and xxx.6; you shut down the first VM and bring up a third VM, this new VM will get the address of the VM you just shut down (xxx.5) because when that VM shutdown its address became free! See this post for an elaboration on this behavior. 
  • Starting from Feb 2014 (I think) you can now set a static IP on your VM and tell Azure about it. Basically, you tell Azure you want a particular IP on your VM and Azure will assign it that during boot up. Later you can go and set it as a static IP in the OS too if certain apps in the OS fuss about it getting a DHCP address (even though it’s actually a reserved DHCP address). Since Azure knows the static IP, things will work when you set the IP statically in the OS. 
  • The ability to set a static IP is not available via the GUI. Only Azure PowerShell 0.7.3.1 and above (and maybe the other CLI tools, I don’t know). There are cmdlets such as Get-AzureStaticVNetIP, Remove-AzureStaticVNetIP, and Set-AzureStaticVNetIP. The first gets the current static IP config, the second removes any such config, and the third sets a static IP. 
    • There’s also a cmdlet Test-AzureStaticVNetIP that lets you test whether a specified static IP is free for use in the specified VNet. If the IP is not free the cmdlet also returns a list of free IPs.
  • You can’t set a static IP on a running VM. You can only do it when the VM is being created – so either when creating a VM, or an existing VM but it will involve recreating the VM by restarting it. 
    • For an existing VM:
      
      PS> Get-AzureVM -Name 'vmname' -ServiceName 'servicename' | Set-AzureStaticVNetIP -IPAddress 'xxx.xxx.xxx.xxx' | Update-AzureVM

      1	PS> Get-AzureVM -Name 'vmname' -ServiceName 'servicename' | Set-AzureStaticVNetIP -IPAddress 'xxx.xxx.xxx.xxx' | Update-AzureVM

    • Maybe when importing from a config file:
      
      PS> Import-AzureVM '\full\path\to\somefile.xml' | Set-AzureStaticVNetIP -IPAddress "xxx.xxx.xxx.xxx" | New-AzureVM -ServiceName "vmname" -VNetName "vmnet"

      1	PS> Import-AzureVM '\full\path\to\somefile.xml' | Set-AzureStaticVNetIP -IPAddress "xxx.xxx.xxx.xxx" | New-AzureVM -ServiceName "vmname" -VNetName "vmnet"

    • Or just modify the config file beforehand and then import as usual. Here’s where the static IP can be specified in a config file:
      
      <SubnetNames> <string>RAXNET1-23</string> </SubnetNames> <StaticVirtualNetworkIPAddress>xxx.xxx.xxx.xxx</StaticVirtualNetworkIPAddress> <PublicIPs /> <NetworkInterfaces />

      1 2 3 4 5 6

      <SubnetNames> <string>RAXNET1-23</string> </SubnetNames> <StaticVirtualNetworkIPAddress>xxx.xxx.xxx.xxx</StaticVirtualNetworkIPAddress> <PublicIPs /> <NetworkInterfaces />

      Import as usual:

      PS> Import-AzureVM "vmname" | New-AzureVM -ServiceName "vmname"

      1	PS> Import-AzureVM "vmname" | New-AzureVM -ServiceName "vmname"

    • See also MSDN article. 
  • Maybe it’s because I changed my VM IP while it’s running (the first option above), even though the IP address changed it didn’t update on the BGInfo background. So I looked into it. BGInfo runs from C:\Packages\Plugins\Microsoft.Compute.BGInfo\1.1. The IP address is got via a registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Azure\BGInfo\InternalIp which seems to be set by C:\Packages\Plugins\Microsoft.Compute.BGInfo\1.1\BGInfoLauncher.exe (I didn’t investigate further).
• When creating a new VM you must specify the Cloud Service name. Usually it’s the VM name (that’s the default anyways) but it’s possible to have a different name when you have multiple VMs in the same Cloud Service. This blog post has a good explanation of Cloud Services, as does this.
• There’s no console access! Yikes.

While importing VMs above I got the following error from the New-AzureVM cmdlet. 

• This usually indicates your Storage Account and Cloud Service are in different locations/ affinity groups. So double check that this is not the case. 
• Once you are sure of the above, specify a Cloud Service – but no affinity group – so the cmdlet knows which one to use. Else specify a Cloud Service that does not exist so Azure can create a new one. See this blog post for more info.
• In my case it turned out to be a case of Azure PowerShell not knowing which storage account to use.  Notice the output below:
  
  PS> Get-AzureSubscription <snip> IsDefault : True IsCurrent : True CurrentStorageAccountName :

  1 2 3 4 5 6

  PS> Get-AzureSubscription   <snip> IsDefault                 : True IsCurrent                 : True CurrentStorageAccountName :

  There’s no Storage Account associated with my subscription. So all I needed to do was associate one:

  # get a list of available Storage Accounts PS> Get-AzureStorageAccount # associate one with my subscription PS> Set-AzureSubscription -SubscriptionName 'SubName' -CurrentStorageAccountName 'fromabove'

  1 2 3 4 5

  # get a list of available Storage Accounts PS> Get-AzureStorageAccount   # associate one with my subscription PS> Set-AzureSubscription -SubscriptionName 'SubName' -CurrentStorageAccountName 'fromabove'

That’s all for now!