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

Preparing for Migration

Before migrating your existing IIS Web sites, ensure that the Web sites, applications, and their components are compatible with Windows Server 2003 and IIS 6.0. If you have setup programs or provisioning scripts that you are currently using on the source server and that you intend to continue using after migration, then ensure that the setup programs and provisioning scripts are compatible with Windows Server 2003 and IIS 6.0.

In addition, determine whether the existing Web sites and applications are compatible with worker process isolation mode in IIS 6.0. In cases where the existing Web sites and applications are not compatible with worker process isolation mode, you can still migrate to IIS 6.0 and Windows Server 2003 by configuring IIS to run in IIS 5.0 isolation mode. This allows the Web sites and applications to utilize other Windows Server 2003 and IIS 6.0 improvements

Also, if you are migrating ASP.NET applications, you must ensure that the ASP.NET applications are compatible with the latest version of the .NET Framework. If your ASP.NET applications require version 1.0 of the .NET Framework, you must configure IIS to run in IIS 5.0 isolation mode.

Lastly, you must determine whether you can perform the migration with the IIS 6.0 Migration Tool or if you need to perform the migration manually. You need to be aware of the additional migration steps that you must complete manually, regardless of the migration method that you choose. This allows you to have the appropriate tools and resources available when you are ready to perform the migration.

Figure 6.2 illustrates the process for preparing to migrate Web sites to IIS 6.0.

Figure 6.2: Preparing for Migration of Web Sites to IIS 6.0

Identifying Which Web Site and Application Components to Migrate

Before you begin the migration, identify the components that comprise the Web sites and applications. In addition to identifying the components, you must determine if there are any special circumstances associated with migrating these components. This Web site and application component migration is in addition to the Web site content and configuration that needs to also be migrated.

If you have setup, installation, or provisioning scripts for these Web sites and applications, you can use them to help you identify the components. If no setup, installation, or provisioning scripts exist, you must identify the Web site and application components manually.

Table 6.1 illustrates common application components that require a specific action when migrating to IIS 6.0.

Determining Compatibility with Windows Server 2003

At a minimum, your existing system hardware and software must be compatible with the Windows Server 2003 family before migrating the Web sites and applications to IIS 6.0. You must identify any software or hardware devices that are incompatible with Windows Server 2003.

Compatibility of Existing Hardware

When you select the computer that will be the target server, ensure that the computer is compatible with Windows Server 2003. The most common hardware incompatibility is a device driver that is no longer supported or is not yet supported in Windows Server 2003. When a device is no longer supported, remove the existing device and then install an equivalent device that is supported by Windows Server 2003. When a device is not supported, look for updated drivers on the device manufacturer's Web site or see the Windows Update link on the Web Resources page at [http://www.microsoft.com/windows/reskits/webresources]. It is also important that you have the latest BIOS version that is available from your computer manufacturer.

For example, the target server might have a network adapter that is not included with Windows Server 2003. You can review the manufacturer's Web site to obtain a driver that is compatible with Windows Server 2003.

For more information about the hardware devices supported by the Windows Server 2003 operating systems, see the Hardware Compatibility List on the product CD-ROM or see the Hardware Driver Quality link on the Web Resources page at [http://www.microsoft.com/windows/reskits/webresources].

Compatibility of Existing Software

Before migrating, you need to consider the compatibility of your existing applications, or other software that is installed on your server, with Windows Server 2003. This includes software and tools from manufacturers other than Microsoft, as well as Microsoft server products that do not ship with the Windows operating system. Make sure that you have the latest versions of all preexisting software or service packs that are compatible with Windows Server 2003.

The most common software incompatibilities are caused when your application depends on software from another manufacturer that does not support Windows Server 2003. Or, you might have applications that were designed to run on Windows NT Server 4.0 or Windows 2000 Server operating systems, which reference APIs that have been changed or removed in Windows Server 2003.

To help you determine the compatibility of your existing software with Windows Server 2003, use the Windows Application Compatibility Toolkit before migrating your Web sites and applications to the target server. To download the latest version of the Windows Application Compatibility Toolkit, see the Windows Application Compatibility link on the Web Resources page at [http://www.microsoft.com/windows/reskits/webresources]. For the latest information about compatibility with Windows Server 2003, see the Windows Server 2003 link on the Web Resources page at [http://www.microsoft.com/windows/reskits/webresources].

Determining Application Compatibility with Worker Process Isolation Mode

IIS 6.0 can run in one of two distinct modes of operation, which are called application isolation modes. Application isolation is the separation of applications by process boundaries that prevent the applications from affecting one another, and it is configured differently for each of the two IIS application isolation modes: IIS 5.0 isolation mode and worker process isolation mode.

Worker process isolation mode uses the redesigned architecture for IIS 6.0. This application isolation mode runs all application code in an isolated environment. However, unlike earlier versions of IIS, IIS 6.0 provides isolation without a performance penalty because fewer processor instructions are run when switching from one application pool to another. Worker process isolation mode is compatible with most existing Web sites and applications. Whenever possible, run IIS 6.0 in worker process isolation mode benefit from the enhanced performance and security in IIS 6.0.

IIS 5.0 isolation mode provides compatibility for applications that depend upon the process behavior and memory model of IIS 5.0. Run IIS in this mode only when a Web site or application cannot run in worker process isolation mode, and run it only until the compatibility issues are resolved.

During the migration process, you install Windows Server 2003 and IIS 6.0 on the target server. IIS 6.0 is configured to run in worker process isolation mode by default. Before you begin migrating your production Web sites and applications, evaluate whether your Web sites and applications are compatible with worker process isolation mode. Most of the compatibility issues with IIS 6.0 occur when configuring IIS 6.0 to run in worker process isolation mode.

One of the most common reasons for incompatibility with worker process isolation mode is that applications do not recognize custom Internet Server API (ISAPI) extensions or dynamic-link libraries (DLLs) that depend on the memory and request processing models used by earlier versions of IIS. Determine application compatibility in your lab before migrating your existing IIS Web sites and application, and if you determine that your applications are not compatible with worker process isolation mode, you can run the applications in IIS 5.0 isolation mode.

Determine the compatibility of an application with worker process isolation mode by completing the following steps:

Evaluate the benefits of moving to worker process isolation mode.

Evaluate the application changes that are required so that the applications can run in worker process isolation mode.

Evaluate the management and provisioning script changes that are required to set up programs and provisioning scripts in worker process isolation mode.

Verify the compatibility of the application with worker process isolation mode in a lab.

Evaluating the Benefits of Worker Process Isolation Mode

Worker process isolation mode provides higher levels of security and availability for Web sites and applications than IIS 5.0 isolation mode. Therefore, it is recommended that you configure IIS 6.0 to run in worker process isolation mode.

Worker process isolation mode provides the following improvements to IIS 6.0.

Security Enhancements

IIS 6.0 includes a variety of security features and technologies that help ensure the integrity of your Web site content, and of the data that is transmitted through your sites. The following security enhancement is only available when IIS 6.0 is running in worker process isolation mode.

Default process identity for Web sites and applications is set to NetworkService

In IIS 5.0 isolation mode, the default process identity is LocalSystem, which enables access to, and the ability to alter, nearly all of the resources on the Web server. The potential of attacks is reduced in worker process isolation mode because Web sites and applications run under the NetworkService identity. The NetworkService identity is granted less privileges, which helps prevent an attack from compromising the Web server, which is possible with the LocalSystem identity.

Performance and Scaling Enhancements

Future growth in the utilization of your Web sites and applications requires increased performance and scalability of Web servers. By increasing the speed at which Hypertext Transfer Protocol (HTTP) requests can be processed and by allowing more applications and sites to run on one Web server, the number of Web servers that you need to host a site is reduced. The following are a few of the performance improvements included in worker process isolation mode.

Support for processor affinity for worker processes in an application pool

You can configure all of the worker processes in an application pool to have affinity with specific processors in a multiprocessor or server. Processor affinity allows the worker processes to take advantage of more frequent processor caching (Level 1 or Level 2).

Elimination of inactive worker processes and reclamation of unused resources

You can configure application pools to have worker processes request a shutdown if they are idle for a certain amount of time. This can free unused resources for other active worker processes. New worker processes are then started only when they are needed.

Distributing client connections across multiple worker processes

You can configure an application pool to have more than one worker process servicing client connections, also known as a Web garden. Because there are multiple worker processes, the incoming client connections are distributed across the worker processes and throughput is not constrained by a single worker process.

Ability to Isolate Web sites and applications from each other

You can isolate Web sites and applications without incurring a performance penalty. This is because the Web site and applications, and their associated ISAPI filters, run in the same process.

Availability Enhancements

Because worker process boundaries isolate the applications in an application pool from the applications in other application pools, if an application fails, it does not affect the availability of other applications running on the server. Deploying applications in application pools is a primary advantage of running IIS 6.0 in worker process isolation mode.

Reduced number of Web server restarts required when administering Web sites and applications

Many of the common operation tasks do not force the restart of the server or the Web service restart. These tasks, such as upgrading site content or components, debugging Web applications, or dealing with faulty Web applications, can be performed without affecting service to other sites or applications on the server.

A fault-tolerant request processing model for Web sites and applications

In IIS 5.0 isolation mode, each Web site or application has only one worker process. However, in worker process isolation mode, you can create a Web garden by configuring a number of worker processes to share the processing. The benefit of a Web garden is that if one worker process stops responding, other worker processes are available to accept and process requests.

Isolation of failed worker processes from healthy worker processes

In worker process isolation mode, IIS can determine that a worker process is failing and start a new worker process to replace the failing worker process. Because a new worker process is created before the old worker process terminates, users requesting the Web site or application experience no interruption of service. After IIS creates the new worker process, the failed worker process can be separated, or orphaned, from the application pool. The advantage of orphaning a worker process rather than terminating it is that debugging can be performed on the orphaned worker process.

Health monitoring of Web sites and applications

In worker process isolation mode, you can configure an application pool to monitor not only the health of the entire application pool, but also individual worker processes servicing the application pool. Monitoring the health of a worker process allows IIS to detect that a worker process is unable to serve requests and to take corrective action, such as recycling the failed worker process.

In addition, worker process isolation supports other responses when a failed worker process or application pool is detected. For example, IIS can attach a debugger to an orphaned worker process or notify an administrator that an application pool has failed due to rapid-fail protection.

Prevention of Web sites or applications that fail quickly from consuming system resources

In some cases, availability can be affected by Web sites and applications that fail very quickly, are automatically restarted, and then fail quickly again. The endless cycle of failure and restarting can consume system resources, causing other Web sites and applications to experience denial of services because of system resource shortages.

Worker process isolation mode includes rapid-fail protection that stops an application pool when too many of the worker processes assigned to an application pool are found to be unhealthy within a specified period of time.

Automatic restart of poorly performing Web sites and applications

Some Web sites and applications have memory leaks, are poorly coded, or have other unidentified problems. In IIS 5.0 isolation mode, these applications can force you to restart the entire Web server. The recycling feature in worker process isolation mode can periodically restart the worker processes in an application pool in order to manage faulty applications. Worker processes can be scheduled to restart based on several options, such as elapsed time or the number of requests served.

Evaluating Application Changes Required for Worker Process Isolation Mode

In most cases, the existing Web sites and applications can be hosted in worker process isolation mode without modification. However, the following are known application issues that can create incompatibilities with worker process isolation mode and require you to run IIS 6.0 in IIS 5.0 isolation mode.

Requires Inetinfo.exe. When the application must run in the same process with Inetinfo.exe, IIS must be configured to run in IIS 5.0 isolation mode because Inetinfo.exe does not process Web requests in worker process isolation mode. In worker process isolation mode, W3wp.exe processes Web requests.

Requires Dllhost.exe. When the application depends on Dllhost.exe to process Web requests for the application, IIS must be configured to run in IIS 5.0 isolation mode because Dllhost.exe is not available in worker process isolation mode.

Requires read raw data filters. If the application uses an IS API raw data filter, IIS must be configured to run in IIS 5.0 isolation mode.

Requires version 1.0 of the .NET Framework. When the application requires version 1.0 of the .NET Framework, IIS must be configured to run in IIS 5.0 isolation mode because version 1.0 of the .NET Framework is only supported in IIS 5.0 isolation mode.

Requires ISAPI filters or extensions that are incompatible with worker process isolation mode. When the application requires ISAPI filters or extensions that are incompatible with worker process isolation mode, IIS must be configured to run in IIS 5.0 isolation mode. ISAPI filters or extensions might be incompatible if the filter or extension has one of the following characteristics:

Runs in multiple instances and expects to be recycled by using the recycling provided in IIS 5.0.

Expects to have exclusive lock on a resource, such as a log file.

If any of the Web sites and applications running on the existing Web server has one or more of these characteristics, then do one of the following:

Configure IIS 6.0 to run in IIS 5.0 isolation mode to ensure Web site and application compatibility. If the Web sites and applications need to be hosted in IIS 5.0 isolation mode, then the migration process is complete.

Modify the existing applications to remove the dependencies.

Evaluating Management and Provisioning Script Changes Required for Worker Process Isolation Mode

When management or provisioning scripts exist for your Web sites and applications, you might need to modify them so that they properly set up the Web sites and applications for the application isolation mode that is running on the Web server — IIS 5.0 isolation mode or worker process isolation mode. If you do not modify your management and provisioning scripts as required, you will be unable to use them to install and configure your Web sites and applications on IIS 6.0.

For example, you might have a provisioning script that uses Microsoft Active Directory Service Interfaces (ADSI) to create a Web site and configure the site for High isolation in IIS 5.0 isolation mode, which does not exist in worker process isolation mode. After migration and when the Web server is running in worker process isolation mode, you need to modify the script to create application pools instead.

Common modifications that might be necessary to your setup programs and provisioning scripts include:

When the script installs an ISAPI extension or filter, you might need to modify the script to add an entry for the ISAPI extension or filter to the Web service extensions restriction list and set the status of the entry to Allowed.

For more information about modifying your setup programs or provisioning scripts to install and enable an ISAPI extension or filter, see "Configuring Web Service Extensions" later in this chapter.

When the script installs an application that contains dynamic content, you might need to modify the script to set the status of the appropriate Web service extensions to Allowed, so that IIS allows the dynamic content to run.

For more information about modifying your setup programs or provisioning scripts to enable dynamic content, see "Configuring Web Service Extensions" later in this chapter.

When the script installs a Web site or application that runs in High isolation in IIS 5.0, you might need to modify the script to create an application pool and configure the application pool with settings that are comparable to the original IIS 5.0 isolation settings.

For more information about modifying your setup programs or provisioning scripts to create and configure application pools, see "Configuring Application Isolation Settings in Worker Process Isolation Mode" later in this chapter.

When the script references metabase properties, you might need to modify the script if it references metabase properties that have changed or are no longer supported in IIS 6.0.

For more information about modifying your setup programs or provisioning scripts to reference the proper metabase properties in IIS 6.0, see "Modifying References to IIS 6.0 Metabase Properties" later in this chapter.

Verifying Application Compatibility with Worker Process Isolation Mode in a Lab

After modifying your Web sites, applications, setup programs, and provisioning scripts to be compatible with worker process isolation mode, you need to test your modifications in a lab. Be sure to test for compatibility before performing the migration process on a production Web server.

Verify the compatibility of your Web sites, applications, setup programs, and provisioning scripts with worker process isolation mode in a lab by completing the following steps:

Make an image backup of the source server.

Restore the backup to a Web server in your lab, referred to hereafter as a test source server. Ensure that the test source server is not connected to your production network, to prevent any problems encountered during the migration from affecting your production network.

Perform a migration from the test source server to the test target server.

Configure the test target server to run in worker processor isolation mode or IIS 5.0 isolation mode.

Make the necessary modifications to the Web sites, applications, setup programs, and provisioning scripts so that they are compatible with worker process isolation mode.

Verify that the Web sites, applications, setup programs, and provisioning scripts run correctly on the test target server.

For more information about setting up a test lab, see "Designing a Test Environment" in Planning, Testing, and Piloting Deployment Projects of the Microsoft Windows Server 2003 Deployment Kit.

Determining Application Compatibility with the .NET Framework

For a successful migration to Windows Server 2003 and IIS 6.0, you need to determine whether your ASP.NET applications are dependent on specific versions of the .NET framework. Windows Server 2003 ships with version 1.1 of the .NET Framework, while most of the .NET applications that were developed before the release of Windows Server 2003 were designed to run on version 1.0 of the .NET framework.

Typically, ASP.NET applications running on version 1.0 of the .NET Framework are compatible with version 1.1 of the .NET Framework. However, there might be some incompatibilities, the majority of which are security related and can be corrected by configuring the .NET Framework to be less restrictive.

For example, in the .NET Framework version 1.0, the .NET Framework only examines the SQLPermission.AllowBlankPassword attribute if the user actually includes the password keyword in their connection string. If an administrator or user sets the SQLPermision.AllowBlankPassword attribute to False, it is possible to specify a connection string like "server=(localhost);uid=sam" and succeed. In the .NET Framework version 1.1, this connection string fails.

You can use both version 1.0 and version 1.1 of the .NET Framework on the same server running IIS 6.0, which is also known as side-by-side configuration. Side-by-side configuration allows you to run a mixture of applications that require version 1.0 or version 1.1 of the .NET Framework. During your lab testing, determine the version of the .NET Framework that is required by your applications.

For a current list of possible compatibility issues when upgrading from version 1.0 to version 1.1 of the .NET Framework, see the Compatibility Considerations and Version Changes link on the Web Resources page at Configuring IIS to Use the Correct Version of the .NET Framework" later in this chapter.

Selecting a Migration Method

Before migrating your Web sites and applications to IIS 6.0, you need to determine whether to perform the migration manually or with the IIS 6.0 Migration Tool. It is recommended that you use the migration tool to begin the migration process, except when one of the following is true:

You have set up programs, installation scripts, or provisioning scripts for the Web sites and applications that you are migrating. When the Web sites and applications that you are migrating have setup programs, installation scripts, or provisioning scripts, use those programs or scripts to install the Web sites and applications on the target server. Ensure that the setup programs, installation scripts, and provisioning scripts have been properly modified to install the Web sites and applications on IIS 6.0.

The target server is configured to run in IIS 5.0 isolation mode. When the Web sites and applications that you are migrating require the target server to run in IIS 5.0 isolation mode, you must perform the migration manually. To determine whether your Web sites and applications are compatible with worker process isolation mode, see "Determining Application Compatibility with Worker Process Isolation Mode" earlier in this chapter.

The source server has a significant number of FrontPage extended Web sites. When the FrontPage extended Web sites make extensive use of the administrative and publishing security-related settings found in FrontPage 2000 Server Extensions, perform the migration manually. To ensure that these security-related settings are migrated properly to the target server, perform the migration manually and use FrontPage publishing to transfer the Web site to the target server.

You want to migrate individual virtual directories. When you want to migrate individual virtual directories, perform the migration manually. The IIS 6.0 Migration Tool only moves Web site content and configuration settings at the Web site level, which means that all of the virtual directories beneath the Web site are migrated to the target server.

If you determine that you need to perform the migration manually, then you can proceed to the next step in the migration process — Deploying the Target Server. Otherwise, you need to know which steps in the migration process are automated by the IIS 6.0 Migration Tool, and which steps you must complete manually after running the migration Tool. Knowing the role of the IIS 6.0 Migration Tool in the migration process enables you to have the appropriate tools and resources available when you are ready to begin the migration.

Identifying the Role of the IIS 6.0 Migration Tool

The IIS 6.0 Migration Tool is a command-line utility that automates some of the steps in the process for migrating Web sites and applications hosted on IIS 4.0 or IIS 5.0 to IIS 6.0. The migration tool does not provide an end-to-end migration solution, but it automates some of the time-consuming, repetitive migration tasks. Although the migration tool is conceptually similar to the IIS 5.0 Migration Tool, the IIS 6.0 Migration Tool is a completely new tool designed specifically for Windows Server 2003 and is not compatible with the previous tool.

Migration Tasks That Are Automated by the IIS 6.0 Migration Tool

The IIS 6.0 Migration Tool automates the following steps in the IIS migration process:

Transferring the Web site content. All of the files and folders located in the home directory of the Web site and virtual directories (which can be located outside of the home directory of the Web site) are copied from the source server to the target server. The NTFS file system permissions assigned to the files and directories that make up the Web site content on the source server are granted to the corresponding files and directories on the target server. Any content referenced by the Web site or application that is not located in subdirectories of the home directory of the Web site or in virtual directories is not migrated.

Transferring the Web site configuration in the IIS metabase. The configuration for each Web site and application, which is stored in the IIS metabase properties on the source server, is translated and then the corresponding IIS 6.0 metabase properties are appropriately configured on the target server.

Translating the application isolation configuration. The target server is running in worker process isolation mode. The application isolation configuration for each Web site and application on the source server is translated into application pool configuration settings on the target server.

Backing up the IIS metabase configuration to the target server. The IIS metabase configuration is backed up on the target server before migration. You can use this backup to restore the target server to a known state in the event that the migration process is not successful.

Migration Tasks That Must Be Completed Manually

The following steps in the Web site migration process must be completed after running the IIS 6.0 Migration Tool.

Migrating Additional Web Site and Application Content

The IIS 6.0 Migration Tool migrates all of the content that is located in the home directory of the Web site and in any subdirectories contained in that home directory. You can migrate any Web site and application content that is not located in these directories by completing the following steps:

Migrate content located outside the home directory and subdirectories of the Web site. When the Web sites and applications reference content that is located in folders outside of the home directory of the Web site or the virtual directories beneath the home directory, you must migrate this content manually.

Migrate content located in a virtual directory. When the virtual directory content on the source server is stored on a disk volume, such as F:, that does not exist on the target server, you must migrate this content manually.

Configuring Additional Web Site and Application Properties

After running the IIS 6.0 Migration Tool, the Web sites are configured comparably to how they were configured on the source server. However, depending on the configuration of the Web sites and applications on the source server, you might need to configure additional Web site and application properties, by completing the following steps:

Change the IIS metabase settings to reflect where Windows is installed. If the Windows Server 2003 systemroot path does not match the Windows systemroot path on the source server, you must modify the metabase settings on the migrated Web sites to reference the correct folder on the target server. For example, if Windows was installed on C:\WINNT on the source server, the IIS metabase entries for ScriptMaps, and HTTPErrors properties might still reference these paths, and therefore need to be updated on the target server.

Configure IIS properties that reference local user accounts. There are a number of Web site configuration properties on the source server that you can configure to utilize user accounts that are local to the source server. Local user and group accounts are not migrated from the source server to the target server by the IIS 6.0 Migration Tool. As a result, the migrated Web sites reference user accounts that do not exist on the target server. In these cases, you must configure the Web sites to utilize user accounts that are domain-based or local to the target server, and then re-create the file system permissions on migrated content by completing the following steps:

Configure local user NTFS permissions on content. If NTFS permissions are granted to local user accounts on the source server, you must create new user accounts, or designate existing user accounts, for use on the target server and then grant the corresponding NTFS permissions to the user accounts on the target server.

Configure anonymous account properties for Web sites and virtual directories. If a Web site or virtual directory is configured to use a user account on the source server for anonymous access (other than the default IUSR_computername account), you must create a new user account, or designate an existing user account, for use on the target server.

Configure IIS 4.0 and IIS 5.0 application isolation identities. If the Web sites or applications are isolated and are configured to use a local user account on the source server as the application isolation identity, you must create a new user account, or designate an existing user account, for use on the target server. Then you must configure the corresponding application pool, on the target server, to use the newly created account as the identity of the application pool.

Add Web service extensions for dynamic content used by the Web sites. Any dynamic content types, including ISAPI extensions, ISAPI filters, or CGI applications, which are not automatically migrated by the IIS 6.0 Migration Tool need to be added to the Web service extensions list.

Add MIME types for static content used by the Web sites. MIME types define the types of static files that are served by the Web server. You must identify the MIME types defined on the source Web server and then create the same associations of MIME types to file name extensions on the target Web server.

Configure SSL certificates. You must export server certificates for Secure Sockets Layer (SSL)-enabled Web sites from the source server, and then install the certificates on the target server after the migration process is complete.

Configure FrontPage Server Extensions users and roles. If FrontPage Server Extensions is configured to use a local user account on the source server as the FrontPage administrator, you must create a new user account, or designate an existing user account, for use on the target server. In addition, you must assign the user the same FrontPage role as the corresponding user had on the source server.

Configure IIS for ASP.NET applications. If you migrate ASP.NET applications from the source server, you might need to migrate the attribute settings in the Machine.config file that are used to set process-model behavior. When the target server is configured for worker process isolation mode, the attribute settings in the Machine.config file need to be converted to corresponding application pool settings. This is because ASP.NET uses the IIS process model when IIS is running in worker process isolation mode. For more information, see "Migrating Machine.config Attributes to IIS 6.0 Metabase Property Settings" later in this chapter.

Performing Application-Specific Migration Tasks

In addition to the IIS 6.0 configuration changes that are required, you might need to complete any migration tasks that are specific to the applications running on the source server. The application-specific steps that you might need to perform include the following:

Modifying application code for compatibility with Windows Server 2003 and IIS 6.0. When the applications on the source server are not compatible with Windows Server 2003 and IIS 6.0, you need to modify the applications. Most of these modifications are required when applications use application programming interfaces (APIs) no longer supported by Windows Server 2003 and IIS 6.0.

Installing additional software required by the applications. When applications on the source server require additional software that was developed by your organization, by Microsoft, or by other organizations, you need to install that software on the target server. This software can include filters and ISAPI extensions. You must obtain a version of the software that is compatible with Windows Server 2003 and IIS 6.0.

Migrating MTS packages, COM objects, and COM+ applications. When your applications include MTS packages, COM objects, or COM+ applications, you must migrate them to the target server. For MTS packages, you need to rewrite the MTS as a COM+ application.

Creating IP addresses that are used to uniquely identify the applications. Web sites and applications are uniquely identified by a unique IP address, a unique combination of an IP address and a TCP port, or host headers. When Web sites and applications on the source server are uniquely identified by IP addresses, you must create corresponding IP addresses on the target server and then configure the migrated Web sites and applications to use the new IP addresses.

Creating users and groups that are used by the applications. When users that access the applications on the source server have accounts that are local to the source server, you need to create new accounts on the source server and then assign the appropriate NTFS permissions on the target server to the new accounts. When the user accounts are in Active Directory, you only need to assign the appropriate NTFS permissions on the target server to the accounts in Active Directory.

Creating registry entries for the applications. When your applications store configuration information in the registry, you might need to create the same registry entries for the applications on the target server.

For information about using the IIS 6.0 Migration Tool to perform your migration, see "Migrating Web Sites with the IIS 6.0 Migration Tool" later in this chapter.