Manageability Extensions for Enterprise Library January 2006


If it’s true that men are from Mars and women from Venus, then it would probably be fair to say that developers and infrastructure/operations people are from different galaxies. With few exceptions, these groups of people view the world from entirely opposing directions, follow different processes, speak different languages, and use different tools and technologies. Which is all fine, until these galaxies collide with the release of a new application. Far too often, the application was not built to fit in with the infrastructure, tools or processes that rule the datacenter – and the result is at best an application which is inefficient to mamange, and at worst an application that cannot be deployed.


While I really do believe this problem has far more to do with people and culture than technology, the fact that many key operations technologies are unknown or inaccessible to developers does compound the problem. How many .NET developers do you know who are able to implement technologies such as WMI, Group Policy, ETW, MMC or even CAS? Probably not many – and to be fair to all you developers, many of these are not even properly exposed through managed APIs.


I’d love to be able to tell you that we’ve solved the whole problem, but alas it’s going to take a long and concerted effort from all of us (yes, you too :-). However, we’re hoping that the release of the Manageability Extensions for Enterprise Library January 2006 will be a small but valuable step in the right direction.


The idea behind these extensions is to make it very easy for configuration data in Enterprise Library applications to be exposed to WMI and Group Policy, without it being necessary for the developers to be experts in these technologies. The heart of these extensions is a new Configuration Source class called the ManageableConfigurationSource. As far as the developer and even the application is concerned, this configuration source seems to act almost identically to the standard FileConfigurationSource – that is, it will read the configuration data from a .config file and return the information as ConfigurationSections to the blocks and the application.


However there is something sneaky going on beneath the covers. The ManageableConfigurationSource is spying on the configuration data and reporting it via WMI, so it can be queried using tools such as Microsoft Operation Manager. Currently the WMI APIs in the .NET Framework are read-only, so it isn’t currently possible to manipulate the configuration data using WMI – however this capability should be supported in a future release of the platform. However it is currently possible to use Group Policy to manipulate the configuration information. If an administrator has configured the application for group policy, they can push configuration changes to machines and users via Active Directory. The ManageableConfigurationSource will query the registry for the group policy changes and merge this into the configuration information before handing it off to the application. And if you’re using the built-in Enterprise Library blocks, all of this happens without developers needing to write any addional code!


We’d love you to try out these extensions and use them to build more manageable .NET applications. We plan on rolling these extensions into the next release of Enterprise Library, so it would be great to hear any feedback on the extensions (good or bad) to help us ensure the next release is even better. And these extensions are only a part of our wider effort around guidance for building more manageable applications – so let us know what else you’d like to see.

Comments (6)
  1. Elizabeth says:

    Hello Tom Hollander.  Interesting blog.

  2. Alois Kraus says:

    Hi Tom,

    I am not sure if these things will be welcome in low trust scenarios. At least WMI will need Admin privileges to work properly. The idea to deploy configuration via group policies is interesting. I will look deeper into this but here does the trouble begin. At work I cannot alter my forest becaus in a big enterprise domain (we have about 30 000 users inside one domain) only very few have administrative access to these things. As far as I know I need an Active Directory installation with full access to it to try it out. This could become difficult at home (I do not intend to install AD at home just for 10 minutes to try it out) and in my office.

  3. Ian says:

    Hi Tom,

    This article grabbed my attention. I can see great value in being able to push configuration changes to machines and access settings via WMI. However, I’m trying to understand why Group Policy (excuse my limited knowledge) and what configuration information we are talking about here.

    Are we talking about storing application configuration, such as would be found in the app.config file in Group Policy? Is group Policy a good fit for this kind of configuration and what is it providing above say storing the configuration directly in AD or ADAM and pushing out the changes from there?

  4. OK, I know the sun has already set on February in some parts of the world, but over here it’s still well

  5. RSS It All says:

    OK, I know the sun has already set on February in some parts of the world, but over here it's still

  6. Zamiast wstępu Jakiś czas temu Tom Hollander napisał na swoim blogu zdanie, z którym ciężko się nie zgodzić:

Comments are closed.

Skip to main content