I have a question about the in-between place at authoring and staging of .mof files in a pull scenario. Just to review the workflow as I understand it:
- A configuration builds .mof files, one for each node.
- The .mof files must be renamed according to a machine's assigned GUID. (I've also read it's possible for many machines to share a GUID as well)
- .checksums are generated for each new .mof file and these file pairs are placed in the appropriate directory of the pull server.
- Sometime within the next interval (30 minutes default) pull-enabled DSC machines will check in and fetch their .mof file and process it.
The LCM for each DSC node will only parse one .mof file, the one it fetched because that filename matched its assigned GUID. So it follows that if I write two or three or more configs that create .mof files for the same node then we have a bit of a situation. Either we need to get all these merged together, or the powershell configurations need to be melded into one by compositing, but I haven’t read anywhere where someone explicitly says this. This leads me to wonder whether I’ve missed something, like for example there is a .mof merger and it’s part of some utility that “publishes” your .mof files.
If the workflow is as I describe it then all configs we write for publication to one DSC server probably should be managed in one giant set of composite powershell configurations, otherwise you risk a situation where running more that one script produces multiple .mof files for the same machine. Either that, or you must logically segregate all your machines into groups that are managed by separate configs, but this leaves out the possibility of managing all of them with some uniform basic parameters which I imagine most organizations might want.
At this time, the documentation describing the process of publishing and managing .mof files seems a bit thin. Can anyone recommend some good blog posts on the subject or a publishing utility of the sort I just described?