Azure Automation State Configuration overview
Azure Automation State Configuration is an Azure configuration management service that allows you to write, manage, and compile PowerShell Desired State Configuration (DSC) configurations for nodes in any cloud or on-premises datacenter. The service also imports DSC Resources, and assigns configurations to target nodes, all in the cloud. You can access Azure Automation State Configuration in the Azure portal by selecting State configuration (DSC) under Configuration Management.
You can use Azure Automation State Configuration to manage a variety of machines:
- Azure virtual machines
- Azure virtual machines (classic)
- Physical/virtual Windows machines on-premises, or in a cloud other than Azure (including AWS EC2 instances)
- Physical/virtual Linux machines on-premises, in Azure, or in a cloud other than Azure
If you aren't ready to manage machine configuration from the cloud, you can use Azure Automation State Configuration as a report-only endpoint. This feature allows you to set (push) configurations through DSC and view reporting details in Azure Automation.
Managing Azure VMs with Azure Automation State Configuration is included at no extra charge if the installed Azure VM Desired State Configuration extension version is greater than 2.70. For more information, see Automation pricing page.
Why use Azure Automation State Configuration
Azure Automation State Configuration provides several advantages over the use of DSC outside of Azure. This service enables scalability across thousands of machines quickly and easily from a central, secure location. You can easily enable machines, assign them declarative configurations, and view reports showing each machine's compliance with the desired state you specify.
The Azure Automation State Configuration service is to DSC what Azure Automation runbooks are to PowerShell scripting. In other words, in the same way that Azure Automation helps you manage PowerShell scripts, it also helps you manage DSC configurations.
Built-in pull server
Azure Automation State Configuration provides a DSC pull server similar to the Windows Feature DSC-Service. Target nodes can automatically receive configurations, conform to the desired state, and report on their compliance. The built-in pull server in Azure Automation eliminates the need to set up and maintain your own pull server. Azure Automation can target virtual or physical Windows or Linux machines, in the cloud or on-premises.
Management of all your DSC artifacts
Azure Automation State Configuration brings the same management layer to PowerShell Desired State Configuration as it offers for PowerShell scripting. From the Azure portal or from PowerShell, you can manage all your DSC configurations, resources, and target nodes.
Import of reporting data into Azure Monitor logs
Nodes that are managed with Azure Automation State Configuration send detailed reporting status data to the built-in pull server. You can configure Azure Automation State Configuration to send this data to your Log Analytics workspace. See Forward Azure Automation State Configuration reporting data to Azure Monitor logs.
Consider the requirements in this section when using Azure Automation State Configuration.
Operating system requirements
For nodes running Windows, the following versions are supported:
- Windows Server 2019
- Windows Server 2016
- Windows Server 2012R2
- Windows Server 2012
- Windows Server 2008 R2 SP1
- Windows 10
- Windows 8.1
- Windows 7
The Microsoft Hyper-V Server standalone product SKU does not contain an implementation of DSC. Thus it can't be managed by PowerShell DSC or Azure Automation State Configuration.
For nodes running Linux, the DSC Linux extension supports all the Linux distributions listed in the PowerShell DSC documentation.
For all Linux nodes running in Azure, PowerShell DSC for Linux is installed when machines are enabled.
Configuration of private networks
If your nodes are located in a private network, the following port and URLs are required. These resources provide network connectivity for the managed node and allow DSC to communicate with Azure Automation.
- Port: Only TCP 443 required for outbound internet access
- Global URL: *.azure-automation.net
- Global URL of US Gov Virginia: *.azure-automation.us
- Agent service: https://<workspaceId>.agentsvc.azure-automation.net
If you are using DSC resources that communicate between nodes, such as the WaitFor* resources, you also need to allow traffic between nodes. See the documentation for each DSC resource to understand these network requirements.
To understand client requirements for TLS 1.2, see TLS 1.2 enforcement for Azure Automation.
Proxy support for the DSC agent is available in Windows version 1809 and later. This option is enabled by setting the values for
ProxyCredential properties in the metaconfiguration script
used to register nodes.
Azure Automation State Configuration does not provide DSC proxy support for previous versions of Windows.
For Linux nodes, the DSC agent supports proxy and uses the
http_proxy variable to determine the URL. To find out more about proxy support, see Generate DSC metaconfigurations.
DNS records per region
It's recommended to use the addresses listed in the DNS records per region table when defining exceptions.
- To get started, see Get started with Azure Automation State Configuration.
- To learn how to enable nodes, see Enable Azure Automation State Configuration.
- To learn about compiling DSC configurations so that you can assign them to target nodes, see Compile DSC configurations in Azure Automation State Configuration.
- To see an example of using Azure Automation State Configuration in a continuous deployment pipeline, see Set up continuous deployment with Chocolatey.
- For pricing information, see Azure Automation State Configuration pricing.
- For a PowerShell cmdlet reference, see Az.Automation.