Organise RDP Connections with Remote Desktop Connection Manager
Years ago when I first started working with Hyper-V I soon realised there must be a better way of remoting to servers than using the client built in to Windows. There was, in the form of a nifty utility called Remote Desktop Connection Manager or RDCMan. There are other tools but this one is simple and does the job very nicely. For many years it was stuck on version 2.2 published in 2010, probably because it originated as a tool used by Microsoft engineering and technical staff and wasn't the focus of any official attention. Fast-forward to 2014 and there is now a new 2.7 version, as before available as a free download from Microsoft. I highly recommend this for organising your RDP connections to your Azure (or any other) Windows VMs. In addition RDPMan is able to save your logon credentials and if you are in an environment where it's safe to do this it's a great time-saver.
There is a trick to getting RDCMan to work with Azure VMs which can cause endless frustration if you don't know it. The DNS name of the cloud service and the port of the Remote Desktop endpoint need to be entered in separate places in the RDCMan profile for your VM. See here for a post that has all the details you need to get started.
Cheers -- Graham
Use Azure Automation to Shut Down VMs Automatically
If you have an MSDN subscription (which gives you Azure credits) you will hopefully only forget to shut down your VMs after you have finished using them once. This happened to me and I was dismayed a few days later to find my Azure credits had been used up and I had to wait until the next billing cycle to carry on using Azure. There are a few ways to keep costs down (use a basic VM, size appropriately and don't install an image with a pre-loaded application such as SQL Server and instead install from an ISO from your MSDN subscription) but the most effective is to deallocate your VMs when you are finished using them.
As a safeguard after the episode where I ran down my credits I created a PowerShell script that I set up as a scheduled task to run daily at 1am on an always-on server that runs in my home datacentre under the stairs. Doable but not ideal, not least because of all the components that are installed by Azure PowerShell just to run one script. However, the recent launch of Azure Automation means this script can now be run from within Azure itself. Getting started with Azure Automation used to be a bit of a pain as there were quite a lot of steps to go through to set up authentication using certificates. The process is much simpler now as Azure Active Directory can be used. If you are just getting going with Azure Automation it's worth watching the Azure Friday Automation 101, 102 and 103 videos. When you are ready to start using Automation this post has the instructions for setting up the authentication. Once that is in place it's a case of navigating to the Automation pane in the Portal and creating an Automation Account. You then create a Runbook using the Quick Create feature and start editing it in draft mode. The following code is an example of how you might go about shutting down your VMs:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
workflow Stop-AzureVMExceptDomainController { $Cred = Get-AutomationPSCredential -Name "Automation" Add-AzureAccount -Credential $Cred Select-AzureSubscription -SubscriptionName "Visual Studio Premium with MSDN" Get-AzureVM | ForEach-Object { if ($_.Name -ne 'ALMDC') { if ($_.InstanceStatus -ne 'StoppedDeallocated') { Write-Output "Shutting down : $_.Name" Stop-AzureVM -ServiceName $_.ServiceName -Name $_.Name -Force } } } } |
If you were to use the example code above you would need to have created a Runbook called Stop-AzureVMExceptDomainController and be using an Azure Active Directory user called Automation. (The code also ensures that a VM called ALMDC isn't shut down.) With the Runbook in place you can link it to a Schedule. You'll need to publish it first, although the typical workflow is to run in draft to test it until you are satisfied that it's working correctly. When you do finally publish you click the Schedule tab where you can link to a new or an existing schedule -- I have mine set to 1am.
Once your Runbook is in place you can of course run it manually as a convenient way to shut your VMs down when you have finished with them. No longer do you have to wait for PowerShell running locally to finish before you can turn your PC off. And if you do forget to shut your VMs off you can relax knowing that your schedule will kick in and do the job for you.
Cheers -- Graham
Continuous Delivery with TFS: Creating a Domain Controller
In this second post in my series about creating a continuous delivery pipeline using TFS I describe how to create a domain controller in Azure. It's not mandatory -- it's perfectly possible to use shadow accounts and that's how I started -- however the ability to use domain accounts makes configuring all of the moving parts much simpler. It also turns out that creating a domain controller isn't that much of a chore.
Create the VM
The first step is to create a Windows Server VM using the foundations configured in the first post in the series. I use a naming convention for groups of VMs so my domain controller is ALMDC, and since this VM won't be doing a lot of work size A0 is fine. If you have other VMs already created they should be deallocated so you can specify the first none-reserved IP address in the allocated range as static. For my Virtual Network in the 10.0.0.0/25 address space this will be 10.0.0.4 -- previous slots are reserved. If you create the VM using PowerShell you can specify which IP should be static when the VM is created. If you use the Portal you can do that later which is the technique I'll describe here. See this article for more details.
Configure the VM for DNS
Whilst the VM is being provisioned head over to your virtual network and select the Configure panel and add your new server and its IP address as a DNS server, as it will be also performing this role. You should end up with something like this:
Once the DC has been provisioned you use your version of the following PowerShell command to specify a static internal IP for a previously created VM:
|
|
Get-AzureVM -ServiceName AlmCloudService -Name ALMDC | Set-AzureStaticVNetIP -IPAddress 10.0.0.4 | Update-AzureVM |
This command needs to be run from an admin workstation that has been configured to work with Azure PowerShell and your Azure subscription. You need to install Azure PowerShell (easiest way is via the Microsoft Web Platform Installer) and then work through configuring it to work with your Azure subscription, details here. If all that's too much right now you can just make sure that your DC is the first VM in the cloud service to start so it uses the IP specified as DNS.
Install and Configure Active Directory
One you are logged in to the domain controller install the Active Directory Domain Services role via Server Manager > Add roles and features. After rebooting you will be prompted to install Active Directory and to specify a Fully Qualified Domain Name -- I chose ALM.local. Defaults can be chosen for other options. Next, install the DNS Server role. I deleted the Forwarder entries (Server Manager > DNS Manager > Tools and choose Properties from the shortcut menu of the DNS node and select the Forwarders tab) but I'm not sure now if that was absolutely necessary. You can check if everything is working by accessing a well-known website in IE. One point to note is that you shouldn't manually change the NIC settings of an Azure VM as that can lead to all sorts of trouble.
Although I've mentioned previously that you need to shut down your VMs so they show their status as Stopped (Deallocated) in the portal to avoid being charged I actually leave my DC running all the time as it only costs about £4 per month and I like to know that when I start my other VMs I have a fully functioning DC for them to connect to.
Cheers -- Graham
Continuous Delivery with TFS: Laying the Azure Foundations
For anyone interested in creating a continuous delivery pipeline with TFS this is the first article in a series of posts that will explain how I created my demo pipeline. I've used Azure IaaS (ie virtual machines configured with specific roles such as IIS) however if that's not an option for you then it should be easy to translate everything to your way of working -- virtualisation, actual physical servers etc. I won't be going in to very much detail about using Azure so if you are new to Azure see one of my previous posts here for details of how to get started, and make sure you are familiar with its IaaS capabilities, ie how to create and remote desktop to VMs.
Many technologies have both a quick-and-dirty way of doing things and also a more considered way. Azure is no exception and if you don't make any alternative arrangements creating a new virtual machine in Azure will create a new storage account and a new cloud service. Things can quickly get out of hand and you end up with stuff all over the place and the possibility of using credits faster than you intended. To keep things tidy it's best to create some foundations upon which you can create your VMs. Buck Woody has a great post here which explains the steps and is mostly still relevant even though the post dates back to April 2013. I'm not going to repeat the detail of the post here but this is a summary of what you need to set up:
- Affinity Group -- keeps a set of resources together which can help to minimise costs. Choose a region that makes sense for all of the VMs you will create.
- Virtual Network -- allows all of the VMs to talk to each other. At the time of Buck Woody's post it was possible to specify an Affinity Group for a Virtual Network but this has now changed and you can only specify a region. You can read more about this here, but when you create your network choose the same region as the Affinity Group.
- Storage Account and Container -- this is where the VHDs of your VMs are stored. Choose the Affinity Group you created previously. When your Storage Account is running create a Container called vhds.
- Cloud Service -- this is the container in which all of your VMs will live. You can create a new Cloud Service at the same time as creating a new VM but I prefer to create one up front, specifying the previously created Affinity Group.
In the spirit of keeping things neat and tidy when I create a new set of the above resources I like to use a naming convention which consists of a short prefix plus the name of the resource I'm creating, eg AlmAffinityGroup, AlmVirtualNetwork and so on. Bear in mind that some of the names -- in particular the Cloud Service -- need to be globally unique so it's worth navigating to the first page of the Cloud Service wizard (which will validate names you put in) to find something that is likely to work before you start in earnest.
Once all the above are in place it's worth creating a test VM -- it's simple to delete it once you have finished testing. I tend to create my VMs with PowerShell and will post about this in the future, but for the meantime in the Portal you can choose New > Compute > Virtual Machine > From Gallery. Choose Windows Server 2012 R2 Datacenter (or whatever might have superseded this) and move on to the next step of the wizard. I always use the latest version, and choose the basic tier as it's cheaper, and for a test VM choose an A0 size, again to keep costs down. Supply a name for the VM and a username and strong password and then at the next step in the wizard you can supply all the resources you created above.
On the subject of keeping costs down it's worth noting that to ensure you don't get charged when you are not using your VMs you have to actually shut them down from the portal or use the Stop-AzureVM PowerShell cmdlet so that their status is Stopped (Deallocated). Simply powering off from within the VM isn't enough. Automating this is the way forward -- another future post!
Cheers -- Graham
Getting Started with Microsoft Azure
Back in the olden days when I wanted to use my MSDN subscription to learn a new technology such as SQL Server I pressed an old PC in to service to act as the host. Several years on and virtualisation had become commonplace and this allowed me to run several hosts using Hyper-V on an always-on beefier box located in my home datacentre under the stairs. With the arrival of Microsoft Azure all that tin is now a thing of the past and anyone using Azure has an extraordinary wealth of computing power and flexibility at their disposal. (There are other cloud providers of course but I find it’s enough of a job keeping up with the latest offerings from Azure, never mind what Google or Amazon might be churning out.)
For anyone new to Azure, where to start? If you already have an MSDN subscription then the great news is that you already have free monthly credits, and this page has more details. If you don’t have MSDN then other options include taking advantage of the Azure one-month free trial or maybe even paying for Azure yourself. This isn’t as crazy as it sounds since you only pay for what you use and services such as virtual machines can be shut down when they are not being used so you won’t get charged.
So you have your subscription set up, now what about learning Azure? There are numerous free resources you can take advantage of (including lots of videos if that’s your thing) and below I’ve listed what I consider to be the most useful at the time of writing this post. In particular, this video from Scott Guthrie is a great way to get a broad overview of what Azure offers.
Microsoft Azure is evolving so rapidly that once you have learned the basics you need a strategy for keeping abreast of what’s new. For me this is a combination of The Azure Podcast as listed above and a variety of blogs. Scott Guthrie’s blog is particularly noteworthy, but if you are a .NET developer you are hopefully already following it.
Cheers – Graham
