For each site you want to have as a sub-application, right click on Default Website and select Add Application:
Then point the application at your existing physical folders for the site:
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:
%systemroot%\system32\inetsrv\config\applicationHost.config
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:
When you launch this you'll see a list of (almost) all of the configurable features of your server:
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.:
...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):
When this setting is applied it is stored in the applicationHost.config file and looks like:
<location path="SiteA">
<system.webServer>
<asp scriptErrorSentToBrowser="true" />
</system.webServer>
</location>
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">
<system.webServer>
<asp scriptErrorSentToBrowser="true" />
</system.webServer>
</location>
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.
Footnotes
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.
