Udostępnij za pośrednictwem

The new Configuration System in IIS 7

  • Artykuł

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 https://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

  • Anonymous
    April 25, 2006
    Прошли старые добрые деньки. Реестр закапывают в землю, бинарные форматы закапыв
  • Anonymous
    April 25, 2006
    Can all these various .config files reside on a UNC share, and be shared by multiple instances of IIS running on different nodes?
  • Anonymous
    April 25, 2006
    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.
  • Anonymous
    April 25, 2006
    What about the ApplicationHost.config and Administration.config?
  • Anonymous
    April 26, 2006
    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).
  • Anonymous
    April 26, 2006
    The comment has been removed
  • Anonymous
    May 25, 2006
    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??
  • Anonymous
    October 26, 2006
    the path of the applicationHost.config is no longer in  <windows>System32InetSrv but rather  <windows>System32InetSrvconfig with the RC build
  • Anonymous
    March 19, 2007
    <a href="http://dvdfilms.jedo.info/antonela-download-filme.html">antonela download filme</a>
  • Anonymous
    May 17, 2007
    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.
  • Anonymous
    September 17, 2007
    Web Development – ASP.NET / ASP.NET AJAX Community Sites/ Learning Centers · www.asp.net · www.asp.net/ajax
  • Anonymous
    September 28, 2007
    More than a year ago I wrote about Microsoft.Web.Administration.dll and how it was a new API we were
  • Anonymous
    October 24, 2007
    More than a year ago I wrote about Microsoft.Web.Administration.dll and how it was a new API we were
  • Anonymous
    February 06, 2008
    <a href= http://index1.chasehunt.com >winter olympics of 1972</a>
  • Anonymous
    April 10, 2008
    The comment has been removed
  • Anonymous
    January 30, 2009
    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!
  • Anonymous
    December 18, 2010
    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.
  • Anonymous
    December 18, 2010
    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.
  • Anonymous
    August 25, 2011
    The applicationHost.config file for 64bit IIS is located under %WINDIR%SysWOW64inetsrvConfig. See xuanyili.com/.../configure-gzip-http-compression-on-iis-7
  • Anonymous
    June 02, 2016
    HiI'm using the Microsoft.Web.Administration API to install an application in IIS 7. I would like to set the authentication mode to Windows from the setup. However, I run into the "This configuration section cannot be used at this path" problem. Is there a way around this, besides manually unlocking in IIS?
    • Anonymous
      June 06, 2016
      The only option is to either unlock the section if you want to set it in the web.config, or specifically edit ApplicationHost.config and use a locationPath for that. Basically call "serverManager.GetApplicationHostConfig(); and then specify a locationPath when calling GetSection