Getting Started With Azure Automation DSC

Let’s start with the word DSC, it stands for Desired State Configuration. There are certain scenarios wherein an IT administrator of a huge enterprise faces complexities and issues to maintain the same configuration of resources across the network farm and this is where DSC comes to the rescue.

Need of DSC

Suppose there are thousands of servers in your environment and many of those are configured with specific roles like Web front end, application servers, search servers etc. also some set of server needs special configuration settings like firewall configurations. Now you being an administrator of your IT infrastructure need to make sure that everything is working as expected on each server and their state is maintained at any given point of time, also if any configuration change comes from stakeholders then it needs to be distributed across all servers in the environment without downtime, now imagine how cumbersome it would be if you decide to do it manually.

Above is the one hypothetical scenario, however there are lots of more complicated scenarios than this in the real world and with larger enterprises. So there has to be a solid solution to cater such needs and Automation DSC is one such solution.

As the name suggests, it is a technique used to maintain the desired state of your IT resources (e.g. Virtual Machines). Apart from this basic necessity, DSC not only helps in maintaining the state of the resources but also helps in deploying, monitoring and updating these resources consistently and gives peace of mind to IT administrators.

Let’s take a look at a  few other examples where DSC can be used,

• Adding / removing / configuring server roles.
• Managing files and directories.
• Deploying new software.
• Running Windows PowerShell scripts.
• Managing Registry.

Azure DSC

Azure DSC is built on top of the existing PowerShell DSC feature to provide easier configuration management experience.

In a nutshell, a script is written wherein you mention all the required configurations for a machine and the script gets deployed on the target machines in farm, script gets executed there and target machine or node comes to the desired state by obeying to those mentioned configurations in script file. If at a later point, any node gets drifted from its state then DSC engine makes sure to runs this script again on drifted node to bring it back to desired state.

Let’s try to visualize how DSC maintains the state and how it works, 
Azure Automation DSC uses the power of Azure Automation Service. If you are not familiar with Azure Automation service, it is recommended that you should read more about it here, this article focuses mostly on Azure Automation DSC and not on Azure Automation service.

Before we jump into writing PowerShell script, let’s get familiar with Azure DSC Terminologies.

Configuration

It can be related to a function in programming language which defines state of your environment or nodes in it. A configuration block can have zero or more nodes in it.

Configuration MyConfig{

}

Node

Inside configuration block, we write node block which means set of configurations needs to be applied on one or many nodes (computers) in an environment.

Configuration MyConfig{

Node "PC-01" {

  }

}

Note that the node in above configuration targets computer with name PC-01. Node could be a VM running in Azure or on premise VM or physical host or in another public cloud.

You can further parameterize the node name such as,

Note that in example below – the node name is parameterized and stored into a variable which is then used in place of the actual node name definition. The default value of the node is localhost.

Configuration MyConfig{

param(
   [string[]]$computerName="localhost"
)

Node $computerName {

  }

}

Resources

Inside the node block, you define the DSC configuration of various resources of DSC, e.g. WindowsFeature is one of the in-built resource which can be used in node block.

To know more about built in resources in DSC, please visit this link. It is possible to create custom resources for DSC – refer this link for more information.

Configuration MyConfig{

Node "PC-01" {
        WindowsFeature IIS
        {
            Name = “Web-Server”
            Ensure = “Present”
        }

        WindowsFeature InstallAspDotNet45
        {
            Name = "Web-Asp-Net45"
            Ensure = "Present"
        }
}

}

MOF Files

Compiling DSC will create one or more DSC node configurations (depending on node blocks in the configuration) known as MOF files.

Above DSC file will make sure that nodes will be configured with IIS and ASP.NET 4.5 features.

Compilation Job

It is similar to Azure automation running book jobs, however it doesn’t perform any task except creation of node configuration.

DSC Pull Server

DSC pull server is nothing but a common place where all the node configurations are placed. Each node (machine) in the infrastructure setup polls this pull server to check if it is aligned with its configured state. Once the compilation job runs, the output of it i.e. node configuration is placed on to DSC pull server (it overwrites previous version of node configuration if there is any).

The process can be visualized as below,

 

Compiling DSC Files

So far we have seen how we can author DSC files mentioning all desired machine configurations in it, we will now see how we can compile those files to generate MOF documents as shown in diagram above.

There are two ways to compile DSC file,

• Using Azure Automation
• Using PowerShell

This article focuses on the first method – i.e. Compiling DSC files using Azure automation service.

Demo

Let’s go ahead and create Azure automation service using new Azure portal. We will name it as demoautomation and will place it under new resource group named as rg-dscdemo

 

Let’s create a storage account “dscdemostorageacc“ and a VM in same resource group and name it as demo-vm, we will create administrator credentials with user name as DSCAdmin.

Note - this article focuses on Azure DSC and hence creation of VM and its required azure artifacts is not documented in this article, if you want to go through detailed step by step demo of creating a virtual machine in Azure, you can follow this article.

Let’s create out DSC script file with basic configuration to install IIS and ASP.NET framework on the node.

configuration DSCDemo
{
    Import-DscResource –ModuleName 'PSDesiredStateConfiguration'

    Node "localhost"
    {
        WindowsFeature IIS
        {
            Name = “Web-Server”
            Ensure = “Present”
        }
        WindowsFeature InstallAspDotNet45
        {
            Name = "Web-Asp-Net45"
            Ensure = "Present"
        }
    }
}
DSCDemo

Save this file on local machine and upload it to azure automation service using new azure portal.

Once above script is compiled and deployed to desired machines, it will enable IIS role and install ASPNET framework on those machines.

All right, with this let’s move ahead.

Click on the automation service account and you will be navigated to Dashboard.

 

Click on DSC Configurations tile and upload new script file by clicking add button in header of the blade,

Once it is uploaded, the file will be listed on the DSC Configurations blade. Select the file and click on the compile option from blade header.

 

Once you click compile, you will be shown a message that “Are you sure you want to compile this configuration? Any node configurations generated will be automatically placed on the Azure Automation DSC pull server. If node configurations with the same name exist on the pull server, they will be overwritten.” – click yes.

It immediately queues a new job for compilation and details can be seen in azure portal. Once the scheduler executes the job, you will see the job status as completed and you can also dive deep into compilation logs, errors and warnings.

Since we have now registered and DSC configuration and compiled it, let’s go ahead and associate our demo-vm with the node configuration. To do this, navigate to the azure automation service account dashboard and click on DSC nodes tile. It will open up a new blade wherein you will be able to add your machines (Cloud VMs or On-Premise).

 

Let’s click on on Add Azure VM, it will open up a new blade asking to select VM to be registered. Select your VM. Now next step is to select the node configuration you want to apply to a VM, and enter the node name. (You can get the node name from automation service dashboard by clicking on DSC nodes tile.)

 

After filling in all the required details, once you select ok – the DSC extension gets installed on the selected VM.

 

Once the VM / node is registered, you will be able to see it under the list of registered VMs in automation service’s dashboard under DSC Nodes.

 

It shows the status of the VM, right now it is compliant. You can even drill down to the history reports of consistency check of VM.

Once it is completed, you can log on to the VM and verify if it has really installed the configurations on it.

Updating Configuration

To update the configuration of registered nodes at same time, we will simply need to update the configuration file and update appropriate node settings.

Let’s assume that now we need to make sure that all registered nodes should also support .NET Framework 3.5 features (which are currently not installed on our demo VM)

 

Let’s update configuration file and modify localhost node configurations as below,

configuration DSCDemo
{
    Import-DscResource –ModuleName 'PSDesiredStateConfiguration'

    Node "localhost"
    {
        WindowsFeature IIS
        {
            Name = “Web-Server”
            Ensure = “Present”
        }
        WindowsFeature InstallAspDotNet45
        {
            Name = "Web-Asp-Net45"
            Ensure = "Present"
        }
        WindowsFeature NET3.5
        {
            Name= "NET-Framework-Features"
            Ensure = "Present"
        }
    }
}
DSCDemo

We will follow the same procedure of compilation of DSC script using Azure portal described above.

Once the updated script file is compiled and generated MOF documents are deployed on the pull server, all registered nodes will refer to the new policy and make themselves compliant with it.

Note that Demo VM node status changes to pending.

 

Once the node starts to update its configuration (based on the node pull frequency interval), the status changes to In Progress.

Once the status changes to Compliant, meaning that node has updated itself with latest provided configurations, we can log on to the VM and check if it has installed the configuration i.e. .NET Framework 3.5 features.

 

This is all about Azure Automation DSC for now.

Thanks for reading the article, feel free to share your views or comments.