I've lately been fooling around with the Desired State Configuration capabilities in Windows. Having done a bit of deployment to servers, as well as developer machine maintenence, I can say I'm pretty tired of doing one-off scripts for unicorn problems.
Enter DSC... It's the golden solution for all your problems (spoiler alert, it's not).
The thing is, it's more of a "machine state" framework than than a package of capabilities, and even viewed as such, it has some quirks. That being said; what makes DSC good is that it doesn't do too much out of the package. It turns out that a framework for this kind of problems is pretty much exactly what people have been waiting for, and by clearly separating the "what" from "how", it's actually really easy to dive into DSC resource development.
My goal of this post is simply to ramble down my experience during my first couple of weeks trying to do actual work with DSC.
Someone doesn't want you to use a pull server
Ok, if you're not into the lingo of DSC, a pull server is a way to constantly check a central source for new configurations. The alternative is a push model, where you simply apply a configuration directly to a machine.
I'll leave it to other guys to explain how you get a pull server up, but it's actually not a big deal. What kinda is, is how you maintain your configurations.
I find it a bit odd that you get a Windows feature out of the box to serve configurations, but no automated way to turn a .ps1-script from code to pull-server-food.
What the back of the box tells you to do is: "put configurations you want to serve here". What this actually means is:
- Run your configuration section.
- Take the output, a .mof file, and put it where your server can find it
- Suddenly remember that this file has to have a Guid as filename.
- Create a checksum file for your .mof file.
- Provide all the modules used by your configuration, zipped, where your server can find it (yeah, this doesn't really seem to be a thing you'd do again and again, so I made this little thing).
- Suddenly remember that your module also has to have a checksum file
The the thing is, once you've automated the steps above, publishing new configurations is a dream. It's just.. You have to do it yourself.
Someone doesn't want you to make DSC modules
Ok, this is a lie. Someone has made this, and when I found out that the xDismFeature-module lacked functionality important to me, both Microsoft and the community really has made it easy to contribute.
I'll have to admit that I was pleasantly surprised that there's virtually no skeleton code, and that the layout of a module is pretty much two simple function (plus one no one seems to know why you need to write). The thing is, if you want to test your resource, like actually use it, you have to put stuff in global folders. Yes, there's probably ways to hack past this, but with DSC having the limited functionality it has today, this should be easy.
Yes I know, I'm complaining that it's a hassle, but it's still so low effort that when finding out that I wanted to do some unsupported task, it took pretty much just a few hours to create modules that could modify the /etc/services file and add certificates to the certificate store.
It actually is pretty awesome though
All in all, I'm pretty happy with the whole thing, and I'm really psyced to see what will happen going forward.
Even with the quirks of today, I've managed to get a system up and running in a short two weeks of hacking (while still working on other projects) that let's me:
- Take a fresh server, run a bootstrapping script, and have a pull server up and running in literally minutes, without external dependecies.
- Have a versioned desired state configuration in pure PowerShell, also without external depencies.
- Make changes to my configuration, have it deployed to my pull server.
- Have modules used in the script deployed to the pull clients
- Monitor pull clients for compliance state
So yeah, it's hacky, and it's a bedwetting puppy, but DSC is actullay pretty darn awesome.