Today I was planning on talking about the configuration classes that I purposedly skipped in my last post, but I realized it would be better to explain a little bit more about the new configuration system used in IIS 7.

First of all, many of you (as me) will be extremely happy to know that the old "monolithic-centralized-admin only" metabase is dead, we have got rid of it for a much better configuration store. Now, before you feel panic, let me assure you that we haven’t just killed it and forget about the thousands of lines of scripts or custom tools built using the old metabase API’s (such as ABO), for that we have created something we called ABOMapper which will allow all of those applications to keep running transparently, since it will auto-magically translate the old calls to the metabase to actually modify the new configuration system.

So what is this new configuration system? Well for those of you who have been working with ASP.NET for the past years, you will feel right at home and happy to know that we are moving to used the exact same concept as ASP.NET does .config files.

ApplicationHost.config

At the root level we have a file called ApplicationHost.config that lives in the same directory of IIS (typically <windows>\System32\InetSrv\ directory). This is the main configuration file for IIS, this is where we store things like the list of sites, applications, virtual directories, general settings, logging, caching, etc.

This file has two main groups of settings:
  • system.applicationHost: Contains all the settings for the activation service, basically things like the list of application pools, the logging settings, the listeners and the sites. These settings are centralized and can only be defined within applicationHost.config.
  • system.webServer: Contains all the settings for the Web server, such as the list of modules and isapi filters, asp, cgi and others. These settings can be set in applicationHost.config as well as any web.config (provided the Override Mode settings are set to allow)
ApplicationHost.config

Administration.config

This is also a file located in the IIS directory where we store delegation settings for the UI, including the list of modules (think of it as a UI Add-in) available, and other things like administrators.
Administration.config

Web.config

Finally the same old web.config from asp.net has gotten smarter and now you will be able to include server settings along with your asp.net settings.


Why is this important?

Well, as I said at the beginning the old metabase could only be accessed by administrators, so in order for someone to change a settings as simple as the default document for a specific application (say you want to change it to be index.aspx), you would need to be an administrator or call the administrator to do the changes.
With this new distributed configuration system I can now safely modify the web.config within my application and have it my own way without disturbing anyone else. Furthermore, since it lives in my own web.config along with the content of my application I can safely XCopy the whole application and now even the web server settings are ready. No longer the case of going to InetMgr and start setting everything manually or creating a bunch of scripts to do that.

So how does this actually looks like:


In applicationHost.config my Sites section looks as follows:
    <sites>
        <site name="Default Web Site" id="1">
            <application path="/" applicationPool="DefaultAppPool">
                <virtualDirectory path="/" physicalPath="c:\inetpub\wwwroot" />
            </application>
            <bindings>
                <binding protocol="HTTP" bindingInformation="*:80:" />
            </bindings>
         </site>
    </sites>
This basically defines a site that has a root application with a virtual directory that points to \inetpub\wwwroot. This site is listening on any IP address on port 80.
Say I wanted to add a new application and make it listen also in port 8080.
    <sites>
        <site name="Default Web Site" id="1">
            <application path="/" applicationPool="DefaultAppPool">
                <virtualDirectory path="/" physicalPath="c:\inetpub\wwwroot" />
            </application>
            <application path="/MyApp" applicationPool="DefaultAppPool">
                <virtualDirectory path="/" physicalPath="d:\MyApp" />
            </application>
            <bindings>
                <binding protocol="HTTP" bindingInformation="*:80:" />
                <binding protocol="HTTP" bindingInformation="*:8080:" />
            </bindings>
         </site>
    </sites>
Just by adding the previous markup, I can now browse to http://localhost:8080/MyApp
IIS Settings in web.config
More interesting I can now add a file called web.config to c:\MyApp\web.config, and set the content to be:
<configuration>
    <system.webServer>
        <defaultDocument>
            <files>
                <clear />
                <add value="Index.aspx" />
            </files>
        </defaultDocument>
    </system.webServer>
</configuration>
And with this change, my application now will respond using index.aspx whenever /MyApp is requested.
You can extrapolate from this that all the IIS settings for your application including authentication, authorization, asp and cgi settings, the list of modules, custom errors, etc can be configured within your web.config and never have to request changes to administrators again.

Of course this brings the question, isn’t this insecure? The answer is no, by default all the IIS sections (except DefaultDocuments) is locked at the applicationHost.config, meaning no one can change them within their web.config unless explicitly changed by the administrator. The cool thing is that the administrator can change it and customize it per application allowing certain apps to change settings while preventing others from doing it. All this can be done through plain config using Notepad or using the very cool NEW InetMgr (which I will blog about it later)
Finally, the following image shows the hierarchy of config files for each url. config hierarchy

Now that I have shown a high level overview of how configuration works in IIS 7, I will finally blog about the API to actually change this settings programmatically using Managed code and Microsoft.Web.Administration.dll