Chapter 3 - Migrating a Web Server to IIS 5.0

Article
12/09/2009

The previous chapter, "Managing the Migration Process," gave an overview of the activities and planning steps involved in migrating Web services to IIS 5.0. The present chapter takes a "nuts and bolts" approach to the subject, providing information about migrating configuration settings, content, and applications to IIS 5.0 from another type of Web server. In addition to including the basic steps to accomplish this, the chapter explains using the IIS Migration Wizard to replicate configuration settings and content from a Web server running Apache HTTP Server, Netscape Enterprise Server, IIS 4.0, or IIS 5.0 itself to one running IIS 5.0. Should you plan to continue running another type of Web server along with IIS 5.0 on your network, you'll find information about interoperation methods and tools as well.

This chapter also reviews several approaches to migrating a Web application to IIS 5.0. It suggests considerations for deciding whether or not to rewrite a Common Gateway Interface (CGI) application as an Internet Server Application Programming Interface (ISAPI) extension or Active Server Pages (ASP) application in order to improve its functionality and performance.

Before migrating a Web server to IIS 5.0, you should know how to upgrade, configure, and administer the Microsoft® Windows® 2000 Server operating system and should have implemented a valid Windows 2000 Server domain and network design. For references on these subjects, see "Additional Resources" at the end of this chapter.

Basic Steps to Migrate a Web Server

Once you've completed the planning and preparatory steps described in the previous chapter, you're ready to begin migrating your Web server to IIS 5.0. This section describes the basic steps required to migrate from almost any type of Web server. Later sections provide details about migrating from Apache HTTP Server and Netscape Enterprise Server, as well as upgrading from IIS 4.0 to IIS 5.0 or replicating settings and content from one IIS 5.0 Web server to another.

The following steps are discussed in this section:

Assessing hardware requirements and acquiring any new hardware needed for deployment.
Preparing the destination computer by creating partitions, installing Windows 2000 Server with IIS 5.0, and structuring directories.
Using the IIS Migration Wizard.
Migrating Web and File Transfer Protocol (FTP) sites by replicating their content to the destination computer, correcting any problems with the files, and implementing special features.
Replicating Web application files to the destination server, configuring the applications, and installing and configuring any necessary script interpreters. Additional steps that might be required to migrate CGI applications to IIS 5.0 are discussed in "Migrating Web Applications" later in this chapter.
Migrating log files.
Migrating Web server configuration settings.
Securing the new Web server by importing user and group information, setting permissions, installing security certificates, and configuring other security parameters.

Note: You can use the IIS Migration Wizard, included on the Microsoft® Windows® 2000 Server Resource Kit companion CD, to replicate Web site content and migrate Web server settings from Netscape Enterprise Server 3.5 or Apache HTTP Server 1.3. You can also use the wizard to upgrade a server running IIS 4.0, or to replicate a server running IIS 5.0.

Assessing Hardware Requirements

The first thing you must do is decide what type of hardware to use for the migration, and then obtain it and set it up. There are four different approaches to migration, and each one has a different implication for deployment hardware. This section describes the pros and cons of each approach and the hardware required. Subsequent sections give more information about performing the migration steps mentioned here.

Migrate to a clean installation of Windows 2000 Server and IIS 5.0. Perform a clean installation of Windows 2000 Server and IIS 5.0 on a computer other than the production Web server. Migrate settings, content, and applications from the production Web server to the new IIS 5.0 server. Test and debug the new server before deploying it and taking the old production Web server offline.

Hardware needed: A second computer is required, in addition to the existing production Web server.

Pros: You can opt to put new, updated hardware in place at the same time you perform the migration. You also avoid taking your production Web server offline until the new server is tested and deployed. Following deployment, if problems arise with the new server that didn't appear during testing, you can use the original server as a backup.

Cons: You might need new hardware. However, the cost will be at least partly offset by the time saved conducting the migration as well as troubleshooting any problems that occur during the migration.

Recommendation: This method is highly recommended because it has the least likelihood of resulting in unforeseen problems. Because of the difficulty in conducting a cross-platform migration on a single computer, this is the only approach recommended for migrating a UNIX-based Web server to IIS 5.0.
Migrate a duplicate of a Windows NT–based Web server. If you're migrating from a computer running Microsoft® Windows® NT, you can use this approach: On a second computer, install the same software as exists on the production Web server, and then use the Windows 2000 Server Setup Wizard in order to upgrade to Windows 2000 Server and IIS 5.0. Migrate Web configuration settings, content, and applications to the new Web server. Test and debug the new server before deploying it and taking the old production Web server offline.

Hardware needed: A second computer is required, in addition to the existing production Web server.

Pros: You can opt to put new, updated hardware in place at the same time you perform the migration. You also avoid taking your production Web server offline until the new server is tested and deployed. Following deployment, if problems arise with the new server that didn't appear during testing, you can use the original server as a backup.

Cons: You might need new hardware. However, the cost will be at least partly offset by the time saved conducting the migration as well as troubleshooting any problems that occur during the migration.

Recommendation: This approach is acceptable, but it requires the preliminary step of installing the software on the new server. It is only feasible for a migration from a Windows NT–based server.
Migrate a mirror of a Windows NT–based Web server. If you're migrating from a computer running Windows NT, you can use this approach: Create a mirror image of the current production Web server (operating system, software, configuration settings, and content) on a second computer. Then use the Windows 2000 Server Setup Wizard to upgrade it to Windows 2000 Server and IIS 5.0. Migrate Web configuration settings, content, and applications to the new Web server. Test and debug the new server before deploying it and taking the old production Web server offline.

Hardware needed: For this approach to be successful, you need hardware exactly duplicating that of your existing server.

Pros: You avoid taking your production Web server offline until the new server is deployed. Following deployment, if problems arise with the new server that didn't appear during testing, you can use the original server as a backup.

Cons: All hardware on the second system must exactly duplicate the original server, so you forego having the option to upgrade your hardware at the same time you migrate or upgrade the Web server.

Recommendation: This method is fine if you don't need to upgrade your hardware, and it's far less risky than the next approach described. It is only feasible for a migration from a Windows NT–based server.
Migrate the production Web server. Take your production Web server offline. If it's already running Windows NT Server, use the Windows 2000 Server Setup Wizard to upgrade it to Windows 2000 Server with IIS 5.0. For a new installation, install Windows 2000 Server on a primary disk partition, which may require reformatting and repartitioning of the hard disk. Migrate Web configuration settings, content, and applications to IIS 'in place' on the production Web server. Test and debug the server before deploying it.

Hardware needed: No new hardware is required.

Pros: There is no hardware cost.

Cons: Migrating a production Web server is extremely risky. You must take the server offline, and it will not be available to users until you complete all migration tasks, testing, and debugging.

Recommendation: This method is not recommended.

Preparing the Destination Server

Once you've acquired and set up the necessary hardware, you need to take several steps to prepare the destination server for migration, including installing Windows 2000 Server and IIS 5.0, configuring directories, and installing tools and utilities.

Note: The destinationserver (sometimes called the target server) is running Windows 2000 Server with IIS 5.0, and the sourceserver is running the Web server software you plan to migrate. While source and destination servers could exist on the same physical computer, carrying out a migration on a single computer is not recommended. (The issues involved are described in the previous section, "Assessing Hardware Requirements.") Therefore, in this discussion, source and destination servers are assumed to exist on separate computers.

Back up the source server. Before you begin, create a backup file of all source server configuration settings, as well as files, applications, utilities, and other software used by your Web and FTP sites.

It's always good policy to have a backup of the server even when you are migrating to a separate computer. This step is critical if you plan to perform the migration on the actual production Web server (which, again, is not recommended). If anything goes wrong, you can then restore the original system and content.
Identify items to migrate. Decide which items to migrate from the source server. Note any applications and scripts you need to modify in order for them to run on IIS 5.0. To migrate these items, you need to transfer them to a development computer for modification, then to a test server for testing, and finally to the production Web server for deployment. For more information, see "Migrating Web Applications" later in this chapter.
Estimate disk space and partition requirements. Estimate the total disk space needed for data, files, applications, and server software on the destination computer. For each item, make a note of the disk partition on which it will reside (some considerations are discussed in the next step). Make sure the destination computer has sufficient hard disk space for your requirements.
Install Windows 2000 Server and IIS 5.0. Install Windows 2000 Server and IIS 5.0 on the destination computer. For more information, see the Windows 2000 Server product documentation.When installing to a new computer, choose the clean install option.By default, Windows 2000 installs as a file server. If you are using your server primarily as a Web server, you should install it as an application server.

During setup you create disk partitions and specify the file format for the primary, or system, partition onto which Windows 2000 Server will be installed. Be sure to allocate sufficient space in each partition for the content or system files it will hold. The following are some other issues to consider when creating disk partitions and specifying file format:
- Security To implement the highest level of security, format the partition onto which you install Windows 2000 Server as the NTFS file system. For more information about NTFS and security, see "Security" in this book.
  
  For security reasons, it is also a good idea to install the Windows 2000 Server and IIS 5.0 system software on a separate partition from the Web and FTP site content and applications. A good configuration might be as follows:
  
  Drive C: Allocate 1.5 to 2 GB of disk space for Windows 2000 Server and IIS 5.0 executables.
  
  Drive D: Allocate 1 to 2 GB of disk space for the IIS root and Web site directories.
  
  Drive E: Allocate sufficient disk space to contain remaining software and content for your server.
- Access from UNIX-based Computers Keep in mind that only Windows NT– or Windows 2000–based computers can natively access data and files stored on NTFS partitions. Therefore, when using NTFS in a mixed environment, you need to take additional steps to make sure files are available to UNIX-based computers. There are a couple of ways to do this. You can use Microsoft® Network File Sharing (NFS) client and server components that run on Windows 2000 and that support cross-platform file sharing. These and other useful tools and utilities are available as part of Windows NT Services for UNIX. For more information about these utilities, see https://www.microsoft.com/ntserver/techresources/interop/unix/sfu.asp.
  
  Likewise the SAMBA shareware application suite allows UNIX clients to access Windows-based file systems. It also allows Windows-based clients to access files and printers on UNIX, NetWare, OS/2, or VMS servers that support the Server Message Block (SMB) protocol. For more information about SAMBA, see https://samba.anu.edu.au/samba/.
For more information about creating and configuring Windows 2000 operating system partitions and directories, see the Windows 2000 Server online product documentation.
Configure Windows 2000 Server. After installation, the next step is to configure Windows 2000 Server networking and security, and any additional services. For references on setup and administration, see the Windows 2000 Server online product documentation, as well as the "Additional Resources" section at the end of this chapter.
Structure Web and FTP site directories. When you install IIS 5.0 for the first time, the Windows 2000 Server setup program creates a Web server directory structure in Windows Explorer at c:\Inetpub\wwwroot\. This is where actual Web site content and application files are stored. IIS 5.0 also creates a Default Web Site in the IIS snap-in of Microsoft® Management Console (MMC). It points to the content stored in the root directory and provides configuration settings (properties) for the Web site and its associated files. IIS 5.0 gives the Default Web Site the same name as the computer running IIS 5.0, unless the computer Internet Protocol (IP) address is registered with a different name on the Internet or your corporate network.

Figure 3.1 shows the Wwwroot directory in Windows Explorer and its associated Web site (in this case, the Default Web Site) in the IIS snap-in.

Figure 3.1 The Wwwroot Directory in Windows Explorer and the Default Web Site in the IIS Snap-in

You might be able to use the default directory structure as it is, or you might want to make some modifications to preserve paths (also called pathnames) within your content and application files. As much as possible, try to replicate the directory structure and names used on the source server. This minimizes broken links and the need to update URLs and pathnames within files following migration.

Note: The Default Web Site in the IIS snap-in points to the IIS 5.0 online product documentation, supporting code, and application samples (accessible from the IIS snap-in Help menu, or by typing https://localhost/ in the address bar of your browser). If you delete the Default Web Site, you will no longer be able to open these items. Also, be aware that the Default Web Site is assigned port 80 by default. When you create a new Web site in the IIS snap-in, it also will be assigned port 80 by default. In order to continue accessing the documentation, you must change the port number of any new Web site you create to something besides 80 so that it doesn't conflict with the Default Web Site. To avoid these problems, it is best to use the Default Web Site to manage your Web site, rather than creating a new one. For more information, see the "Adding Sites" topic in the IIS 5.0 online product documentation.

Storing Content outside the Web Server Root Directory

The Virtual Directory feature of the IIS 5.0 snap-in allows you to publish content to your Web and FTP sites that is stored outside of the Web server root directory tree (c:\Inetpub\wwwroot) in Windows Explorer. Content®HTML files, scripts, images, and other files®can be stored in any Microsoft® Windows® directory on the local computer or another computer on your network. The only restriction is that the network drive containing the directory must be in the same Windows 2000 Server Domain as the computer running IIS 5.0. For more information about virtual directories, see the "Creating Virtual Directories" topic in the IIS 5.0 online product documentation.
Install tools and utilities. Next, install tools and utilities on the destination server. These include all of the items you listed during the planning phase that must reside on the new server. If you're migrating from UNIX, you'll want to obtain and install the Windows 2000 Server counterparts of UNIX tools and utilities. Many of these are available on the Resource Kit companion CD. Others are available with Windows NT Services for UNIX. For more information, see https://www.microsoft.com/ntserver/techresources/interop/unix/sfu.asp.

You'll also want to obtain and install the appropriate script interpreters (also called scripting engines) to run applications written as scripts. IIS supports any scripting language for which you have installed a script interpreter that follows the Active Scripting standard. For ASP applications, IIS natively supports Microsoft® Visual Basic® Scripting Edition (VBScript) and Microsoft® JScript®, so you don't need to install their interpreters. Active Scripting interpreters for Perl 5.0 and Regina REXX are included on the Resource Kitcompanion CD and are also available through third-party developers. TCL/Tk, Python, and REXX script interpreters that are compatible with Microsoft® Win32® are available from third-party sources. In most cases, you should install the script interpreter in the Web server root directory (c:\Inetpub\wwwroot) and set appropriate NTFS and IIS 5.0 permissions. For more information, see "Configuring a Script Interpreter" and "Additional Resources" later in this chapter.

Using the IIS Migration Wizard

At this point, if you're migrating from Netscape Enterprise Server 3.5 or Apache HTTP Server 1.3, you can use the IIS Migration Wizard, included on the Resource Kit companion CD, to migrate Web site content and configuration settings. The wizard can also perform a cross-machine upgrade from IIS 4.0 to IIS 5.0, or replicate an IIS 5.0 Web server. Instructions for using the wizard are included on the Resource Kit companion CD.

You will still need to make necessary corrections to UNIX files to make them compatible with Windows conventions, as described later in "Converting UNIX File Names and Pathnames" and "Special Considerations for UNIX Applications." While the wizard replicates application files, you might need to take additional steps to migrate them, as described later in "Migrating Web Applications." In addition, you'll need to configure applications and components, as described in the "Configuring Applications" topic of the IIS 5.0 online product documentation.

Migrating Web and FTP Sites

The next step in migration is to populate the newly created IIS directories with Web and FTP site content by replicating these items from the source server to the destination server. Then you'll take additional steps to complete their migration by creating virtual directories, correcting file formatting problems, repairing broken hyperlinks, and implementing special features, such as content expiration, footers, and server-side includes.

Replicating Windows-Based Files

You can copy files and directories between two Windows-based computers by using FTP, a serial connection, or the rcp utility that comes with the Windows 2000 operating system, or by creating a shared directory and copying the files across your local area network (LAN).

Keep in mind that a simple file copy and paste operation does not preserve some file data, such as security configuration, hyperlinks, and share information. The following paragraphs discuss some methods of preserving file data.

Preserving Permissions and Audit Settings

To copy files while retaining current Windows permissions and audit settings, you can use the XCopyutility that comes with Windows 2000 Server, by typing the following at the command prompt:

XCopy <current>:\<dir> <new>:\<dir> /o /a /s

For more information about using this tool, see the Windows 2000 Server online product documentation.

Preserving Hyperlinks and Web Structure

Both Microsoft® FrontPage® and Microsoft® Visual InterDev® Web development systems can replicate Web sites from one Windows-based computer to another, while preserving site directory structure and hyperlinks. However, you will need to recreate virtual paths, as these tools don't import this information.

Copying files and directories is simple enough; however, share information isn't maintained in Windows directories, but rather in the registry, under LanmanServer. To preserve share information, you must also replicate this registry information from the source server currently hosting the shared files and directories, to the destination computer, as follows:

Note: The action described next will destroy any existing shares on the destination computer. Be sure to back up the registry before you begin.

Using the following registry key, save the source computer registry settings for shares to a file. Use Regedt32.exe, and not Regedit.exe, to edit the registry.

HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \LanmanServer \Shares

Copy the resulting settings file to the destination computer and then use the following registry key to restore the share settings to the destination server from this file. The settings will take effect after you restart the computer.

HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \LanmanServer \Shares

Caution Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible.

Replicating UNIX-Based Files

You can copy files and directories (directories are also called folders in Windows) from a UNIX-based computer onto disks or tape media, or move them across a network connection by using FTP. To transfer an entire Web directory tree in one file, you can use Tar.exe for concatenating files and directories, compress them with one of several available utilities, and then use recursive FTP to transfer them to Windows 2000 Server. SAMBA is also useful for transferring files between computers running UNIX and Windows operating systems.

You can also copy files across a network by using the Windows 2000 rcp client to access a UNIX computer that's running the rcp daemon called rshd (Remote Shell Daemon). With rcp you can specify security parameters, as well as recursively copy files and directories between source and destination computers. In this case, the name of the Windows 2000 Server computer must appear in the .rmhosts file on the UNIX computer. For more information, see the "RCP" topic in the Windows 2000 Server online product documentation.

Note: Microsoft® MS-DOS and Windows files use a carriage return and line feed character to mark the end of each line, while UNIX files use only a line feed character. The Windows 2000 rcp client automatically makes this conversion for you when run in ASCII transfer mode (the default).

Once the files are copied to Windows 2000 Server, you can separate any concatenated directories and files by using Tar.exe for Win32, or you can use WinZip to separate and uncompress them. WinZip provides built-in support for TAR, gzip, UNIX compress, UUencode, BinHex, and Multipurpose Internet Mail Extensions (MIME). Then you can move the files into the appropriate Web server directory, which is c:\Inetpub\wwwroot by default. For applications, it's particularly important to retain the original directory structure.

To obtain a public domain copy of Tar.exe for Win32, go to https://www.acs.oakland.edu/ and use the search term "nttar.zip."

Ws_ftp, a tool that performs recursive FTP, is available at https://www.shareware.com/.

To download an evaluation version of WinZip, see https://www.winzip.com/.

Items to Note about Windows File Systems

Here are a few items you might want to note about Windows file systems if you've been accustomed to working in a UNIX environment.

On a Windows File Allocation Table (FAT) file system, Write access to a file is equivalent to full access. To protect data shared on a FAT file system, share it as a read-only resource. NTFS provides more security options for protecting data and is generally recommended over FAT. For more information about NTFS security, see the Windows 2000 Server online product documentation.
Because Windows FAT file systems were designed around single-user computers, they don't support the concept of a file owner or file group. However, NTFS allows you to specify a file owner, which can be either an individual or a group.
Windows file systems do not support file links (symbolic links), but rather use a single-name/single-file concept with no support for multiple directory entries referring to the same file.

Converting UNIX File Names and Pathnames

When you migrate files and directories from a UNIX-based Web server, you need to edit file names and pathnames (called paths in Windows) so that they adhere to Windows conventions. Otherwise, hyperlink references to the files might malfunction, and in some cases files could be overwritten.

Conventions are slightly different between the Windows FAT and NTFS file systems. While for security reasons you will want to use NTFS as much as possible, there are cases where you might need to use FAT for cross-platform file sharing. The issues involved with both systems are described below.

File Name and Extension Length UNIX supports long file names and four-character file name extensions. When you copy a UNIX file or directory to a Windows FAT or NTFS file system, Windows truncates a long file name or extension using the Microsoft® MS-DOS® 8.3 convention. It reduces the file name to its first six letters followed by a tilde (~) and a unique number, for a total of eight characters, not including the extension. It truncates the extension to its first two letters, followed by a tilde (~). For example, the long name ProjectOverview.esti would change to Projec~1.es~.
Case Sensitivity UNIX file names are case sensitive. Windows FAT file names are not case sensitive, and Windows NTFS file names are "case aware." NTFS preserves case, but doesn't use it in some functions, such as indexing. In UNIX you can have two different files in the same directory with names distinguished only by case. For example, in any given directory you could have two different files, one named MyFile and the other named myfile. If you copy these files to a FAT directory, the Windows operating system preserves the letter cases of UNIX file names, but interprets the two names as being identical as long as they use the same characters in the same order, regardless of case. In this situation, the Windows operating system reads the first name correctly, and then reads the second as a duplicate name, and appends a number to it to make it unique. Using the previous example, this would result in the file name, MyFile(2). Because this is a different file name, any hyperlinks or applications that reference the file will malfunction. Therefore, before you copy UNIX files to a FAT directory make sure they have unique Windows-style file names, and also remember to correct any hyperlink or application references to the file name.
Illegal Characters The following characters are supported in UNIX-style file names, but are not permitted in Windows file or directory names:

/ \ : * ? " < > |

The Windows operating system will replace each occurrence of one of these characters with the letter "X."
Directory Separators UNIX pathnames use the forward slash (/) as a directory separator, and Windows paths use the backslash (\). Windows produces an error when it encounters UNIX-style pathnames.
Directory Hierarchy The UNIX file system appears to be a single directory hierarchy whereas Windows storage is divided into one or more physical or virtual disk drives with a directory hierarchy on each. To access a file on Windows, you must know what disk drive the file is on and specify the drive letter (C:, D:, E:, and so forth ) as part of the pathname for the file.

You also need to edit any file names and pathnames within UNIX application files in order to run them on Windows 2000 Server. This subject is discussed later, in "Migrating Web Applications."

Completing Web Site Migration

This section describes some additional steps you might need to take when migrating Web sites in order to restore hyperlinks, set up user Web sites, and replicate (or add) special features such as server-side includes, redirects, and directory indexes.

Repairing Hyperlinks

When you migrate Web pages, you need to find and repair any hyperlinks within them that were broken due to changes you might have made in the original Web site directory structure. You can use FrontPage features for testing and repairing hyperlinks, not only for internal URLs, but for those referring to external sites on the Internet as well.

Note: It is not recommended that you install the FrontPage client on the same computer as IIS 5.0. Instead, use FrontPage on a development computer to check and repair hyperlinks. Then publish the files to the computer running IIS 5.0, using the Web publishing features of FrontPage.

Setting up User Web Sites

IIS 5.0 provides the following options for implementing user Web sites, which are common in most Internet service provider (ISP) and volume hosting environments:

Host Headers Implementing the HTTP 1.1 host header standard, you can create multiple Web sites on a single IIS server that share the same IP address. For browsers that do not support the HTTP 1.1 standard, IIS displays the home page for the Default Web Site and can be configured to send a cookie that automatically redirects users to the selected site on their next visit. For this reason, it is recommended that ISPs use the Default Web Site for their Web site, rather than for a customer Web site. This Web site can then display links to customer Web sites.
IP Addressing You can create multiple Web sites by assigning each one a unique IP address.
UniquePort Numbers You can create multiple Web sites by assigning each one a unique port number. For sites using something other than port 80, which is the default, users must append the port number to the URL to access the site. For example, https://www.microsoft.com/IIS:82 would access a Web site named IIS that uses port 82.

For more information about implementing these methods, see the "Web and FTP Sites" and "Name Resolution" topics in the IIS 5.0 online product documentation.

Implementing Special Web Features

IIS 5.0 supports many popular Web site features, such as directory browsing and indexing, document footers, and server-side includes. The following paragraphs describe some features you might want to implement on your Web sites.

Directory Browsing and Indexing You can enable directory browsing and indexing on the Home Directory tab of Web Site Properties.
Document Footers You can specify a document footer on the Enable Document Footer tab of Web Site Properties. For more information about document footers, see the "Adding a Footer to Web Pages" topic in the IIS 5.0 online product documentation.
Dynamically Updated Content For content that must be frequently updated, you can generate dynamic Web pages by using ASP and HTML templates. IIS 5.0 builds pages on-the-fly from content that is dynamically extracted from a database. For more information about dynamic content, see "Data Access and Transactions" in this book.
Personalized Content By using Dynamic HTML (DHTML) or the Browser Capabilities Component you can detect user browser capabilities to provide personalized content based on the user environment. For more information, see the "Client Capabilities" topic in the IIS 5.0 section of the SDK documentation on MSDN.
Redirection (HTTP redirect) You can specify redirection from a Web site to another URL on the Home Directory tab of Web Site Properties.
Server-Side Includes IIS 5.0 supports server-side includes. A Web page that has included information must have the .stm file name extension. The virtual directory containing the .stm files must have either script or execute permissions enabled.
Time-Sensitive Content To direct the user's browser to expire cached content at a specific date and time, you can enable content expiration on the HTTP Headers tab of Web Site Properties.

Completing FTP Site Migration

Here are a few steps you can take to reproduce (or add) special FTP site features.

Creating User Directories To have a user automatically placed in their own FTP directory when logging on, create a virtual FTP directory with the same name as the user.
Limiting Access You can lock anonymous users into the FTP directory so they cannot browse outside it, while still enabling an authenticated client (who is not using FrontPage) to upload files to the same FTP directory.

To limit access
1. In Windows Explorer, place the FTP directory under the Www root directory.
2. In the IIS snap-in, point the FTP server to the FTP directory.
3. While still in the IIS snap-in, create a second FTP server under the first one and give it the same name as the user name of the client who wants to upload files.
4. Point the second FTP server to the FTP directory (the same one as in step 2).
5. In Windows Explorer set the following NTFS permissions on the FTP directory: give Anonymous FTP User Full Control on the FTP directory and deny all permissions on the root directory.
After logging in, the authenticated client is placed in the virtual FTP site that has the same name. The client has full control over directory content and can upload files. An anonymous user who logs in will be able to read the files, but will have no control over them and will be unable to browse outside the virtual FTP directory.
Creating Welcome Messages On the Messages tab of FTP Site Properties, you can create a welcome message that will be displayed to users when they enter the FTP site.

Replicating and Configuring Applications

Application files are a special case. Rather than copying them directly to the new IIS 5.0 server, application files should be transferred to a development computer for any necessary editing or rewriting, and then to a test computer for testing and debugging. When you're ready to deploy the application on the new IIS 5.0 server, follow the instructions given in the "Configuring Applications" topic of the IIS 5.0 online product documentation.

Later in this chapter, "Migrating Web Applications" describes your options for migrating a CGI application to IIS 5.0. You can leave it as a CGI and make relatively minor changes so it runs on IIS 5.0. Or you can rewrite it as an ISAPI extension or an ASP application. The pros and cons of each approach are discussed in terms of development costs and server resources.

Migrating Log Files

IIS 5.0 supports the new W3C Extended Logging Format, and you can migrate any compliant log file to IIS 5.0. IIS 5.0 logs are stored in ASCII (text) files. If you want to preserve logging information from the source server, you can copy ASCII data from your log files to the IIS 5.0 log files.

The primary difference between UNIX and Windows 2000 Server logging is that UNIX log files are generally stored and viewed in plaintext, but Windows 2000 Server provides a graphical user interface (GUI), called Event Viewer, for logging administration and viewing.

IIS 5.0 provides several features you can use to customize logged information, and you can either log to a text file or to an Open Database Connectivity (ODBC) Data Source Name (DSN) for dynamic evaluation. For more information about logging, see the "Logging Site Activity" topic in the IIS 5.0 online product documentation and "Administering an ISP Installation" in this book.

Migrating Configuration Settings

Web servers®whether they are IIS 5.0, Netscape, Apache, or some other type®perform many of the same basic functions, and therefore offer many similar configuration options. Web servers differ primarily in secondary features that address a special requirement, such as security. However, the way in which you configure a server and what settings are named can vary a great deal from one server to the next.

IIS 5.0 uses property sheets to provide a GUI for server configuration. You open property sheets from the IIS 5.0 MMC snap-in by right-clicking the item you want to configure, and then clicking Properties. For information about IIS 5.0 configuration options, see the "Server Administration" topic in the IIS 5.0 online product documentation.

You can set IIS 5.0 properties in the metabase for greater granularity at the computer, Web site, virtual directory, directory, and file level. For more information about the metabase, see the "Introduction to the IIS Metabase" topic in the IIS 5.0 online product documentation. For more information about automating IIS 5.0 administration tasks and administering from the command line, see "Administering an ISP Installation" in this book.

Here are some things to keep in mind when configuring IIS 5.0:

When in doubt, right-click. When you are running Windows, right-clicking a window or an object reveals a menu of useful operations. In the case of IIS 5.0, if you want to configure an object that appears in the IIS snap-in, such as the Administration Web Site, Default Web Site, or other Web site you have created, rightclick the object, and then click Properties. Then at the top of the dialog box, click the tab that corresponds to the configuration options you want to set.
If you get stuck, click the Help button. Click the Help button that appears in most dialog boxes to open a topic specific to that dialog box. You can also open the in-depth IIS 5.0 online product documentation as follows: In the left pane of the IIS snap-in window, click the Default Web Site and make sure it's running. At the top of the IIS snap-in window, click Help or click the Help toolbar button, and then click Help on Internet Information Services. You can also open IIS Help from Windows 2000 Server Help, from within the "Internet Information Services"topic.

Remember that the IIS snap-in isn't Windows Explorer. Even though the IIS snap-in and Windows Explorer look very similar, you use them for different purposes. In the IIS snap-in, you configure Web site, FTP site, and Web administration properties. In the IIS snap-in you can also create virtual directories for a Web or FTP site, but only in Windows Explorer can you actually manage files and directories, performing operations such as the following:
- Copying files and directories (or folders) to your Web and FTP site directories
- Creating, moving, and deleting files and directories
- Setting NTFS permissions for files and directories
- Defining network file sharing for files and directories
Configure IIS 5.0 to recognize both Windows and UNIX-style home page names. To make migrating UNIX Web sites easier, specify the following five home page names in IIS Web Site Properties:
- Index.htm
- Index.html
- Default.htm
- Default.html
- Default.asp
This will cover nearly all cases for both UNIX and Windows Web sites. When you transfer a Web site from a UNIX-based computer, you won't need to change the home page file name for IIS 5.0 to serve it.

Later sections in this chapter®"Migrating from Apache HTTP Server," "Migrating from Netscape Enterprise Server," and "Upgrading or Replicating an IIS Web Server"®describe using the IIS Migration Wizard to replicate configuration settings from a server running Netscape Enterprise Server, Apache HTTP Server, IIS 4.0, and IIS 5.0 to a different server running IIS 5.0.

Securing the Server

Once you've migrated Web content and applications to IIS 5.0, you need to configure security. This section discusses the basics of securing your Web server: migrating user and group accounts, migrating certificates, setting NTFS file and directory permissions, and setting IIS 5.0 permissions. For more in-depth information, see "Security" in this book, as well as the security topics in the IIS 5.0 and Windows 2000 Server online product documentation. For information about using FrontPage security with IIS 5.0, see "Administering an ISP Installation" in this book. For additional details on security, see https://msdn.microsoft.com/nhp/Default.asp?contentid=28001191 and https://www.microsoft.com/security/default.asp.

Migrating Users and Groups

An important component of migration is transferring the identities and passwords of system users and groups to the new server. To make this easier, you can use Addusers.exe, a utility for adding user accounts to Windows 2000 Server, included on the Resource Kit companion CD.

If you're migrating from Netscape Enterprise Server 3.5, consider using the IIS Migration Wizard included on the Resource Kit companion CD to automate the migration of your local user database.

You also need to configure security on the user and group accounts, and you might want to create new group identities to enhance security. For information about doing this, see the Windows 2000 Server online product documentation.

Setting NTFS Permissions

To protect your Web server from unwanted intrusions, you can set access permissions by user and group account for each file or directory stored in the Windows NTFS file system. Permissions set on a directory apply to each file within the directory. However, if a file within the directory has more restrictive settings, the more restrictive settings apply. For information about setting NTFS permissions, see the "Setting NTFS Permissions for a Directory or File" topic in the IIS 5.0 online product documentation. Note that you cannot set these access permissions for files and directories stored in a FAT file system.

The following are a few guidelines for configuring NTFS permissions for user and group accounts used by IIS 5.0:

Anonymous User During installation, the IIS 5.0 Web and FTP services are assigned a default user account, called IUSR_computername, for anonymous users*.* Do not make this account a member of any privileged group.
IIS Admin Service Do not give the IIS Admin Service the right to log on as the LocalSystem account.
Test It's a good idea to create a Test group account to which you can give enlarged access permissions, such as Write or Execute, needed by application developers and testers.
Full Control Only two accounts should be always given NTFS Full Control permissions: LocalSystem and Administrator. On selected files, you might want to also give full control to Owner/Creator.

Setting IIS 5.0 Permissions

You set additional access permissions for Web users in the IIS snap-in. The easiest way to set up basic IIS 5.0 security is to use the Permissions Wizard. To start the wizard, in the IIS snap-in select the Web site or directory for which you want to set permissions, click Action on the toolbar, point to All Tasks, and then click Permissions Wizard.

You can also configure security on Web Site property sheets. The following are some rules-of-thumb for setting IIS 5.0 permissions based on the type of access you want to provide. You might need to implement security differently than described here, depending on the requirements of your particular system. For more information about setting access permissions, see the "Access Control" topic in the IIS 5.0 online product documentation and "Security" in this book.

Note: If NTFS file and directory access permissions do not match the access permissions set in the IIS snap-in, the more restrictive settings take effect.

Web and FTP Site Anonymous Access To protect the information on your computer, restrict access by anonymous users. To do this, in the IIS snap-in deny all access to the anonymous user account, which is IUSR_computername by default. Next, select the specific files and directories under the root to which you want to allow anonymous access and enable the appropriate permissions for the anonymous user account. To override the access restrictions you set at the root level for these files and directories, clear the Allow inheritable permissions from parent to propagate to this object check box.
Web and FTP Site Authenticated Access To require users to provide a valid user name and password in order to access a Web or FTP site, in the IIS snap-in disable anonymous access on the Directory Security tab of Web Site Properties or FTP Site Properties. For Web sites, you can then select the type of authentication: Basic, Digest, or integrated Windows authentication. For more information, see the "Authentication" topic in the IIS 5.0 online product documentation and "Security" in this book.

By default IIS 5.0 attempts to authenticate Web and FTP users from the local user database. For a Web site, you can change authentication to the domain user database from within the IIS snap-in. For an FTP site, you must modify the DefaultLogonDomain metabase property for the FTP service. To do this, you can use the IIS Administration Script Utility (Adsutil.exe), installed with IIS 5.0, as follows:

At the command prompt, type:

adsutil.exe set msftpsvc/DefaultLogonDomain "Name of Your Domain"

Note: To set up an FTP site where users can upload files, but not see files already uploaded to the site by other users, use virtual directories. Enable Write, but not Read, permission for the user accounts. Give Read permission to the Administrator account only.

Setting Permissions Based on Content

Table 3.1 provides guidelines for setting NTFS and IIS 5.0 security on a directory, based on its type of content.

Table 3.1 Basic Web Security Settings

Content	Directory Name/Type	NTFS Account	NTFS Directory Permissions	IIS 5.0 Virtual Directory Permissions
Static (.htm, .gif, .jpg, and so on.)	Content	Authenticated Users	Read	Allow Anonymous Access. Allow Read permissions. Directory Browsing okay.
ASP pages	ASP pages	Authenticated Users	Execute	Allow Anonymous Access. Allow Read permissions. For Execute Permissions, choose Scripts only. Directory Browsing okay.
ASP-page includes	Includes	Authenticated Users	Execute	Allow Read permissions.
Server-side includes	Content	Authenticated Users	Execute	Disable Anonymous Access. For Execute Permissions, choose Script or Execute permissions.
CGI scripts	Scripts	Authenticated Users	Execute	Disable Anonymous Access. For Execute Permissions, choose Scripts only. Disable Read, Write, and Directory browsing.
ISAPI server extensions	ISAPI Extensions	Authenticated Users	Execute	Disable Anonymous Access. For Execute Permissions, choose Execute. Disable Read, Write, and Directory browsing.
ISAPI filters	ISAPI Filters	Authenticated Users	Execute	Disable Anonymous Access. For Execute Permissions, select Execute. Disable Read, Write, and Directory browsing.
Executable CGI applications	CGI bin	Authenticated Users	Execute	Disable Anonymous Access. For Execute Permissions, choose Execute. Disable Read, Write, and Directory browsing.
Databases	Databases	For remote databases, share out the directory and enable the Guest account for the IIS 5.0 Web service that accesses the share.	Security depends on the database. * See note that follows.	Security depends on the database.
Microsoft® Component Object Model (COM) and Microsoft® Distributed Component Object Model (DCOM) components	Components		** See note that follows.	Disable Anonymous Access. Enable Execute permissions only. Disable Read, Write, and Directory browsing.
Downloadable executable files	Downloads	Authenticated Users	Read	Enable Read permissions only. Disable Execute permissions or the file will execute rather than download.

Note: *Whenever possible, keep Microsoft® Access databases on the same computer asIIS 5.0. There isn't a secure way for an IIS 5.0 application to connect to an Access database located on a networked drive.

**In general, you should place COM and DCOM components in a directory with Execute permissions only. Place COM and DCOM components that need to write to data files in the same directory with the data files and enable both Execute and Write permissions. Be aware that setting Write permissions on a components directory creates the potential for intruders to upload and run an executable file on your server.

To help prevent unauthorized access to a directory

In the IIS snap-in, disable Directory Browsing for that directory and its parent directory.
Set up auditing on the directory so you can monitor any suspicious activity. For more information about auditing, see "Security" in this book.

Migrating Security Certificates

The easiest approach to migrating security certificates is using the Web Server Certificate Wizard. You can start the wizard in the IIS 5.0 snap-in from the Directory Security tab of Web Site Properties. For information about using the wizard, see the "Using the New Security Task Wizards" topic in the IIS 5.0 online product documentation.

Another approach to migrating a certificate is saving it as a .cer file and copying it to the new Windows 2000 Server. You can install the certificate by double-clicking the .cer file and then use the Web Server Certificate Wizard to bind the certificate to the appropriate Web site. Remember to create a backup copy of server and client certificates and keys in case they become corrupted during the transfer.

Integrating UNIX and Windows 2000 Server Security

Windows 2000 Server and UNIX handle their respective user accounts very differently, complicating security implementation in a mixed environment. If you plan a multistep approach to migrating from UNIX to the more secure Windows 2000 Server environment, you might find it necessary to use a mixed authentication scheme during the early stages.

Windows 2000 Server implements the Kerberos v5 authentication protocol, a mature Internet security standard, as the default protocol for network authentication. This provides a foundation for authentication interoperability with other platforms, such as UNIX. For more information about the Kerberos v5 protocol, see "Security" in this book.

Migrating from Apache HTTP Server

So far this chapter has described migration in general terms. Each step is applicable to a migration from almost any type of Web server. This section provides details about migrating from Apache HTTP Server. It briefly compares some Apache and IIS 5.0 features and then provides tables that match Apache directives to their corresponding IIS 5.0 configuration properties. The tables indicate whether or not the IIS Migration Wizard, included on the Resource Kit companion CD, migrates a particular directive. They also describe how to configure each setting manually on IIS 5.0.

Comparing Apache and IIS 5.0

The following are some Apache features that have different names and implementations on IIS 5.0.

Administration Interface

IIS 5.0 properties, which correspond with Apache directives, are contained in the metabase. The most significant difference you'll find between administering Apache and IIS 5.0 is the fact that IIS 5.0 provides graphical tools, the IIS snap-in and the Internet Services Manager (HTML), for configuring the metabase, whereas Apache provides plaintext configuration files, usually httpd.conf, srm.conf, and access.conf, in which you configure directives.

Apache administrators who prefer to work from the command line and to script routine tasks will be happy to know that IIS 5.0 also provides a set of tools for programmatic administration. These tools are described in the "Administering IIS Programmatically" topic in the IIS 5.0 online product documentation. For more information about using the tools, see "Administering an ISP Installation" in this book.

Apache administrators will also find that Windows 2000 Server commands are similar to familiar UNIX commands. Additional utilities for command-line administration are included with the Windows NT Services for UNIX, a suite of interoperability tools and utilities provided by Microsoft for Windows NT Server and UNIX. At the time of this writing, a version of these tools is under development for Windows 2000.

Security

If you're accustomed to Apache security, be aware that Allow and Deny access permissions are processed in a different order by Windows 2000 Server, producing results you might not expect. Windows 2000 Server always honors a Deny. If you deny permission to a group, and then try to allow permission to an individual member of the group, the member still will not be able to access the resource.

Also note that, unlike in Apache, CGI-bin is contained within the IIS 5.0 Web space. This is because NTFS and IIS 5.0 security sufficiently protects it from attack.

User Directory

You set up individual user Web sites differently on IIS 5.0 than on Apache HTTP Server. With Apache, you add a user to the machine, and then create a <~username> directory for the user's Web pages. The server then responds to the following request by displaying the user's Web pages:

https://domain.com/\<~username>

IIS 5.0 does not automatically create virtual directories for users. Instead, to add a user Web site you create a <username> directory for their files in Windows Explorer, create a virtual directory named <~username> in the IIS 5.0 snap-in, and then point it to the <username> directory.

Virtual Host

The IIS 5.0 counterpart to the Apache Virtual Host is a virtual server. As with Apache virtual hosts, each virtual server in IIS 5.0 has its own domain name and IP address. Apache also includes "name-based" virtual hosts in this category. IIS 5.0 supports this feature in the same manner as Apache, through host header names, but doesn't have a specific term for it.

Alias/Directory Alias

In IIS 5.0 an alias or directory alias is called a virtual directory. In Apache, you use the RedirectMatch/AliasMatch command to map a directory alias to a real directory located on the hard disk, as shown in the following example:

Alias /folder "c:/apache/htdocs/newfolder/"

To do the same thing in IIS 5.0, in the IIS snap-in, create a virtual directory and point it to the real directory in Windows Explorer. Using the previous example, the virtual directory would be named "folder," and you would point it to c:\apache\htdocs\newfolder\. Note the change from using forward slashes (/) in the UNIX pathname to backslashes (\) in the Windows path.

Custom Error Messages

In Apache, you provide custom error messages by editing the Error Document and referring to it by using the command:

ErrorDocument 404 https://domain.com/404.html

To customize error messages in IIS 5.0, in the IIS snap-in open Properties for the Web site. On the Custom Errors tab, you'll see the location of the error message files. From here, you can map custom error messages to a file or to a URL on the local server.

Redirects

In Apache you use the following .htaccess command to redirect a user to another file:

Redirect /oldfile.html https://domain.com/path/to/new/file

There are two ways to implement a redirection in IIS 5.0:

In the IIS snap-in open Properties for the Web site. On the Home Directory tab, select A redirection to a URL, and choose the appropriate options.
Or, put a Default.asp file, containing the following code, in the same directory as the old file:

Response.Redirect /oldfile.html https://domain.com/path/to/new/file

Migrating Apache Directives

This section lists the core Apache HTTP Server 1.3 directives and indicates whether, and how, the IIS Migration Wizard migrates them to IIS metabase properties. This section also explains how to configure each property in the IIS snap-in. There is not a one-to-one correspondence between Apache and the IIS 5.0 configuration options: not all IIS 5.0 settings exist on Apache and vice versa. This section does not cover IIS 5.0 properties that have no counterpart in Apache. For in-depth information about IIS 5.0 configuration parameters and metabase properties, see the "Administrator's Reference" topic in the IIS 5.0 online product documentation.

Server Directives

Table 3.2 Apache httpd.conf Directives and Corresponding IIS 5.0 Properties

Apache Directive	Wizard Migrates (Y/N)	IIS Metabase Property	IIS Snap-in Configuration
AccessConfig	No	Not applicable	The wizard uses these parameters for mapping to the access configuration information. However, in IIS 5.0 there is no separate access configuration file.
BindAddress	Yes	ServerBindings	For multihoming, IIS 5.0 allows you to specify Virtual Hosts, or virtual servers. To configure a virtual server, right-click a Web site, choose Properties, and then select the Web Site tab. Click the Advanced button on the Web Site tab, and add the correct IP address and Transmission Control Protocol (TCP) port.
CacheNegotiatedDocs	No	Not applicable	You can specify an expiration date for content in a browser or proxy cache. To configure this setting, right-click a Web site, choose Properties, and then select the HTTP Headers tab. Select the Enable Content Expiration check box and enter expiration dates.
ErrorLog	No	Not applicable	All errors for the Inetinfo process are logged to the Windows® Event Log and do not need to be specified in the Web server configuration. The wizard uses IIS 5.0 default log settings.

ExpiresActive	Yes	HttpExpires	In IIS 5.0 content expiration is disabled by default. To enable content expiration, rightclick a Web site, choose Properties, select the HTTP Headers tab, and then check the Enable Content Expiration check box.
ExpiresDefault	Yes	HttpExpires	In IIS 5.0 content expiration is disabled by default. To enable content expiration, rightclick a Web site, choose Properties, and then select the HTTP Headers tab. Select the Enable Content Expiration check box, and then set the parameters.
Header	Yes	HttpCustomHeaders	To create a custom header, right-click a Web site, choose Properties, and then select the HTTP Headers tab. In the Custom HTTP Headers box, click Add, and then type a name and a value for the header.
HostnameLookups	Yes	EnableReverseDNS	IIS 5.0 log files capture the IP addresses of Web site visitors. To look up the host name of a given IP address, enable the metabase property EnableReverseDns. To set IP address restrictions, right-click a Web site, click Properties, click the DirectorySecurity tab, and then click the Edit button in the IP Address and Domain Name Restrictions box.
IdentityCheck	Yes	LogExtFileUserName	To log the identity of each Web site visitor, right-click a Web site, click Properties, and then click the Web Site tab. Select the Enable Logging check box, and then click Properties. Click the Extended Properties tab, and then select the User Name check box.
<IfDefine>	Yes	Not applicable	The wizard uses this information when parsing the Apache files.
Include	Yes	Not applicable	This directive is not needed in IIS 5.0.

KeepAlive	Yes	AllowKeepAlive, MaxConnections	In IIS 5.0, HTTP Keep-Alives are enabled by default. To disable Keep-Alives, right-click a Web site, and choose Properties. On the Web Site property sheet, clear the HTTP KeepAlives Enabled check box. You set the maximum number of connections and the connection time-out in this location as well.
KeepAliveTimeout	Yes	Connection Timeout	To set the Keep-Alive time-out, right-click a Web site and then choose Properties. In the Connections box on the Web Site property sheet, select the Limited To radio button and, in the Connection Timeout box, specify the number of seconds you want before an idle connection times out.
Listen	Yes	ServerBindings	IIS 5.0 allows you to specify a port for namebased virtual hosts. To configure this setting, right-click a Web site and then choose Properties. On the Web Site property sheet, click the Advanced button, and then enter the TCP port number.
ListenBacklog	Yes	ServerListenBacklog	This is a service-level property, and it cannot be configured from MMC.
MaxClients	Yes	MaxConnections	To configure this property, right-click a Web site, choose Properties, and then select the Web Site tab. Select the Unlimited or the LimitedTo radio button. For limited connections, in the Connection Timeout box specify the number of seconds before a connection should time out.
MaxKeepAliveRequests	No	Not applicable	There is no equivalent in IIS 5.0.
MaxRequestsPerChild	No	Not applicable	IIS 5.0 uses a limited number of processes, and there is no need to set the maximum number of requests per child process as there is with Apache.

Min/MaxSpareServers	No	Not applicable	IIS 5.0 uses a limited number of processes, and there is no need to account for this number.
NameVirtualHost	Yes	ServerBindings	An Apache virtual host corresponds to an IIS 5.0 Web site. In IIS 5.0, you can create virtual hosts either by using multiple IP addresses or by using a single IP address and HTTP 1.1 Host Header Names. To create a virtual host with a unique IP address, right-click a Web site, choose Properties, and then select the Web Site tab. Click the Advanced button and specify the IP address. To specify a host header name for a name-based virtual host, right-click a Web site, and then choose Properties. On the Web Site property sheet, click the Advanced button and enter the host header name for the IP address you want to use.
PidFile	No	Not applicable	IIS 5.0 does not offer the option to log its process ID to a file.
Port	Yes	ServerBindings	To set the port to which your Web server should listen, right-click a Web site, choose Properties, and then select the Web Site tab. Enter a port number in the TCPPort box.
Proxy Cache Parameters	No	Not applicable	IIS 5.0 cannot function as a proxy server on its own. Microsoft® Proxy Server is recommended as a proxy server for use with Windows 2000 Server.
ProxyRequests	No	Not applicable	See the previous note for Proxy Cache Parameters.
RlimitCPU	Yes	CpuLimit	IIS 5.0 has a number of properties that specify CPU throttling parameters. To specify performance parameters in the IIS snap-in, right-click a Web site, choose Properties, click the Performance tab, and then choose the settings you want.

ScoreBoardFile	No	Not applicable	IIS 5.0 does not have a Scoreboard file.
ServerAdmin	No	Not applicable	IIS 5.0 does not have a configuration setting for displaying the administrator's name and contact information. You can add this information to your pages by using ASP.
ServerAlias	Yes	ServerBindings	IIS 5.0 allows you to specify a host header name for a name-based virtual host. To configure this setting, right-click a Web site, and then choose Properties. On the Web Site property sheet, click the Advanced button and enter the host header name for the IP address you want to use.
ServerName	No	Not applicable	The host name for your Web server is stored in your Domain Name System (DNS) server and is not required in IIS 5.0 configuration properties. However, you must specify an IP address and HTTP port in order for IIS 5.0 to serve content.
ServerPath	Yes	Path	This directive is migrated to the Path property of the IIS Virtual Directory object. This property defines the path from a virtual directory to its corresponding physical directory. You configure this property in the IIS snap-in when you create a new virtual directory, by specifying from which directory the content is to be served.
ServerRoot	Yes	Not applicable	The wizard uses this information for parsing Apache files, but IIS 5.0 does not have the same concept of server root and does not have a corresponding property.
ServerType	No	Not applicable	IIS 5.0 always runs in stand-alone mode. Once IIS 5.0 is started, its process remains in memory and listens to the specified HTTP port. You can't configure IIS 5.0 to dynamically load as with an inetd server on Apache.
StartServers	No	Not applicable	See the previous note for Min/MaxSpareServers.
Timeout	Yes	ConnectionTimeout	You can specify the maximum amount of idle time to elapse before your server drops a connection. To configure this setting, right-click a Web site, choose Properties, and then select the Web Site tab. Enter the maximum timeout value in the Connection Timeout box.
TransferLog	No	Not applicable	IIS 5.0 does not use a transfer log.
User/Group	No	Not applicable	When IIS 5.0 is installed, by default it creates the IWAM user account under which the server runs. You must be logged on as an administrator or operator in order to start and stop the IIS 5.0 service, but the process does not retain your permissions.
<VirtualHost>	Yes	Not applicable	For each Apache virtual host, the wizard creates a new IIS Web site. It migrates the directives contained between the <VirtualHost> tags, including server bindings, and applies them to the Web site. You might need to correct the IP address of the new Web site following migration.

Resource Configuration

Table 3.3 Apache srm.conf Directives and Corresponding IIS 5.0 Properties

Apache Directive	Wizard Migrates (Y/N)	IIS Metabase Property	IIS Snap-in Configuration
AccessFileName	Yes	Not applicable	The wizard uses these parameters for mapping access configuration information. However, in IIS 5.0 there is no separate access configuration file. IIS 5.0 security is integrated with Windows 2000 security. To limit access to a site or directory by user, you must configure a new user account in the Windows 2000 Server User Manager. You can also classify individuals or groups as "Web site Operators" with limited authority to administer a Web site. They do not have to be Windows 2000 Administrators. To define Web site Operators, in the IIS snap-in right-click a Web site, click Properties, and then click the Operators tab.
AddDescription	No	Not applicable	There is no corresponding property in IIS 5.0.
AddEncoding	Yes	MimeMap	To map a file extension to a MIME type, right-click a Web site, choose Properties, and then select the HTTP Headers tab. In the Mime Map box, click File Types, and then click New Type. Or, to edit an existing MIME type, select a file type in the list, and then click Edit. Type the file extension and associated MIME type in the appropriate boxes.
AddIcon	No	Not applicable	IIS 5.0 uses the standard Windows 2000 icons when displaying a directory. You cannot specify a substitute icon.
AddLanguage	No	Not applicable	There is no corresponding property in IIS 5.0.
AddType	Yes	MimeMap	To add MIME types, right-click a Web site, choose Properties, and then select the HTTP Headers tab. In the Mime Map box, click File Types, and then click New Type. Type the file extension and the associated MIME type in the appropriate boxes.
Alias	Yes	Not applicable	The wizard creates a Virtual Directory object for each Apache alias and applies the appropriate parameters by configuring corresponding metabase properties. To create a virtual directory, right-click the FTP or Web site, click New, and select Virtual Directory. Use the New Virtual Directory Wizardto complete this task.
AliasMatch	Yes	Not applicable	There is no direct equivalent in IIS 5.0 because there is no concept of regular expressions. The wizard creates a corresponding Virtual Directory object. See the previous note for Alias.
DefaultIcon	No	Not applicable	Windows 2000 Server offers a standard default icon for file types that do not have a preset icon in the file system.
DefaultType	Yes	MimeMap	IIS 5.0 contains a comprehensive list of MIME types. You can add new MIME types to the list should you need to serve a new MIME type. To view default MIME types, right-click a Web site, choose Properties, and then select the HTTP Headers tab. Click the File Types button in the MIME Map section of the tab.
DirectoryIndex	Yes	EnableDirBrowsing	You can configure IIS 5.0 to allow directory browsing. To configure this setting, right-click a Web site, choose Properties, select the Home Directory tab, and then select the Directory Browsing check box. IIS 5.0 does not allow you to specify a prewritten HTML document as a directory index.
DocumentRoot	Yes	Path	The wizard migrates this directive to the Path property of the IIS Root object. This property defines the path from a Web site home directory to its corresponding physical directory. To configure this property, right-click a Web site, choose Properties, and select the Home Directory tab. Then specify the location of the home directory (document root).
ErrorDocument	Yes	HttpErrors	To enable custom error messages, right-click a Web site, choose Properties, and then select the Custom Errors tab. In cases where the custom error page is a standard HTML page, you need only copy the file to the IIS 5.0 system in order to complete the migration. In the case of CGI custom errors, you need to test the CGI scripts after moving them to IIS 5.0.
FancyIndexing	No	Not applicable	IIS 5.0 offers default indexing only.
HeaderName	No	Not applicable	There is no corresponding property in IIS 5.0.
IndexIgnore	No	Not applicable	There is no corresponding property in IIS 5.0.
LanguagePriority	No	Not applicable	There is no corresponding property in IIS 5.0.
MetaDir	No	Not applicable	You do not need to specify a Meta Directory to serve HTTP header information. To specify custom HTTP headers, right-click a Web site, choose Properties, select the HTTP Headers tab, and then click Add. Specify a header name and value in the appropriate boxes.
MetaSuffux	No	Not applicable	See the previous note for MetaDir.
ReadmeName	No	Not applicable	IIS 5.0 does not specify a default name for ReadMe files.
Redirect	Yes	HttpRedirect	To redirect a request to another resource, right-click a Web site, choose Properties, select the Home Directory tab, and then select A redirection to a URL. Type the URL in the Redirect to box.
RedirectTemp	Yes	HttpRedirect	In IIS 5.0, redirections are temporary by default.
RedirectPermanent	Yes	HttpRedirect	To make a redirection permanent, follow the steps previously given for Redirect. In addition, select the A permanent redirection for this resource check box after typing the URL.
ResourceConfig	Yes	Not applicable	The wizard uses this information, but it does not directly translate to an IIS 5.0 property.
ScriptAlias	Yes	Not applicable	The wizard creates a Virtual Directory object using the Apache path information and sets the IIS AccessExecute property to TRUE. Any virtual directory can execute scripts when the "Allow Scripts" permission is enabled in the IIS snap-in. To configure this property, right-click a Web site, choose Properties, select the Home Directory tab, and then select the Scripts only or the Scripts and Executables option in the Execute Permissions box.
TypesConfig	Yes	MimeMap	The wizard adds specified MIME types to the IIS 5.0 MIME map. To view or configure MIME types, right-click a Web site, choose Properties, and then select the HTTP Headers tab. Click the File Types button in the MIME Map section of the tab.
UserDir	No	Not applicable	IIS 5.0 does not offer a default directory for ISP user httpd directories. You must create a virtual directory for each user in the IIS snap-in, and then point it to the user directory in Windows Explorer.

Access Configuration

Table 3.4 Apache access.conf Directives and Corresponding IIS 5.0 Properties

Apache Directive	Wizard Migrates (Y/N)	IIS 5.0 Metabase Property	IIS Snap-in Configuration
AllowOverride	Yes	Not applicable	The wizard uses this information to parse the access configuration files. However, IIS 5.0 utilizes Windows 2000 security in order to restrict access to a site, so htaccess files are not necessary to control access. Note that in IIS 5.0 you can classify individuals or groups as "Web site Operators" with limited authority to administer a Web site. They do not have to be Windows 2000 Administrators. To define Web site Operators, in the IIS snap-in right-click a Web site, click Properties, and then click the Operators tab.
AuthDBGroupFile	No	Not applicable	The wizard does not directly migrate this information, but uses it to create the Users file for use with Addusers.exe. Following migration, you must reconfigure all security on IIS 5.0.
AuthDBUserFile	No	Not applicable	See previous note for AuthDBGroupFile.
AuthDBMGroupFile	No	Not applicable	See previous note for AuthDBGroupFile.
AuthDBMUserFile	No	Not applicable	See previous note for AuthDBGroupFile.
AuthName	No	Realm	See previous note for AuthDBGroupFile.
AuthType	No	AuthBasic	In Apache, AuthType is usually set to Basic. The corresponding IIS 5.0 metabase property is AuthBasic. To configure authentication, right-click the virtual directory for which you want to set authentication, click Properties, and then click Directory Security. In the Enable anonymous access and edit the authentication methods for this resource box, click Edit, and then choose an authentication method.
<Directory>	Yes	Not applicable	The wizard migrates defined directives enclosed in this tag to the corresponding IIS 5.0 virtual directory.
<DirectoryMatch>	Yes	Not applicable	The wizard migrates defined directives enclosed in this tag to the corresponding IIS 5.0 virtual directory.
<Files>	Yes	Not applicable	The wizard migrates defined directives enclosed in this tag to the corresponding IIS 5.0 virtual directory.
<FilesMatch>	Yes	Not applicable	The wizard migrates defined directives enclosed in this tag to the corresponding IIS 5.0 virtual directory.
<Limit>	No	Not applicable	There is no equivalent in IIS 5.0.
<LimitExcept>	No	Not applicable	There is no equivalent in IIS 5.0.
<Location>	Yes	Not applicable	The wizard migrates defined directives enclosed in this tag to the corresponding IIS 5.0 virtual directory.
<LocationMatch>	Yes	Not applicable	The wizard migrates defined directives enclosed in this tag to the corresponding IIS 5.0 virtual directory.
Options, ExecCGI	Yes	AccessExecute	You can set most of the IIS 5.0 equivalents of the Options parameter by enabling execution or script permissions for any virtual directory. To do this, in the IIS snap-in right-click the directory for which you want to set permissions, and then click Properties. Click the Home Directory tab, and then set permissions in the Execute Permissions box.
Options Indexes	Yes	EnableDirBrowsing	To enable users to view directory contents, in the IIS snap-in right-click the directory for which you want to enable browsing, and then click Properties. Click the Home Directory tab, and then select the Directory browsing check box.
Server status reports	No	Not applicable	IIS 5.0 does not provide server status reports.

Migrating Custom Modules

In Apache, custom modules extend the capabilities of the Web server. With IIS 5.0, there are a number of options for extending server capabilities. There is no direct way to migrate a custom module, so it must be recreated in IIS 5.0 using one of the following approaches:

ASP with COM components or ISAPI DLLs can be written to duplicate most of the desired functionality, such as database or file system access. There are a number of built-in ASP objects to speed this task, such as FileSystemObject, which provides the methods, properties, and collections you use to access the file system.
ISAPI filters allow you to implement custom authentication and logging, as well as URL rewriting, or "munging." For more information about using ISAPI filters to extend IIS 5.0 security, see "Security" in this book.

For more information about using these technologies, see the IIS 5.0 section of the SDK documentation on MSDN.

Migrating from Netscape Enterprise Server

This section provides additional details about migrating from Netscape Enterprise Server (NES). It briefly compares NES with IIS 5.0 and provides tables that match NES configuration settings to their corresponding IIS 5.0 metabase properties. The tables indicate whether or not the IIS Migration Wizard, included on the Resource Kit companion CD, migrates a particular setting. They also describe how to configure each setting manually.

Comparing NES and IIS 5.0

Terminology

Here are some essential terms used in NES with explanations of their equivalents in IIS 5.0.

Hardware Virtual Server In NES, a "hardware virtual server" is a site with a separate IP address; the term implies a number of Web sites on a single computer, each with a separate IP address. The counterpart in IIS 5.0 is a virtual server. As with NES hardware virtual servers, each virtual server in IIS 5.0 has its own domain name and IP address.
Software Virtual Server In NES, a "software virtual server" is a site that may share an IP address with one or more other sites. In IIS 5.0, you can assign any number of sites to a single IP address and distinguish them by using host headers, but no special term is employed to describe them.

Multiple Instances of the Server In NES, you host multiple Web sites on one computer by using multiple instances of the server if:
- The operating system does not have strong thread support.
- The operating system does not allow a single process to schedule threads on more than one processor.
- Multiple instances of the server provide full process isolation, protecting a Web site from failure should another site on the same system crash.
  
  It isn't appropriate to run multiple instances of IIS 5.0, because IIS 5.0 running on Windows 2000 Server offers thread support across multiple processors, full configuration of each site hosted by the server, and process isolation for applications.
Server Manager Server Manager is the NES administration tool equivalent to the IIS snap-in for MMC.
Directory Aliases In NES, you can map an alias such as this:

/admin-offices/student

to a real directory such as this:

/admin-offices/studaffairs/cpc

In IIS 5.0 a virtual directory corresponds to an alias. You can use the New Virtual Directory Wizardto create a virtual directory. To start the wizard, in the IIS snap-in select the Web site for which you want to define a virtual directory, click the Action button, point to New, and then select Virtual Directory. For more information, see the "Creating Virtual Directories" topic in the IIS 5.0 online product documentation.

Migrating NES Configuration Settings

The IIS Migration Wizard, included on the Resource Kit companion CD, migrates NES Web server settings, the virtual directory structure, and user accounts.

The tables in this section list NES 3.5 settings and indicate whether or not the IIS Migration Wizard migrates the setting and where the setting is found in IIS 5.0. Each heading within this section corresponds to a tab within the NES Server Manager.

Note that IIS 5.0 administrative settings, or properties, can be set on the server, site, directory, or even file level. Most NES settings apply to the site level only.

Server Preferences

Table 3.5 NES 3.5 Server Preferences and Corresponding IIS 5.0 Properties

NES 3.5 Configuration Setting	Migrated by Wizard? (Y/N)	IIS Metabase Property	IIS Snap-in Configuration
Bind To Address	Yes	ServerBindings	Right-click a Web site, click Properties, and then click the Web Site tab. The setting appears in the IP Address box.
Convert 2.0 ACL file	No	Not applicable	There are no settings to migrate.
Dynamic Configuration Files	No	Not applicable	In IIS 5.0 you can classify individuals or groups as "Web site Operators" with limited authority to administer a Web site. They do not have to be Windows 2000 Administrators. To define Web site Operators, in the IIS snap-in right-click a Web site, click Properties, and then click the Operators tab.
Enable DNS	No	Not applicable	In IIS 5.0 you can restrict access by domain name. However, this feature can have a significant negative effect on server performance.
Encryption	No	Not applicable	You can install a server certificate and enable encryption by using the Security Task Wizards.
Error Responses	Yes	HttpErrors	When migrating a custom error page that is a standard HTML page, you need only copy the file to the IIS 5.0 system to complete the migration. In the case of CGI custom errors, you need to test the CGI scripts after moving them to IIS 5.0. To enable custom error messages in the IIS 5.0 snap-in, right-click a Web site, choose Properties, and then select the Custom Errors tab.
HTTP Persistent Connection Timeout	Yes	ConnectionTimeout	Right-click a Web site, click Properties, and then click the Web Site tab. The setting appears in the Connection Timeout box.
Maximum Simultaneous Requests	Yes	MaxConnections	Right-click a Web site, click Properties, and then click the Web Site tab. The setting appears in the Limited To box.
MIME Types	Yes	MimeMap	Right-click a Web site, click Properties, click the HTTP Headers tab, and then select the File Types button.
MTA Host and NNTP Host	No	Not applicable	Windows 2000 Server includes Simple Mail Transfer Protocol (SMTP) and Network News Transfer Protocol (NNTP) services. For more information, see the Windows 2000 Server online product documentation.
On/Off	No	Not applicable	Select a Web site you want to stop or start, and then click the Stop or Start toolbar button.
Restore Configuration	No	Not applicable	IIS 5.0 supports configuration backup. To back up the IIS 5.0 metabase, in the IIS snap-in rightclick the computer name, choose Backup/Restore Settings, click Backup, type a name for the backup file, and then click OK.
Restrict Access	No	Not applicable	IP address restrictions are not migrated because they are defined differently in IIS 5.0. To set IP address restrictions, right-click a Web site, click Properties, click the DirectorySecurity tab, and then click the Edit button in the IP Address and Domain Name Restrictions box.
Server Name	Yes	ServerBindings	The setting is migrated to a host header name. For information about this feature, see the "Naming Web Sites" topic in the IIS 5.0 online product documentation.
Server Port	Yes	ServerBindings	Right-click a Web site, click Properties, and then click the Web Site tab. The setting appears in the TCPPort box.

Applications

NES CGI applications can be ported directly to run on IIS 5.0, or they can be converted to ISAPI or ASP. For more information, see "Migrating Web Applications" later in this chapter.

Table 3.6 NES 3.5 Application Settings and Corresponding IIS Properties

NES 3.5 Configuration Setting	Migrated by Wizard? (Y/N)	IIS Metabase Property	IIS Snap-in Configuration
CGI Directory	Yes	Not applicable	The wizard creates a CGI virtual directory and enables the CGI Execute permission.
CGI File Type	No	Not applicable	There is no corresponding property in IIS 5.0.
Java	No	Not applicable	The Java virtual machine is already enabled on IIS 5.0, so there is no need to migrate this setting.
Query Handler	No	Not applicable	There is no corresponding property in IIS 5.0.
Server Side JavaScript	No	Not applicable	IIS 5.0 includes server-side support for JScript and VBScript. There is no need to migrate a switch setting for these languages.
ShellCGI Directory	Yes	Not applicable	The wizard creates a ShellCGI virtual directory and enables the CGI Execute permission.
URL Prefix	Yes	Not applicable	The wizard creates a corresponding virtual directory.
WAI Management	No	Not applicable	This setting has to do with the Internet Inter-ORB Protocol (IIOP); IIS 5.0 uses the COM and DCOM object models.
WinCGI Directory	No	Not applicable	WIN CGI is not supported in IIS 5.0.

Server Status

Table 3.7 NES 3.5 Server Logging and Corresponding IIS 5.0 Properties

NES 3.5 Configuration Setting	Migrated by Wizard? (Y/N)	IIS 5.0 Metabase Property	IIS Snap-in Configuration
Archive Log	No	Not applicable	There are no settings to migrate. When you set your logging preferences in IIS 5.0, you can use Microsoft® Windows® 2000 Backup or other third-party backup tools to archive the log files and remove them from the server as appropriate.
Generate Report	No	Not applicable	There are no settings to migrate. You can customize and extend IIS 5.0 logging in the IIS snap-in. You can set viewing options and filters in the Windows 2000 Server Event Viewer.
Log Preferences	Yes	Not applicable	Basic log file settings are migrated, but due to differences in logging methods you should review the settings created in IIS 5.0 to make sure they are optimal for your new environment.
Log Client Accesses	Yes	LogType	See previous note for Log Preferences.
Record Domain Names/IP Addresses	Yes	LogExtFileClientlp, LogExtFileComputerName	See previous note for Log Preferences.
Format	No	Not applicable	There is no corresponding property in IIS 5.0.
Monitor Current Activity	No	Not applicable	There are no settings to migrate. To monitor server activity on IIS 5.0, use the Windows 2000 Server System Monitor to evaluate performance and resource consumption.
Simple Management Network Protocol (SMNP) Sub-Agent Configuration	No	Not applicable	There is no corresponding property in IIS 5.0.
Rotate Log	Yes	LogFilePeriod	See previous note for Log Preferences.
View Access Log	No	Not applicable	There are no settings to migrate. You can view access logs from the Windows 2000 Server Event Viewer.
View Error Log	No	Not applicable	There are no settings to migrate. You can view error logs from the Event Viewer.

Configuration Styles

The settings under this heading are not migrated to IIS 5.0. IIS 5.0 includes support for property inheritance, which achieves much the same result as configuration styles. In the IIS snap-in, you can right-click the server and set global properties for the WWW Service. Every new Web site created on the server inherits these properties. Similarly, when you set properties for a Web site, directories created for the site inherit site properties.

Content Management

Table 3.8 NES 3.5 Content Management and Corresponding IIS 5.0 Properties

NES 3.5 Configuration Setting	Migrated by Wizard? (Y/N)	IIS 5.0 Metabase Property	IIS Snap-in Configuration
Document Footer (Footer Text)	Yes	DocFooter	You can specify a document footer for the entire IIS 5.0 server, for a single Web site, or for a directory. To configure this setting, right-click the server, a Web site, or a directory; click Properties, and then click the Documents tab.
Additional Document Directories (URL Prefix, Map to Directory)	Yes	Not applicable	The wizard creates a corresponding virtual directory. You can use the New Virtual Directory Wizard to create a virtual directory. To start the wizard, select the Web site for which you want to define a virtual directory, click the Action button, point to New, and then select Virtual Directory.
Cache Control Directives	No	Not applicable	By default, HTML pages in IIS 5.0 are cached by proxy servers. The default value for ASP pages is "private," meaning they cannot be cached. You can use the Response object to control whether a proxy server caches the page.
Default MIME Type	No	Not applicable	IIS 5.0 contains a comprehensive list of MIME types. Should you need to serve new MIME types, you can add them to the list. To view or edit MIME types, right-click a Web site, choose Properties, and then select the HTTP Headers tab. Click the File Types button in the MIME Map section of the tab.
Directory Indexing	Yes	EnableDirBrowsing	If you have selected "Simple" or "Fancy" directory indexing, the IIS Migration Wizard sets the Directory Browsing Allowed setting. To configure this setting, right-click a Web site, click Properties, and then click the HomeDirectory tab.
Hardware Virtual Servers (IP Address, Document Root)	Yes	ServerBindings	This is migrated as a component of ServerBindings. To configure a virtual server, right-click a Web site, choose Properties, and then select the Web Site tab. Click the Advanced button, and add the IP address and TCP port.
Home Page/Index File	Yes	DefaultDoc	A home page is migrated to IIS 5.0 using the default document name, and is listed ahead of any documents using index file names (according to the Index Filenames setting in this table). If no home page is listed, any specified index file names are used for the default document.
Index Filenames	Yes	DefaultDoc	See the previous note for the Home Page/Index File.
International Characters	No	Not applicable	With ASP pages, you specify the character set by using the Response.Charset property.
Parse Accept Language Header	No	Not applicable	Microsoft® Indexing Service can interpret this header, in order to determine the language in which a query is being written.
Parse HTML	No	Not applicable	By default IIS 5.0 processes files with .stm, .shtm, or .shtml file name extensions. For information about enabling and using server-side includes, see "About Server-Side Includes" in the IIS 5.0 online product documentation.
Primary Document Directory	Yes	Not applicable	The wizard creates a corresponding virtual directory. You can use the New Virtual Directory Wizard to create a virtual directory. To start the wizard, select the Web site for which you want to define a virtual directory, click the Action button, point to New, and then select Virtual Directory.
Software Virtual Servers (URL Host, Home Page)	Yes	ServerBindings	In IIS 5.0, you can assign any number of sites to a single IP address and distinguish them by using host headers, but no special term is employed to describe them. To configure a virtual server by using host headers, right-click a Web site, and then choose Properties. On the Web Site property sheet, click the Advanced button and enter the host header name for the IP address you want to use.
URL Prefix, Forward Requests To	Yes	HttpRedirect	This is called redirection in IIS 5.0. To redirect a request to another resource, right-click a Web site, choose Properties, select the Home Directory tab, and then select A redirection to a URL. Type the URL in the Redirect to box.

Web Publishing

The wizard does not migrate Web publishing settings. Web publishing can be supported with client-side development and management tools such as FrontPage (a member of the Microsoft® Office family) and Visual InterDev.

Agents and Search

The wizard does not migrate Agents and Search settings. Indexing Service, included with Windows 2000 Server, provides index and search capabilities. For more information, see the Windows 2000 Server online product documentation.

Auto Catalog

The wizard does not migrate Auto Catalog settings. As with Agents and Search settings, IIS 5.0 uses Indexing Service to build a searchable catalog of information about the content of the Web site.

Upgrading or Replicating an IIS Web Server

In addition to migrating to IIS 5.0 from another Web server, you might want to upgrade from an older version of IIS, or you might want to replicate an IIS 5.0 Web server to another computer. This section provides some tips for upgrading and replicating an IIS Web server.

First, here are a few items to note about upgrading IIS:

You can no longer use IS2WCGI to run WinCGI applications on IIS, starting with IIS 4.0.
For important information about what's changed between IIS 4.0 and IIS 5.0, see the "What's Changed" topic in the IIS 5.0 online product documentation.
For information about changes to ASP in IIS 5.0, see the "Important Changes in ASP" topic in the IIS 5.0 online product documentation.

Choosing an Approach

There are several ways you can approach upgrading an IIS Web server, as summarized in the following paragraphs.

Upgrade to a clean installation. Perform a clean installation of Windows 2000 Server and IIS 5.0 on new hardware, and then migrate settings, content, and applications to the new server by using the IIS Migration Wizard included on the Resource Kit companion CD. Thoroughly test and debug the migrated server prior to deploying it and taking the original production Web server offline.

Pros By doing this, you avoid taking your production Web server offline for a potentially extended time period while you upgrade and test it. Following deployment, if problems arise with the new server that didn't appear during testing, you have the original server available as a backup.

Cons The IIS Migration Wizard will not migrate large numbers of Web sites.

Recommendation This is the recommended method if you want to upgrade your hardware at the same time you upgrade IIS.
Upgrade a duplicate of the IIS server. On a second computer, install the same version of Windows NT Server and IIS as exists on the current production Web server and replicate content and applications. Upgrade the new server to Windows 2000 Server with IIS 5.0 by using the Windows 2000 Server Setup Wizard. Install IIS 5.0 during setup. Thoroughly test and debug the migrated server prior to deploying it and taking the original production Web server offline.

Pros: By doing this, you avoid taking your production Web server offline for a potentially extended time period. Following deployment, if problems arise with the new server that didn't appear during testing, you have the original server available as a backup.

Cons: You could potentially run into problems with the upgrade if the new server hardware is quite different from the old one. You'll probably need to adjust performance settings that are affected by hardware.

Recommendation: This is a good approach if you want to upgrade your existing hardware.
Upgrade a mirror of the production IIS server. Mirror the current production IIS server (operating system, software, configuration settings, and content) to a second computer. Then upgrade the mirror to Windows 2000 Server with IIS 5.0 by using the Setup Wizard. Thoroughly test the upgraded server prior to deploying it and taking the original production Web server offline. (You might be able to use Iissync.exe to replicate configuration settings. For more information about using this tool, see the topic "Replication and Clustering in IIS" in the IIS 5.0 online product documentation.)

Pros: By doing this, you avoid taking your production Web server offline for a potentially extended time period. Following deployment, if problems arise with the new server that didn't appear during testing, you have the original server available as a backup.

Cons: All hardware on the second system must exactly duplicate the original IIS server, so you must forgo the option to upgrade your hardware when you upgrade IIS.

Recommendation: This is an acceptable approach if you don't want to upgrade your hardware.
Upgrade the production IIS server. Take your existing IIS production Web server offline, and then upgrade it to Windows 2000 Server with IIS 5.0 by using the Setup Wizard. Thoroughly test the upgraded server prior to re-deploying it.

Pros: No hardware cost.

Cons: Upgrading a production Web server is extremely risky. You must take the server offline, and it will not be available to users until you complete all upgrade tasks, testing, and debugging.

Recommendation: This method is not recommended except when you have implemented a Web server cluster and only need to take one of the clustered production Web servers offline at a time to implement the upgrade. The remaining servers in the cluster stay online and are fully functional.

Recommendations for Upgrading or Replicating

It is recommended that you do the following when upgrading or replicating an IIS Web server:

Back up the metabase. To do this, from the IIS snap-in, right-click the computer name, choose Backup/Restore Settings, click Backup, type a name for the backup file, and then click OK. Or you can use the Iissync utility to replicate the metabase.
Use the Iissync utility to replicate configuration settings to a different computer, as described in the "Replication and Clustering in IIS" topic of the IIS 5.0 online product documentation.
Back up all Web and FTP site content as well as security certificates to a different computer. You can use XCopy, included in the Windows 2000 operating system, to copy the Web directory structure recursively and preserve security settings.
Write down the Web site names and IP addresses.
Use one of the approaches listed in the previous section to upgrade or replicate the server to the upgraded or new IIS server.
Add all the IP addresses to the Network Information Center (NIC) on the upgraded or new server and configure the network accordingly.
Install Microsoft® Internet Explorer on the upgraded or new server.
In the IIS snap-in, assign IP addresses to the virtual directories.
Make sure that the IUSR account agrees with the IIS snap-in and User Manager for domains.
Using FrontPage Server Administrator, apply new FrontPage Extensions to the Web sites.

Migrating Web Applications

An important decision to make when migrating to IIS 5.0 is how to handle existing Web applications. IIS 5.0 supports applications based on CGI, ISAPI, and ASP. In some cases, it is best to simply port an application to IIS 5.0, making only a few necessary changes. This is usually true for existing ISAPI extensions and ASP applications, which make efficient use of server resources, and for CGI applications that are not heavily used. However, you might decide to rewrite CGI applications as either ISAPI extensions or as ASP applications in order to improve their scalability and performance as well as to simplify the development process. This will save both time and money.

This section discusses the following:

Issues to consider when deciding whether to port a CGI application directly to IIS 5.0 or to rewrite it as an ASP application or ISAPI extension.
The basic work involved in each approach to migration and references to more in-depth information.
Changes that must be made to UNIX-based applications before they will run on IIS 5.0.

This material assumes you're familiar with Web-based applications and CGI. You can find additional references on migrating and porting applications in the "Additional Resources" section at the end of this chapter, and more information about developing with ASP in "Developing Web Applications" in this book. For information about installing and configuring applications, see the "Configuring Applications" topic of the IIS 5.0 online product documentation.

IIS 5.0 Application Technologies

The following is a brief description of the application technologies supported by IIS 5.0.

CGI IIS 5.0 fully supports both scripts and executables written to the CGI specification. IIS 5.0 supports scripts written in a variety of languages when the appropriate Win32 script interpreter is installed and configured, for example, Perl, Python, TCL, REXX, and JScript. It also supports scripts written in VBScript that have been modified to support standard input and output variables. As a result, many CGI applications can be ported to IIS 5.0 with minimal changes.
ISAPI Extensions ISAPI extensions consist of multithreaded DLLs loaded into IIS 5.0. ISAPI extensions have a strong performance advantage over CGI applications for several reasons. First, ISAPI extensions can be configured so all of them run in a single process, or so they run in the same memory space as the Web service. Second, instead of loading an executable for each request, ISAPI uses thread-safe DLLs that are loaded only once. Finally, ISAPI uses Win32-based APIs to communicate with the Web service, which is much faster than CGI methods. ISAPI extensions developed for other Web servers are generally easy to port to IIS 5.0. In addition, it is sometimes advantageous to rewrite existing CGI applications as ISAPI extensions to improve their performance, as discussed later in this section.
ISAPI Filters ISAPI filters extend the capabilities of IIS 5.0. You can write an ISAPI DLL to intercept specific server events and perform appropriate actions. This functionality is especially useful in implementing server security. For more information, see https://www.bnt.com/inetsdk/httpfilt.htm#_in_Overview .
ASP ASP is an open, server-application environment in which you can combine HTML, server-side scripts, and reusable COM components to create dynamic and powerful Web-based business solutions. IIS 5.0 natively supports scripts in ASP pages written in both VBScript and JScript, but you can use any scripting language when the appropriate script interpreter conforming to the Active Scripting standard is installed. ASP provides a number of intrinsic objects that make application development quick and easy, including Application, Session, Request, Response, and Server objects. ASP also supports COM components, which allow you to reuse business logic in other applications. ASP is supported by a number of Web servers, and existing ASP applications can be easily ported to IIS 5.0. In addition, it is often a good idea to rewrite CGI applications as ASP, as discussed later in this section, particularly those with functionality that you can quickly and easily reproduce by using ASP built-in objects.

Note: The terms "CGI script" and "script in an ASP page" can be confusing. Generally, when people use the term "CGI script," they are referring to a Perl script and then become mystified when this "CGI script" causes an ISAPI error. To ease the confusion, keep in mind that a script is simply a file containing instructions that are processed by some other component. A script in an ASP page, for example, might be a VBScript or a JScript file that is handed off to Asp.dll for processing. As with scripts in an ASP page, Perl scripts are handed off to a Perl interpreter for processing. However, some Perl interpreters are CGI-based executables and some are ISAPI-based DLLs®and the latter can create an ISAPI error.

Deciding to Port or Rewrite CGI Applications

An important decision you must make is whether to simply port a CGI application, making minimal changes needed for it to run on IIS 5.0, or to rewrite it as an ISAPI extension or an ASP application. Two basic considerations are as follows:

Expected performance gains compared to the work involved in rewriting the application.
Relative ease of developing and maintaining the application over time.

Performance vs. Development Work

Regarding the first consideration, ISAPI and the ASP scripting environment yield applications that are faster and more scalable than CGI applications. However, the work involved to migrate a particular CGI application to ISAPI or ASP can vary a great deal, depending on the structure of the application. In the case of a simple, clearly structured CGI application, you may be able to simply preserve the business logic and implement IIS 5.0 built-in input and output techniques. For a discussion of this approach, see "Migrating from CGI to ASP" later in this section. However, if the application is complex and the business logic is not easily separated from the rest of the application, rewriting it can be time-consuming. At this point, you need to carefully weigh the expected performance gains against the required effort.

Performance differences between CGI, ISAPI, and ASP are due to differences in server process overhead. CGI applications do not use server resources efficiently because a new, separate process is created for every client request, even if a single client submits more than one request. At any given time, the server must support a separate process for each ongoing request.

Unlike CGI applications, ISAPI extensions and ASP applications can be configured to either run in the same process as the Web service, or run in a pooled process. The server does not create a new process for each request, which greatly reduces the drain on resources. As a result, some benchmarks show that CGI applications run anywhere from two to three times slower than ASP applications and from three to five times slower than ISAPI extensions.

Besides avoiding server process overhead, ASP provides other performance-enhancing features, such as ODBC connection pooling and Microsoft® OLE DB session pooling, as described in "Data Access and Transactions" in this book.

Besides using more resources, CGI applications scale poorly on IIS 5.0. Adding additional processing power or RAM typically does not allow the application to support correspondingly more concurrent users. Therefore, if a CGI application is heavily used, you have compelling reasons to move to a solution that uses ISAPI or ASP, even when the application is complex and will be time-intensive to convert.

In deciding between ISAPI and ASP, bear in mind that ISAPI extensions offer some performance advantages over ASP applications, but ASP applications can often be developed more quickly.

Effort to Develop and Maintain

Regarding the second consideration, the ASP development environment has several advantages over that of CGI. First, the Microsoft® Script Debugger, IIS 5.0 application management features, and built-in database connectivity enhance ASP development productivity. Also, the ASP environment provides much of the functionality for managing forms, output, and state, so with ASP you might be able to remove a significant amount of existing CGI code, giving you a smaller code base to maintain.

Note: When migrating an application, it's important to consider application architecture. To build a successful and scalable distributed application, where application logic can reside on a Web client, a Web server, and on other back-end servers (such as databases), you must separate the application's functionality into logical groups of services, or tiers.

For more information about three-tier architecture, about designing and building Web applications, and about reusable application components, see "Developing Web Applications" in this book and the "Windows Script Components" topic in the IIS 5.0 online product documentation. For references to other resources, see the "Additional Resources" section at the end of this chapter.

Porting CGI Applications

IIS 5.0 supports the CGI 1.1 standard. Porting a CGI application to IIS 5.0 from a Windows-based Web server is fairly simple, and you do not need to make many changes for the application to run. The most frequent problems encountered by individuals porting a Windows-based CGI application to IIS 5.0 are installing the application in the correct directory and configuring security. You also need to make sure you have the necessary script interpreter installed, if the application consists of a script. These issues are covered in the "Configuring CGI Applications" topic in the IIS 5.0 online product documentation.

Porting a CGI application to IIS 5.0 from a UNIX-based Web server requires some work to bring it into conformance with Windows file and application conventions. For more information, see "Special Considerations for UNIX Applications" later in this chapter.

Another type of CGI application, WinCGI, isn't as easy to port. WinCGI was developed as a simple way to get Visual Basic applications to work with the O'Reilly Web server. Visual Basic doesn't normally use the standard input (stdin) and output (stdout) streams or environment variables as do CGI- and character-based applications. Therefore, WinCGI takes the query string arguments, server variables, and stdin data and places them in an .ini file. The application then reads the .ini file for input and writes to it for output. WinCGI isn't supported on IIS 4.0 or IIS 5.0, and you cannot directly port applications based on WinCGI. You have three options for dealing with this type of application:

Rewrite it as a CGI that uses standard input and environment variables to transfer data.
Rewrite it as a script in an ASP page.
Write an ISAPI DLL to host WinCGI.

ASP is by far the best solution for anyone who wants to write IIS 5.0 applications in Visual Basic. ASP is very fast. In addition, it's designed to work with VBScript, and contains built-in objects that make application development easy®you can write a script in Notepad in seconds without having to build an .exe or a .dll file. Finally, ASP is robust with COM, is fully supported, and handles non-thread-safe components (although it's faster with thread-safe components).

Configuring a Script Interpreter

IIS 5.0 provides built-in JScript and VBScript interpreters for ASP, so you don't have to take any additional steps to run ASP applications written in these scripting languages. However, to run ASP applications written in Perl or to run CGI scripts, you must install and configure a Win32-compatible version of the appropriate script interpreter (also called a scripting engine).

To configure a script interpreter

Obtain the script interpreter. Perl 5.0 and Regina REXX script interpreters are included on the Resource Kit companion CD. You can also obtain Win32-compatible script interpreters on the Internet. The following Web sites provide Win32 implementations of Perl, TCL, Python, and REXX:

·Perl

https://www.activestate.com/

·TCL

https://www.scriptics.com/

·Python

https://www.python.org/windows/

·REXX

https://www.software.ibm.com/ad/obj-rexx/

Note: The ActiveState Tool Corporation provides three Perl interpreters of interest to IIS 5.0 developers: Perl for Win32 (Perl.exe), Perl for ISAPI (PerlIS.dll), and PerlScript, an Active Scripting interpreter for PerlScript code in ASP pages.
Install the script interpreter. Extract the script interpreter archive into a new directory on your hard drive, for example, c:\perl. Be sure directory names are expanded from the archive. Follow the instructions provided by the vendor to build the script interpreter from the source code package, and install the files. If the script interpreter package contains files with long file names, when downloading from the Internet be sure to use a zip file handler that opens them correctly, such as WinZip or Info-Zip Unzip.

Note: Before running Install.bat, you might want to change directory to the DOS version of your directory if you gave it a long file name. This will ensure that readable paths are listed in the registry.
Set permissions. In Windows Explorer, set NTFS permissions on the directory containing the script interpreter by giving Execute permissions to the Everyone account. Next, set permissions on the directory containing the actual scripts. For testing purposes, you can give Read permissions to the Everyone account. Otherwise, you should set access permissions to Script, and disable Read permissions. In the IIS snapin, set Script only permissions on the scripts virtual directory. For more information, see Table 3.1, "Basic Web Security Settings."
Set application mappings. In the IIS snap-in, map the extension for the script file(s) to the executable for the script interpreter. For example, you might map the extension .py to Python.exe, the executable for the Python script interpreter. For more information, see the "Setting Application Mappings" topic in the IIS 5.0 online product documentation.

Note: For the ActiveState Perl script interpreter, the extension .pl is associated with PerlIS.dll by default. If you want to change the association of .pl to perl.exe, you need to change the application mapping. In the mapping, you must add two percent (%) characters to the end of the pathname for perl.exe, as shown in the following example:

c:\perl\bin\perl.exe %s %s

Set permissions on the script interpreter executable directory. In the IIS snap-in, edit the application configuration for the home directory to recognize the script interpreter executable.

Special Considerations for UNIX Applications

There are special considerations when you're migrating Web applications from a UNIX environment. Not only do you need to be concerned with how the application functions on the Web server, but on the operating system as well. There are many differences between UNIX and Windows 2000 operating systems, and the degree to which your application is based on UNIX-specific technology affects how easy or difficult it will be to migrate.

The effort required to port a UNIX application to IIS 5.0 will be affected not only by the portability of the application, but also by the products and tools used to build it. This means that the database, round-robin DNS, developer tools, dynamic content pages, CGI applications, and any custom binaries or third party tools must work well with Windows 2000 Server.

The "ideal" UNIX-based application to port to IIS 5.0 would have the following characteristics:

It would use the Perl language for CGI applications (Perl script interpreters are available for IIS 5.0).
It would use FrontPage Extensions for Web publishing.
It would access a Structured Query Language (SQL) Server or Oracle back end.
Third-party tools it used would also run on Windows 2000 Server.
Development tools used for it would work with Windows 2000 Server.
It would not use any custom Apache modules.

This type of application would be a good candidate to migrate "by hand," converting it to a CGI, ISAPI, or ASP-based application that can run natively on IIS 5.0.

Most applications won't be so ideal. You might decide it isn't cost-effective to migrate some or all of your CGI applications, for example, if they're difficult to migrate, or if you have a large number of them. In this case, you might consider using a third-party tool such as PerlEX, a plug-in you can use with IIS 5.0 that dramatically improves the performance of Perl CGI applications. This way, you can run existing Perl CGI applications without creating a drain on IIS 5.0 resources. PerlEX also supports embedding Perl scripts within HTML. For more information, see https://www.activestate.com/plex/ .

As an interim solution, you might also consider using a third-party tool that provides a UNIX-like environment for running applications on IIS 5.0. This way, you can gradually migrate applications to run natively on IIS 5.0, avoiding the need to rewrite a large amount of code in a short time frame. One such tool is Interix, by Softway Systems, Inc., which provides a Portable Operating System Interface (POSIX) environment. In addition, NutCracker, by DataFocus, has a run time that provides UNIX calls on Windows NT and Windows 2000. It uses the Win32 environment, which is more efficient than POSIX, and also provides access to COM.

For more information about available tools for migrating UNIX applications, see "Additional Resources" at the end of this chapter.

Migrating a UNIX Perl Script

Here are some issues you might encounter when migrating a Perl script from a UNIXbased Web server to IIS 5.0.

Binary Mode

If you plan to use the Perl for Win32 script interpreter to run UNIX Perl scripts, you might need to make modifications to ensure the scripts run correctly. When reading a text file from a disk, Windows translates \r\n into \n, and reads ^Z as an end-of-file marker, but it doesn't use any such translation for binary files. For some Perl interpreters, the C run-time library opens files in text mode by default. For binary data, you should specify binary mode for the file handle by using the binmode function. For more information about doing this, see the perlfunc documentation.

Pathname Delimiters

When migrating a Perl script from UNIX, remember that Windows uses the backslash (\) character as a delimiter for paths in a file name, for example, c:\path\somefile.txt. Because Perl uses the backslash as an escape code, to symbolize a special character such as the line feed character (\n) or the tab character (\t), an error results if you attempt to open a file in this manner:

Open( MYFILE, "C:\path\somefile.txt" )

To resolve this problem, you can replace each backslash with a double backslash (\\), in order to indicate an actual backslash rather than the introduction of a special character. Or you can use noninterpolating single quote strings in order to indicate there are no special characters in the string, as follows:

Open( MYFILE, 'C:\path\somefile.txt' );

Converting UNIX Application Files

There are many differences between UNIX and Windows file descriptors and conventions. Those pertinent to migrating a Web application to IIS 5.0 are listed in the following table. To avoid application errors, you must make the necessary changes so your UNIX files adhere to Windows conventions.

Table 3.9 Necessary Changes to UNIX Application Files

Feature	UNIX Implementation	Change to This Windows Implementation
Directory separator	Forward slash (/).	Backslash (\). Note that Perl uses the backslash as an escape code, so in Perl scripts you'll want to replace the forward slashes (/) in paths (pathnames) with double backslashes (\\). Or you can use non-interpolating single quote strings to indicate there are no special characters in the string.
File names and pathnames	See the earlier discussion in "Converting UNIX File Names and Pathnames."
Directory hierarchy	The UNIX file system appears to be a single directory hierarchy.	Windows storage is divided into a number of physical or virtual disk drives with a directory hierarchy on each. To access a file on Windows, you must know what disk drive the file is on and specify the drive letter (C, D, E, and so forth) as part of the file path (pathname).
Text file line termination	UNIX uses only a line feed character to flag an end of a line in text files.	Text file lines should be terminated by a line feed and a carriage return. Some applications require both line feed and carriage return terminations to work correctly.
File descriptors/handles	UNIX file descriptors 0, 1, and 2 represent stdin, stdout, and stderr, respectively.	Win32 uses handles rather than descriptors, and you can't assume that they're fixed as you can in UNIX. Use the Win32 API call, GetStdHandle(), to ascertain which handles are being used.

Converting CGI to ISAPI

ISAPI extensions are Web applications implemented as DLL files. Converting a CGI application into an ISAPI extension will improve its performance.

ISAPI extensions run faster than any other type of application on IIS 5.0. ISAPI extensions run in the same memory space as the Web server, or in a pooled application process, unless a separate process is called. IIS 5.0 typically loads an ISAPI DLL the first time a request that calls the DLL is received. The DLL then remains in memory, ready to service other requests until the Web server is stopped or until the DLL is manually or programmatically unloaded.

Rather than using environment variables and standard input/output (I/O), as CGI does, ISAPI extension DLLs communicate through a data structure called the Extension Control Block (ECB). A small set of functions allow the DLL to communicate with the Web server. Because function pointers are used to communicate with the server, applications written in languages that support function pointers, such as C, C++, and Perl, are good candidates for conversion to ISAPI. CGI applications written in Visual Basic should be rewritten as ASP applications.

Perl scripts run most efficiently under ISAPI. PerlIS.dll, also called Perl for ISAPI, is an ISAPI extension that runs Perl scripts on the Windows operating system. Using the Perl for Win32 Perl.exe rather than PerlIS.dll to run your Perl scripts requires that the server create a new process for each request. For information about obtaining and installing PerlIS.dll, see "Configuring a Script Interpreter" earlier in this chapter.

Creating ISAPI DLLs requires a thorough understanding of the Win32 programming environment, including thread management. For some useful information sources on Win32 programming, see the "Additional Resources" section at the end of this chapter.

Note: An ISAPI DLL can be deployed by the developer or system administrator to run either within the IIS 5.0 process, in a pooled process with other DLLs, or in its own process. Developers frequently configure their applications to run out of process until they are fully tested because, should they malfunction, they won't affect other applications running on the computer. Once applications are fully tested, they are then configured to run in a pooled process for faster execution. Or if an application is prone to violation errors and failures, it can continue to run out of process on the production Web server.

Migrating from CGI to ASP

Whenever possible, migrate CGI applications to ASP, to take advantage of improved performance and the simplified development environment. Converting to the ASP scripting environment may not require as much effort as you think, because when you examine the application code you might find that much of it is unnecessary in the ASP environment. All you might need to do is port the business logic, greatly reducing the work involved. Removing CGI code that isn't required within the ASP environment®form processing, environment variable processing, e-mail manipulation, database handling, state management, and most importantly, output processing®can result in much smaller applications to migrate.

ASP Scripting Support

ASP enables server-side scripting for IIS 5.0 with native support for VBScript and JScript development software. In addition to these native languages, the ASP environment supports any scripting language that conforms to the Active Scripting requirements when its script interpreter is installed and configured. You can obtain ASP implementations of the Perl and Python script interpreters. (Perl 5 is included on the Resource Kit companion CD.)

You can select the scripting language to use within an ASP page. If you're migrating a CGI application written in C or Java, it may be easiest to use JScript because of its syntactical similarity. If the CGI application is written in Perl, you might find it convenient to use PerlScript.

In any case, consider using VBScript for building ASP pages. Millions of developers use the Visual Basic language. Organizations that move to VBScript can take advantage of this synergy and might find they have many more resources at their disposal.

Analyzing the Application

The first step in porting a CGI application to ASP is to analyze its logic. Most Web applications consist of five basic types of logic:

Input processing (reading forms, environment variables, and decoding HTML)
Business logic
Database (or gateway) logic for connecting to external services
Logic for maintaining state between forms
HTML output logic for returning results to browser clients

The following is a general discussion on how to handle each of these types of logic within the ASP environment.

Input Processing

A great deal of CGI processing involves capturing the contents of HTML forms as presented to the standard input stream, then reformatting them, decoding the HTML, reading environment variables, and so on. Because this is one of the most tedious aspects of developing CGI applications, many developers use third-party libraries and tools, such as the Perl utilities Cgi.pm or Cgi-lib.pl.In most cases, these utilities are unnecessary in ASP applications because the ASP environment takes care of most of these housekeeping tasks for you, as described in the following paragraphs.

Accessing Form Input and Decoding HTML

One of the major differences between CGI applications and ASP applications is the method for handling form input. Accessing form data from an ASP page is much simpler than it is from a CGI application. When migrating to ASP, you can often remove most of the third-party form decoding and processing utilities, as well as any custom generic formprocessing modules.

A CGI application written in Perl receives form input from a POST request on the standard input stream using code such as:

$form_size = $ENV('CONTENT_LENGTH');
read( STDIN, $form_data, $form_size );

This form data is encoded and must be translated. Using Perl, the translation code might look like:

$value =~ s/%([0-9a-fA-F]{2})/pack("c",hex($1))/ge;

Once the form data is decoded, the developer can search for a form variable. Here is a typical Perl routine to parse the form data and place it in a list:

sub get_form
{
local (*FORM) = @_;
local ( $env_string, @collection, $key_value,
$key, $value );
read (STDIN, $env_string, $ENV{'CONTENT_LENGTH'});
@collection = split( /&/, $env_string );
foreach $key_value (@collection)
{
($key, $value) = split( /=/, $key_value);
$value =~ tr/+/ /;
$value =~ s/%([0-9a-fA-F]{2})/pack("c",hex($1))/ge;
if (defined($FORM{$key}))
{
$FORM{$key} = join("\0",, $FORM{$key}, $value);
} else
{
$FORM{$key} = $value;
}
}
}

Once the routine is in place, it can be called to parse the form. The following code calls the get_form routine and references a variable called home_address:

&get_form(*my_form);
print $my_form('home_address');

Fortunately, the ASP environment takes care of these form processing and decoding chores for you. In ASP, the content of an HTML form is made available as a collection, which is a named list of key/value pairs. For developers familiar with languages like Perl or Awk, collections are analogous to hashes or associative arrays.

Form variables are included in the Form collection of the ASP Request object.

Instead of referring to a form variable with a Perl construction like this:

print $my_form('home_address');

you can refer to a form variable as shown in the following VBScript example:

MyAddress = Request.Form("home_address")

The following is the same instruction written in PerlScript:

$MyAddress = $Request->Form('home_address')

There is no need to parse the input, as was required in the CGI example, because the ASP environment takes care of parsing.

Although ASP applications do an excellent job of eliminating form-processing drudgery, developers sometimes need to access the unprocessed input stream. The following VBScript fragment writes the unprocessed input stream back to the output stream:

Response.Write Request.Form

In addition to the Form collection, the Request object includes a collection called QueryString. This collection contains form elements sent in response to the GET method of the HTML <FORM> tag. The elements of the QueryString collection are accessed in the same way elements of the Form collection are accessed.

Often, quite a bit of CGI code is devoted to determining whether a given form variable exists within the Query_String environment variable or in the standard input stream. However, within the ASP environment, you can avoid testing many of these conditions simply by referring to a variable by name:

MyVariable = Request("home_address")

In this case the Web server will search the Query_String first, then search the form, in order to find the correct variable. This feature can eliminate the need to rewrite code that is used for searching both the query string and the form.

To encode URLs or HTML, you can use the built-in HTMLEncode and URLEncode methods of the Server object.

Environment Variables

CGI applications that inspect environment variables can continue to do so when converted to ASP. Environment variables are provided as part of the Request object ServerVariables collection.

In a CGI application, you might access the Server_Name environment variable using a line of C code like the following:

serverName = getenv("SERVER_NAME");

or this line, written in Perl:

serverName = $ENV{'SERVER_NAME'};

In ASP, you can use the following instruction, written in VBScript:

serverName = Request.ServerVariables("SERVER_NAME")

You can iterate through collections such as ServerVariables in order to examine all the values they contain. The following ASP code, written in VBScript, generates an HTML table containing all the variables contained in the ServerVariables collection, with their values:

<%@ LANGUAGE=VBSCRIPT %>
<HTML>
<BODY>
<TABLE BORDER=1>
<% For Each Name in Request.ServerVariables %>
<TR>
<TD><%= Name %></TD>
<TD><%= Request.ServerVariables(Name)%></TD>
</TR>
<% Next %>
</TABLE>
</BODY>
</HTML>

Business Logic

Usually, once much of the "plumbing" is removed from a CGI application, some business logic remains to be ported. Approaches to migrating business logic include:

Taking business logic written in a language such as C, C++, or Perl, and rewriting it as an ASP-supported scripting language such as VBScript, JScript, or PerlScript. This is a good approach when the business logic is fairly simple and if it is useful in only one or two applications.
Encapsulating the business logic within a component. If the logic is extensive, requires more functionality than is available in a scripting environment, or is very general, this is a good approach. You can write components in any language that supports COM, including C, C++, Java, Visual Basic, Delphi, and even some implementations of COmmon Business Oriented Language (COBOL). The advantage of using components is that they can be reused in other business applications both within and outside the Web environment.

Note: Server-side components run completely within the server environment. Their use has no effect on whether an application can support a particular browser on a specific platform.

External Gateway and Database Logic

CGI applications were originally created to give Web clients access to applications outside the Web environment. Most CGI applications interface with databases of some sort, and many CGI applications are used to access services such as electronic mail servers. This section describes techniques for using ASP to access databases and other external services.

Databases

Microsoft® ActiveX® Data Objects (ADO) is a database access method you can use within the ASP environment. ADO is designed to be highly efficient in a multithreaded environment, where many instances of the ADO code execute simultaneously. Thus, ADO is ideal for Web applications, particularly when they need to scale to many concurrent users.

ADO exposes an object model to abstract the ideas of connecting to, and executing commands against, a remote database. The database need not support SQL, but if it doesn't, a database-specific piece of software called an OLE DB provider is required. If your database vendor supplies an ODBC driver for your database, you can use a provider for ODBC data sources that is supplied with IIS 5.0.

Perl developers commonly access a database by using a package such as Dbperl or the more current DBI package. No special package is required within the ASP environment. For example, the following simple ASP page, written in PerlScript. uses the ODBC data source ADOSamples to dump the contents of a table called "Orders":

<%@ LANGUAGE=PerlScript %>
<HTML>
<BODY>
<P>
<%
$Conn = $Server->CreateObject("ADODB.Connection");
$Conn->Open( "ADOSamples" );
$RS = $Conn->Execute( "SELECT * FROM Orders" );
%>
<TABLE BORDER=1>
<TR>
<%
$count = $RS->Fields->Count;
for ( $i = 0; $i < $count; $i++ )
{
%><TD><B><%= $RS->Fields($i)->Name %></B></TD><%
}; %> </TR> <%
while ( ! $RS->EOF )
{
%> <TR> <%
for ( $i = 0; $i < $count; $i++ )
{
%><TD VALIGN=TOP>
<%= $RS->Fields($i)->value %></TD><%
};
%> </TR> <%
$RS->MoveNext;
};
$RS->Close;
$Conn->Close;
%>
</TABLE>
</BODY>
</HTML>

An additional benefit of working within the ASP environment is the ability to take advantage of Component Services. Not only does Component Services provide support for process isolation, as discussed previously, it also enables developers to easily build scalable Web applications based on components. Component Services takes care of all the plumbing issues such as transactions, connection management, and thread management, thus freeing the developer to concentrate primarily on building business logic.

For more information about ADO and Component Services, see "Data Access and Transactions" in this book and see https://www.microsoft.com/com/.

For more general information about ADO, ODBC, and Microsoft's overall data access strategies, see https://msdn.microsoft.com/library/default.asp?url=/nhp/Default.asp?contentid=28001860.

Maintaining State

There are several schemes commonly used in CGI applications for maintaining state information about the client session on the Web server. Some of these involve scripts that save and restore data from server-side text files. Others involve embedding state in the client-side HTML (for example, using hidden form fields). Some CGI applications even maintain state by setting themselves up as "mini Web servers" for the duration of the session, intercepting incoming HTTP requests. Many Web developers have moved to using browser-based cookies for storing state information.

ASP provides built-in state management through the Session collection of variables, making session management transparent to the Web developer. When a client first connects to the application, the server can send a session cookie that identifies the new session. As the browser accesses other pages in the application, the cookie is retrieved by the system and is used to manage state.

For example, consider an ASP page in which the user's login name is retrieved and assigned to a session variable:

Session("login_name") = Request.Form("login_name")

The value of login_name will be available to all other pages within the application, until the session times out (the default is 20 minutes, but it is configurable) or is explicitly abandoned.

Output Handling

A key difference between ASP and CGI applications is that in an ASP page you can interweave industry-standard HTML and server-side scripting code to deliver the appropriate HTML to the client. By doing so, you combine the most powerful elements of both environments.

Using standard HTML as part of the application code is a benefit that cannot be overemphasized. With this feature, the developer can emit any HTML that the client browser supports, whereas utilities such as Cgi.pm are necessarily limited by the tags they implement. With new developments such as DHTML, tools such as Cgi.pm must be modified, perhaps heavily, to support new tags or other new client-side features.

In addition, with ASP, Web designers and nonprogrammers can author in pure HTML. On the other hand, having to use a special HTML dialect, as required by CGI tools such as Cgi.pm makes it difficult for these users to modify the generated HTML.

Many CGI applications emit HTML by using the output facilities of the language in which they're written. For example, a simple Perl-based CGI application might look like this:

#!/usr/local/bin/perl
print "Content-type: text/html", "\n\n";
$server_name = $ENV('SERVER_NAME');
print "<HTML><BODY>Your server name is ", $server_name;
print "</BODY></HTML>";
exit(0);

Note that the HTML is embedded within the print function. The following is the corresponding ASP page, with code written in VBScript:

<HTML>
<BODY>
Your server name is <%= Request.ServerVariables("SERVER_NAME") %>
</BODY>
</HTML>

Note that the entire page is just simple HTML, except for the VBScript expression

<%= Request.ServerVariables("SERVER_NAME") %>

For some applications you must specify HTTP header information, rather than using the default MIME type of text/html. In the ASP environment, you can accomplish this by using the ContentType property of the Response object. For example, the following instruction sets the content type to "text/plain":

<% Response.ContentType = "text/plain" %>

Many Perl-based CGI applications use the Cgi.pm or Cgi-lib.pl modules for formatting HTML output, as well as for performing other tasks. For example, the following script uses Cgi.pm to generate a form that collects the user's address; once the form is submitted, the form is redisplayed with the address beneath it:

use CGI qw(:all);
print header;
print start_html('Enter your address'),
h1('Enter your address'),
hr,
p,
start_form,
table(
Tr(td("Street"),td(textfield('street'))),
Tr(td("City"), td(textfield('city'))),
Tr(td("State"), td(textfield('state'))),
Tr(td("Zip"), td(textfield('zip')))
),
submit,
end_form,
hr;
if (param())
{
print
"Street is: ", param('street'), p,
"City is: ", param('city'), p,
"State is: ", param('state'), p,
"Zip is: ", param('zip'), p,
hr;
}

The preceding script provides a convenient way to lay out a form if you aren't able to generate the HTML as part of the source code. The drawback to these utilities is that they require the developer to master a "pseudo-HTML" dialect in order to generate the page.

The corresponding ASP page looks almost exactly like the actual HTML page that will be sent to the browser, except for the VBScript that is interwoven with the HTML:

<HTML>
<HEAD>
<TITLE>Enter your address</TITLE>
</HEAD>
<BODY>
<H1>Enter your address</H1>
<HR>
<P>
<FORM METHOD=POST>
<TABLE>
<TR><TD>Street</TD><TD><input name="street"></TD></TR>
<TR><TD>City</TD><TD><input name="city"></TD></TR>
<TR><TD>State</TD><TD><input name="state"></TD></TR>
<TR><TD>Zip</TD><TD><input name="zip"></TD></TR>
</TABLE>
<INPUT TYPE=SUBMIT>
</FORM>
<HR>
<% If Request.Form.Count > 0 %>
Street is: <%= Request.Form("street") %> <P>
City is: <%= Request.Form("city") %> <P>
State is: <%= Request.Form("state") %> <P>
Zip is: <%= Request.Form("zip") %> <P>
<HR>
<% End If %>
</BODY>
</HTML>

The File System

CGI applications frequently interact with the file system. There are several approaches to accessing the file system from within the ASP environment. The easiest method is to use the FileSystemObject and TextStream objects, which provide high-level access to the file system. For example, the following ASP page, written in VBScript, creates a text file, and writes the contents of the environment variable Server_Name to its own line:

<%@ LANGUAGE=VBScript %>
<HTML>
<BODY>
<%
Dim objFS, objFile, append
append = 8
Set objFS = Server.CreateObject("Scripting.FileSystemObject")
Set objFile = objFs.OpenTextFile("c:\servlist.txt", append, True )
objFile.WriteLine Request.ServerVariables("SERVER_NAME")
objFile.Close
%>
Done
</BODY>
</HTML>

If the supplied FileSystemObject and TextStream objects do not meet your needs, file system access can be encapsulated with a COM component. To learn more about components, see the "COM Concepts" topic in the IIS 5.0 section of the SDK documentation on MSDN, and see https://www.microsoft.com/com/.

Reproducing Common CGI Services

It is easy to reproduce many common CGI services, such as e-mail message delivery and page counters, by using ASP intrinsic objects or a comparable Win32 application. This section describes how to reproduce some of the most common CGI services on IIS 5.0.

Electronic Mail Delivery

Many CGI applications, such as sendmail, format RFC-822 e-mail messages for delivery to a mail server. You can easily reproduce this functionality by using ASP. Or you can make minor modifications to your sendmail script, and then run a comparable Win32 mail application, such as Blat.exe.

Using ASP to Send E-mail Messages

IIS 5.0 includes a SMTP service and exposes all of its functionality through the Collaboration Data Objects (CDO) object model. When the SMTP service is installed and configured, you can use the CDONTS object included with IIS 5.0 to send an e-mail message from an ASP page, as shown in the following example, written in JScript:

<%@ LANGUAGE=JScript %>
<%
var msg;
msg = Server.CreateObject("CDONTS.NewMail");
msg.From = "someone@microsoft.com";
msg.To = "someone@microsoft.com";
msg.Subject = "Sample message";
msg.Body = "This is a sample message.";
msg.Send();
%>

or in VBScript:

<%@ LANGUAGE=VBScript %>
<%
Dim objMail
Set objMail = CreateObject("CDONTS.NewMail")
objMail.Send "someone@microsoft.com","someone@microsoft.com","Message subject","Message body"
%>

The following is an ASP page written in VBScript that illustrates how to capture the Http_Referer, Remote_User environment variables from a form and return the message, "Thank you User_Name for sending mail."

<%@ LANGUAGE=VBScript %>
<%
'*** Load Constants
SENDTO = "someone@microsoft.com"
SUBJECT = "Form Reply-Response Example"
USERNAME = Request.ServerVariables("LOGON_USER")
'*** Post values to the form
name = Request.Form("name")
email = Request.Form("email")
telephone = Request.Form("telephone")
category = Request.Form("category")
'*** Build message body
BodyString = BodyString & "Name = " & name & VbCrLf
BodyString = BodyString & "Email = " & email & VbCrLf
BodyString = BodyString & "Telephone = " & telephone & VbCrLf
BodyString = BodyString & "category = " & category & VbCrLf
'***Begin Send mail to customer***
Set myMail =
Server.CreateObject("CDONTS.NewMail")
myMail.From = email
myMail.To = SENDTO
myMail.Subject = SUBJECT
myMail.Body = BodyString
myMail.Send
Set myMail = Nothing
'***End Send mail to customer***
'***Build confirmation body***
OutputString = "<P></BODY></HTML>"
OutputString = OutputString & "<P>  <P>Thank you " & USERNAME & " for
sending mail<P>" & VbCrLf
'***Begin Build footer and send to customer***
OutputString = OutputString & "<P></BODY></HTML>"
Response.Write OutputString
'***End Build footer and send to customer***
%>

The following example, also in VBScript, shows how to send an e-mail attachment.

att_file="c:\Reports\wklyRpt.txt"
f_name="WklyRpt.txt"
Set objMail = CreateObject("CDONTS.NewMail")
objMail.From="someone@microsoft.com"
objMail.To="someone@microsoft.com"
objMail.Subject="Weekly Report"
objMail.Body="Attached below is my weekly report file."
objMail.AttachFile att_file,f_name
mailres=objMail.Send()

Migrating a UNIX Mail Script

A common CGI application in UNIX uses commands to call a Perl script, which then pipes messages to the "mail" e-mail application. In the following example, the Perl script is named MAILPROGRAM:

#Open a pipe to the MAILPROGRAM script located in /usr/local/bin:
Open (MAILPROGRAM, "l/usr/local/bin/mail someone@microsoft.com");
#Write the e-mail message:
Print MAILPROGRAM $emailMessageText;
#Close the pipe and send the message:
Close MAILPROGRAM;

When migrating to Windows 2000 Server, you can modify the Perl MAILPROGRAM script to call a Win32-compatible e-mail application, named Blat.exe. This is a simple, command-line SMTP e-mail application that works very much like mail on UNIX. You can obtain Blat.exe on the Resource Kit companion CD, or see https://www.shareware.com.

Install Blat.exe in the Web site applications directory, and be sure to configure it in the IIS 5.0 snap-in. Also, in the Services Control Panel, disable the SMTP service that comes with Windows 2000 Server.

Here is the Perl MAILPROGRAM script as used on UNIX:

Open(MAILF,"lmail-s\"Calendar activity $what $boss");>>print MAILF"For$today";
Print MAILF",and continuing for $days days";
Print MAILF"$val{$what}was";
Print MAILF"added to the schedule:\n";
Print MAILF"$val{$from}$val{$till}$work";
Print MAILF"removed from the schedule:\n";
Print MAILF"(originally was $gonzo)";
Close MAILF;

To run this script on Windows 2000 Server, replace mail with blat in the first line, as follows:

Open(MAILF,"lblat-s\"Calendar activity $what $boss");>>print MAILF"For$today";

Page Counters

To improve the performance and efficiency of your Web site, you can replace CGI-based page counters with the ASP Page Counter Component included with IIS 5.0. This creates a PageCounter object that counts and displays the number of times a Web page has been opened. It also writes the number of page hits to a text file. The following ASP script, written in PerlScript, demonstrates how to query the component and display the hit count:

<%@ LANGUAGE=PerlScript %>
<HTML>
<BODY>
<%
$counter = $Server->CreateObject("MSWC.PageCounter");
$hits = $counter->Hits;
%>
You are visitor number <%= $hits %> to this page.
</BODY>
</HTML>

For more information about ASP components, see the "Module 2: Using COM Components" topic in the ASP Tutorial, found in the IIS 5.0 online product documentation.

Additional Resources

The following Web sites and books provide additional information about IIS 5.0 and about other features of Windows 2000 Server, all of which can help you perform migration.

IIS 5.0 Migration Tools

IIS Migration Wizard

The Resource Kit companion CD includes the IIS Migration Wizard, which automatically migrates most configuration settings to IIS 5.0 from the following Web servers:

Netscape Enterprise Server 3.5 (Windows version). (You can find the wizard to migrate from Netscape Enterprise Server 2.x and 3.x to IIS 4.0 in the Microsoft® Internet Information Server 4.0 Resource Kit.)
Apache HTTP Server 1.3 (UNIX version).
IIS 4.0.
IIS 5.0. (This feature is useful for replicating an IIS 5.0 server.)

Note: The IIS Migration Wizard is provided for educational purposes only and is not supported by Microsoft.

Application Migration Tools

https://msdn.microsoft.com/developer/sdk/

The Microsoft Platform Software Development Kit (SDK)®January 1998 Edition:Current and emerging Microsoft technologies including tools, headers, libraries, and sample code, as well as information about developing ISAPI extensions. This is the successor to the Win32 SDK, and includes components that have been distributed separately in the Microsoft® Win32 SDK, the Microsoft® BackOffice® SDK, the Microsoft® ActiveX/Internet Client SDK, and the Microsoft® DirectX SDK.

https://msdn.microsoft.com/scripting/

Information about Microsoft Windows script technologies, including JScript, VBScript, and Microsoft® Windows® Script Host (WSH).

https://www.activestate.com/

ActiveState provides three Perl interpreters of interest to IIS developers: Perl for Win32, Perl for ISAPI, and PerlScript, an Active Scripting interpreter that runs PerlScript in ASP pages. In addition, it provides PerlEX, a plug-in you can use with IIS 5.0 that dramatically improves the performance of Perl CGI scripts and allows you to embed Perl code within HTML.

https://www.microsoft.com/technet/interopmigration/unix.mspx

To Windows 2000 Server and IIS 5.0, Interix adds the ability to host complete Internet applications developed for UNIX systems. It provides full support for sendmail, Perl and TCL/TK, UNIX commands and shells, including rcommands, and remote access with telnetd and rlogind.

https://www.datafocus.com/

This Porting Guide by DataFocus Inc. describes how to use Nutcracker to migrate UNIX and X/Motif applications to Windows 2000, Windows NT, and Microsoft® Windows® 95 as native Win32 applications.

https://www.mks.com/

Mortice Kern Systems makes the MKS Toolkit, which provides many utilities, such as htdiff, htsplit, url, and Web, to help you automate Web development and maintenance tasks. The Toolkit includes a version of Perl, as well as Pscript, an Active Scripting interpreter that allows you to use PerlScript code in an ASP page.

https://www.python.org/windows/

Provides Python language products for the Windows operating system.

https://www.scriptics.com/

Provides Tcl scripting language productsfor the Windows operating system.

https://cygwin.com/

Includes GNU development tools for the Windows operating system.

https://cgi-lib.berkeley.edu/

Provides information about the Cgi-lib.pl library.

https://stein.cshl.org/WWW/software/CGI/

Provides information about the Cgi.pm utility.

Server Administration and Interoperation Tools

https://www.microsoft.com/ntserver/techresources/interop/unix/sfu.asp

Windows NT Services for UNIX, a suite of interoperability tools and utilities for Windows NT Server and UNIX. At the time of this writing, a version of this tool suite is under development for Windows 2000.

https://www.microsoft.com/ntserver/techresources/interop/unix/WindowsNTUNIX.asp

This white paper lists Microsoft interoperation initiatives and partners.

https://www.netmanage.com/

NetManage, Inc. provides PC connectivity solutions, such as Chameleon UNIX Link 97, version 8.0, with significant enhancements to X Windows and NFS applications, extended browser access to UNIX, AS/400, and mainframe systems, as well as SupportNow technology. Chameleon UNIX Link 97 supports Windows 3.x, 9x, and Windows NT.

https://www.shareware.com/

Offers a tool called Ws_ftp to perform recursive FTP for the Windows operating system.

Reference Books

Migrating to Windows NT by Steve Heath, 1997, Houston: Digital Press.

Windows NT & UNIX, Administration, Coexistence, Integration, & Migration by G. Robert Williams and Ellen Beck Gardner, 1998, Reading: Addison Wesley Longman, Inc.

Windows NT, UNIX, NetWare Migration and Coexistence, A Professional's Guide by Raj Rajagopal, 1998, Boca Raton: CRC Press LLC.

Windows NT & UNIX Integration Guideby David Gunter, Lola Gunter, et al, 1997, Berkeley: Osborne McGraw-Hill.

Security Resources

https://msdn.microsoft.com/library/en-us/dniis/html/Websec.asp

An article on IIS security, "Untangling Web Security: Getting the Most from IIS Security."

https://www.microsoft.com/security/default.asp

The Microsoft Security Advisor.

In addition, the following Internet resources provide general information about security:

CERT Advisory

ftp://cert.org/.message/

Usenet News

Alt.comp.security

Search Yahoo

You'll find many listings under the general search term "security."

·Perl	https://www.activestate.com/
·TCL	https://www.scriptics.com/
·Python	https://www.python.org/windows/
·REXX	https://www.software.ibm.com/ad/obj-rexx/