This topic contains 9 replies, has 7 voices, and was last updated by
February 19, 2015 at 8:17 am #22747ParticipantPoints: 0Rank: Member
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?
February 19, 2015 at 10:17 am #22753ParticipantPoints: 0Rank: Member
Check out Partial DSC configurations that is coming in Powershell 5.
February 19, 2015 at 11:40 am #22763
The partial config is more for multiple department configs. once group does OS, another does the application SQL, not to mention no all companies can use Preview software (unless we like looking for work)
I find it best to think of it this way.
GPO does all the compiling of settings every 90 minutes on each and every server.
DSC, you do all the compiling of settings on the development machine then every server just runs the results.
Instead of compiling multiple mof's you just update the existing configuration script and run it again to create a new .mof There is even some good examples or composite configs that work with vmf 4.0
February 20, 2015 at 4:00 am #22782ParticipantPoints: 0Rank: Member
So is your suggestion that I would implement each "to be created VM" as a partial configuration of my localhost server?
Would this not also end up in me having to use different resource names for each partial configuration? I bet it would complain about that here as well. Would it?
February 20, 2015 at 6:34 am #22784
I'm not sure I understand the problem your running in to.
We are managing configs for close to 3000 machine with only one configuration script. There are plenty of If statements, so only sections of the config that are valid to a specific node run for that node run. The script is stored in Git so every one who needs to has access to it.
February 20, 2015 at 12:53 pm #22796ParticipantPoints: 0Rank: Member
If you haven't downloaded the free DSC Book from PowerShell.org, you should do that first:
There is a multi-node Config sample in the "Including Credentials in a Configuration" section.
May 11, 2015 at 5:33 am #25083ParticipantPoints: 0Rank: Member
Based on the answers to that question and the information in the DSC book (and lots of blog entries) I still can't figure out what do to if I want so store different resources in different mof files for the same node in pull mode.
I have setup a pull server and placed a couple of mof files eeach with a different guid in $env:programfiles\windowspowershell\dscservice\configuration.
Obvisiously its not possible to have more than mof file for each node.
is this by design that there is only one mof file or are there any other options besides partial configuration?
Any thoughts are welcome;)
May 13, 2015 at 7:46 pm #25214
Multiple .MOF files are only supported in WMF 5. Check WMF5 april preview release notes under Partial Configurations
May 15, 2015 at 8:23 am #25282ParticipantPoints: 0Rank: Member
So I assume with WMF 5 you can have several mof files for one specific node on a single pull server that have different prefixes in their names.
This article by Ravikanth gives a good explanation:
May 20, 2015 at 6:15 pm #25491ParticipantPoints: 0Rank: Member
Do you mind if I ask why you would like to have multiple MOF files per node? What are the requirements you are trying to meet?
The topic ‘Managing .mof files. How do you avoid making multiple .mofs for the same node?’ is closed to new replies.