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

Performing Application-Specific Migration Tasks

When no setup or provisioning scripts exist for your applications, you might need to perform additional application-specific migration tasks, whether you have migrated content and metabase information manually or with the IIS 6.0 Migration Tool. Some of these tasks involve the modification of application code and might require the assistance of the application developers. Depending on your application, you might need to perform any combination of the steps in Figure 6.8.

Figure 6.8: Performing Application-Specific Migration Tasks

Modifying Application Code for Compatibility with Windows Server 2003 and IIS 6.0

If any application code needs to be changed or recompiled to run on Windows Server 2003, you must make those changes manually. The most common application code changes include the following:

Code that references Windows platform components or APIs no longer supported in Windows Server 2003.

Code that references IIS metabase properties that have changed or are no longer supported in IIS 6.0.

Code that is incompatible with worker process isolation mode.

Modifying References to Windows Platform Components and APIs No Longer Supported in Windows Server 2003

Applications developed to run on earlier versions of Windows server operating systems and IIS can call APIs that are not supported in Windows Server 2003 and IIS 6.0. Usually these APIs are replaced with newer APIs that provide additional functionality.

If your Web sites and applications use an API that is not supported in Windows Server 2003 and IIS 6.0, you must modify your code to use an API that provides the same functionality and is supported in Windows Server 2003 and IIS 6.0.

For example, the APIs supported by the Collaboration Data Objects for Windows NT Server 4.0 (CDONTS) DLL are not supported in Windows Server 2003. The functionality provided by CDONTS is supported by Collaboration Data Objects for Windows 2000 (CDOSYS), which, in turn, is supported by Windows Server 2003. Therefore, if your applications use CDONTS, you can modify your code to use CDOSYS instead. For more information about modifying your application to use CDOSYS, see the Collaboration Data Objects Roadmap link on the Web Resources page at [http://www.microsoft.com/windows/reskits/webresources].

Modifying References to IIS 6.0 Metabase Properties

Some metabase properties that were used to configure features in earlier versions of IIS are no longer supported in IIS 6.0. Because some features are eliminated, or implemented differently in IIS 6.0, the corresponding unused metabase properties are not referenced by any code in IIS 6.0. In cases where the feature is implemented differently in IIS 6.0, new metabase properties have been created to replace the obsolete, or unused, properties.

In addition, there is one IIS 5.0 metabase property — CPUResetInterval — whose behavior has changed because of architectural changes made to IIS 6.0.

To determine whether any of your Web sites, applications, or setup programs reference these changed or unsupported IIS metabase properties, see "Changes to Metabase Properties in IIS 6.0" in this book. You can then follow the recommendations associated with each changed metabase property listed in this appendix to accommodate functionality changes in IIS 6.0.

Modifying Applications To Be Compatible with Worker Process Isolation Mode

Most applications that were developed to run on earlier versions of IIS run in worker process isolation mode without modification. However, you might need to modify your applications to make them compatible with worker process isolation mode. For more information about the types of modifications that you might need to make to your applications, see "Application Changes Required for Worker Process Isolation Mode" earlier in this chapter.

Your applications can require other modifications that are not described in this chapter because of the myriad of approaches to developing applications. For the most current information about modifying your applications to be compatible with worker process isolation mode, see the MSDN Online link on the Web Resources page at [http://www.microsoft.com/windows/reskits/webresources], and search for relevant articles.

Installing Additional Software Required by Applications

Some of your applications might require or be dependent upon additional software that is not in the same folder with the Web site content. This software can be developed by your organization, by Microsoft, or by other organizations. You must install this software on the target server by running the setup or installation program that accompanies the software.

Examples of this type of software include software that creates reports, integrates databases with dynamic content generation, or provides connectivity with applications running on other servers with non-Microsoft operating systems.

Migrating MTS Packages, COM Objects, and COM+Applications

In addition to installing any software that you installed earlier in the migration process, there can be MTS packages, COM objects, and COM+ applications that need to be migrated. Table 6.5 lists the tasks that you need to complete to migrate MTS packages, COM objects, and COM+ application from earlier version of Windows.

For more information about migrating MTS packages, COM objects, and COM+ applications to Windows Server 2003, see the following articles: "COM: Delivering on the Promises of Component Technology", which you can find on the Microsoft Web site at IIS Deployment Procedures" in this book.

Modifying ODBC Data Connection Strings and DSNs

If your application establishes database connectivity through an ODBC data connection string or through an ODBC data source name (DSN), you must do any combination of the following:

Manually modify ODBC DSNs when the ODBC data connection string references a database that is stored on the source server and the database has not been migrated to the target server.

Manually create a system ODBC DSN on the target server for each system ODBC DSN on the source server.

Modifying ODBC DSNs

ODBC data connection strings might need to be modified if they reference the database or are migrated to a different location. For more information about modifying ODBC data connection strings, see the article "Connection String Format and Attributes." To find this article, see the MSDN Online link on the Web Resources page at [http://www.microsoft.com/windows/reskits/webresources], and then search for "ODBC connection string".

Creating System ODBC DSNs

In addition, if you have system ODBC DSNs that are defined on the source server, you need to create corresponding ODBC DSNs on the target server. Table 6.6 lists methods for administering ODBC DSNs on different Windows server operating systems. You can administer ODBC DSNs on the source server and the target server by using the methods listed in this table.

Creating IP Addresses That Are Used by Applications

You can uniquely identify a Web site or application by associating the Web site or application with a unique IP address, a unique combination of an IP address and a TCP port number, or host headers. For Web sites and applications on the source server that are uniquely identified by IP addresses, you must create corresponding IP addresses on the target server and then configure the Web sites and applications to use the newly created IP addresses.

To create IP addresses that are used by applications, complete the following steps:

Determine which Web sites and applications on the source server are uniquely identified by IP addresses.

For more information about how to determine which Web sites and applications on the source server are uniquely identified by IP addresses see, "Determine Web Sites Uniquely Identified by IP Addresses" in "IIS Deployment Procedures" in this book.

For each Web site and application identified in Step 1, assign new a new IP address to the TCP/IP properties of the network adapter in the target server that the clients use to access the Web sites and applications.

For more information about how to assign a new IP addresses to the network adapter in the target server that the clients use to access the Web sites and applications see, "Assign Additional IP Addresses to a Network Adapter" in "IIS Deployment Procedures" in this book.

Configure the migrated Web sites and applications on the target server to use the IP addresses assigned in Step 2.

For more information about how to configure the IP addresses assigned to Web sites and applications see, "Configure IP Address Assigned to Web Sites" in "IIS Deployment Procedures" in this book.

Creating Users and Groups That Are Used by Applications

The Web sites and applications on the source server might be accessed by accounts that are local to the source server. The local user and group accounts need to be created on the target server so that the accounts can access the Web sites and applications on the target server.

In cases where the users and groups that are used by the applications exist in Active Directory, no steps are required and you can continue to the next migration step. To continue to the next step in the migration process, see "Creating Registry Entries for Applications" later in this chapter.

Create the users and groups that are used by applications and are local to the source server by completing the following steps:

Identify the users and groups that are local to the source server.

For each group on the source server, create a corresponding group on the target server.

For each user on the source server, create a corresponding user on the target server.

For each user created in Step 3, assign the user to the same groups as the corresponding user on the source server.

For more information about viewing the users and groups on the source server, see "Creating user and group accounts" in Windows 2000 Server Help and Windows NT Server 4.0 Help. For more information about creating users and groups in Windows Server 2003, see "Create a Service Account" in "IIS Deployment Procedures" in this book.

For each user created in Step 3, assign the same user rights assigned to the corresponding user on the source server.

For more information about assigning user rights to a user, see "Grant User Rights to a Service Account" in "IIS Deployment Procedures" in this book.

Assign the same NTFS permissions for the content on the target server as the NTFS permissions for the content on the source server.

For more information about configuring NTFS permissions on the target server, see "Configure NTFS Permissions" in "IIS Deployment Procedures" in this book.

Creating Registry Entries for Applications

Some applications save configuration information in the Windows registry. If the setup program or provisioning script creates the registry entries, run the setup program or provisioning script on the target server. Otherwise, you must manually identify the registry entries and then re-create them on the target server.

Create application registry entries on the target server manually by completing the following steps:

Identify the registry entries required by the applications that are currently running on the source server.

Earlier in the migration process, you identified the registry entries required by the applications on the source server. For more information about identifying registry entries, see "Identifying Which Web Site and Application Components to Migrate", earlier in the chapter.

Back up the registry entries on the source server that you identified in the previous step by using the registry editor Regedit.exe.

For more information about backing up copies of registry entries, see "Back Up and Restore Registry Entries" in "IIS Deployment Procedures" in this book.

Copy the .reg backup file, created in Step 2, to the target server.

Modify the .reg backup file created in the previous step to accommodate for changes in disk volume letters, such a F:, or paths to folders by completing the following steps:

In Notepad, open the .reg backup file created in Step 2.

Search for specific references to disk volume letters or paths that you want to change, and update them to reflect the disk volume letters or paths on the target server.

Save the .reg file.

Restore the registry backup on the target server.

For more information about restoring registry entries, see "Back Up and Restore Registry Entries" in "IIS Deployment Procedures" in this book.