Azure VM Deployments with DSC and Chocolatey

I kinda love deploying servers. Really I do. It’s one of the consistent parts of my job as Sysadmin over the years and generally it has resulted in great amounts of satisfaction. As a technical evangelist, I still get to deploy them all the time in Azure for various tests and a projects.  Of course, one of the duller parts of the process is software installation.  No one really enjoys watching progress bars advance, when really you want to get to the more useful “configuration” part of whatever you are planning.

Not that long ago, Sysadmins utilized a not quite magical process of imaging machines to speed this up.  The process still required a lot of waiting.  If one was doing desktop deployments, the process was only made slightly more bearable by looking at the family photos and other trinkets left on people’s desks. Depending on the year one might have been working, this imaging process was also known by the brand name of a popular software – “ghosting.” If you look up the definition of imaging or ghosting in the dictionary, you’d find that it basically meant spending hours installing and capturing the perfect combination of software only to find one or more packages out of date the next time the image is used.

At any rate, fast forward to now and for the most part, we still have to install software on our servers to make them useful. And without a doubt, there will always be another software update. But at least we have a few ways of attempting to make the software installation part of the process a little less tedious.

I’ve been working on a project where I’ve been tackling that problem with a combination of tools for deployment of a “mostly ready to go” server in Azure. The goal was to provide a single server to improve the deployment process for small gaming shops – in particular, allow for the building of a game to be triggered from a commit on GitHub. Once built, Jenkins can be configured to copy the build artifacts to a storage location for access.  For our project, we worked with the following software requirements to support a Windows game, but there is nothing stopping you from taking this project and customizing it to your own needs.

  • Windows Server with Visual Studio
  • Jenkins
  • Unity
  • Git

I’m a big fan of ARM Template deployments into Azure, since they can be easily kicked off using the Azure CLI or PowerShell. So I created a basic template that would deploy a simple network with the default Jenkins port open, a storage account and VM. The VM would use an Azure supplied image that already include the current version of Visual Studio Community. (Gotcha: Before deploying the ARM template, confirm that the Azure image specified in the template is still available. As new versions of Visual Studio are released, the image names can change.)

The template also takes advantage of the DSC extension to call a DSC configuration file to install the additional software and make some basic OS configuration changes. The DSC extension call the package from our GitHub repo, so if you plan to customize this deployment for yourself, you may want to clone our repo as a starting point.

You can find our working repo here and the documentation is a work in progress at the moment.   The key files for this deployment are:

  • StartHere.ps1
  • buildserverdeploy.json

Use the StartHere.ps1 PowerShell file to connect to your Azure account, set your subscription details, create a destination resource group and deploy the template.  If you are more an Azure CLI type of person, there are equivalent commands for that as well.

Once you deploy the buildserverdeploy.json template, the is automatically called to do the additional software installations.  Because the additional software packages come from a variety of vendors, the DSC configuration first installs Chocolatey and then installs the community maintained versions of Jenkins, Unity and Git. (Creating the DSC configuration package with the BuildServerDSCconfig.ps1 is another topic, stay tuned.)

Once the deployment is complete, all that remains is for the final configuration to be set up to meet the needs of the developers.  This includes connecting to the proper GitHub repo, providing the necessary Unity credentials and licensing and creating the deployment steps in Jenkins.

Congrats!  You’ve now created an automated CI/CD server to improve your development process.

DevCamps for Azure and O365 for public sector companies

Do you work in the health, government, public safety or education industries and are looking to learn more about Azure, Office365 and DevOps?  This free training from Microsoft is 300-level and geared toward partners who want to learn more about coding on these Microsoft platforms using .NET, Node.js, and Java.

This course are crafted as a combination of lecture and lab that put you on track to explore new Microsoft integrations, Modern Cloud Apps, Infrastructure as Code, Azure Active Directory, and much more!

You can register here for the one upcoming in Silicon Valley on January 24 and 25th.


Hack Day at the SF Reactor – 1/10/17

Start the New Year off right by learning how you can improve your company’s workflow. Sit down with Microsoft technical experts who will help you automate your most repetitive tasks through open source technology. Spend the afternoon with us coding side by side where we will show you how you could automate your build process, create a chat bot to answer frequently asked questions, or scale your existing app through Azure.

As part of the hackfest you will hear from the Microsoft Technical Evangelism team who will show you how, you could:

    • Build great bots that converse where your users are
    • Build an automated, continuous integration Jenkins pipeline to help get your applications to market faster
    • Build Docker containers and scale through Azure app services

1:00 PM-5:00 PM, Microsoft Reactor, San Francisco, CA 94107 — A detailed agenda will be shared prior to the event.

You *must* RSVP by Friday, January 6th to

We’ll help implement your existing project or create a new one. Our goal is to help you with your project so you feel empowered to keep working to refine your scenarios at work.

REMINDER: Bring your laptop and create a production ready prototype or proof of concept by the end of the day. An Azure subscription is required, we can help you get started with a free trial if needed.



PacITPros November Meeting Resources

This month at the PacITPros meeting, I covered several of the ways you can create virtual machines in Azure and get started doing Infrastructure as Code. For a quick summary of the various ways to do this check out this bit of Azure documentation.

If you need to get started with Azure and don’t have a subscription yet, break out your Microsoft Account (aka LiveID, Hotmail account, etc) and pick one of these options:

Since I dove deeper on doing these deployments with ARM templates and JSON, here are some of the resources you might want to revisit (or check out if you missed the meeting).

Here is an example of the PowerShell command for getting an updated list of images for Windows Server or Ubuntu Server in a particular region:

Get-AzureRmVMImageSku -Location "west us" -PublisherName Microsoftwindowsserver -Offer WindowsServer 
Get-AzureRmVMImageSku -Location "West US" -PublisherName Canonical -Offer UbuntuServer

Finally, here is my “cheat sheet” of PowerShell commands to connect to your Azure account and deploy a template.


$VSSubID = "7ebd5b2e-7d4b-49xe-bab6-4d593ed76x41" # copy the sub-id from the previous command
Set-AzureRmContext -SubscriptionID $VSSubID

# get the "raw" URL from GitHub for the template you want to deploy and break it up as follows:

$assetLocation = "" 
$templateFileURI  = $assetLocation + "nanoslabdeploy.json"  # deployment template
$parameterFileURI = $assetLocation + "SVCC.parameters.json" # parameters file

$RGName = "PacITPros"  # set your resource group name
New-AzureRmResourceGroup -Name $RGName -Location "West US"  # create your resource group

# deploy the template!
New-AzureRmResourceGroupDeployment -ResourceGroupName $RGName -TemplateParameterUri $parameterFileURI -TemplateUri $templateFileURI -verbose

Deconstructing JSON: Tale of Two VNETs (Linked templates with VNET peering!)

The last month or so has been packed with announcements and training! I’ve been to Ignite in Atlanta, as well as some internal training and some fun community events.  Finally, I’ve had some time to sit down and work on trying out a few things.  If you missed the announcement around Ignite time, Azure VNET Peering is now generally available.   With peering, you can now link virtual networks together without having to set up multiple VNET gateways.

This peering feature can be set up using the Azure Portal, but what fun is that, right?  Let’s do it with some ARM templates instead.  My goal was to create two VNETs with different address spaces (you can’t peer networks with an overlapping address space) then peer them together.  I could do this with one big template, but I wanted to also take some time to try out linking templates together – where one parent template calls others.  I also wanted to take advantage of parameters files to create the different VNETs.

For this example, I ended up with five JSON files:

  • azuredeploy.json – The deployment template for one VNET
  • vnet1.parameters.json – The parameters file for VNET1
  • vnet2.parameters.json – The parameters file for VNET2
  • peeringdeploy.json – Template to peer together the networks once created
  • parentdeploy.json – The template used to manage the complete deployment

Within the parentdeploy.json file we only need to define the schema and resources sections and the only resource I’m calling is the “Microsoft.Resources/deployments” type.  Within that, you’ll need to define a name, mode, template link (located in a repo or blob storage) and an optional parameters link.  For this deployment, I’m calling the deployment resource three times – once for each vnet, plus a final time to peer them. In the snippet below, you can see that I called the azuredeploy.json file and the vnet1.parameters.json file.

     "apiVersion": "2015-01-01", 
     "type": "Microsoft.Resources/deployments", 
     "name": "linkedTemplateA", 
     "properties": { 
       "mode": "Incremental", 
       "templateLink": {
       "parametersLink": { 

The second resource uses the same template link and uses the vnet2.parameters.json file.  Finally, the last one will only call the peeringdeploy.json template with no parameters file needed. Each deployment resource needs it’s own unique name and you can’t reference anything directly that isn’t included in the template itself.   There are also ways to share state between linked templates to be even more “elegant” in your template creation.

Within the peeringdeploy.json template we also only need to define resources which link the newly created VNETs together. In the snippet below, you can see BigNetA (created with vnet1 parameters) being connected to BigNetB (created with vnet2 parameters).

    "apiVersion": "2016-06-01",
    "type": "Microsoft.Network/virtualNetworks/virtualNetworkPeerings",
    "name": "BigNetA/LinkToBigNetB",
    "location": "[resourceGroup().location]",
    "properties": {
    "allowVirtualNetworkAccess": true,
    "allowForwardedTraffic": false,
    "allowGatewayTransit": false,
    "useRemoteGateways": false,
        "remoteVirtualNetwork": {
        "id": "[resourceId('Microsoft.Network/virtualNetworks', 'BigNetB')]"       

Finally, as with all my previous templates, I can deploy the whole thing with just one line of PowerShell!

 New-AzureRmResourceGroupDeployment -ResourceGroupName $RGName -TemplateUri $templateFileURI -verbose


Nano Server Management

Where has the time gone? I looked up from my computer and the summer is nearly over! One of the things I’ve been tinkering with as of late with some of my “infrastructure as code” projects is Nano Server. Not only is Nano Server gearing up to be a great Hyper-V host and a cool place to start dabbling in containers, it’s also great server to use when testing deployment scripts because it’s small and deploys quickly. When all I want to do is spin up and tear down to test my templates, I love being able to use a Windows server with a smaller footprint.

With Nano server being “headless”, it only supports remote administration, so this has also lead me to check out all the newish ways we can manage servers remotely. You’ll need to take a few steps so you can remotely manage a Nano server deployed in Azure.

  1. Open NSG on Azure for the Nano Server – If you created a VM from the Azure Portal and accept all the defaults (which include an NSG), that NSG doesn’t open the ports for WinRM by default.  It only opens RDP.  The OS firewall is open to accept WinRM and PowerShell, but the NSG blocks it.  You need to edit the NSG to include TCP ports 5985 (http) and/or 5986 (https) for remote management.
  2.  Add Nano External IP Address as a Trusted Host – Since you’ll be connecting to your VM remotely over the public internet, you’ll need to add that IP address to your trusted host list on your workstation. You can do that via PowerShell or via CMD (just pick one).
    1. winrm set winrm/config/client @{ TrustedHosts="" }
    2. Set-Item WSMan:\localhost\Client\TrustedHosts ""

At this point you should be able to remotely connect to your Nano Server using PowerShell. On your workstation, run (replacing the IP address and username as appropriate):

$ip = ""
 $user = "$ip\sysadmin"
 Enter-PSSession -ComputerName $ip -Credential $user

You’ll be prompted for your password and then you’ll be given a remote PowerShell prompt to your Nano VM. But what if you want MORE than just a PowerShell prompt? What if you want access to event logs? Or some basic performance information? Or dare say, use “Computer Manager”??

You can use Server Manager tools from workstation or you can use the Azure Server Management Tools (and Gateway).

While your remotely connect to the server you want to manage, you may need to make a few other small changes, particularly if your servers aren’t domain joined or are on a different subnet than the machine you are connecting from. I recommend checking out this troubleshooting guide –

If you specify in Microsoft Azure the local administrator account to connect to the managed server, you have to configure this registry key on the managed server:
REG ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1

If you are connecting from a different subnet:
NETSH advfirewall firewall add rule name=”WinRM5985″ protocol=TCP dir=in localport=5985 action=allow

If you want to use Computer Manager and other common Server Manager tools:
Set-NetFirewallRule -DisplayGroup ‘Remote Event Log Management’ -Enabled True -PassThru |
select DisplayName, Enabled

Happy Remoting!