In the course of working with IIS configuration, you
will need to perform a variety of management tasks in addition to
editing the configuration itself. Notably, you will need to back up and
restore configuration, in order to revert from unintended changes or
recover from corrupted configuration files. This is especially critical
because the ease of editing IIS XML configuration files also makes it
easy to make undesired changes.
In fact, when working with
IIS configuration, you should always insure that you make a backup that
can be used to go back to the state before the changes. Luckily, IIS
makes it very easy to do this.
In this section, we
will review the management tasks around backing up and restoring IIS
configuration. We will also discuss setting up shared configuration
between multiple servers and setting up configuration delegation that
enables some configuration to be set in distributed web.config
configuration files.
Backing Up Configuration
Before making
changes to IIS configuration files, you should back them up so that you
can restore them later if your changes corrupt configuration or result
in incorrect server operation. The latter is a critical reason—the
server may look like its working properly initially until a future time
when problems are detected, at which point you may want to come back to
the previous configuration state.
Typically, it is not
necessary to make special arrangements to back up delegated
configuration located in web.config inside your Web site structure,
because those files are backed up together with your site content (of course, you need to maintain backups of your site content for this to work).
However, if
you make changes to the server-level configuration files, you should
make a backup of server configuration. Thankfully, IIS 7.0 makes it easy
to do that via the Appcmd command line tool.
From an administrative command prompt, type
%windir%\system32\inetsrv\ AppCmd Add Backup MyBackup
This creates a backup of
IIS configuration files, including applicationHost.config,
redirection.config, and administration.config, and custom schema files
if there are any. The backup is created as a named directory under the
%windir%\system32\inetsrv\backup directory, using the name you specified
to the “Add Backup” command. This directory will contain the backed-up
files.
Note
If you do not specify a backup name, Appcmd will automatically create a name using the current date and time. |
You can list the backups made on your system by using the List Backups command.
%windir%\system32\inetsrv\AppCmd List Backups
Then, you can restore any of the listed backups by using the Restore Backup command.
%windir%\system32\inetsrv\AppCmd Restore Backup "MyBackup"
The restore command
will restore all of the files in the backup folder, overwriting the
current server configuration with those files. No confirmation prompt is
given, so always consider backing up the current configuration first
before restoring another set.
A note about
configuration file security and encryption: the backup process simply
copies the server configuration files to the inetsrv\backup directory,
which by default is secured with the same NTFS permissions as the
inetsrv\config directory, which contains the original files. If the
files contain encrypted configuration, those details will stay encrypted
in the backed-up copies. No additional encryption is performed as part
of the backup mechanism. Therefore, the files are only protected when
they are in the backup directory and are not safe to place in an offline
location without additional protection.
Using Configuration History
By default, IIS 7.0 via
the AppHostSvc will check every two minutes to see if
applicationHost.config has changed, and if so will make a backup of the
file. You’ll find the backed-up configuration files in the
Inetpub\history folder by default. You can change both the location of the backups as well as several other configurable parameters in the <configHistory> configuration section, as shown in Table 1.
Table 1. <configHistory> Attributes
| Attribute | Default Setting | Definition |
|---|
| Enabled | True | This value indicates whether configuration history is enabled or disabled |
| Path | %systemdrive%\inetpub\history | The path where history directories will be created and stored |
| maxHistories | 10 | The maximum number of directories retained by IIS 7.0 |
| Period | 00:02:00 | The time between each check made for changes by IIS 7.0 |
If you do nothing at all, the values listed in Table 4-7
are preconfigured for you. To modify these values, you need to enter
them into applicationHost.config, because the IIS Manager does not have a
UI for configuring this section of applicationHost.config. You can use
Appcmd for this. For example, the following command will change the path
for storing backups to %systemdrive%\MyWebHistory. Note that the path
must exist first or the service will not work.
%windir%\system32\inetsrv\Appcmd set config /section:configHistory
"/path:%systemdrive%\MyWebHistory"
You can use the Appcmd Restore Backup command to restore any of the configuration history backups the same way you restore manual backups performed by the Appcmd Add Backup
command. You can list all of the available backups, including both
manual and configuration history backups, by doing the following.
%windir%\system32\inetsrv\AppCmd List Backups
Exporting and Importing Configuration
By default, IIS 7.0
configuration stores no secrets and therefore is not tied to a specific
server as it was in previous versions. The reason for the IIS 6.0
metabase to be tied to a local server and protected is that by default
it contains the passwords for the anonymous user and IWAM user. If these
passwords were discovered, it is feasible they could be used to log on
to the server. They were random and complex, which provided a high very
high degree of security.
In IIS 7.0, the
anonymous user (IUSR) is a “built-in” account rather than a local
account, so it does not require a password. Don’t worry, even though
there is no password, you can’t use this built-in account to log on to
the server. There is no possibility that the IUSR account can be
used to log on locally or remotely except through IIS. In addition,
there is no IWAM account, since IIS5 application isolation mode is not
part of IIS 7.0. Since there are no secrets by default in
applicationHost.config, there is no need to key it to an individual
server.
This means that you can
take applicationHost.config from one server and copy it to another
server provided you also synchronize the server encryption keys,
presuming the target server has the same content and directory
structure. This provides a simple mechanism for exporting and importing
configuration between servers.
Note
To
use the applicationHost.config file from one server on another server,
you do need to make sure the servers use the same configuration
encryption keys. This is because applicationHost.config contains
encryption session keys that are themselves encrypted using the server’s
RSA configuration key. |
In the case in which
your configuration files do contain encrypted information, such as
application pool identities, the configuration files are tied to the
specific server on which the encryption information is generated. You
can, however, export and import the configuration keys in order to allow
multiple servers to share the same encrypted configuration—in fact,
this is one of the requirements for the shared configuration feature
supported by IIS 7.0.
Unlike IIS 6.0, IIS 7.0
does not provide a built-in mechanism to export configuration for a
particular site, as opposed to exporting the entire server’s
configuration. In a lot of cases, this can be accomplished by manually
re-creating the site definition on the target server and then simply
copying the site content, which can now define its configuration in the
web.config files contained within the site’s directory structure.
However, if the
site configuration is located inside location tags in
applicationHost.config, there is no automated mechanism to export it.
You can, of course, simply copy the contents contained in the location
tag (including the location tags) and add it to the bottom of another
applicationHost.config. An automated mechanism may become available in
the future.
