WMI7: A primer...

WMI stands for Windows Management Instrumentation.  I'm going to skip the whole introduction of what WMI is as there are numerous articles available online that will do a much better job at explaining it.  These articles are easily discoverable simply by type 'WMI' into your favorite search engine.  Microsoft.com has a lot of useful information that digs deep into the guts of WMI and is very useful for people wanting to write their own providers.  For people that just want a general overview, I found that Wikipedia is sufficient.

Why a new WMI provider for IIS7?

A WMI provider was shipped for IIS 6.0 and it will still be supported for IIS7, meaning that your existing scripts to manage your IIS 6.0 servers will still mostly work after switching to IIS7.  I say mostly because IIS 6.0 used a metabase to store most of its configuration settings while IIS7 has switched to a new Xml-based configuration system that allows a deeper integration with Asp.Net.  Due to this change, there are certain features which are no longer applicable.  I'll discuss the specific features in a later blog.

The WMI7 Object Model

One of the goals of the new WMI provider for IIS7 was to provide a simplified object model to make it easier for administrators to write scripts to managing their web server.  Though the total number of classes in the provider makes it seem complex, they really break down into two simple groups:

  1. A set of classes for managing IIS intrinsic objects such as Sites, Applications, ApplicationPools, etc.
  2. A set of classes for managing configuration sections of various features of IIS, Asp.Net and the .Net Framework.

The majority of the classes in the namespace belong to the second group, 'ConfigurationSections'.  A ConfigurationSection class represents an xmlNode in the configuration file (ie applicationhost.config, machine.config or web.config).  This xmlNode may contain many elements and, because most elements are unique, a separate class is required to represent each element of a ConfigurationSection.  Thus, a configurationSection will be comprised of one or more classes.  Multiply that by the 50+ sections that span IIS7 and/or the .Net Framework, and you can easily see why there are so many classes in the WMI provider for IIS7.

However, don't let the large number of classes intimidate you.  Most people will probably only ever need to use roughly 5 classes or less on a regular basis...

Intrinsic Objects

The basis of this blog will be to list the IIS7 intrinsic objects necessary to manage your server, or the first group of classes from above.  The top-level classes in the WMI Provider for IIS7 are 'Object' and its derived 'abstract' class 'ConfiguredObject'.  The 'Object' class is simply a generic base class with no default properties or methods.  'ConfiguredObject', on the other hand, derives from 'Object' and provides some generic methods for accessing the ConfigurationSections applicable to that particular 'ConfiguredObject'.  The list of types which derive from 'Object' and 'ConfiguredObject' are as follows:

  • Object
    1. AppDomain
    2. ApplicationPool
    3. ConfiguredObject    // This is an another abstract class
    4. HttpRequest
    5. Server
    6. SSLBinding
    7. WorkerProcess 
  • ConfiguredObject
    1. Site
    2. Application
    3. VirtualDirectory
  • ConfigurationSection
    1. [Too many to list here...]


The ConfiguredObject's are probably the classes most people will be interested in and the ones more commonly used.  These are the objects one would use to create a website hierarchy, such as a Site, Application and Virtual Directory.  The 'ApplicationPool' and 'Server' classes under Object may also be commonly used and all 5 of these objects are represent settings which physically live in ApplicationHost.config.  This means that you have the option of manually editing the values of these classes directly via ApplicationHost.config, though it not recommended.

The AppDomain, HttpRequest and WorkerProcess classes represent the core objects in IIS and will only exist for the lifespan of that object.  For example, an HttpRequest represent a currently executing request being processed by IIS.  While IIS is handling the request, there will exist an HttpRequest object in WMI.  However, after the request has finished processing, that HttpRequest object will no longer exist.

SSLBinding is a special class which represents Server certificates.  I'll have a separate post specifically for this class and Server certificates on IIS in general.

My next post will discuss the Application Hierarchy and the relationships between a Site, an Application and a VirtualDirectory.  See you soon...

No Comments