First, let’s look at an overview of what we’re going to build and how PowerShell DSC works. PowerShell Desired State Configuration was first introduced in Windows Server 2012 R2. It was widely used for on-premises infrastructure management well before it was brought to Azure. PowerShell DSC also supports for several Linux operating systems which runs on top of the Open Management Infrastructure, or OMI.

You see several items, which I will define. First, a “DSC_IIS.ps1” file represents the actual DSC Configuration which is a PowerShell script that serves as a wrapper around the cross-platform industry standard MOF or Managed Object Format file format as we mentioned earlier. In fact, you could create configurations directly in the MOF format, but for our purposes, we’re going to use the PowerShell syntax for ease of use with our Azure Resources. We can optionally have Configuration Data which is just a .PSD1 file containing environmental data for the configuration. Second we have a PowerShell script “DeployDSC_IIS.ps1” we use to actually push our configuration to Azure, which can also be done through the Portal as well. Also, our deploy script will push the PowerShell DSC extension to our Target VM. We have the storage account where our PowerShell configuration will live in Azure once we push it from our client machine where we developed the configuration. I should note that since this is a simple configuration file, we can easily imagine having source control around these configuration changes such that we always know who made what change when or simply integrate with your current Change Management processes. Since the PowerShell DSC extension is installed on the VM, it knows to “pull” the configuration from the storage account. Finally, we have a “Node” which is simply the Azure VM which is the target of the DSC Configuration.

As you can see in the diagram, we want to ensure our Target VM or Node is an IIS Web-Server if not already in order to meet our Desired state.