The new Configuration System in IIS 7


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

Comments (19)

  1. Прошли старые добрые деньки. Реестр закапывают в землю, бинарные форматы закапыв

  2. Can all these various .config files reside on a UNC share, and be shared by multiple instances of IIS running on different nodes?

  3. CarlosAg says:

    Yes, you can have all your content along with the web.config files living in a UNC share that is shared by all the servers in your web farm and this way changing a single file will alter the settings of all servers.

  4. What about the ApplicationHost.config and Administration.config?

  5. CarlosAg says:

    There is only one ApplicationHost.config and currently has to live within InetSrv directory (though we are looking into options here).

    Administration.config is similar to web.config’s, only that the root "administration.config" has to live in InetSrv, but you can also use it in a distributed way, having administration.config’s with your content in a UNC (this is used when a site delegates tasks from Site to its Applications).

  6. I’d certainly like to open up the discussion on the "options" you mention. I’ve posted my concerns in other comments, as well as on David Wang’s blog.

  7. Karun says:

    You have written "(this is used when a site delegates tasks from Site to its Applications)", when and how site delegates tasks from Site to its Applications. Any Article on it??

  8. FrankC says:

    the path of the applicationHost.config is no longer in  <windows>System32InetSrv but rather  <windows>System32InetSrvconfig with the RC build

  9. venkat says:

    I modified the Applicationconfig in D:WindowsSystem32inetsrv directory to enable caching,but still as I continue page refresh I am unable to see any Kernel cache hits happening.Please help out.

  10. Web Development – ASP.NET / ASP.NET AJAX Community Sites/ Learning Centers · http://www.asp.net · http://www.asp.net/ajax

  11. More than a year ago I wrote about Microsoft.Web.Administration.dll and how it was a new API we were

  12. More than a year ago I wrote about Microsoft.Web.Administration.dll and how it was a new API we were

  13. lol says:

    <a href= http://index1.chasehunt.com >winter olympics of 1972</a>

  14. jagadish says:

    Hi,

    We want to provide a way for our website users to use different themes, so each individual user can put their own them in their pages. For this I want to use IIS redirection using IP Address or DNS names to

    Track individual users page themes. Can you please help on  how to know user setting using IP Address and IIS.?

    Thanks

    C.Jagadish

  15. diego says:

    When you added a second application in port 8080

    <binding protocol="HTTP" bindingInformation="*:8080:" />

    How you distinguish the 8080 for MyApp and 80 for the default website? Isn’t there a setting missing or both ports work with both apps?

    Thanks you!

  16. rupesh chowdary says:

    Luckily IIS makes a backup each time you make a change. All those versions are stored in the folder C:inetpubhistory. All you have to do is to copy a former applicationHost.config file into the C:WindowsSystem32inetsrvconfig working directory.

  17. rupesh chowdary says:

    Luckily IIS makes a backup each time you make a change. All those versions are stored in the folder C:inetpubhistory. All you have to do is to copy a former applicationHost.config file into the C:WindowsSystem32inetsrvconfig working directory.

  18. xuanyi says:

    The applicationHost.config file for 64bit IIS is located under %WINDIR%SysWOW64inetsrvConfig. See xuanyili.com/…/configure-gzip-http-compression-on-iis-7