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.