Updating a Node Configuration

This topic contains 3 replies, has 2 voices, and was last updated by Profile photo of Justin King Justin King 9 months, 3 weeks ago.

  • Author
  • #32833
    Profile photo of Ed O'Connor
    Ed O’Connor


    I am in the very early stages of testing DSC. I have set up a Pull server using HTTP and configured a node to pull the configuration. I have been able to get this to work. My question is say I need to change the configuration for a node. Here are the steps I think I must take:

    1)Update the Configuration script and run to generate a new MOF
    2)Generate a new GUID, rename the new MOF with the GUID ID and copy to the congfiguration folder
    3)Generate a new Checksum
    4)Run a script/command for the server to pull the new MOF

    My question is; isn't there a more streamlined way to do this?
    Is there a way to simply update the existing MOF with the updated changes?

    I have been reading a ton of articles on DSC and have not see a clear process on how to update a config that has already been pushed out/pulled.



  • #32872
    Profile photo of Ed O'Connor
    Ed O’Connor

    FYI, last night I tried generated a new MOF with the updated configuration, made a copy of it, then renamed it to the GUID.mof currently being used for that node, copied it to the *program files\windowspowershell\dscservice\configuration folder and nothing happened. No changes were made.

  • #32926
    Profile photo of Ed O'Connor
    Ed O’Connor

    Can someone confirm if there is a easier/more streamlined method to update a node configuration file/mof and ensure it gets deployed?


  • #33450
    Profile photo of Justin King
    Justin King

    Hey Ed, sorry about the quiet here, but I posted a different question and noticed this so I thought I'd chime in.

    Couple things:

    There is no reason to generate a new GUID for a Node unless there's a conflict somewhere (2 nodes, 1 mof ... I'm afraid to google that without safe search). If the mof is still valid and you're just doing something like updating an LCM setting or which URL it checks, you can simply re-use the same GUID in your push. This way you're not needlessly generating new MOF files for no reason.

    Also, joke aside: there's no reason multiple servers couldn't look at the same MOF ... just doesn't seem like a very practical thing to do.

    Now as for configuration changes, unless you're talking about the LCM (aka the local DSC Agent) you generally never want tot change the GUID you assigned to that box. That's basically it's unique identifier so that in a world of changing configs and code we have something static to reference. All you want to do is generate your new mof against the new configuration using the same node name, generate a checksum, and place it in the configuration folder _overwriting_ the old configuration.

    On the next poll, the agent should find it.

    The pains you're running into is basically the lack of management tools around DSC as it's a framework rather than a full management stack. If you're interested I just happened to start my only little pet-project of writing modules/functions to make this easier, and literally posted a blog post on it with link to my github just yesterday.

    It's not 100% polished, but I think there might be enough there to help you through the basics.

    Short version: it tracts the GUID/thumbprint of various nodes in a CSV file so it's easier to write configurations and configuration data in "english" and let the modules manage the GUID portions. it's very much in it's infancy, but hopefully valuable.

You must be logged in to reply to this topic.