System Center

How to Publish a Desired State Configuration

The work is almost done! Our configuration has been generated using a simple hash table, offering a really easy and flexible method to build up customized configurations without the hassle of many different configurations to be maintained. After all, that would almost defeat the objective, as we would surely end up with having to manage these to be consistent!

Editor’s note: Need to catch up? Check out our previous articles in this series:

After we generated our configurations, we were provided with a .MOF file for each server in the table. Our final task is to take this file and publish it to our pull server, so that the nodes can pick up the instructions held in the file and get on with the work of implementing our configurations.

Publishing the .MOF File

You might be forgiven to think all that you need to do is simply copy over the new .MOF files to the pull servers distribution folder, but that really is only part of the story. First, the correct location to drop the .MOF files will depend on how you configured your pull server (but if you followed my posts, then this will be C:\Program Files\WindowsPowerShell\DscService\Configuration).

Sponsored Content

Devolutions Remote Desktop Manager

Devolutions RDM centralizes all remote connections on a single platform that is securely shared between users and across the entire team. With support for hundreds of integrated technologies — including multiple protocols and VPNs — along with built-in enterprise-grade password management tools, global and granular-level access controls, and robust mobile apps to complement desktop clients.

Publish a Desired State Configuration

In this folder, you are correct in thinking we will place our .MOF files, but (and this is a big but) the .MOF files generated by our configuration were all created based on the friendly name of the nodes. However, you will recall, that when we configured the Local Configuration Manager we provided a ConfigurationID, which was based on the GUID of the computer; we even used a smart PowerShell function from Johan Åkerström to get the GUID for us.

We will leverage this script again, but this time, we will use it to rename the .MOF files from their friendly names to their respective ConfigurationID, as this is the only information which the Local Configuration Manager will provide to the pull server, so we need to ensure that these match up for the magic to work.

Almost there! But one final validation is still required. The DSC pull server also insists that we provide a checksum file for each MOF it will publish – this is to help ensure that the files are not tampered with and that the LCM can quickly validate that the received configuration is fully intact.

I am going to leverage PowerShell one more time, this time to help automate the above steps. The following function is a combination of some tricks and tips I have collected online and wrapped up to make a simple method of pointing to the configuration .MOF files, and I’ve had them named, checksum’ed, and deposited on the DSC configuration folder ready for serving out.

​ function Publish-DSCConfiguration {
   param (
      [Parameter(Mandatory=$true, position=0)]
      [ValidateScript({Test-Path $_})]
      [string] $Path = "C:\WorkSpace\DSC"

      # Publish MOFs for Web Service
      Get-ChildItem $Path -Filter *.mof | ForEach-Object {
         $guidMofFile = "$(Get-ComputerGuid $_.BaseName).mof"
         $newMof = copy $_.FullName $env:programfiles\WindowsPowerShell\DscService\Configuration\$guidMofFile -PassThru -Force
         $newHash = (Get-FileHash $newMof).hash

Of course, you will want to run this on the DSC pull server and provide the path to where your generated configuration .MOF files are stored. For example, we might use the following:

​ Publish-DSCConfiguration –Path \\Myworkstation\DSC\PetriDSC

And that is it! You are now configured end to end. All you need to do now is wait a little, then check your nodes to validate that your new configurations are been deployed and, of course, applied.

Related Topics:

The World’s Most Comprehensive Teams to Teams Migration Checklist

Whether you have just started thinking about migration or have already begun to move, our Microsoft Teams Migration Checklist can help guide you through the different phases for a Teams migration to another tenant.

This detailed six-step guide will walk you through key decision points while also providing more prescriptive best practice recommendations where appropriate.

Discover key insights for the following phases of a Teams migration: 

  • Discovery
  • Pilot
  • Planning
  • Communication
  • Execution
  • Validation

Sponsored by: