Managing .mof files. How do you avoid making multiple .mofs for the same node?

Tagged: 

This topic contains 9 replies, has 7 voices, and was last updated by Profile photo of Michael Greene Michael Greene 1 year, 6 months ago.

  • Author
    Posts
  • #22747
    Profile photo of Shawn Magill
    Shawn Magill
    Participant

    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?

  • #22753
    Profile photo of Robert Kozak
    Robert Kozak
    Participant

    Check out Partial DSC configurations that is coming in Powershell 5.

    [url]http://www.powershellmagazine.com/2014/10/02/partial-dsc-configurations-in-windows-management-framework-wmf-5-0/[/url]

  • #22763
    Profile photo of David Jones
    David Jones
    Participant

    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

  • #22782
    Profile photo of Thomas Mehl
    Thomas Mehl
    Participant

    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?

  • #22784
    Profile photo of David Jones
    David Jones
    Participant

    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.

  • #22796
    Profile photo of David Stiff
    David Stiff
    Participant

    If you haven't downloaded the free DSC Book from PowerShell.org, you should do that first:

    https://www.penflip.com/powershellorg/the-dsc-book

    There is a multi-node Config sample in the "Including Credentials in a Configuration" section.

    Take care,
    Dave

  • #25083
    Profile photo of Peter Monadjemi
    Peter Monadjemi
    Participant

    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;)

    Regards,
    Peter

  • #25214
    Profile photo of David Jones
    David Jones
    Participant

    Multiple .MOF files are only supported in WMF 5. Check WMF5 april preview release notes under Partial Configurations
    http://www.microsoft.com/en-us/download/details.aspx?id=46889

  • #25282
    Profile photo of Peter Monadjemi
    Peter Monadjemi
    Participant

    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:

    Regards
    Peter

  • #25491
    Profile photo of Michael Greene
    Michael Greene
    Participant

    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?

You must be logged in to reply to this topic.