Delegating Configuration in IIS 7.0
Internet Information Services (IIS) 7.0 provides a file-based, distributed configuration system that allows application and Web site owners in shared, hosted environments a level of control over their settings that they did not have in previous versions of IIS. The MSCOM Ops team uses this distributed, or delegated, configuration system to:
· Reduce administrative overhead.
· Achieve greater flexibility and control for application owners.
· Reduce overall total cost of ownership.
This article describes how the Microsoft.com Engineering Operations (MSCOM Ops) team determines whether to delegate IIS 7.0 configuration settings, and includes our recommendations. It discusses considerations such as performance and availability, security, and delegating administrative control to Web sites. It also describes configuration settings that we unlock by using <location> tags and settings that we lock.
Unlike previous versions of IIS, application owners no longer have to request that administrators make application or Web site changes for them. Applications can now be self-contained, with both content and configuration stored side-by-side in the directory structure. Application owners can then modify and copy applications, content, code, or configuration without the assistance of an administrator. To perform these activities, the administrator only needs to delegate, or grant, privileges to application owners, who may include Web site owners, developers, and so on.
The central, master configuration file for IIS 7.0 is applicationHost.config, an XML-based file that is located in %windir%\system32\inetsrv\config. This clear, file-based configuration store replaces the metabase.xml file that is used by IIS 6.0. Only administrators can modify settings in applicationHost.config, and those settings apply to any or all sites, applications, and virtual directories on the Web server.
An administrator can unlock global default settings so that application owners can override them by using web.config files that are stored in folders at the application level. Application owners can define IIS configuration in their web.config files alongside ASP.NET settings, and then use xcopy deployment to copy the configuration and related content to other Web servers. Xcopy deployment is defined as using the XCopy command line tool or another utility that has similar file copying capabilities.
Determining Whether to Delegate ConfigurationSettings
www.microsoft.com Web servers contain hundreds of applications and web.config files, and as many application owners. Our administrators receive dozens of requests every week for IIS configuration changes, such as HTTP redirects and custom errors. The ability to delegate control of these settings to the owners results in less administrative overhead, greater flexibility and control for application owners, and lower overall total cost of ownership (TCO) to run our Web farms.
MSCOM Operations Unlocking and Locking Considerations
There are several factors MSCOM Ops considers when unlocking and locking configuration settings. These factors include:
· Performance and availability
· Application of the appropriate level of administrative control to Web sites
Performance and Availability
Because availability is a key success metric for the MSCOM Ops team, we try to maintain control of settings that can negatively impact performance where possible. For example, the server resource cost of tracing can have a negative impact on overall server performance and, consequently, impact other applications on the server. Additionally, we lock the <caching> section in applicationHost.config to take advantage of the resulting performance benefits, and to ensure that the <caching> setting that we have defined (for example, kernel caching) remains enabled for all applications.
To help ensure that security settings are consistent for all www.microsoft.com applications, MSCOM Operations keeps the <requestFiltering> section in applicationHost.config under the control of administrators. You should always consider the potential impact on security whenever you make any changes to your configuration.
Applying the Appropriate Level of Administrative Control to Your Web Sites
Each Web site is different, and there may be many variations in architecture and goals from site to site. Therefore, instead of simply using default settings, we recommend that you carefully consider the benefits versus the risks of unlocking each setting for your environment and sites. The settings outlined in this document pertain to www.microsoft.com and may not apply to other sites and applications that we host.
Unlocking IIS Configuration Settings
When the MSCOM Ops team embarked on the path of migrating to Microsoft® Windows Server™ 2008 and IIS 7.0, it became clear that the one of biggest benefits was the simple, clear applicationHost.config file and its associated schema file, IIS_schema.xml (which is located in %windir%\system32\inetsrv\config\schema). We could easily browse through these files to view available properties, settings, and default values. To reduce the size of the file and improve readability, many of the default settings are not listed in applicationHost.config. Instead, the values for these default settings are stored in IIS_schema.xml.
The <configSections> section near the beginning of the applicationHost.config file controls the registration of sections, which are the basic unit of locking for configuration settings. Each section has an overrideModeDefault attribute, the default delegation mode, that is set to either Allow or Deny.
The following are examples of sections in the <system.webServer> section group:
<section name="httpErrors" overrideModeDefault="Allow" />
<section name="httpLogging" overrideModeDefault="Deny" />
<section name="httpProtocol" overrideModeDefault="Allow" />
<section name="httpRedirect" overrideModeDefault="Allow" />
<section name="httpTracing" overrideModeDefault="Deny" />
At first glance, one might think that simply changing the vaule of overrideModeDefault is how sections can and should be unlocked. Although changing this vaule unlocks or locks these sections at a global level, it is not recommended because:
· Making this global change allows any Web site or application on the Web server to override the unlocked setting, which may be more than what is actually necessary.
· The overrideModeDefault is part of the section declaration, and it is best to keep the declaration separate from the implementation of the configuration. Section declaration is part of the installation process. Therefore, if an administrator were to uninstall and then reinstall a feature for a section, the overrideModeDefault would be reset.
· The Reset all Delegation feature in IIS Manager relies on the overrideModeDefault values.
Instead, you should add <location> tags to applicationHost.config, because they allow you to apply configuration settings to a very specific path within the Web server application hierarchy.
For more information about configuring the delegation state of IIS Manager features for sites and applications on your Web server, see "Feature Delegation Page".
The following example demonstrates how to unlock <defaultDocument> at the Web site level.
<location path="mySite" overrideMode=”Allow”>
<add value="default.aspx" />
By setting the location value to mySite and overrideMode to Allow, you apply the configuration settings specified in the location section to the mySite Web site and any applications and virtual directories below the site in the directory hierarchy. Application owners can then override any setting specified in the <location> section at any location in the hierarchy by using web.config files.
After <defaultDocument> is unlocked at the Web site level, all applications within that Web site inherit the settings and can override <defaultDocument> if necessary. The following example demonstrates how to override the <defaultDocument> setting for the application mySite/myApplication by using a web.config file that resides in the same physical directory as myApplication. This setting is stored in the web.config in the <system.webServer> section along with the ASP.NET settings, which are declared in the <system.web> section.
<!-- ASP.NET Settings -->
<!-- IIS 7.0 Settings -->
<add value="default2.aspx" />
More granular locking is possible by locking or unlocking section attributes. For more information about locking attributes, see “How to Use Locking in IIS 7.0 Configuration”.
Sections can also be locked by using the same technique. In the following scenario, the <defaultDocument> value for all applications and virtual directories in the mySite Web site is default.aspx. The overrideMode is set to Deny so that the <defaultDocument> value cannot be overridden in application-level web.config files. Any attempt to do so results in a configuration error.
The following example demonstrates how to lock the <defaultDocument> section for the mySite Web site.
<location path="mySite" overrideMode=”Deny”>
<add value="default.aspx" />
Configuration Settings that You Cannot Delegate
There are limitations to which configuration settings you can delegate. For example, you cannot delegate the following tasks:
· Application pool assignment and creation
· Web site creation and bindings
· Adding global modules
These tasks cannot be delegated because non-administrators could make changes that might extend beyond the scope of their applications. For example, changing the application pool identity to Local System would result in elevated privileges, which would not only change scope, but could potentially result in a security problem.
How Microsoft.com Engineering Operations Uses Locking
Some configuration settings are locked by default, but many are allowed. The following list contains the complete list of <system.webServer> sections in applicationHost.config that are unlocked by default:
MSCOM Ops also unlocks the following sections by using <location> tags:
Additionally, MSCOM Ops locks the following sections, which are allowed by default:
In contrast, none of the ASP.NET settings in the root web.config is locked at the global level by default. Therefore, application owners can override the global settings in their web.config files at the application level. However, we do lock some settings due to performance and security implications. The settings that we lock are:
For more information about how to lock ASP.NET configuration settings, see "How to: Lock ASP.NET Configuration Settings".
For more information about the settings listed in this section and their associated modules, see "Installing Windows Server 2008 Role Features" in "Customizing IIS 7.0 Roles and Modules".
Performing Remote Administration and Feature Delegation by Using IIS Manager
Another approach to delegation in IIS 7.0 is to use IIS Manager to configure remote administration and feature delegation. Administrators can grant application owners permissions to remotely connect to Web servers by using IIS Manager, and allow specific configuration settings to be controlled in a manner similar to that of the distributed configuration file model. One of the key considerations in this scenario is administrative overhead.
Microsoft.com Ops does not use feature delegation due to the additional cost of managing user permissions for hundreds of users. No additional work is necessary to configure delegation because file ACLs are already in place on the folders for each application.
For more information about how to configure remote administration and feature delegation, see "Configuring Remote Administration and Feature Delegation in IIS 7.0".
In this article, we described how the Microsoft.com Engineering Operations team determines whether to delegate IIS 7.0configuration settings, and included our recommendations. We discussed considerations such as performance and availability, security, and delegating administrative control to Web sites. We also described configuration settings that we unlock by using <location> tags and settings that we lock.