Friday, 27 July 2007

Discovering IIS7 Schema

One of the major changes introduced with IIS7 is the removal of the metabase.  This probably comes as a great relief to many of the admins and developers that struggled with coordinating configuration across multiple machines.  Instead of the metabase, IIS7 has chosen to schematize all the web server settings and host them centrally in a new XML file called applicationHost.config located at '%windir%\system32\inetsrv\config'.

The schema itself can be found in the 'schema' folder right below the 'config' directory.  This new centralized configuration file holds all the global default values for IIS7 as well as defines what sites, applications, virtual directories, app pools, etc. are on the server.

Let's take a look just a couple items I found in my applicationHost.config:

<applicationPools>
    <add name="DefaultAppPool" />
    <add name="Classic .NET AppPool" managedPipelineMode="Classic" />
    <applicationPoolDefaults>
        <processModel identityType="NetworkService" />
    </applicationPoolDefaults>
</applicationPools>

Here is the configuration of the application pools on my IIS7 server.  Let's see what happens if we just edit this directly and add a new application pool.

AppPool

If we open our new IIS Manager (Start > Run > inetmgr), we can see that this is all there is to it.

AppPoolsInManager

Further poking around will yield lists of sites, applications, and virtual directories as well - all described neatly in XML format.  Now, how did the IIS team put all this together?  Were they using their own black box implementation?  If we inspect the schema, we will find there is no magic here and the IIS team is leveraging its own schema system for IIS itself.  Opening the "IIS_Schema.xml" file found in the 'schema' directory shows us the exact settings available for 'applicationPools'.

  <sectionSchema name="system.applicationHost/applicationPools">
    <collection addElement="add" defaultElement="applicationPoolDefaults">
      <attribute name="name" type="string" required="true" isUniqueKey="true" validationType="applicationPoolName" />
      <attribute name="queueLength" type="uint" defaultValue="1000" validationType="integerRange" validationParameter="10,65535"/>
      <attribute name="autoStart" type="bool" defaultValue="true" />
      <attribute name="enable32BitAppOnWin64" type="bool" defaultValue="false" />
      <attribute name="managedRuntimeVersion" type="string" defaultValue="v2.0" />
      <attribute name="managedPipelineMode" type="enum" defaultValue="Integrated">
        <enum name="Integrated" value="0" />
        <enum name="Classic" value="1" />
      </attribute>
      <attribute name="passAnonymousToken" type="bool" defaultValue="true" />
      <element name="processModel">
        <attribute name="identityType" type="enum" defaultValue="NetworkService">
          <enum name="LocalSystem" value="0"/>
          <enum name="LocalService" value="1"/>
          <enum name="NetworkService" value="2"/>
          <enum name="SpecificUser" value="3"/>
        </attribute>
            <...SNIP...>
  </sectionSchema>

As we can see here, there are some basic typed attributes that describe our application pool.  They have things like types, default values, and even enumerations with possible values (managedPipelineMode is one such).  There really is no magic here.  Someone could very easily write a program that inspected the schema of IIS7 fully and presented all possible options just by inspecting this schema.

What should immediately come to mind as a developer is, "how can I leverage this system"?  If there is one word that describes IIS7, it is "Extensible".  In my next post, I will show you how to leverage this powerful schema system that IIS7 introduces for your own application purposes without code.