In the run up to Windows 2012 R2 I’ve not been paying as close attention as I would normally, meaning that I seem to have missed out on an interesting new feature in powershell 4 called Desired State Configuration (or DSC).
It ships with Windows 8.1 and Server 2012 R2 and allows you to:
- Install and remove server roles and features
- Manage the registry, files, directories and environment variables
- Start, stop, and manage processes and services
- Manage local groups and user accounts
- Install and manage packages (primarily msi packaged applications)
- Run PowerShell scripts
- Discover the configuration state on a given node
- Maintain the configuration state
- Operate in push, pull and manual mode
If you’ve ever used Puppet the syntax will look familiar, however as far as I’m aware theres currently no ability (other than via custom modules) to include configurations from other files which could result in large blocks.
Additionally, and importantly, DSC configuration blocks need to be compiled to a “MOF” file before they can be applied. Having looked at a MOF file, whilst readable I’d suggest that the configurations are stored under version control not the MOF files.
Whilst I’m sure there is a good reason this it adds an extra step between version control and deployment that may result in less experienced admins not bothering with version control, and frequently rewriting their DSC configurations. I would have prefered to see a syntax checker and if compiling really is necessary having it compiled silently before being applied just to skip this step.
What about System Center and Group Policy?
System Center covers a multitude of products, most of which won’t be impacted by DSC. As for the rest I’m not clairvoyant, however I can only imagine some components of System Center realigning and simply getting better, not going away.
DSC simply doesn’t fulfill all of the roles that Group Policy does, so I’d expect GPOs are here to stay.
What about Puppet and Chef?
Both of these tools have started making roads towards Windows CM and it would be a shame if they stopped. It appears that at least Opscode are adding compatibility to Chef and I hope that Puppetlabs follow this trend as well. As much as I like the addage of the Best Tool For The Job™ sometimes One Tool To Rule Them All™ needs to win for political or training reasons.
I’m interested to see how DSC can be leveraged in an attack. Other than the obvious improperly secured MOF files scenario I’m yet to look into push or pull mode and if/how DSCs are signed and transported, etc. and how they can be manipulated or how data can be retreived. For example can a similar/the same method that can be used to retreive credentials from a GPO preference also be used to retreive them from DSC?
Without looking I don’t know, but it’s the start of a series of questions you should look at before deploying.
Should you use it?
As always, evaluate what you already use and see if powershell DSC is what you’re looking for. The powershell 4 requirement may be a problem for many.
However, if the question is should I be using some form of configuration management, the answer is yes. It’s not only enterprises, MSPs, or cloud scale start ups that can benefit from configuration management. The thing that you need is for all of your operations staff to have buy-in. As soon as little bits start getting changed manually, without being added to your configuration, the less useful your chosen CM system will be.