Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have IIS 7 set up with the 'Default Website' intact at port 80, and I have added a handful of other websites parallel to it under 'Sites', all running on different ports.

I'd like to move these sites to exist as sub applications of the Default Website (ie: all running on port 80, reachable as ../SiteA ../SiteB), while maintaining their current configurations.

Current site setup:


  • Default Website
  • SiteA
  • SiteB
  • SiteC

Wanted site setup:


  • Default Website
    • SiteA
    • SiteB
    • SiteC

I could just remove them and re-create them, but I'd like to maintain their configurations.

Edit: Current setup -

Current IIS 7 Setup

For clarification - I have existing sites created in IIS, configured within IIS - I don't want to delete them and re-create them by adding them to Default Web Site as sub applications from scratch. I'm wondering if there is a way to literally move the existing applications along with their configurations (Meaning I have Mime types, Authentication rules, Bindings, and other custom settings I don't want to re-create if I can avoid it).

To be even more specific, I had thought I might be able to click and drag one of the sites here ONTO 'Default Web Site' effectively relocating it as a sub application.

If this is not supported functionality that's fine, I just wanted to explore the possibility of support for this kind of thing.

share|improve this question
up vote 6 down vote accepted

For each site you want to have as a sub-application, right click on Default Website and select Add Application:

enter image description here

Then point the application at your existing physical folders for the site:

enter image description here

Now depending on how you've secured the physical folders for SiteA, SiteB and SiteC, you may need to adjust the NTFS permissions to allow the Application Pool identity for whichever application pool will host these sites.

You could just re-use the pools that exist already for SiteA, SiteB and SiteC by clicking Select next to the Application Pool greyed out textbox.

Further to your update to the question:

I had thought I might be able to click and drag one of the sites here ONTO 'Default Web Site' effectively relocating it as a sub application.

Unfortunately IIS MMC doesn't have that capability, this is something you need to do by hand and it can be done with some careful copy, pasting and tweaking of settings in IIS7's applicationHost.config file.

Where To Find Your Site Configuration(s)

If most of the settings were configured via the IIS MMC UI using the Mime, Default Document, Error Pages etc features then these settings will be persisted in your sites web.config files under <system.webServer>. If this is the case then there isn't much you need to do.

However, if the settings were configured using the appcmd.exe command line tool or using the IIS MMC Configuration Editor feature and the commit location was set to /commit:apphost (or ApplicationHost.config <location path="SiteX" /> if using the config editor) then these settings will be persisted directly in IIS7's main configuration file which resides in:


To understand the structure of the applicationHost.config configuration file I would recommend having a read of the following:

<system.applicationHost> - MS IIS.NET site

Click on "View by Schema" in the right hand panel which will show the hierarchy of settings.

A site is defined in the <sites> collection which contains as you might guess a collection of <site> elements. There are a few settings that are children of a <site> element that make no sense residing anywhere else, for example the <bindings> collection which specifies the site IP address, host headers, port to listen on etc.

About Feature Delegation

When configuring site features via the MMC UI, the way a setting is persisted (whether it is saved in the local site web.config file or stored in the applicationHost.config file is generally controlled by how feature delegation for that setting is configured.

You can find the feature delegation configuration tool under the Management section of IIS7's MMC server wide configuration node:

enter image description here

When you launch this you'll see a list of (almost) all of the configurable features of your server:

enter image description here

In a nutshell anything that is set to Read Only will have it's configuration settings locked and can only be configured/saved in the applicationHost.config file.

Any feature that is delegated as Read/Write or Configuration Read/Write will be saved in the site or sub application's web.config file.

The caveat to the above is that if you used the site level Configuration Editor to change any settings that are delegated (Read/Write) i.e.:

enter image description here

enter image description here

...and you specified ApplicationHost.config <location path="SiteA" /> then the setting will be configured back in the applicationHost.config file regardless of the delegation setting for that feature.

This hopefully explains where you can expect to find your settings based on interpreting the Feature Delegation rules.

Copying Non-Delegated Feature Settings

Non-delegated feature settings that can be controlled on a per site or application basis are stored in <location> configuration elements in the applicationHost.config file. These behave much like the <location> element in ASP.NET. Here's a worked example using the classic ASP settings.

Classic ASP settings by default aren't delegated (the Delegation setting is set to Read Only in the Feature Delegation tool.

SiteA has had its Classic ASP Debugging Properties -> Send Errors To Browser setting changed to True (the default is False):

enter image description here

When this setting is applied it is stored in the applicationHost.config file and looks like:

<location path="SiteA">
    <asp scriptErrorSentToBrowser="true" />

You'll probably need to skip to the end of the file to locate this.

Now if you want to copy this setting to a new application residing under another site i.e. Default Website/SiteA then copy and paste the above setting and just change the path to match the exact hierarchy:

<location path="Default Website/SiteA">
    <asp scriptErrorSentToBrowser="true" />

Doing this should work for 99% of cases and without knowing your exact configuration it'd be hard to speculate on the 1% where some special attention is needed.


When working with the applicationHost.config file it's always a good idea to take a copy of it before making each change. Do one thing at a time so you can roll back should you completely clobber IIS by accident :)

If you're working in a 64 bit environment then you'll need to use a tool like Notepad2 which has a 64 bit version to be able to edit and save the applicationHost.config file. You also need to "Run As Administrator" as well when performing these operations.

share|improve this answer
This explains how to go about creating the sites from scratch in IIS - what if I have all the sites created in IIS already outside the Default Website - and I have a heavy amount of configuration on each. I'd like to move the entire site as-is from Sites > SiteA, to Sites > Default Website > SiteA – Jeff Dalley Dec 2 '11 at 18:26
@JeffDalley That's what the above does, it creates sub applications under the Default Website. Re-read the second sentence: right click on Default Website and select Add Application. That will create a sub application under the Default Website. – Kev Dec 2 '11 at 19:48
Definitely, I don't disagree and I do understand, check my update to the question above to see if that helps clarify my question. Sorry for the confusion. – Jeff Dalley Dec 2 '11 at 20:01
@JeffDalley - right, now you've cleared that up. No there isn't a way to achieve that in the UI. However...if you can wait a while (I'm having dinner etc right now), I can explain how to move stuff around inside IIS7's c:\windows\system32\inetsrv\config\applicationHost.config file to achieve this. – Kev Dec 2 '11 at 20:12
Perfect that would be great. – Jeff Dalley Dec 2 '11 at 20:36

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.