Azure Automation DSC Composite Configurations

While working on DSC for a client I came across the need to use Composite Configurations, however it needed to work with Azure Automation.  Microsoft did use to say that Azure Automation DSC does not support partial or composite configurations, however composite ones can actually be wrapped up as a module and imported.  After that it works just like any composite configuration in normal DSC.

The trick here is in the words ‘wrapped up as a module’.  This sounds daunting but is actually pretty straight forward.

Firstly set up the following directory structure (assuming your module is called myDSCModule and your composite resource is the MMAgent (OMS Agent installation via DSC))

DSC Folder Structure

The top level folder will contain the manifest for the module, the bottom level folder will contain the manifest and the PowerShell code for the resource.

Now creating the manifest is pretty simple, create a new file called myDSCModule.psd1 and add the following content

@{

# Version number of this module.
ModuleVersion = '1.0.0.0'

# ID used to uniquely identify this module
GUID = <yourGUID>

}

Generate a GUID for your module by using PowerShell to execute

[guid]::newguid()

Ok so that’s the module, now the resource.  We need two files this time, a manifest and the PowerShell code.  So let’s start with the PowerShell code.  Create a file called MMAgent.schema.psm1 and add your PowerShell code.  In my case I amended the standard code to pull the agent from a file share

Configuration MMAgent
{
 param
 (
 [string]
 $SourcePath = "\\Server\DSCResources$\OMS\MMASetup-AMD64.exe",
 [string]
 $LocalPath = "C:\DSCSource\OMS\MMASetup-AMD64.exe"
 )

$OPSINSIGHTS_WS_ID = Get-AutomationVariable -Name "OPSINSIGHTS_WS_ID"
 $OPSINSIGHTS_WS_KEY = Get-AutomationVariable -Name "OPSINSIGHTS_WS_KEY"
 $DSCRESOURCE_PATH = Get-AutomationVariable -Name "DSCRESOURCE_PATH"

Service OIService
 {
 Name = "HealthService"
 State = "Running"
 DependsOn = "[Package]OI"
 }

Package OI {
 Ensure = "Present"
 Path = $LocalPath
 Name = "Microsoft Monitoring Agent"
 ProductId = "6D765BA4-C090-4C41-99AD-9DAF927E53A5"
 Arguments = '/C:"setup.exe /qn ADD_OPINSIGHTS_WORKSPACE=1 OPINSIGHTS_WORKSPACE_ID=' + $OPSINSIGHTS_WS_ID + ' OPINSIGHTS_WORKSPACE_KEY=' + $OPSINSIGHTS_WS_KEY + ' AcceptEndUserLicenseAgreement=1"'
 DependsOn = "[File]OIPackage"
 }

File OIPackage {
 Ensure = "Present"
 SourcePath = $SourcePath
 DestinationPath = $LocalPath
 }
}

Now create the manifest file called MMAgent.psd1 and add the following, again generating your own GUID

@{

# Script module or binary module file associated with this manifest.
RootModule = 'MMagent.schema.psm1'

# Version number of this module.
ModuleVersion = '1.0.0'

# ID used to uniquely identify this module
GUID = '<yourGUID>'

}

Now you need to take the myDSCModule folder and compress it into a zip file and then upload it into Azure as a DSC Module.  After that you can simply call

Import-DscResource -ModuleName 'myDSCModule'

MMAgent myMMAgent{}

to consume the resources within your module as composite DSC Resources

That’s it…  Now if only Microsoft could have documented it step by step like this 🙂

Twan van Beers

Twan is a senior consultant with over 20 years of experience. He has a wide range of skills including Messaging, Active Directory, SQL, Networking and Firewalls. Twan loves to write scripts and get deep and dirty into debugging code, in order to understand and resolve the most complex of problems.

This Post Has 4 Comments

    1. Hi there,

      Once you have the module in Azure then you can create a configuration, e.g.

      Configuration myServers
      {
      Import-DscResource -ModuleName ‘myDSCModule’

      node myBaseServer
      {
      MMAgent myMMAgent { }
      }
      }

      Then after you’ve imported and compiled that configuration you can assign some of your servers the myBaseServer configuration and it will apply/test/correct that config just per normal DSC

  1. Twan – terrific and concise write-up. Thank you for documenting this. I had read the documentation Microsoft provided and it wasn’t clear how the nested configuration needed to be wrapped up as a module to be imported, but you nailed it.

Leave a Reply

Your email address will not be published. Required fields are marked *

Search