共用方式為

Server managed by Desired State Configuration service

  • Code Sample
Browse code

Azure Public Test Date Azure Public Test Result

Azure US Gov Last Test Date Azure US Gov Last Test Result

Best Practice Check Cred Scan Check

Deploy To Azure Deploy To Azure US Gov Visualize

This template demonstrates a managed virtual machine where the configuration will be maintained by Azure for the life of the node as opposed to only applying the configuration at the time of deployment.

For details about Azure Operations Management services, see the Azure Automation Documentation.

What is new in this template

Unlike previous examples, this template includes examples of nested templates that create an automation account, publish a configuration script and supporting modules from the PowerShell Gallery, compile the configuration, bootstrap the machine to the service, and wait for the initial delivery of the configuration to complete, all from a single deployment. This is possible because new API methods (reference, listkeys) are now available for the Automation service.

Notice that no custom scripts or chained-together ARM templates are required in this example.

There is one important concept to note when using nested templates such as this, where dependencies flow across separate declared deployments. In order for the Server template to "depend on" the Configuration template, the Automation Account is declared again in the Server template. Since the account already exists, this is essentially verifying the account before the server deployment.

What is unique about this concept

This model is the go-forward recommendation for utilizing DSC with Azure Virtual Machines. The DSC Extension is used only to apply settings to the Local Configuration Manager (LCM) and direct it to use the Azure Automation DSC service to deliver and maintain the state of the machine. The compliance state or any error messages from DSC can be viewed in the reporting available with the service.

Users of the service also have tools to support Operations practices, such as publishing changes to the configuration without re-deployment of the virtual machine, or linking the Automation Account with Log Analytics for alerting (including notifications to mobile devices) when a node has drifted from the intended configuration.

The expected workflow from any public gallery is to download/save an artifact, review the source code and test it to verify functionality, and then publish it to a private, trusted feed for usage. However, since module authors releasing to PowerShell Gallery increment the version number when changes are made, if template authors would like to validate and test specific versions of modules in the gallery and use static links to those artifacts, those artifacts can be expected to remain unchanged. This does not change the operational best practice behavior of reviewing, validating, and testing all code artifacts including ARM templates, PowerShell scripts, and DSC resources, before production deployment.

Tags: Microsoft.Resources/deployments, Microsoft.Automation/automationAccounts, modules, credentials, configurations, uri, compilationjobs, Microsoft.Network/virtualNetworks, Microsoft.Network/publicIPAddresses, Microsoft.Network/networkInterfaces, Microsoft.Compute/virtualMachines, Microsoft.Compute/virtualMachines/extensions, DSC