Decision Maker
Microsoft's Ever Evolving Configuration Management
Microsoft has followed a long and winding road with configuration management, and the company is taking some interesting new steps on the path.
Configuration management at Microsoft started with the registry-based system policies introduced in Windows 95. These policies -- which the client would download along with its logon script from a predetermined file share -- essentially just hacked (permanently) the registry to achieve various settings.
Group Policy Objects (GPOs) were a direct evolution of those system policies. GPOs basically establish a second parallel registry, and client-side software is designed to obey the "GPO side" of the registry when settings exist there, ignoring the usual, "permanent" portion of the registry.
In parallel, System Center Configuration Manager has its own configuration-compliance functionality. It's mainly registry-based like the old system policies, although it can also enforce the existence of files, and it can run scripts for custom configurations. In addition to refreshing more frequently (you can control the refresh interval), Configuration Manager provides feedback, letting you audit configurations and force settings back to the desired state through remediation. The downside to the Configuration Manager functionality is it's pretty basic. Anything you can't audit or remediate through the registry will usually require a custom script.
API Needed
What's needed is some kind of agreed-upon API for configuration management. The OS, along with installed applications, would deliver this API so that configuration-management tools could use it. The OS might offer "modules" for networking, the registry, installed roles, and so on, with each module offering a way to "audit" a given configuration and a way to "enforce" the configuration. This API would provide a standard for interacting between the OS (and other software) and configuration-management tools.
That standard, which Microsoft announced at its TechEd conference in June, is Windows PowerShell 4.0 and a new feature called Desired State Configuration (DSC). This is a declarative way of specifying a desired configuration. In other words, while you're kind of writing a script, you're not really programming, per se. You're writing a set of static instructions that, for example, state your desire for Ethernet cards to use Dynamic Host Configuration Protocol (DHCP), for the Web Server role to be installed, and for the Telnet Server role to not be installed. Windows PowerShell executes those instructions, interacting with underlying components to implement your instructions. Anyone can write those underlying DSC components, meaning the "reach" of Windows PowerShell will expand and grow over time -- just as it has with the normal cmdlets you use for administration. An underlying Exchange Server DSC component, for example, would open up Exchange to configuration management.
DSC's Flexibility
The upside of DSC is it makes changing your mind easy. Decide you want Remoting enabled on all machines? You don't reconfigure them yourself -- you just change your centralized DSC "script." Windows PowerShell will realize one of your desired configurations (Remoting) isn't installed, and will ensure it gets installed. Feedback mechanisms might let you generate reports on your machine compliance -- something that'll likely happen through a tool like Configuration Manager.
This new Windows PowerShell functionality is an API. You might never use it directly; instead, it might get used by something like Configuration Manager under the hood. Or you might use it directly. That's the beauty of where Windows PowerShell sits in the stack -- with the right tools, it can provide the power without you needing to touch it directly, but you always have the option of going behind the scenes and tweaking it yourself.
DSC further emphasizes the hugely important role Windows PowerShell is going to play in your organization's future. IT administrators must become proficient in Windows PowerShell -- there's simply no longer an option to ignore it. IT decision makers should be closely monitoring their Windows PowerShell skill set, and ensuring that it grows and gets used. Microsoft is clearly not done with Windows PowerShell, and Redmond is continuing to make it the primary surface for administration. DSC is the latest step, but I seriously doubt it's the last.
About the Author
Don Jones is a multiple-year recipient of Microsoft’s MVP Award, and is an Author Evangelist for video training company Pluralsight. He’s the President of PowerShell.org, and specializes in the Microsoft business technology platform. Follow Don on Twitter at @ConcentratedDon.