Azure Automation State Configuration

Azure Automation provides a Desired State Configuration (DSC) pull server along with every Azure Automation account. The pull server can hold configuration scripts that can be pulled by servers across clouds and on-premises. This means that Azure Automation can be used to configure any server hosted anywhere in the world.

The DSC needs a local agent on these servers, also known as a local configuration manager (LCM). It should be configured with the Azure Automation DSC pull server so it can download the required configuration and autoconfigure the server.

The autoconfiguration can be scheduled to be periodic (by default it is half an hour), and if the agent finds any deviation in the server configuration compared to the one available in the DSC script, it will autocorrect and bring back the server to the desired and expected state.

In this section, we will configure one server hosted on Azure, and the process will remain the same irrespective of whether the server is on a cloud or on-premises.

The first step is to create a DSC configuration. A sample configuration is shown here, and complex configurations can be authored similarly:

configuration ensureiis {

import-dscresource -modulename psdesiredstateconfiguration

    

node localhost {        

        WindowsFeature iis {

            Name = "web-server"

            Ensure = "Present"

             

        }

    }

}

The configuration is quite simple. It imports the PSDesiredStateConfiguration base DSC module and declares a single-node configuration. This configuration is not associated with any specific node and can be used to configure any server. The configuration is supposed to configure an IIS web server and ensure that it is present on any server to which it is applied.

This configuration is not yet available on the Azure Automation DSC pull server, and so the first step is to import the configuration into the pull server. This can be done using the Automation account Import-AzAutomationDscConfiguration cmdlet, as shown next:

Import-AzAutomationDscConfiguration -SourcePath "C:\Ritesh\ensureiis.ps1" -AutomationAccountName bookaccount -ResourceGroupName automationrg -Force -Published

There are a few important things to note here. The name of the configuration should match the filename, and it must only contain alphanumeric characters and underscores. A good naming convention is to use verb/noun combinations. The cmdlets need the path of the configuration file and the Azure Automation account details to import the configuration script.

At this stage, the configuration is visible on the portal:

Figure 4.30: Adding configuration

Once the configuration script is imported, it is compiled and stored within the DSC pull server using the Start-AzAutomationDscCompilationJob cmdlet, as shown next:

Start-AzAutomationDscCompilationJob -ConfigurationName 'ensureiis' -ResourceGroupName 'automationrg' -AutomationAccountName 'bookaccount'

The name of the configuration should match the one that was recently uploaded, and the compiled configuration should be available now on the Compiled configurations tab, as shown in Figure 4.31:

Figure 4.31: Listing compiled configurations

It is important to note that the Node Count in Figure 4.31 is 0. It means that a node configuration called ensureiss.localhost exists but it is not assigned to any node. The next step is to assign the configuration to the node.

By now, we have a compiled DSC configuration available on the DSC pull server, but there are no nodes to manage. The next step is to onboard the VMs and associate them with the DSC pull server. This is done using the Register-AzAutomationDscNode cmdlet:

Register-AzAutomationDscNode -ResourceGroupName 'automationrg' -AutomationAccountName 'bookaccount' -AzureVMLocation "west Europe" -AzureVMResourceGroup 'spark' -AzureVMName 'spark' -ConfigurationModeFrequencyMins 30 -ConfigurationMode 'ApplyAndAutoCorrect'

This cmdlet takes the name of the resource group for both the VM and the Azure Automation account. It also configures the configuration mode and the configurationModeFrequencyMins property of the local configuration manager of the VM. This configuration will check and autocorrect any deviation from the configuration applied to it every 30 minutes.

If VMresourcegroup is not specified, the cmdlet tries to find the VM in the same resource group as the Azure Automation account, and if the VM location value is not provided, it tries to find the VM in the Azure Automation region. It is always better to provide values for them. Notice that this command can only be used for Azure VMs as it asks for AzureVMname explicitly. For servers on other clouds and on-premises, use the Get-AzAutomationDscOnboardingMetaconfig cmdlet.

Now, a new node configuration entry can also be found in the portal, as shown in Figure 4.32:

Figure 4.32: Verifying node status

The node information can be obtained as follows:

$node = Get-AzAutomationDscNode -ResourceGroupName 'automationrg' -AutomationAccountName 'bookaccount' -Name 'spark'

And a configuration can be assigned to the node:

Set-AzAutomationDscNode -ResourceGroupName 'automationrg' -AutomationAccountName 'bookaccount' -NodeConfigurationName 'ensureiis.localhost' -NodeId $node.Id

Once the compilation is complete, it can be assigned to the nodes. The initial status is Pending, as shown in Figure 4.33:

Figure 4.33: Verifying node status

After a few minutes, the configuration is applied to the node, the node becomes Compliant, and the status becomes Completed:

Figure 4.34: Verifying if the node is compliant

Later, logging into the server and checking if the web server (IIS) is installed confirms that it is installed, as you can see in Figure 4.35:

Figure 4.35: Checking whether the desired state has been achieved

In the next section, Azure Automation pricing will be discussed.