DSCPullServer needs improved client registration
The DSCPullServer is basically a knock off of Puppet-OpenSource project .. so let's finish some of the critically missing tools
I'm talking mainly about client registration (or lack thereof).
How it's done in puppetOS:
1. Make sure "puppet" CNAME is in DNS
2. Install puppet_agent (no questions asked, just install)
3. On the puppet server, use "puppet cert list" to see pending machines, and "puppet cert sign" to add it.
That's it I'm ready to write manifests and go for it. It issues the cert, tracks the box, basically handles everything.
Compare that to DSC:
1. Create a CName to point out the pull server.
2. Determine a custom model for determining and tracking the GUID for each machine you want to register.
3. Determine ANOTHER custom model for tracking the current certificate to use for encrypting passwords in the mof
4. Create a client configuration to configure the agent that includes manually specifying all variables including hooking into these custom "agent tracking" models
5. Come up with a model for relaying these GUIDs to configurationdata so MOFs get applied to the right box (as the DSC pull server really doesn't care)
See where this is going? While using a GUID/certificate is a good idea in practice, in practicality without some kind of management solution in place it leaves DSC PullServers needlessly complicated. I actually maintain a CSV file currently and all my custom scripts/resources defer to that ... which is silly.
DSC is a framework ... but it needs at least a modicum of tools to make it functional by the MS lovers out there ... don't force us to invest in puppet/chef.
Sebastian N. commented
Yeah, the slow adoption of DSC is directly related to the lack of proper tooling even though it's been around for a while now.