Configuration Management is Hard – Responses - Server Fault Blog

I’ve been getting some great response to my previous post, and I wanted to make a few things very clear.


What I’m not doing –

  1. I’m not advocating or dismissing any particular configuration management tool.
  2. I’m not discounting the tough work done by companies and community projects that have created abstractions on managing disparate systems.

What I am attempting to do –

  1. Highlight the challenges of cross-platform management and application management.
  2. Show one of the efforts in providing a standards based management abstraction.
  3. Offer my thoughts on why I see value in that direction and what challenges I see.

Managing the Operating System vs. Managing Applications

There is definitely some confusion around using CIM to manage the OS vs managing applications.

  1. CIM Classes can be used to model applications as well as OS resources.
  2. Most of the “applications” that are packaged as roles and features in Windows Server expose a CIM management API.
  3. WMI is an implementation of the CIM standard and starting with Server 2012 and the Windows Management Framework V3, CIM is exposed via WSMAN.

Hyper-V, File Shares, Clustering, IIS, and others all offer CIM based management models.  Other applications can expose a CIM management model as well.  As long as the host CIM server (WMI on Windows and OMI or OpenPegasus or ???? on Linux based Operating Systems) is operational, applications can also offer their configuration and status via that channel by creating a provider.  To do this on Windows, there is some documentation to get you started:

To do this with OMI, you can find some documentation and source at

The Current State – Reprise

But, but, tool {fill in your favorite tooling here} already does THAT!!!

There are a number of tools that valiantly strive to provide cross-platform management.  I mentioned several of them in my last post, but there are a number of others.

Yep, it does.  Until…

things change.  The challenge these tools have is that they have had to implement their abstractions against very different implementations.  The problem there is that these things are not stagnant.  The management APIs can change over time and since there is not a standard description of the API or underlying configuration.

If CIM were the standard API exposing the configuration, the underlying implementation details can change, but configuration management and monitoring tooling don’t have to care about that.  The tool vendors and community projects can focus on other value adds for their particular tooling, rather than being forced to continually update the basics.

The Next Steps

We are still in the early stages of the push for CIM and WSMAN.  We’ll have to see how adoption picks up.  The continuing work around OMI holds promise, but it needs a deployment or integration story for various Linux distros and more public providers for managing components of the Linux OS and attendant applications.

There have been some interesting announcements at TechEd in relation to Windows Server 2012 R2 (watch this video and pay attention around 49 minutes in).  I’m going to talk more about this feature and it’s implications and my plans with it in the very near future.