Automation Configuration Management is the other major capability of the Azure Automation service. Configuration Management is built on top of the PowerShell Desired State Configuration (DSC) platform. DSC is a management platform introduced in Windows Management Framework (WMF) 4 and significantly enhanced in version 5. This new platform enables management of configuration on physical hosts, VMs or any device using a declarative syntax that is based on PowerShell. Besides Windows machines, DSC is also available on Linux, which makes Azure Automation a cross-platform management service. DSC extends the PowerShell language through PowerShell cmdlets and resources that can be used to declaratively specify how your environment should be configured and then applies that configuration. It also provides maintenance and management of existing configurations. DSC has many practical applications, but the most compelling is to create and maintain your infrastructure as code.
As Configuration Management builds on top of PowerShell DSC, it basically allows you to manage all the DSC components and tasks at scale, like authoring and managing DSC configurations, importing DSC resources and generating DSC Node configurations. All of this is performed in the cloud, where there is a DSC Pull server to which target nodes (physical machines, VMs, and devices) connect. These target nodes pick up the configurations, compare them with their local state and report back the compliance to Azure Automation. They can even automatically remediate the desired state if needed. The target nodes can be located on-premises or in the cloud. Configuration Management gives you all this management capability without the need to deploy infrastructure on your own, whether in the cloud or on-premises.
Note: As Process Automation and Configuration Management capabilities both reside inside the Azure Automation service, we suggest you go through "Chapter 3 – Process Automation" to get familiar with concepts such as Automation accounts, assets, etc. that are used by both features.
Before seeing how we can use Configuration Management, we should get familiar with its components.
DSC Configuration is a new concept in PowerShell 4.0. In declarative PowerShell syntax, you define your environment's state. Configurations are used in PowerShell by defining a script block using the keyword Configuration, followed by the name of the configuration which is used as an identifier and finally, braces to delimit the block.
Configuration OMSBook {
...
}
Inside the configuration block, a node block needs to be defined. That node block represents a set of servers that should have the same configuration. You can think of a node block as a role. A node block starts with the keyword Node. After the keyword, a name must be given to that node which can be replaced by a variable or expression if needed. Last are the braces used to delimit the node configuration block.
Configuration OMSBook {
Node "SNMPserver" {
...
}
}
Inside the node block, a resource block is defined to configure DSC resources. A resource block starts with a name, which should be the same as the DSC resource that we want to use. After the name, an identifier is specified, and finally the braces are used to delimit the block.
Configuration OMSBook {
Node "SNMPserver" {
WindowsFeature SNMP {
Ensure = "Present"
Name = "SNMP-Service"
}
}
}
IMPORTANT: A configuration should contain only one configuration block, which should have the same name as the configuration in Configuration Management in the Azure portal.
When a DSC Configuration is created, it needs to be converted to a Node Configuration so it can be distributed to Nodes. The instance of such a conversion of single DSC Configuration to Node Configuration is called a compilation job.
A Node Configuration is a document that is distributed to Nodes so they can run it locally and check their state. These documents are written in Managed Object Format (MOF). When DSC Configuration is converted to Node Configuration, the latter receives a name in the following format "<DSC Configuration Name>.<Node Block Name>".
Note: Instead of importing DSC configurations and compiling them into Node configurations, you can also import both signed and unsigned Node Configurations (MOFs) directly with Configuration Management.
DSC Resources are the building blocks for creating and running configurations. DSC for Windows and Linux comes with a set of built-in resources that can be used out of the box. Additional DSC resources can be imported, in the same fashion as PowerShell Modules are imported in Azure Automation. When an additional DSC resource is used in a configuration, that resource will be pulled by the node from the Configuration Management DSC Pull Server prior to running the configuration.
DSC Pull Server is the place where all the above resources are being managed. When an Azure Automation Account is created, a logical DSC Pull Server is created for that account to enable the Configuration Management functionality.
A node is any machine that has its configuration managed by a Configuration Management DSC Pull Server. Nodes pull Node Configurations from a DSC Pull Server and maintain compliance according to what is defined in those configurations. Nodes run those configurations on a defined interval and report their state to the DSC Pull server. Because Nodes initiate all the actions to the DSC Pull Server, only an outbound Internet connection on the Nodes is needed.
When a node is onboarded for the first time in Azure Automation you can specify several settings that configure the behavior of the Local Configuration Manager (LCM) agent.
Table 1 lists those options:
Setting | Description | Default value |
Node Configuration Name | Initial node configuration can be applied during onboarding. The node configuration must be present in Configuration Management in advance. | N/A |
Refresh Frequency | The time interval, in minutes, at which the LCM checks a pull server to get updated configurations. Either the value of this setting must be a multiple of the value of the Configuration Mode Frequency setting, or the value of the Configuration Mode Frequency setting must be a multiple of the value of this setting. | 30 |
Configuration Mode Frequency | How often, in minutes, the current configuration is checked and applied. This property is ignored if the Configuration Mode setting is set to 'ApplyOnly'. | 15 |
Configuration Mode | Specifies how the LCM applies the configuration to the target nodes. Possible values are:
| ApplyAndMonitor |
Allow module override | Allows new configurations downloaded from the configuration server to overwrite the old ones on the target node if set to true. | false |
Reboot node if needed | Automatically reboot the node after a configuration that requires a reboot is applied if set to true. If the value is set to false the node needs to be rebooted manually. | false |
Action after reboot | Specifies what happens after a reboot during the application of a configuration. The possible values are:
| ContinueConfiguration |
TABLE 1. LOCAL CONFIGURATION MANAGER SETTINGS
A common task in any environment is the compliance of a specific system or application settings with corporate standards. With Configuration Management, you can achieve that easily. There are three ways to use Azure Automation Configuration Management: through the Azure portal, through Azure Resource Manager PowerShell cmdlets or through ARM Templates. We will show steps for all of them where applicable. In the sections that follow, we will set a specific time zone on a server managed by
Configuration Management by using a DSC resource that is not available out of the box in Windows. That resource will be imported in Azure Automation and we will use it when we apply our configuration to the server. We will also create a simple file on a Linux machine with DSC.
We mentioned earlier that we can import PowerShell Modules and a DSC resource through the PowerShell Gallery website. In this exercise, we will go through the steps for importing a DSC resource, but the same steps apply for PowerShell modules as well, which we covered in the previous chapter.
FIGURE 1. BROWSE POWERSHELL GALLERY FROM AZURE AUTOMATION ACCOUNT
FIGURE 2. IMPORT XTIMEXONE MODULE
FIGURE 3. SEARCH GALLERY FOR LINUX MODULES
Both xTimeZone and nx resources can be imported via PowerShell rather than using the Azure portal. You can download the full script from the GitHub repository provided in the link at the end of this section. The AzureRM PS module v4.0.0 or later is required for executing the PowerShell code in the next sections.
Download the Code
You can download the full script from GitHub at https://github.com/insidemscloud/OMSBookV2 ,in the \Chapter 4\scripts directory. The file name is ImportDSCResources.ps1.
The third option is to use an ARM template to import the DSC resources:
Download the Code
You can download the full template from GitHub at https://github.com/insidemscloud/OMSBookV2 ,in the \Chapter 4\templates directory.
The file name is ImportDSCResources.json.
Note: If you have developed a custom DSC Resource or PowerShell module, you can still upload it. In this case, the module will be archived in a zip file. When uploaded via the Azure portal, you can grab it from your local computer. However, when using PowerShell or an ARM template, you would place the archived module on a publicly available Azure Storage account, GitHub repository or any place that allows access via http/https.
To apply the configuration to a Windows based server, that server first needs to be added as a DSC node to Azure Automation. The Windows Server 2008 R2 SP1 version and above are supported by Configuration Management.
Note: Configuration Management requires Windows Management Framework (WMF) 5 or above to be installed on the server prior to adding it as a DSC node.
Download the Code
You can download the full script for "Getting DSC Onboarding Meta Configuration" from GitHub at https://github.com/insidemscloud/OMSBookV2 ,in the \Chapter 4\scripts directory. The file name is GetDscOnboardingMetaconfig.ps1.
Download the Code
You can download the full script for "Setting DSC local Configuration to connect to Azure
Automation" from GitHub at https://github.com/insidemscloud/OMSBookV2 ,in the \Chapter 4\scripts directory. The file name is SetDSCLocalConfiguration.ps1.
Follow these steps to add a server as an Azure Automation DSC node.
Note: WMF 5.1 installation requires a restart of the server.
FIGURE 4. WMF 5.1 INSTALLATION
# Variables
$VM = 'ONPREMVM'
# Set Local DSC Configuration to connect to
# Azure Automation DSC
Set-DscLocalConfigurationManager`
-Path 'C:\DscMetaConfigs\' `
-ComputerName $VM`
-Verbose
FIGURE 5. SET DSC LOCAL CONFIGURATION
FIGURE 6. DSC NODES BLADE
Note: You can register Azure Windows-based VMs by using the portal or by using the Azure VM DSC extension.
Note: The default Local Configuration Manager settings were applied during onboarding. You can change them by directly editing the downloaded MOF file in the location specified in Step 5 of this walkthrough.
In this section, we will add a Linux-based Azure VM as a DSC Node to Azure Automation.
Table 2 lists the supported Linux distributions and versions:
OS | Version |
CentOS | 5, 6, and 7 (x86/x64) |
Debian GNU/Linux | 6 and 7 (x86/x64) |
Oracle Linux | 5, 6 and 7 (x86/x64) |
Red Hat Enterprise Linux Server | 5, 6 and 7 (x86/x64) |
SUSE Linux Enterprise Server | 10, 11 and 12 (x86/x64) |
Ubuntu Server | 12.04 LTS and 14.04 LTS (x86/x64) |
TABLE 2. DSC FOR LINUX SUPPORTED OPERATING SYSTEMS
Download the Code
You can download the full script for "onboarding an Azure Linux VM to Automation Configuration Management" from GitHub at
https://github.com/insidemscloud/OMSBookV2 ,in the \Chapter 4\scripts directory. The file name is OnboardAzureLinuxVMtoAutomation.ps1.
Execute the steps below to onboard Azure Linux VM to Configuration Management:
FIGURE 7. DSC FOR LINUX AZURE VM EXTENSION
FIGURE 8. LINUX SERVER AS DSC NODE IN CONFIGURATION MANAGEMENT
Note: You can also onboard any supported Linux server manually by installing PowerShell DSC for Linux and using the Register.py script in /opt/microsoft/dsc/Scripts. For full documentation of that process browse https://github.com/Microsoft/PowerShell-DSC-forLinux.
Note: The default Local Configuration Manager settings were applied during onboarding. With version 3 of the DSC for Linux Azure VM extension, you will be able to specify all LCM settings during the deployment of the extension
We have completed all the prerequisites and now in this section, we will apply the different configurations to the added nodes.
Download the Code
You can download the DSC Configuration for the Windows server from GitHub at https://github.com/insidemscloud/OMSBookV2 ,in the \Chapter 4\configurations directory. The file name is SetTimeZone.ps1.
Download the Code
You can download the DSC Configuration for the Linux server from GitHub at https://github.com/insidemscloud/OMSBookV2 ,in the \Chapter 4\configurations directory. The file name is SetFileConfiguraiton.ps1.
Download the Code
You can download the Update DSC Configuration script for Windows from GitHub at https://github.com/insidemscloud/OMSBookV2 ,in the \Chapter 4\scripts directory. The file name is UpdateDscConfigurationWindows.ps1.
Download the Code
You can download the Update DSC Configuration script for Linux from GitHub at https://github.com/insidemscloud/OMSBookV2 ,in the \Chapter 4\scripts directory. The file name is UpdateDscConfigurationLinux.txt.
Follow these steps to add and apply DSC configurations to the DSC Nodes via the Azure portal.
FIGURE 9. DSC CONFIGURATIONS BLADE
Configuration File: SetTimeZone.ps1 located in your local computer
FIGURE 10. IMPORT CONFIGURATION BLADE
FIGURE 11. SETTIMEZONE CONFIGURATION BLADE
FIGURE 12. SETTIMEZONE COMPILATION JOB BLADE
FIGURE 13. ASSIGN NODE CONFIGURATION BLADE
FIGURE 14. DATE AND TIME PROPERTIES
# Update DSC configuration on local machine
Update-DscConfiguration -Wait -Verbose
FIGURE 15. UPDATE DSC CONFIGURATION
FIGURE 16. DATE AND TIME PROPERTIES
FIGURE 17. REPORTS SECTION
FIGURE 18. ASSIGN NODE CONFIGURATION BLADE
# Perform Configuration Check sudo /opt/microsoft/dsc/Scripts/PerformRequiredConfigurationChecks.py
FIGURE 19. CONFIGURATION CHECK
# Open ImportConfiguration file
sudo vim /tmp/ImportantConfiguration
FIGURE 20. IMPORTCONFIGURATION FILE CONTENTS
FIGURE 21. CONFIGURATION MANAGEMENT REPORT FOR LINUX NODE
As Linux is a file-based system and settings are applied in configuration files, it is quite easy to maintain these with Azure Automation Configuration Management.
Both DSC Configurations can be imported, compiled and applied to the nodes using PowerShell as well, as shown here.
Download the Code
You can download the full script from GitHub at https://github.com/insidemscloud/OMSBookV2 ,in the \Chapter 4\scripts directory. The file name is ImportDSCConfigurationsCompileAndApply.ps1.
Alternatively, an ARM template can be used for importing the DSC configurations and compiling them. Due to limitations in the Azure Automation ARM API, assigning the compiled Node configurations needs to be carried out via the Azure portal or PowerShell.
Download the Code
You can download the full template from GitHub at https://github.com/insidemscloud/OMSBookV2 ,in the \Chapter 4\templates directory.
The file name is ImportDSCConfigurationsAndCompile.json.
Infrastructure as code is a key concept of modern IT management. Treating your environment as code brings consistency and faster deployment time. The result is increased business value to your organization by reducing IT operations costs and achieving a competitive advantage against other organizations.
In this chapter, we discussed all the capabilities of the Configuration Management feature in Azure Automation. We have learned through examples how we can use it to achieve real-world tasks. We hope these examples will help you when you start your journey with infrastructure as code in your environment but also encourage you to explore more in the service.
In the next chapter, we will have a look at Change Management and Update Management, which are another part of the Automation & Control offering.