Coming Soon: GET:IT Endpoint Management 1-Day Conference on September 28th at 9:30 AM ET Coming Soon: GET:IT Endpoint Management 1-Day Conference on September 28th at 9:30 AM ET
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

Say Goodbye to Traditional PC Lifecycle Management

Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.

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:

Live Webinar: Active Directory Security: What Needs Immediate Priority!Live on Tuesday, October 12th at 1 PM ET

Attacks on Active Directory are at an all-time high. Companies that are not taking heed are being punished, both monetarily and with loss of production.

In this webinar, you will learn:

  • How to prioritize vulnerability management
  • What attackers are leveraging to breach organizations
  • Where Active Directory security needs immediate attention
  • Overall strategy to secure your environment and keep it secured

Sponsored by: