Managing Hostnames vs. GUIDs on a Pull Server

I think there’s a broader point here, too, which is thinking, “how does Microsoft use this?” Not that there way is the ONLY way, but understanding what THEY do can help you understand what the technology does best.

MS doesn’t necessarily depend on DSC to set per-compuetr things like host names and IP addresses. They have other tools, like SCVMM, that easily manage those things. Host names and IP addresses aren’t massively likely to be reconfigured by accident, and they’re not likely to need to change over time, so they don’t take advantage of the main things DSC does. Having multiple computers looking at one MOF is useful for everything else about the computer in situations where computers aren’t unique. E.g., a domain controller isn’t different from other domain controllers - except in its hostname and IP. So you manage the “sameness” with DSC in a way that lets you easily make changes to the sameness, on all nodes at once.

NOT that that’s the only approach; you could EASILY write a config that produced multiple identical MOFs, and that included unique hostnames and computer names. Changing that config and re-running it would produce all the necessary MOFs.

Point is, don’t think that EVERY setting MUST be configured in DSC. It’ll depend a lot on your environment, your goals, and your approach.

I think the problem with allowing multiple MOF’s is the same as the issues with GPO’s the endpoint has to run logic on them to handle conflicts and overrides. This takes multiple round trips to the pull server and the DSC local configuration process would take longer and be more CPU intensive. Try selling that to management. “We can do all these amazing things but it will spike the CPU every 15 minutes” By placing the logic on the back end when creating MOF files all that mess is placed on the build machine, and only when changes are made. Not every single time the machine checks compliance.

I saw a presentation on a video from this site about composite configs and while I would kill to get the a solid example of the real config’s used. It looks to me the files defining the host, site and rolls also included the GUID’s so when they run the build script all that is taken care of. That is what I’m shooting for when I get my system in production.

I’m managing an “enterprise” environment with a lot of package products that place limits on how I can configure and manage these things. I have one major application that has central config files that contain the individual nodes’ IP addresses and java registry settings that incorporate the hostname of the machine.
With my experimentation with DSC I’ve come to the conclusion that for these sorts of environments (where we don’t have a swag of internal developers) we need to pretty much maintain a one to one relationship with the Guids. We also need to be able to dynamically query for hostnames and IP addresses so that we can use these configuration items within the MOF.
Right now I’m trying to develop a pattern where generic or standard configurations are composite resources and the DSC scripts are the execution points for build servers or operations but keeping it simple enough for others to follow.