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

Migrating Apache-Specific Extensions

If the Apache Web site contains dynamic content, requires database connectivity, or includes external modules, you must separately migrate these Apache-specific extensions to complete the migration process.

Figure 7.8 illustrates the process for migrating Apache-specific extensions to IIS 6.0.

Figure 7.8: Migrating Apache-Specific Extensions to IIS 6.0

The Apache-specific extensions on Linux commonly include MySQL and PHP. The combination of Linux, Apache, MySQL, and PHP are often referred to as LAMP. LAMP is the application platform used for Linux systems. The migration of the Apache Web sites must include the migration of LAMP.

For more information about migrating Apache Web sites to IIS, see the Migration of Linux-Apache-MySQL-PHP Platform to Windows 2000 link on the Web Resources page at [http://www.microsoft.com/windows/reskits/webresources]. Although the white paper refers to IIS 5.0 and Windows 2000 Server, the processes and methods are applicable for IIS 6.0 and Windows Server 2003.

Important

Test the migration of Apache-specific extensions in your lab environment before starting the Web site migration.

The Apache-specific extensions that you might need to migrate include:

Dynamic content.

Database content and connectivity.

External modules.

Migrating Dynamic Content

The Apache to IIS 6.0 Migration Tool transfers the files that make up the dynamic content to the target server during the Web site content migration. However, the dynamic content typically cannot run on IIS and requires further steps. Table 7.5 describes the advantages and disadvantages of the methods for migrating dynamic content.

Table 7.5: Comparison of Methods for Migrating Dynamic Content
Migration Method	Advantages	Disadvantages
Run dynamic content on a preprocessor that ships with IIS and Windows Server 2003.	Requires minimal migration effort, depending on the extent of changes to the dynamic content. Requires no purchase of additional preprocessor.	Might not run as efficiently as dynamic content written in ASP or ASP.NET.
Run dynamic content on a preprocessor external to IIS and Windows Sever 2003.	Requires minimal migration effort, depending on the extent of changes to the dynamic content.	Might not run as efficiently as dynamic content written in ASP or ASP.NET. Requires purchase of an additional preprocessor.
Rewrite the dynamic content in ASP or ASP.NET.	Runs the dynamic content more efficiently than the other methods. Requires no purchase of additional preprocessor.	Requires the most migration effort because the dynamic content must be completely rewritten.

Important

When you run dynamic content written in preprocessors, you need to enable the Web service extensions (request handlers, such as Perl and CGI, that extend IIS functionality beyond serving static pages) for the preprocessor. For more information, see "Configuring Web Service Extensions" later in this chapter.

Run Dynamic Content on a Preprocessor that Ships with IIS

When you select this method for migrating the dynamic content, you must have the source code to the dynamic content and you must use a preprocessor that ships with IIS 6.0 and Windows Server 2003, such as CGI or Perl. You might have to adjust the code to accommodate any differences between preprocessors on Apache and IIS and between Linux and Windows.

Ensure that the version of the preprocessor supported on IIS 6.0 and Windows Server 2003 is compatible with the version of the code in the dynamic content. You most likely need to make modifications to the code in the dynamic content to compensate for version and platform differences. For example, CGI scripts migrated from Apache Web sites typically require modification to run on IIS 6.0 and Windows Server 2003.

Run Dynamic Content on a Preprocessor External to IIS

This method for migrating the external module assumes that you have the source code to the dynamic content and you can purchase or obtain a version of the preprocessor that runs with IIS, such as PHP. You might have to adjust the code to accommodate any differences between preprocessors on Apache and IIS 6.0.

For example, if the dynamic content is written in PHP, you must obtain a version of a PHP preprocessor for IIS to install and configure the PHP preprocessor on IIS 6.0. You must then adjust the PHP code to accommodate any differences between the PHP preprocessors on Apache and IIS 6.0.

Rewrite the Dynamic Content in ASP or ASP.NET

When you select this method for migrating the dynamic content, you need to evaluate the function of the original dynamic content, draft a functional specification for the dynamic content, and then develop a version of the dynamic content in ASP or ASP.NET.

For more information about selecting either ASP or ASP.NET, see the Active Server Pages and ASP.NET links on the Web Resources page at [http://www.microsoft.com/windows/reskits/webresources].

Migrating Database Content and Connectivity

Database connectivity provides a standardized method of connecting to various database systems. Although the Apache to IIS 6.0 Migration Tool migrated the Web site content and configuration, any database content and database connectivity must be migrated separately. Many Apache Web sites and applications use a database server, such as MySQL, the most common database connectivity standard used in Apache Web sites. Dynamic and static content can make requests to databases through MySQL.

For more information about how to migrate database content and connectivity to IIS, see the Migration of Linux-Apache-MySQL-PHP Platform to Windows 2000 link on the Web Resources page at [http://www.microsoft.com/windows/reskits/webresources]. Although the white paper refers to IIS 5.0 and Windows 2000 Server, the processes and methods are applicable for IIS 6.0 and Windows Server 2003.

Migrating the Database Content

The Apache to IIS 6.0 Migration Tool does not transfer the database content to the target computer. You must migrate the database content by other methods, whose advantages and disadvantages are described in Table 7.6.

Table 7.6: Comparison of Methods for Migrating Database Content
Migration Method	Advantages	Disadvantages
Obtain a copy of the database that is compatible with IIS 6.0 and Windows Server 2003.	Requires minimal migration effort. Administrators are familiar with administering the database engine.	Might not run as efficiently as Microsoft Data Engine (MSDE) or Microsoft SQL Server™ 2003. Requires purchase of an additional preprocessor.
Convert the database to MSDE or SQL Server 2000.	Might run more efficiently than the original database engine on IIS 6.0 and Windows Server 2003. Requires no purchase of additional database when using MSDE.	Requires more extensive conversion. Administrators might not be familiar with administering MSDE or SQL Server 2000.

Obtain a Copy of the Database Engine that is Compatible with IIS Most database engines on Linux have compatible versions that are designed for Windows. The easiest method of converting the database is to run the same database engine because little or no modification to the dynamic content is required. For more information, see the Web site or product documentation for the database engine used by the source server to determine if there is a version for Windows.

Convert the Database to MSDE or SQL Server 2000 Microsoft SQL Server supports the importing of data stored in other databases into SQL Server 2000. For example, you can import MySQL data directly into SQL Server 2000. You can use ODBC connectivity between MySQL and MSDE or SQL Server 2000 to import data as well. Client applications, such as Microsoft Access XP, can be used to import data through ODBC to MSDE or SQL Server 2000.

For more information about importing data into SQL Server 2000, see the SQL Server link on the Web Resources page at [http://www.microsoft.com/windows/reskits/webresources]. You can use the same methods for migrating data into MSDE as SQL Server 2000 because MSDE is based on SQL Server 2000.

Migrating the Database Connectivity

You need to ensure the dynamic content migrated to the target computer by the Apache to IIS 6.0 Migration Tool can use a database connectivity supported on IIS 6.0 and Windows Server 2003. Table 7.7 describes the advantages and disadvantages of the methods for migrating database connectivity.

Table 7.7: Comparison of Methods for Migrating Database Connectivity
Migration Method	Advantages	Disadvantages
Obtain a version of the database that runs on IIS 6.0 and Windows Server 2003.	Requires minimal migration effort.	Requires purchase of the database that is compatible with IIS 6.0 and Windows Server 2003.
Convert the dynamic content to use ADO or ODBC.	Requires no purchase of additional database.	Requires more extensive conversion.

Obtain a Version of the Database Connectivity that Runs on IIS 6.0

The database connectivity for dynamic content is implemented on Apache as libraries that are called by the dynamic content. When you install a version of the database connectivity on IIS 6.0 and Windows Server 2003, the appropriate libraries are also installed. There should be minimal changes to the dynamic content.

Note

This method assumes that you are installing a version of the database, such as MySQL, on the target server.

Convert the Dynamic Content to use Windows Database Connectivity

When you use this method, the assumption is that you are connecting to MSDE or SQL Server 2000 as the database engine through ODBC or ADO. If you are installing a version of the database engine on IIS 6.0 and Windows Server 2003, use the database connectivity libraries that accompany the database engine to reduce the effort required in the migration.

For example, there are ODBC drivers for MySQL; however, if you install MySQL on the target server, there is little or no conversion if you continue to use the MySQL libraries. In this case, converting your dynamic content to use ODBC has no long-term advantage unless you are planning to migrate to another database engine.

For more information about selecting ODBC, see the Open Database Connectivity (ODBC) link on the Web Resources page at [http://www.microsoft.com/windows/reskits/webresources]. For more information about selecting ADO, see the ActiveX Data Objects link on the Web Resources page at [http://www.microsoft.com/windows/reskits/webresources].

Migrating External Modules

External modules, such as Cold Fusion and Wpoison, provide extended features to Apache Web sites. The Apache to IIS 6.0 Migration Tool transfers external modules to the target computer if they are in the same directory with the other Web site content. When the external modules are stored in other directories, you must manually transfer the external modules to the target server. After the external modules are transferred to the target server, you must complete additional steps so that the external modules run on IIS and Windows Server 2003.Table 7.8 describes the advantages and disadvantages of the methods for migrating external modules.

Table 7.8: Comparison of Methods for Migrating External Modules
Migration Method	Advantages	Disadvantages
Obtain a version of the external module that runs on IIS 6.0 and Windows Server 2003.	Requires minimal migration effort. Source code for the external module is not required.	Might not run as efficiently as external modules written in ASP or ASP. Requires purchase of another version of the external module. Might require minor modifications to the Web site content to accommodate version differences.
Convert the external modules to run on the same preprocessor as IIS 6.0 and Windows Sever 2003.	Can require minimal migration effort, depending on the extent of changes to the code for the external module.	Might not run as efficiently as external modules written in ASP or ASP.NET. Might require the purchase of an additional preprocessor. Requires the source code of the external module so that the module can be converted.
Rewrite the external module in ASP or ASP.NET.	Runs the dynamic content produced by the original external module more efficiently. Requires no additional purchases.	Requires the most migration effort because the external module must be completely rewritten.

Obtain Version of External Module that Runs on IIS 6.0 and Windows Server 2003

When you select this method for migrating the external module, you need to purchase a version of the external module for Windows. Install and configure the external module on the target server using the documentation that accompanies the external module.

For example, if an Apache Web site uses Cold Fusion, you would purchase a version of Cold Fusion for IIS 6.0 and Windows Server 2003. After installing and configuring Cold Fusion on the target server, you might have to adjust the code, such as PHP, CGI, or Perl, that calls the external module to accommodate any difference between Cold Fusion on Apache and IIS.

Convert External Modules to Run on Same Preprocessor as IIS 6.0 and Windows Sever 2003

This method for migrating the external module assumes you have the source code to the external modules. In addition, you must have a preprocessor on IIS that supports the code in which the external module is written, such as PHP, CGI, or Perl. You might have to adjust the code to accommodate any differences between preprocessors on Apache and IIS.

Important

When you run external modules written in preprocessors, you need to enable the Web service extensions for the preprocessor. For more information, see "Configuring Web Service Extensions" later in this chapter.

Rewrite the External Module in ASP or ASP.NET

Select this method if no version of the external module exists for IIS 6.0 and Windows Server 2003 and you do not have the source code to the external module, or if you want to rewrite the external module to take advantage of the enhanced performance offered by ASP or ASP.NET. You need to evaluate the functions of the external module, draft a functional specification for the external module, and then develop a version of the external module in ASP or ASP.NET.

For more information about selecting either ASP or ASP.NET, see the Active Server Pages and ASP.NET links on the Web Resources page at [http://www.microsoft.com/windows/reskits/webresources].

Important

When you write ASP or ASP.NET applications, you must enable Web service extensions for ASP or ASP.NET. For more information, see "Configuring Web Service Extensions" later in this chapter.