IIS 7 Configuration Paths

Ron picture Ron · Jan 24, 2011 · Viewed 13.8k times · Source

I am trying to make my c++ ahadmin application compatible to IIS 7. My app needs to read the websites configuration (via metabase properties in IIS 6).

I read a lot of articles about the configuration paths and I think I have a good idea of how it work - however I am not sure of one thing:

To get to the configuration, I can either commit the MACHINE/WEBROOT/APPHOST/ path or the MACHINE/WEBROOT/APPHOST/Default Web Site.

I understand that the latter refers to the actual web.config of the specific website, and the former refers to the general applicationHost.config file, in which general settings are set.

My app doesn't know however whether a web.config file exists.

My question: if I want to get to this path - Object.ConfiguredObject.Site.Bindings, do I need to commit the APPHOST path or the APPHOST/Default Web Site path?

How do I know that in runtime?

Answer

Kev picture Kev · Jan 24, 2011

You will always commit your bindings to MACHINE/WEBROOT/APPHOST.

You should go have a look at the schema files in:

%systemroot%\System32\inetsrv\config\schema

They will help you identify where settings should belong.

Update:

Per your comment:

So for example, AccessSSLFlags would be mapped to ConfigurationSection.AccessSection.SslFlags - what section will I commit in that case? How do I know which section I need to commit?

That all depends. IIS7 supports a mechanism called Feature Delegation. If a feature is delegated then this means a user can configure that feature in their local web.config. Some features are configured under system.webServer, others system.web.

What a user can and can't configure locally in his/her web.config is controlled by entries in two files:

%systemrooot%\system32\inetsrv\config\administration.config
%systemrooot%\system32\inetsrv\config\applicationHost.config

If you go and look at the IIS7 configuration schema in:

%systemroot%\System32\inetsrv\config\schema\IIS_schema.xml

What you'll find is that there are two main types of section:

system.applicationHost/xxxx
system.webServer/xxxx

Anything that is configurable under system.applicationHost is generally not considered a user modifiable configuration item. In fact if you open applicationHost.config you will see:

<sectionGroup name="system.applicationHost">
  <section name="applicationPools" allowDefinition="AppHostOnly" overrideModeDefault="Deny" />
  <section name="configHistory" allowDefinition="AppHostOnly" overrideModeDefault="Deny" />
  <section name="customMetadata" allowDefinition="AppHostOnly" overrideModeDefault="Deny" />
  <section name="listenerAdapters" allowDefinition="AppHostOnly" overrideModeDefault="Deny" />
  <section name="log" allowDefinition="AppHostOnly" overrideModeDefault="Deny" />
  <section name="serviceAutoStartProviders" allowDefinition="AppHostOnly" overrideModeDefault="Deny" />
  <section name="sites" allowDefinition="AppHostOnly" overrideModeDefault="Deny" />
  <section name="webLimits" allowDefinition="AppHostOnly" overrideModeDefault="Deny" />
</sectionGroup>

Notice the allowDefinition="AppHostOnly"? That's basically telling you that these settings can't be configured in web.config.

The scope of how feature delegation works is far too wide to cover in an answer so I suggest you read the article linked to above.