This topic contains 3 replies, has 2 voices, and was last updated by
December 10, 2015 at 11:12 am #32833
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.
December 11, 2015 at 6:26 am #32872
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.
December 14, 2015 at 10:10 am #32926
Can someone confirm if there is a easier/more streamlined method to update a node configuration file/mof and ensure it gets deployed?
January 4, 2016 at 2:10 pm #33450ParticipantTopics: 29Replies: 125Points: 0Rank: Member
Hey Ed, sorry about the quiet here, but I posted a different question and noticed this so I thought I'd chime in.
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.
The topic ‘Updating a Node Configuration’ is closed to new replies.