Powershell DSC

In an automated deployment world, window clicking to install Windows features and roles is first of all boring, much too slow, highly error-prone and nineteen nineties.

My team was searching for a solution that helps us to describe and create a specific state of configuration of the operating system of a virtual machine, and that automatically and unattended.

Powershell Desired State Configuration makes it possible to define the wanted state in an easy to use abstract language. Powershell DSC “compiles” the configuration script at runtime on the target machine and applies the necessary actions. Actually, it’s not a compilation, more a transformation process from a domain specific meta language into real Powershell. Each step in the configuration script can be executed atomically, but dependencies are honored and can be configured. The Powershell DSC runtime deals with reboots and continues to process the script after a reboot.

Here’s an example, that configures a desired state by installing different features:

1 configuration InstallMir 2 { 3 node ("localhost") 4 { 5 WindowsFeature IIS 6 { 7 Ensure = "Present" 8 Name = "Web-Server" 9 } 10 #Install NET-Framework-45-Core 11 WindowsFeature NET45 12 { 13 Ensure = “Present” 14 Name = “NET-Framework-45-Core” 15 } 16 17 #Install ASP.NET 4.5 18 WindowsFeature ASP 19 { 20 Ensure = “Present” 21 Name = “Web-Asp-Net45” 22 } 23 24 #Install MSMQ 25 WindowsFeature MessageQueueFeature 26 { 27 Ensure = “Present” 28 Name = “MSMQ” 29 } 30 31 } 32 }


Powershell DSC for developers

Powershell Desired State Configuration also allows a development team to describe easily the configuration the application need on the host system. The domain specific language Powershell DSC is providing makes it easy for developers, who are often not Powershell experts to describe the wanted state in a precise manner.

Powershell DSC for DevOps / QA

From a DevOps QA point of view starting each new deploy from scratch with a reliable and deterministic state is heaven. Poweshell DSC closed the gap between a new Windows image and the installation of the software. All the prerequisites that need to be preinstalled can be described and installed using Powershell DSC.

It also helps in communication with other IT operations teams, because the required state of configuration can be communicated precisely. In fact, most is said by sending the Powershell DSC script.

Powershell DSC and Microsoft Azure

Microsoft Azure provides a VM extension that can be installed when creating the virtual machine. Through that extension Powershell DSC scripts can be executed easily. The Powershell DSC script needs to be uploaded to a Azure storage account first to make the script available for the target machine.

Here a script that uploads a Powershell DSC script into the Azure storage. The $ConfigurationPath variable contains the full path to the PowerShellDSC *.ps1 script on the local machine.

1 $StorageContext = New-AzureStorageContext -StorageAccountName $StorageAccount -StorageAccountKey $StorageKey 2 Publish-AzureVMDscConfiguration -ConfigurationPath $ConfigurationPath -ContainerName $StorageContainer -StorageContext $StorageContext -Force 3

The next script executes the script on the target machine. First it creates a storage credentials object, then it loads the reference to the target VM and calls Set-AzureVMDscExtension to run the earlier uploaded DSC script. The extension is going to be installed if not already.

1 $StorageContext = New-AzureStorageContext -StorageAccountName $StorageAccount -StorageAccountKey $StorageKey 2 $vm = Get-AzureVM -ServiceName $mySvc -Name $vmName 3 4 Set-AzureVMDscExtension -VM $vm -ConfigurationArchive $ConfigZipFilename -ConfigurationName $ConfigName -Verbose -StorageContext $StorageContext -ContainerName $StorageContainer -Force | Update-AzureVM 5

Powershell DSC on Windows

Powershell DSC is onboard Windows 2012 R2 and Windows 8.1. Remotely executed on Windows 2012 R2 in Azure makes fun the most.

Using Microsoft Azure File Service

Almost a year ago Microsoft introduced a file share technology called the Microsoft Azure File Service. Although it’s still in preview and you need to apply to it from within the Azure portal it offers the most convenient (and reliable) way to share directories and files between virtual machines in Azure. The Azure File Service adds powerful flexibility to the IaaS platform, especially when your application is highly scalable and needs to process and share a lot of files in a reliable manner.


To setup a share you need to activate the Azure File Service. The best way to do that is to use the new Azure portal and sign up for the Azure File Service preview program. This can be done in the Azure Storage area. I received the sign up approval a few minutes later and the File Service was unlocked. That enabled me to select a file endpoint when I create a new storage.

Once the new file storage account is configured it’s available for VMs, worker- and web roles, as long as there located in the same region where the storage account is hosted.

To access Azure Files from a virtual machine run the following command in a command prompt on the box:

net use z: \\<account name>.file.core.windows.net\<share name> /u:<account name> <account key>

That’s it. Now the user can access files and folders on the share drive. Account-, name and key and share name is available in the portal.

Allowing IIS to access Azure Files

I needed to grant the IIS application pool user as well as the IUSR access to the share. That was not that easy, because you can’t configure the ACL directly for the share.

I could create a Windows user and gave it the storage account name and password, though. I assigned those credentials to the app pool identity and created a virtual directory in IIS, to which I used the same Windows user again to connect. I couldn’t access files using the drive letter path, but it worked pretty well using the UNC path \\<account name>.file.core.windows.net\<share name> instead.