Anatomy of an IIS7 configuration path

If you have worked with IIS6 and previous versions of IIS, you are most likely familiar with the IIS metabase paths.  You know, the ones that look like LM/W3SVC/1/ROOT.  These metabase paths serve as a mechanism to identify a part of the IIS website hierarchy, or a url therein, for the purposes of read/writing their configuration settings.  For example, the server uses these paths at runtime to retrieve the settings for a particular site, virtual directory, or url in your website, and you use them to manage those settings for your site/virtual directory/url using tools like adsutil.vbs.

As you know, IIS7 repaces the metabase with a whole new configuration system, based on a distributed hierarchy of XML configuration files also used by the .NET Framework/ASP.NET.  This confguration system is fundamentally different from the metabase, and so it should come as no suprise that the way configuration paths work is also different. 

The concept of configuration paths is fundamental to managing and operating an IIS server, so I wanted to spend some time explaining it in hope that this can help everyone enjoy their IIS7 server just a little bit more :)  If you have come here wondering exactly what the hell is MACHINE/WEBROOT/APPHOST, you have come to the right place.

If you want to skip the background and go straight to how IIS7 configuration paths work, click here.

IIS6 Metabase paths – a blast from the past

First, lets take a quick detour and look at how metabase paths worked in previous versions of IIS.  The metabase was a centralized configuration file that contained a configuration tree, with each node of the tree containing a list of configuraton properties/values appropriate for it.  The metabase path uniquely identified a node in that tree, so you had something like this:

LM (root node)
    AppPools (application pool node)
        DefaultAppPool (default application pool)
    W3SVC (website node)
        1 (website id = 1)
            ROOT (website root)
                vdir1 (virtual directory path = /vdir1)


The metabase hierarchy contained nodes for both the url hierarchy (the W3SVC node) and non-url objects such as Application Pools, FTP service, etc.  A metabase path for a url could then be constructed as LM/W3SVC/<SITEID>/ROOT/<VIRTUALPATH>, where <SITEID> identifies the site and <VIRTUALPATH> specifies the virtual path of the url.  This path can then be used to read the settings associated with it from the metabase using the ABO APIs, ADSI, WMI, and various scripts and tools including adsutil.vbs, iisweb.vbs, iisdir.vbs, aspnet_regiis, etc.

IIS7 Configuration paths

In IIS7, the configuration system stores configuration in a hierarchy of files, starting with 3 root configuration files, and descending into distributed web.config configuration files that can be present in any directory of your website to affect the configuration for the url namespace to which the directory corresponds.  This hierarchy contains the following:

Framework<version>CONFIGmachine.config (the .NET framework machine.config file, where most .NET sections are declared)
   Framework<version>CONFIGweb.config (the .NET framework root web.config file, where most ASP.NET sections are declared)
       %windir%system32inetsrvapplicationHost.config (the IIS7 global web server configuration file, where all IIS7 configuration sections are declared)
            delegated web.config files (the distributed configuration files that can be present in any virtual directory of your site or its subdirectory)

In this system, a configuration path has the following syntax:


Where MACHINE, WEBROOT, and APPHOST correspond to the above configuration files, <SiteName> identifies the site, and <VirtualPath> identifies the virtual path.  Note that the site is no longer identified by id, as before, and instead the site name is used (in IIS7, site name is the unique identifier of a site, unlike the ServerComment in IIS6 which was not unique).

The concept of configuration path in the new world has a dual meaning – it can identify both a configuration file in the distributed file hierarchy, AND identify the configuration path (or url) to which configuration settings are applied. 

These concepts are related but not identical, which can be fairly confusing at first.  By default, configuration settings set at a particular file in the hierarchy that has path X are applicable to the configuration path X.  This means that configuration set in applicationHost.config, identified by the configuration path MACHINE/WEBROOT/APPHOST, is applicable to the configuration path MACHINE/WEBROOT/APPHOST and below (due to the hierarchical configuration inherita
nce).  All of the IIS7 configuration settings are by default set at this path, and apply to all sites on the machine.

Likewise, by default, if configuration is written to "MACHINE/WEBROOT/APPHOST/Default Web Site/", it will be placed in the web.config file in the root of "Default Web Site", and apply to all urls in the site.

However, the configuration system supports the concept of location tags, which allow configuration to be set at the configuration path X, but apply only to a child configuration path.  For example, in the applicationHost.config file, it is possible to set configuration like this:

<location path="Default Web Site/vdir1">
      <directoryBrowse enabled="true" />

While set at MACHINE/WEBROOT/APPHOST, this configuration is not effective there.  Instead, this configuration applies only to "MACHINE/WEBROOT/APPHOST/Default Web Site/vdir1" and will only be visible when read there.  It is effectively equivalent to specifying the configuration in a web.config file in the "vdir1" virtual directory of the "Default Web Site".

This example reflects the choice you have as an IIS7 administrator when setting configuration for a particular path:

  1. Directly at the path itself by placing it in the configuration file that corresponds to the file (creating a delegated, and XCOPY-deployable configuration), or
  2. Anywhere above it in the hierarchy, using location tags to apply it to a lower path (creating controlled, centralized configuration). 

You can use this ability to select a set of configuration that is set in an administrator controlled location (such as the applicationHost.config file), and allow the rest of the configuration to be set by the application owner directly in their application using distributed web.config files.  To learn more about configuration locking, see

Finally, a note: the configuration paths in IIS7 DO NOT SPECIFY the actual configuration that you are setting, only the level at which it is set / level at which the configuration applies.  This is somewhat unlike IIS6 metabase paths which sometimes carry information about the object being configured, such as the AppPool node.  In IIS7, all configuration is stored in section and so you need to specify which section you’d like to edit and set its properties in addition to specifying at which level it should be set.

Using IIS7 configuration paths to manage configuration

Armed with the knowledge about IIS7 configuration paths, lets jump into a few examples of managing your IIS7 server that require the use of these paths.  These examples use the AppCmd.exe, although, you will also use the same paths when working with other configuration APIs like Adadmin COM objects, Microsoft.Web.Administration, and WMI.

When working with AppCmd, it is often possible to omit "MACHINE/WEBROOT/APPHOST" when specifying a configuration path, and instead just use the "<SITENAME>/<VIRTUALPATH>" part of it.

1) Finding a site named "Default Web Site"

> %windir%system32inetsrvAppCmd.exe List Site "Default Web Site"

The path to a site is just its name (remember the AppCmd support for omitting the M/W/A part of the path).

2) Finding an application with path /App1 under "Default Web Site"

> %windir%system32inetsrvAppCmd.exe List Site "Default Web Site/App1"

The path to the application is the SITENAME/VirtualPath where VirtualPath is the virtual path of the application.

For more info on the IIS7 site, application, and virtual directory structure and how to manage these objects, see my earlier post about creating IIS7 sites, applications, and virtual directories.

 3) Setting configuration for the root of the "Default Web Site"

> %windir%system32inetsrvAppCmd.exe Set Config "Default Web Site/" /section:directoryBrowse /enabled:true

Applied configuration changes to section "system.webServer/directoryBrowse" for "MACHINE/WEBROOT/APPHOST/Default Web Site/" at configuration commit path "MACHINE/WEBROOT/APPHOST/Default Web Site/"

Note that the tool by default wrote the settings to the web.config in the root of the Default Web Site, because that is what the MACHINE/WEBROOT/APPHOST/Default Web Site/ path corresponds to in the file hierarchy.  These settings will be effective for that same path (and below).

4) Settings configuration for the root of the "Default Web Site", but setting them at the global (applicationHost.config) level.

> %windir%system32inetsrvAppCmd.exe Set Config "Default Web Site/" /section:directoryBrowse /enabled:true /COMMIT:MACHINE/WEBROOT/APPHOST

Applied configuration changes to section "system.webServer/directoryBrowse" for "MACHINE/WEBROOT/APPHOST/Default Web Site/" at configuration commit path "MACHINE/WEBROOT/APPHOST"

Note the usage of the commit parameter to force the configuration path to be MACHINE/WEBROOT/APPHOST, which results in the configuration being written to applicationHost.config with a location tag to apply them to the MACHINE/WEBROOT/APPHOST/Default Web Site/ configuration path.  If you were to open applicationHost.config, you will find the following:

    <location path="Default Web Site">
            <directoryBrowse enabled="true" />

If you were to now read the effective configuration for the server at the global level by using the command below, you will notice that directory browsing is turned OFF there (unless you changed that), meaning that it is turned off by default for all websites. 

> %windir%system32inetsrvAppCmd.exe List Config MACHINE/WEBROOT/APPHOST /

However, if you then see what the settings are for the “Default Web Site/”, you’ll see that directory browsing is turned ON there.  This would be the case if you set that configuration directly at the root web.config for the website using step #3, or set it in applicationHost.config with a location tag in step #4. 

I hope this example helps you understand the IIS7 configuration paths and how to use them to manage your server.  Please comment and let me know if there is anything else that you think needs to be explained here.





  1. Anonymous

    Question: I’m kinda forgot every single detail, now in UNC path setup, say if we try to configure some settings say auth or default doc, etc. by default commit path is the content path and config is kept at the unc path web.config file. In workgroup, when writing such config, the content server will impersonate the current IIS 7 manager user to write the config file, right? and when it failed to write the config file, will it revert to location path in the apphost config file? I forgot what I tested, kinda mess up back then, but I saw some config is actually captured using location path in apphost config file.

    what’s the logic flow if configuration involving in writing config on unc share?

  2. Mike Volodarsky


    The config system will impersonate the caller, unless there is a user configured for the virtual directory, in which case it will impersonate that user always regardless of the caller for accesses to config files in and under that virtual directory. This is similar to the “UNC user” that could be configured in IIS6, only its generic and doesnt depend on whether the directory is on UNC or not (if virtual directory user is set, it will be used).

    The config system has no behavior for falling back to apphost if access is denied. If its denied, you will get back an error. The UI however does have a fallback mechanism, so it will produce the location tags in apphost if it fails to write to the path itself (because of access denied, or section locked issues). So if you are using the UI, you may see this behavior. You can also tell by the config path that is shown in the status bar when using the UI.

    With all other tools, specfying the commit path is up to you (as mentioned above in the post).



  3. Anonymous

    In IIS6.0 i have a variable ASPMaxRequestEntityAllowed if i want to increase the size of my uploads, but in IIS7.0 i dont see a metabase.xml. How do i achieve the same??

  4. Anonymous

    Hi Mike,
    I have been searching everywhere to solve my IIS7 Issue and cannot find anything on it.. I am on vista home premium and after checking all the boxes that all the forums say to check. I get the the 500 error saying I need to run the following in the administrator cmd line
    %systemroot%system32inetsrvAPPCMD.EXE migrate config “Default Web Site/”
    I go ahead and run it, however I am receiving an error that say access is denied. I have full admin privileges however, when I check the security, it says I do not have full rights AND when I go to change that, all the permission boxes are greyed out
    I ran the appcmd.exe as an administrator.

    I found a work around in a different forum where it had the default files listed in the web.config and there was a line of code that allowed acces for both iis6 and iis7. However my superior wants me to run the appcmd.exe and not alter the web.config(plus I can’t find that work around anymore)

    any ideas?

  5. Anonymous

    Hi Mike,
    I wanted to post an update to my previous issue. I found the line of code that I put in my web.config and it removes the 500 error.

    Thanks again for any insight on how I can resolve this


  6. Mike Volodarsky

    Hi Mike W,

    Can you please post the exact error that you get? From your post, its not clear whether you error is coming from the AppCmd command (which must be run from an elevated command line prompt to work) or whether you are getting a request error from IIS.



  7. Anonymous

    Hi Mike,

    Here is my whole cmd line window text

    Microsoft Windows [Version 6.0.6000]
    Copyright (c) 2006 Microsoft Corporation. All rights reserved.

    C:Windowssystem32>%systemroot%system32inetsrvAPPCMD.EXE migrate config “Def
    ault Web Site/
    ERROR ( hresult:80070005, message:Command execution failed.
    Access is denied.


    also, I am positive I pastedin the node from the config that solved my issue. I am pasting it in again with some psuedo code

    system dot webserver node
    validation node
    validateintegratedmodeconfiguration=false attribute

    Thanks again for your time…
    You can also email me direct if you like.
    [email protected]

  8. Anonymous

    Hi Mike,

    I googled elevated cmd prompt and I thought I right click the icon and run as administrator but according to this article I still do not have admin rights and I have to follow the following steps. However, I am unable to follow these steps as when I do, there is nolonger an option to “run as Administrator”. The option to “Run as Administrator” is only available the first time I open it

    Click on Start button.
    In the Search box, type in Command Prompt. Command Prompt will show up in the search results.
    Right click on Command Prompt icon and select Run as administrator.
    Enter the admin credential and you are ready to go.

  9. Mike Volodarsky

    Hi Mike,

    It looks like you are doing everything correctly. Please post these details on the and we will help you there if you are still having trouble.



  10. Anonymous

    Hi Mike.
    Your article was very usefull for me in understanding the new configuration schema of IIS7. For IIS6 I always used WMI to setup my entire site from scratch.
    I’m trying the same method to setup a new site in IIS7 by using WMI, but when I run the entire script in a VB6 program, I get some errors because the configuration file was not updated when I try to create a virtual directory in the new created site. It seems to be a time issue, as when I execute the program step by step this problem doesn’t occurs. Have you ever heard something like this?
    Thank you.

  11. Anonymous

    I wanted to post an update to my previous issue. I found the line of code that I put in my web.config and it removes the 500 error.

  12. Anonymous

    IIS 7 changed fundamentally since IIS 6. Here are some links that might help you when you feel lost with

  13. Anonymous

    Question: Mike, I am trying to get my current web application work on IIS7. It worked on IIS6 and previous IIS. my code extracts the value of Request.ServerVariables(“APPL_MD_PATH”) and search for word “Root” from the value “/LM/W3SVC/1/ROOT/Myweb”(Myweb is virtual directory). It failed on IIS7 because now “ROOT” is all uppercase. Is there anyway I can tweak II7 configuration, so that Request.ServerVariables(“APPL_MD_PATH”) still returns “/LM/W3SVC/1/Root/Myweb”?

    Many Thanks!

  14. Anonymous

    comments about the 80070005 error. I got the same thing and realized I had the web.config checked in, so it wasn’t writable. After I checked it out it worked just fine.

  15. Anonymous

    Hello Mike,

    I’m having difficulties when attempting to alter specific IIS configuration settings from within a VBscript. I’m able to change settings globally no problem, but when I add a specific site name after MACHINE/WEBROOT/APPHOST/ eg.(MACHINE/WEBROOT/APPHOST/InsideFTL/Corp/redirects/netXposure), I receive an 80070005 error. Any help would be much appreciated!


  16. Anonymous

    Hello Mike,

    We have Hyperion application version, IIS 6.0 and smartview 9.3.3. Users update excel sheets using smartview addon with HFM app and refresh the spread sheets.

    When the excel sheets ae above 50MB we get errors related to space issues with memory. We were advised to increase ASPMAXENTITYALLOWED to 1GB.
    It temporarily fixed the issue, but over period of 2 to 3 weeks we are forced to reboot the servers.
    How to overcome this problem in IIS 6.0 ?
    Also, is this issue fixed in IIS 7.0.

    Please send me the reply to [email protected]

    I will appreciate your help on this.

    Suresh Gumidayala

  17. It is rare knowledgeable folks within this subject, nevertheless, you appear like there’s a lot more you are talking about! Thanks 685146

Leave a Reply

Your email address will not be published. Required fields are marked *