About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
An IIS web server can look simple to recover: reinstall Windows, add the Web Server role, copy the website files back. In practice, the part that takes the time is everything around the files. Which sites existed, on which addresses and ports, with which host names? Which application pools, running under which accounts, with which .NET settings? Which modules were installed, and which certificates were bound to which sites?
Most of that lives in one file. IIS also has three built-in ways to keep copies of it. They are often treated as one feature, but they protect against different events, and none of them is a complete backup of an IIS server on its own.
This article sets out what Microsoft documents about IIS configuration, the three mechanisms, what they leave out, and why encrypted settings need more than a copy of a file.
Where IIS keeps its configuration
Microsoft's introduction to ApplicationHost.config describes it as the root file of the configuration system when you are using IIS 7 and above. It includes definitions of all sites, applications, virtual directories and application pools, as well as global defaults for the web server settings.
Two details on that page matter for recovery.
First, many sections in the file are deliberately incomplete. The page explains that the rest of the values are taken from the schema defaults, and the schema files sit in their own folder under the IIS configuration directory. In our reading, this means applicationHost.config is meaningful only on a server with a matching IIS installation and matching modules: the file records what differs from the defaults, and the defaults come from what is installed.
Second, applicationHost.config is not the only configuration file. Web.config files can sit in each site and application, and .NET has its own machine-wide files. Each of those has its own home and its own backup question.
Mechanism 1: configuration history
IIS keeps automatic copies of its configuration. Microsoft's reference for the configHistory element says the feature keeps a running history of changes to your configuration files and that it is especially useful for recovering from mistakes made when manually editing your configuration files.
The page's own example is a broken edit that leaves visitors with an HTTP 503 error, fixed by copying the file back from the history folder. The documented defaults are:
- Enabled: on by default.
- Location: a history folder under inetpub on the system drive.
- Number kept: The default value is 10.
- Check interval: every two minutes.
There is an important condition. The feature requires that the IIS application-host service is running on your server; if this service is stopped or disabled, changes to your configuration files will not be kept in the history folder.
In our reading, configuration history is an undo feature, not a backup. Its copies sit on the same system drive as the file they protect, there are only ten by default, and a run of automated changes could push a good version out of the history. It provides local configuration rollback, but is not an independent copy for server loss. Microsoft documents no user interface for these settings, so they are easy to forget about.
Mechanism 2: configuration backups
The second mechanism is a named backup you take on purpose. Microsoft's Getting Started with AppCmd.exe explains that AppCmd can create and restore backups of global server configuration. It describes what a backup contains: the copy of the current ApplicationHost.config root configuration file, as well as other related server-wide state including FTP configuration and the IIS Administration Tool configuration.
Microsoft recommends taking one before a change: It is a good idea to create a backup before changing server configuration, or installing a component that changes it. The same page notes two things about restoring: restoring stops the server and restores global configuration to its state at the time the backup was created, and the periodic copies made by configuration history appear in the same list of backups.
PowerShell offers the same capability. The Backup-WebConfiguration reference says the cmdlet creates the backup as a named folder under %windir%\System32\inetsrv\backup, and that a backup name that already exists returns an error.
In our reading, the location is the point to notice. These backups are written inside the Windows folder of the server being protected. They are excellent protection before a planned change, and they do nothing if the server or its system drive is lost. To count as part of a recovery plan, they must also be copied somewhere else, along with everything else this article lists.
Mechanism 3: shared configuration export
Shared configuration was designed for web farms, where several servers read one set of configuration from a file share. Microsoft's overview, Shared Configuration in IIS versions, lists exactly what it exports:
- applicationHost.config
- administration.config
- Encryption keys for IIS and ASP.NET, exported as a key file
The export asks for a password, which protects the keys. That page describes the keys as the ones IIS uses to encrypt properties like custom application pool identity passwords.
Even for servers that are not in a farm, our view is that this export is the most complete of the three built-in copies, because it is the only one that deliberately carries the encryption keys. It is also a file set that can be stored away from the server.
What none of the three carries
The same Microsoft page is unusually direct about what shared configuration does not export:
- machine.config
- the root web.config
- Web.config files for sites and applications, which are part of the site content
- website content
- custom modules
- installed modules, which should be configured the same way on each server
That list is a useful checklist for any IIS recovery plan, farm or not. To it we would add two items the configuration file refers to but does not contain:
- Installed roles and features. Our understanding, from the schema-defaults design described earlier, is that the configuration assumes the same IIS features are installed. A rebuilt server needs the same role services, and the same versions of any add-on modules, before the restored configuration will behave the same.
- Certificates. A site binding refers to a certificate; the certificate and its private key live in the Windows certificate store, or in a Centralized Certificate Store on a file share, which IIS 8 and later can use. Either way, the certificates need their own backup or re-issue plan.
Why a copied applicationHost.config may not work on a new server
When an administrator enters a custom account and password for an application pool or a site, IIS stores that password encrypted. Shared configuration's documentation notes that by default, there are no encrypted properties in the applicationHost.config file, unless the server administrator has entered custom identities for an application pool or Web site.
Microsoft's article on using encryption to protect passwords is a hardening walkthrough that creates a dedicated RSA key for application pool passwords. It says IIS_IUSRS initially has read access to created keys, then demonstrates restricting the new key to Administrators and the local system account. That restricted access is the walkthrough’s outcome, not an assumed default; any custom key must be identified in the recovery inventory.
The shared configuration page then makes the recovery consequence explicit. Copying the files by hand is possible, but the server administrator must export and import the encryption keys unless they intend not to use encryption. The IIS 7 shared configuration guide adds a format detail: the user interface exports the keys by using its own custom format, so keys exported by another method would not be in the format that is required by the UI.
In our reading, the practical effect is this: applicationHost.config restored onto a freshly installed server, without the original keys, will contain encrypted values that the new server cannot decrypt. The sites and pools will be listed, but any pool that relied on a stored password will not run as intended until its password is entered again. We have not tested this behaviour for this article; the conclusion follows from Microsoft's description of why the keys must be exported.
Two approaches avoid it, and in our view a recovery plan should choose one deliberately:
- keep a password-protected export that includes the keys, stored away from the server, with its password in the organisation's vault; or
- keep a record of every custom identity, so pool passwords can be entered again on a rebuilt server. Group managed service accounts or built-in identities, where they suit the application, remove the stored password altogether.
Matching each mechanism to the event
It helps to set the three mechanisms against the events a recovery plan has to cover. For a mistaken edit made a few minutes ago, configuration history is usually enough. For a planned change that goes wrong, a named configuration backup taken just before the change returns the server to a known point. For a lost system drive, a failed server or a rebuild on new hardware, only copies held away from the server help, and those need the keys, the content and the installed features alongside them. In our view, a plan that names which copy answers which event is easier to follow under pressure than one that simply says "IIS configuration is backed up".
A recovery plan for one IIS server
These are our recommendations, based on the documented behaviour above.
- Keep configuration history on, and confirm the IIS application-host service is running. Treat it as an undo button, not a backup.
- Take a named configuration backup before every planned change, and delete old ones on a schedule so the folder stays useful.
- Hold an off-server copy of the configuration with its keys, such as a shared configuration export, refreshed after significant changes. Protect its password like any other secret.
- Back up what the configuration doesn't contain: site content and web.config files, any machine-wide .NET changes, custom modules and their installers.
- Record the installed IIS role services and add-on module versions, so a rebuilt server matches the original before configuration is restored.
- Plan certificates separately: which are exportable, which are re-issued, and where any Centralized Certificate Store's share is backed up.
- List application pool identities and where their passwords are kept.
- Test the whole sequence on a non-production server: fresh install, features, configuration, content, certificates, then a request to every site.
A supported whole-server restore may preserve installed features and software key material together. It still needs verification: TPM-bound keys, external secret stores, remote content and database dependencies may remain outside that image. The inventory above is useful for both image recovery and a rebuild.
Risks and limits of this article
- Several of the IIS pages used are older reference articles for IIS 7, still published by Microsoft. The configHistory page states that the element was not modified in IIS 8.0, 8.5 or 10.0; the other pages were not checked against every later version.
- Microsoft community answers suggest that encryption key handling differs on newer IIS versions. We could not confirm this from Microsoft's primary documentation, so the article relies on the shared configuration export rather than a manual key procedure.
- The effect of restoring encrypted settings without their keys is our reading of Microsoft's documentation, not a tested result.
- No commands were run and no configuration was changed for this article.
Sources
Writer research: 11 November 2026. Independently reopened for review: 13 November 2026.
- Microsoft Learn: Introduction to ApplicationHost.config
- Microsoft Learn: Configuration History <configHistory>
- Microsoft Learn: Getting Started with AppCmd.exe
- Microsoft Learn: Backup-WebConfiguration
- Microsoft Learn: Shared Configuration in IIS versions
- Microsoft Learn: Shared Configuration with IIS 7
- Microsoft Learn: Using Encryption to Protect Passwords
- Microsoft Learn: Binding <binding>
This article was originally published on .