An Azure Automation DSC Primer

A common problem that many IT professionals face is maintaining consistent configurations of servers across the enterprise.  Deploying servers and maintaining a consistent configuration can be difficult at best.  Azure Automation DSC is a toolset that addresses this problem.

Azure Automation Desired State Configuration (DSC) allows IT professionals to deploy servers across the enterprise with a consistent configuration.  In addition, Azure Automation DSC allows for the automatic update of all servers to a consistent (or desired) state.  For example, if all servers in a particular location need IIS installed, Azure Automation DSC can ensure that IIS is installed and stays installed on those servers – automatically, and from the cloud.

Built on PowerShell DSC technology, Azure Automation DSC can maintain consistent machine configurations across both physical and virtual machines, whether they are in the cloud or on premises – and it can do so for both Windows and Linux machines.  Rapid configuration changes and consistent control is made possible with Azure Automation DSC.

Azure Automation DSC allows the IT professional to author PowerShell DSC Configurations, import the configurations into Azure, and then generate DSC Node Configurations (which are MOF documents) that are applied to machines that have been configured as DSC Nodes.  Theses configuration items are stored on the Azure Automation Pull Server so all target nodes can be automatically configured.

Key Azure Automation DSC Terms

You should be familiar with a few key terms before working with Azure Automation DSC.  Knowing these key terms and how they are related, will help you better-understand the entire toolset.


Configurations are a concept introduced with PowerShell DSC that allow you to define a desired state of your environment using PowerShell syntax.  Configuring the environment requires the definition of a Windows PowerShell script block using the configuration keyword, followed by an identifier, and then braces ({}) to delimit the block.

Inside the configuration block, node configurations are defined.  These configurations specify the desired configuration for a set of nodes (or computers) in your environment that should be configured the same. In effect, a node configuration represents a “role” for one or more nodes to assume. A node configuration block starts with the “node” keyword. The name of the role being defined follows the node keyword.  Braces are then used to delimit the node configuration block.

Resource blocks are defined within the node configuration block to configure specific DSC resources such as IIS, File Services, etc.  A resource block starts with the name of the resource, followed by the identifier you want to specify for that block.  Braces are used to delimit the block in the same manner they are used to delimit the node configuration block.

Compiling a DSC configuration generates a DSC node configuration, which is also known as a MOF document.  DSC nodes then apply the DSC configuration to maintain a desired state.

As an aside, keep in mind that a configuration can only include ONE configuration block.

Node Configuration

Node configurations are generated when a DSC Configuration is compiled.  As mentioned previously, a node configuration is the same as a “MOF document”.  Node configuration typically represents a “role,” or “feature”, such as webserver, that DSC should check for compliance against.

DSC nodes are notified of node configurations that pertain to them via either DSC push, or pull methods. Azure Automation DSC relies on the DSC pull method.  What this means is that DSC nodes actively request node configurations from the Azure Automation DSC pull server.  A distinct advantage of using the DSC pull method is that the DSC nodes can live behind a firewall with all inbound ports closed.  All that is needed is outbound access to the internet.  There are no firewall issues to deal with.

DSC Node

A DSC node is Windows or Linux machine with a configuration that is managed by DSC. DSC nodes can be on-premises VMs, on-premises physical machines, or machines in a public cloud. Nodes pull down node configurations from the DSC pull server in order maintain compliance with the desired state configuration defined.  DSC nodes also report the status of their configuration and compliance to a reporting server.


DSC resources are the keys to defining a Windows PowerShell Desired State Configuration (DSC) configuration. Built-in resources include files and folders, server features and roles, registry settings, environment variables, and services and processes.

Extending the set of built-in DSC resources is possible by importing additional resources as part of PowerShell Modules as well.

Compilation Job

A compilation job in Azure Automation DSC refers to the process of creating a node configuration by compiling a configuration file.  Following a compilation job, a node configuration is automatically placed on the Azure Automation DSC pull server.  Previous versions of the configuration are overwritten.

There are, of course, other terms you may encounter.  However, these are the most important.  As long as you are familiar with these terms, you should be able to carry an intelligent conversation about the workflows involved in Azure Automation DSC.