Server managed by Desired State Configuration service
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.
Is it acceptable to link directly to PowerShell Gallery in Azure-Quickstart-Templates?
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