Last Update: Sep 04, 2024 | Published: Feb 05, 2014
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.
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 FilesWindowsPowerShellDscServiceConfiguration).
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:WorkSpaceDSC" ) begin { # Publish MOFs for Web Service Get-ChildItem $Path -Filter *.mof | ForEach-Object { $guidMofFile = "$(Get-ComputerGuid $_.BaseName).mof" $newMof = copy $_.FullName $env:programfilesWindowsPowerShellDscServiceConfiguration$guidMofFile -PassThru -Force $newHash = (Get-FileHash $newMof).hash [System.IO.File]::WriteAllText("$newMof.checksum",$newHash) } } }
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 \MyworkstationDSCPetriDSC
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.