Microsoft Windows Server 2003 Deployment Kit—Deploying Microsoft Internet Information Services (IIS) 6.0 [Electronic resources] نسخه متنی

Configuring IIS 6.0 Properties

Up to this point in the migration process, you have migrated the Web site content and configuration settings from the source server — either manually or with the IIS 6.0 Migration Tool. However, you might need to further configure the IIS 6.0 properties on the target server so that the Web sites run as they did before they were migrated. In addition, you should configure your target server even further to utilize the enhanced security and availability capabilities of IIS 6.0.

Figure 6.7 illustrates the process for configuring the IIS 6.0 properties on the target server.

Figure 6.7: Configuring IIS 6.0 Properties

Configuring IIS 6.0 Properties That Reference Local User Accounts

The configuration of IIS and the Web sites on the source server can reference user accounts that are stored in the local account database on the source server. These accounts that are stored locally on the Web server are known as local user accounts. Local user accounts are valid only on the Web server where they are stored, not on any other Web servers.

As a result, when IIS, or any of the Web sites on the source server, reference local user accounts you must configure IIS 6.0 and the Web sites on the target server to reference:

Domain-based user accounts that you create.

Local user accounts that you create on the target server.

For each configuration that references a local account on the source server, you need to do the following on the target server:

Create, or designate, a domain-based or local user account that you can use to configure IIS.

For more information about creating a service account that is domain-based or local to the target server, see "Create a Service Account" in "IIS Deployment Procedures" in this book.

Modify the IIS 6.0 properties, Web site properties, or content configuration settings, based on the type of property that you are configuring.

The types of IIS 6.0 properties, Web site properties, or content configuration settings that can reference or use local user accounts include:

NTFS permissions assigned to Web content. Grant the same NTFS permissions to the account created in step 1 on the target sever as were granted to the local user account on the source server. For more information about granting NTFS permission to content, see "Configure NTFS Permissions" in "IIS Deployment Procedures" in this book.

Anonymous accounts for Web sites. Configure the anonymous account identity for a Web site to use the account created in Step 1 on the target server. For more information about configuring the anonymous account identity, see "Configure Anonymous User Identity" in "IIS Deployment Procedures" in this book.

Application isolation settings. Configure the application isolation identity based on the application isolation mode configured for the server.

When the target server is configured to run in worker processor isolation mode, configure the identity properties of the application pools. For more information about configuring the application isolation settings when the target server is configured for worker process isolation mode, see "Configure Application Pool Identity" in "IIS Deployment Procedures" in this book.

When the target server is configured to run in IIS 5.0 isolation mode, configure the identity properties of the COM+ applications that correspond to the Web site. For more information about configuring the application isolation settings when the target server is configured for IIS 5.0 isolation mode, see "Configure Application Isolation Settings in IIS 5.0 Isolation Mode" in "IIS Deployment Procedures" in this book.

Configuring Web Service Extensions

Many Web sites and applications that are hosted on IIS 6.0 have extended functionality beyond static Web pages, including the generation of dynamic content. Providing dynamic content and other enhanced capabilities requires executable code, such as ASP, ASP.NET, and ISAPI extensions. The handlers that extend IIS functionality beyond serving static pages are known as Web service extensions.

If you installed IIS 6.0 as described earlier in this chapter, all Web service extensions are disabled by default. If you used another method to install IIS 6.0, such as using Manage Your Server, the configuration of IIS might be different.

Enabling all of the Web service extensions ensures the highest possible compatibility with your Web sites. However, enabling all of the Web service extensions creates a security risk because it increases the attack surface of IIS by enabling functionality that might be unnecessary for your server.

Web service extensions allow you to enable and disable the serving of dynamic content. MIME types allow you to enable and disable the serving of static content. For more information about enabling and disabling the serving of static content, see "Configuring MIME Types" later in this chapter.

Configure the Web service extensions by completing the following steps:

Enable the essential predefined Web service extensions based on the information in Table 6.3.

For each Web service extension that is used by your applications and is not a one of the default Web service extensions, add a new entry to the Web service extensions list and configure the status of the new entry to Allowed.

For example, one of your applications might use an ISAPI extension to provide access to a proprietary database. Set the ISAPI extension used by the application to Allowed to explicitly grant it permission to run. For information about how to add a Web service extension to the list, see "Configure Web Service Extensions" in "IIS Deployment Procedures" in this book.

Use a Web browser on a client computer to verify that the Web sites and applications run on the server.

Configuring MIME Types

IIS 6.0 serves only the static files with extensions that are registered in the Multipurpose Internet Mail Extensions (MIME) types list. IIS 6.0 is preconfigured to recognize a default set of global MIME types, which are recognized by all configured Web sites. You can define MIME types at the Web site and directory levels, independently of one another or the types defined globally. IIS also allows you to change, remove, or configure additional MIME types. For any static content file extensions used by the Web sites hosted by IIS that are not defined in the MIME types list, you must create a corresponding MIME type entry.

Configure the MIME types after migration by completing the following steps:

For each static file type used by your Web site, ensure that an entry exists in the MIME types list.

When your application uses the standard MIME types that are included in IIS 6.0, no new MIME types entry is required. For information about how to add a MIME type to the MIME types list, see "Configure MIME Types" in "IIS Deployment Procedures" in this book.

Use a Web browser on a client computer to verify that the Web sites and applications run on the server.

Migrating Server Certificates for SSL

If you use Secure Sockets Layer to encrypt confidential information exchanged between the Web server and the client, you must migrate the server certificate from the source server to the target server, install the certificate on the target server, and then configure the Web site to use the certificate.

Migrate the server certificate for SSL by completing the following steps for each Web site and application that uses SSL:

Export the server certificate for the Web site from the source server.

For more information about exporting a server certificate, see "Export a Server Certificate" in "Deployment Procedures" in this book.

Install the server certificate to be used by the Web site on the target server.

For more information about installing the server certificate on the Web server by using the Certificate MMC snap-in, see "Install a Server Certificate" in "Deployment Procedures" in this book.

Assign the server certificate to the Web site.

For more information about assigning the server certificate to the Web site, see "Assign a Server Certificate to a Web Site" in "IIS Deployment Procedures" in this book.

Migrating FrontPage Users and Roles

When the source server has Web sites that are FrontPage extended and FrontPage roles have been assigned to the Web site users, you need to migrate the FrontPage roles to the target server. The FrontPage roles control the types of access that users have on FrontPage extended Web sites. FrontPage 2002 Server Extensions are administered through the Microsoft SharePoint™ Team Services HTML administration tool, which is installed with FrontPage 2002 Server Extensions.

The predefined FrontPage roles include the following:

Administrator. Users assigned this role can view, add, and change all server content; and manage server settings and accounts.

Advanced author. Users assigned this role can view, add, and change pages, documents, themes, and borders; and recalculate hyperlinks.

Author. Users assigned this role can view, add, and change pages and documents.

Contributor. Users assigned this role can view pages and documents, and view and contribute to discussions.

Browser. Users assigned this role can view pages and documents.

In addition to the predefined FrontPage roles, custom FrontPage roles might be defined on the source server.

Migrate FrontPage users and roles by completing the following steps:

Identify the FrontPage roles on the source server and compare them to the FrontPage roles on the target server.

Create any FrontPage roles on the target server that exist on the source server but do not exist on the target server.

For each FrontPage user on the source server that is local to the source server, create a corresponding user on the target server, and then assign that user the same FrontPage roles that are assigned to the corresponding user on the source server.

For each FrontPage user on the source server that is in Active Directory, assign the user the same FrontPage roles on the target server.

For more information about configuring the FrontPage 2002 Server Extensions users and roles, see "Configure FrontPage Server Roles" in "IIS Deployment Procedures" in this book. For more information about administering FrontPage 2002 Server Extensions, see the SharePoint Team Services Administrator's Guide link on the Web Resources page at [http://www.microsoft.com/windows/reskits/webresources].

Configuring IIS 6.0 to Host ASP.NET Applications

If you migrated any ASP.NET applications to the target server, you need to configure IIS 6.0 to use the correct version of the .NET Framework, and you must configure the .NET Framework to support your applications.

Configure IIS 6.0 to host ASP.NET applications by completing the following steps:

Configure IIS 6.0 to use the correct version of the NET Framework.

Configure the .NET Framework.

Review how ASP.NET applications run in each application isolation mode.

Migrate Machine.config attributes to IIS 6.0 metabase property settings.

Configuring IIS to Use the Correct Version of the .NET Framework

If you have migrated ASP.NET applications that were developed with version 1.0 of the .NET Framework, you might have to install version 1.0 of the .NET Framework on the target server to ensure that your applications continue to function properly. After migration, version 1.1 of the .NET Framework is installed on the target server and the applications are configured to use version 1.1 of the .NET Framework. After installing version 1.0 of the .NET Framework, both version 1.0 and 1.1 of the .NET Framework are installed on the target server. This is referred to as side-by-side support.

Running versions 1.0 and 1.1 of the .NET Framework side-by-side is only supported when IIS is configured to run in IIS 5.0 isolation mode. If you have already configured IIS to run in worker process isolation mode, then you can only use version 1.1 of the .NET Framework on the target server. In most cases, ASP.NET applications function correctly with version 1.1 of the .NET Framework. For more information about possible application incompatibilities when migrating from version 1.0 to version 1.1 of the .NET Framework, see "Determining Application Compatibility with the .NET Framework" earlier in this chapter. When your ASP.NET application is incompatible with version 1.1 of the .NET Framework, configure the application to use version 1.0 of the .NET Framework and configure IIS to run in IIS 5.0 isolation mode.

You can configure each ASP.NET application to use a specific version of the .NET Framework by registering a script map in IIS for the application. A script map associates a file name extension and HTTP verb with the appropriate ISAPI for script handling. For example, when IIS receives a request for a .aspx file, the script map for the corresponding application directs IIS to forward the requested file to the appropriate version of the ASP.NET ISAPI for processing.

The script map for each ASP.NET application can be applied directly to an application, or inherited from a parent application. However, ASP.NET supports only one version of the .NET Framework for each application pool. For more information about how to configure the script map for an ASP.NET application, see "Configure an ASP.NET Application for ASP.NET" in "IIS Deployment Procedures" in this book.

Configuring the .NET Framework

The configuration method for the .NET Framework is determined by the application isolation mode that you use to configure IIS 6.0. Table 6.4 lists the methods for configuring the .NET Framework that are associated with each IIS 6.0 application isolation mode.

When IIS 6.0 is configured to run in IIS 5.0 isolation mode, the .NET Framework uses the <processModel> section of the Machine.config file (in the systemroot\Microsoft.NET\Framework\versionNumber\Config folder) for its configuration and no additional steps are required.

However, if you configured IIS 6.0 to run in worker process isolation mode, the .NET Framework ignores the <processModel> section of the Machine.config file, and instead gets its process configuration from the IIS 6.0 metabase. Because the migration process does not migrate the existing settings in the Machine.config file, you must manually convert any settings required by the ASP.NET applications.

For information about how to convert the Machine.config attribute settings to IIS 6.0 metabase property settings, see "Deploying ASP.NET Applications in IIS 6.0" in this book.

Reviewing How ASP.NET Applications Run in Each Application Isolation Mode

When running IIS 6.0 in worker process isolation mode, ASP.NET applications use the W3wp.exe worker process and application pool properties, which are stored in the IIS 6.0 metabase. When you configure IIS 6.0 to run in IIS 5.0 isolation mode, ASP.NET applications use the ASP.NET request processing model, Aspnet_wp.exe, and configuration settings. These configuration settings are stored in the Machine.config file.

Behavior of ASP.NET Applications That Are Running in IIS 5.0 Isolation Mode

By default, ASP.NET applications are configured to run in worker process isolation mode. If your application can only run in the ASP.NET process model, you must configure the server to run in IIS 5.0 isolation mode to be able to run the application on IIS 6.0. When IIS 6.0 is configured to run in IIS 5.0 isolation mode, ASP.NET applications behave as follows:

The applications run within Aspnet_wp.exe.

Aspnet_wp.exe is a request processing model that is similar to worker process isolation mode, and it contains worker process management capabilities similar to the WWW service in IIS 6.0. Aspnet_wp.exe includes most of the IIS application management features, such as recycling, health detection, and processor affinity. Processor affinity is the ability to force worker processes to run on specific microprocessors.

The configuration settings are stored in the Machine.config file.

When IIS 6.0 is running in IIS 5.0 isolation mode, the configuration settings for ASP.NET applications are managed by modifying the Machine.config file, not the IIS metabase file. Because there is no administrative console for the Machine.config settings, any configuration settings for ASP.NET must be made directly to the Machine.config file.

When IIS 6.0 is configured to run in IIS 5.0 isolation mode, your ASP.NET applications should behave as they did in IIS 5.0. However, incompatibilities can result when running version 1.1 of the .NET Framework. For more information about configuring IIS to support ASP.NET applications that use version 1.0 of the .NET Framework, see "Running Different Versions of ASP.NET Side-by-Side" in "Deploying ASP.NET Applications in IIS 6.0" in this book.

Behavior of ASP.NET Applications That Are Running in Worker Process Isolation Mode

When IIS 6.0 is configured to run in worker process isolation mode, ASP.NET applications behave as follows:

The process model within the ASP.NET ISAPI extension is disabled, and ASP.NET applications run using worker process isolation mode in IIS 6.0.

In this configuration, the ASP.NET application runs in worker process isolation mode like any other application, such as an ASP application. In addition, IIS 6.0 provides all of the management features such as recycling, health detection, and processor affinity.

The ASP.NET ISAPI extension is configured by a combination of configuration settings that are stored in the IIS metabase (MetaBase.xml) and configuration settings in the Machine.config file.

When IIS 6.0 is running in worker process isolation mode, the majority of the application configuration settings are stored in the IIS metabase. You can adjust these settings directly in MetaBase.xml or from administrative consoles, such as IIS Manager, or scripts.

However, if there are existing settings in the <processModel> section of the Machine.config file, those configuration settings must be converted to the appropriate application pool settings when the Web server is configured to run in worker process isolation mode Additionally, there are other configuration settings that are still modified in the Machine.config file, regardless of the application isolation mode. For more information about converting Machine.config attributes to worker process isolation mode settings, see "Migrating Machine.config Attributes to IIS 6.0 Metabase Property Settings" later in this chapter.

When IIS 6.0 is configured in worker process isolation mode, your ASP.NET applications should behave as they did on IIS 5.0. Before deploying your ASP.NET applications on your production Web servers, test compatibility with IIS 6.0 running in worker process isolation mode and version 1.1 of the .NET Framework. For more information about determining application compatibility with IIS 6.0 running in worker process isolation mode, see "Determining Application Compatibility with Worker Process Isolation Mode" earlier in this chapter. For more information about determining compatibility with version 1.1 of the .NET Framework see "Determining Application Compatibility with the .NET Framework" earlier in this chapter.

If you determine that your ASP.NET applications are incompatible with worker process isolation mode, reconfigure IIS to run in IIS 5.0 isolation mode. If your ASP.NET applications are incompatible with version 1.1 of the .NET Framework, configure IIS to use version 1.0 of the .NET Framework with your ASP.NET application.

For more information about configuring IIS 6.0 to run in IIS 5.0 isolation mode, see "Configure Application Isolation Modes" in "IIS Deployment Procedures" in this book. For more information about configuring IIS to use version 1.0 of the .NET Framework with your ASP.NET application, see "Running Different Versions of ASP.NET Side-by-Side" in "Deploying ASP.NET Applications in IIS 6.0" in this book.

Migrating Machine.config Attributes to IIS 6.0 Metabase Property Settings

When IIS 6.0 is configured to run in IIS 5.0 isolation mode, the .NET Framework uses the <processModel> section of the Machine.config file (in the systemroot\Microsoft.NET\Framework\versionNumber\Config folder) for its runtime configuration. When the target server is running in IIS 5.0 isolation mode, you do not need to convert the attribute configuration settings on the source server to their equivalent IIS 6.0 metabase property settings on the target server so you can proceed to the next step in the migration process. To proceed to the next step in the migration process, see "Determining Whether to Run the IIS Lockdown Tool and UrlScan" later in this chapter.

However, if you configured IIS 6.0 to run in worker process isolation mode, the .NET Framework ignores the <processModel> section of the Machine.config file, and instead gets its process configuration from the IIS 6.0 metabase. Because the migration process does not migrate the existing settings in the Machine.config file, you must manually migrate any settings that are required by your ASP.NET applications.

For information about how to migrate the Machine.config settings to IIS 6.0 metabase settings, see "Migrating Machine.config Attributes to IIS 6.0 Metabase Property Settings" in "Upgrading an IIS Server to IIS 6.0" in this book.

Determining Whether to Run the IIS Lockdown Tool and UrlScan

The IIS Lockdown Tool and UrlScan are IIS security related programs designed for IIS 5.1 and earlier. Each tool provides different types of protection for earlier versions of IIS. The IIS migration process does not install the IIS Lockdown Tool and UrlScan on the target server.

IIS Lockdown Tool

The IIS Lockdown Tool is provided to assist administrators in configuring optimal security settings for existing IIS servers. You cannot install the IIS Lockdown Tool after migration because all of the default configuration settings in IIS 6.0 meet or exceed the security configuration settings made by the IIS Lockdown Tool.

UrlScan

UrlScan is a tool that is provided to reduce the attack surface of Web servers running earlier versions of IIS. By default, IIS 6.0 has features that significantly improve security by reducing the attack surface of the Web server. UrlScan provides flexible configuration for advanced administrators, while maintaining the improved security in IIS 6.0. When you need this flexibility in configuring your Web server, you can run UrlScan on IIS 6.0.

For more information about determining whether to run UrlScan after migrating your server to IIS 6.0, see the Using UrlScan link on the Web Resources page at [http://www.microsoft.com/windows/reskits/webresources].