I think we’re probably a little early on for real practices to have emerged. I think, in the long view, we need to view DSC as a platform technology – not as tooling. We do need tooling around it. I can imagine Microsoft, for example, making this a part of SCCM: it keeps track of resources that you target to collections, and handles building composite resources from them, setting the LCM GUID, and so on.
So what you’re asking about is, what kind of DIY tooling are folks using? Right now, probably little to none.
I’m not sure AD is the right answer for everyone; a key part of DSC is that it doesn’t depend on AD. Now, in an environment where every node is in AD – sure, you could use an attribute there to track the machine’s DSC GUID. That’d work.
I certainly don’t think a spreadsheet is the way to go, but a SQL Server database would be a good solution. You could easily build a script that queried the database, built the necessary LCM MOFs, and pushed those to computers to configure them for pull.
I think the idea of generic configuration-resources, that get pulled into composite resources that also contain node- or role-specific stuff, will probably emerge as the “way to go.” That said, we still need some tooling to help us view the resultant configuration, help detect conflicts, and so on. But right now I’m only aware elf a couple of organizations who are using DSC in production, and a couple more that are actively starting to build for it – we just don’t have a lot of experience to draw on, yet.
But I think we’re going to have to see folks trying all of these, and finding what works and what doesn’t, to see what actually works.
I also think that, right now, DSC is good for limited deployments in an organization, so that you can start to get a feel for it, and not make a heavy initial investment in something that we know is going to be enhanced going forward. Start slow, with basic servers (like infrastructure servers), and get a feel for it. Find out what works and what doesn’t.