IIS 7 Configuration Paths

Question

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?

Solution 1

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.

Solution 2

It sounds like you are trying to build a generic tool to manage configuration, and so you might want to consider to follow a similar pattern that IIS Manager follows; in short, it always tries to save configuration to the deepest path possible. What this means is that it will always Commit it to the place where it can, by looking at if the section is locked or not. It uses Managed code (Microsoft.Web.Administration), but you can access the same data from C++ using AppHostElement.GetMetadata("isLocked"). By the way if you are using C++, I would STRONGLY recommend using AHADMIN directly (and not WMI, or anything else), in particular IAppHostWritableAdminManager.

So the algorithm would be, set the CommitPath to the same value as the GetAdminSection configuration path specified. Then check for IsLocked, if it is then remove the last "path part" (trim starting the last '/'), and read again till you find the place where the section is unlocked. That is the deepest place where you can save it. Also, you will need to switch to MACHINE/WEBROOT at some point if it is a system.web section. IsLocked will respect things like Section Definition allow location, and other things that are required. If you want to make it bullet proof you would even need to check for attribute-level locking, but I think that is quite advanced.

Comments

[Ron]

thanks again for your response. I specified bindings as an example - however I want to be able to support ALL metabase properties that are mapped to IIS configuration paths. 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?

[Kev]

@ron - what exactly is it you're trying to achieve?

[Ron]

I am trying to support IIS 6 metabase properties in IIS 7. Can't use the IIS 6 Compatibility package because it doesn't cover enough properties, so I decided to create custom mappings in my code. Then, if a user inputs AccessSSLFlags, my app knows that in IIS 7 that maps to ConfigurationSection.AccessSection.SslFlags, but I don't know which section I need to commit to get to this configuration at runtime..

[Kev]

@ron - ok, then my answer should help. The schema files and the config files themselves do provide enough information to work this out. To be honest, aim to store in APPHOST where you can. Settings that can and need to be overridden in web.config by a user can do so.