The IIS 7.0 configuration system provides a lot of
flexibility for editing server configuration. Because the configuration
is stored in plain-text XML files and uses a well-structured,
human-readable syntax, you can edit it manually using Notepad or your
favorite text editor. In fact, many people prefer this approach when
editing configuration for distributed web.config files located within
the site’s directory structure.
In addition
to enabling configuration to be edited by hand, IIS 7.0 provides a
complete administration stack that offers tools and APIs for editing
configuration. This includes the IIS Manager, a completely redesigned
GUI task-based experience for managing most of the IIS 7.0
configuration. It also includes the Appcmd command line tool, which you
can use to edit configuration quickly from the command line. Finally, it
includes several administrative scripts and APIs for editing
configuration programmatically, including the IIS 7.0 configuration COM
objects that can be accessed from native C++ programs (called the
Application Host Administration objects or AHADMIN) and Windows scripts,
a WMI provider, and new Microsoft.Web.Administration APIs for managing
configuration from .NET programs.
Note
Where
possible, use tools to manipulate IIS 7.0 configuration instead of
changing configuration by hand. This is much easier and provides
protection against generating incorrect configuration. |
In fact, you should choose
to use tools to edit the configuration on the server, because doing so
ensures that you are interacting correctly with the underlying
complexity of the configuration system and guarantees that the
configuration is written using the correct syntax. The IIS Manager is a
great way to do this, because it provides a simplified task-based view
of many IIS 7.0 features, so you don’t need to understand their
configuration structure.
However,
there are times when you need to specify configuration by hand or use
one of the lower-level tools like Appcmd or programmatic interfaces like
the Microsoft.Web.Administration namespace provided in .NET. In this
case, you do need to understand the structure of configuration sections
and inheritance behavior of the configuration hierarchy in order to do
this correctly. In the remainder of this section, we will discuss the
basics of editing IIS 7.0 configuration that will help you to do it
correctly.
Note
Use
Appcmd to edit configuration in situations in which IIS Manager does
not expose the desired configuration functionality. Appcmd can perform
most configuration tasks you can do by hand, and it offers the benefit
of additional validation. It also allows you to perform configuration
tasks in an automated fashion on other machines if needed.
|
Caution
Before
modifying configuration, always make sure you have a backup of the
current state so you can come back to it if necessary.
|
Deciding Where to Place Configuration
The IIS 7.0 configuration hierarchy contains multiple configuration files, comprising the .NET
configuration files, applicationHost.config, and distributed web.config
files in your site directory structure. This hierarchy allows you to map
configuration to a URL namespace on your server by placing it in the
right configuration file. When the server reads configuration for a
particular Web site or URL, it merges all configuration files along the
configuration path, merging the configuration specified in them to
achieve the effective set of configuration for a given path.
Because of the
configuration merging, configuration specified at a higher configuration
path always inherits to all child paths, unless it is overridden lower
down. For example, configuration specified in applicationHost.config is
inherited by all sites and URLs on the server, unless it is overridden
in their respective web.config files.
Table 1 indicates where you may chose to place configuration in order to apply it to the desired scope.
Table 1. Placement of Configuration
| Configuration For | Place In |
|---|
| Entire server | applicationHost.config |
| A specific site | web.config in the site’s physical root directory |
| A specific application | web.config in the application’s physical root directory |
| A specific virtual directory | web.config in the virtual directory’s physical root |
| A specific URL | If
the URL corresponds to a physical directory, in web.config in that
directory; otherwise, in any existing parent web.config file with a location tag for the specific URL |
When
specifying configuration at a specific site or URL, you always have a
choice of specifying configuration in a distributed web.config file
corresponding to the URL or placing it in a configuration file higher in
the hierarchy (for example, applicationHost.config) and applying it to
the specific URL by using location tags. Both have advantages and
disadvantages you need to consider.
Using location
tags can allow you to place all configuration in a single location,
instead of multiple web.config configuration files which may be harder
to discover and manage. Also, if configuration is locked at a particular
configuration path (for example, configuration that should only be set
by server administrators is typically locked in applicationHost.config),
you are forced to use location tags at that path in order to apply
configuration to child paths. However, placing configuration in
distributed web.config files allows the site/application/directory to
become portable and xcopy-deployed to other servers or places in the
site structure without having to set any configuration elsewhere or
requiring administrative privileges on the server. This is a very
powerful ability.
Finally, a note about
configuration delegation—not all configuration sections are allowed to
be specified in distributed web.config files by default. It is up to the
server administrator to decide which configuration sections are
delegated and to unlock them in applicationHost.config. This may impact
your ability to run applications that specify configuration in
distributed web.config files, generating errors if locked configuration
is specified.
