Migrating Web sites from IIS 4.0 to IIS 6.0

Many Web sites run on IIS 4.0, but with Windows NT heading to the sunset and IIS 6.0 now debuting on Windows Server 2003, many organizations are thinking about upgrading. Here's what you'll face when migrating from IIS 4.0 to IIS 6.0.

As an early beta tester, I’ve been using and writing about Windows Server 2003 for more than a year. There are lots of improvements and changes in the platform, not least of all in Internet Information Services 6.0. Those changes could be a big issue for a lot of organizations. A recent Gartner study found that nearly 80 percent of the respondents moving to Windows Server 2003 were coming from Windows NT. For that reason, many organizations will be moving their Web sites from IIS 4.0 to IIS 6.0 as their Windows Server 2003 rollouts take place. Here are the processes and issues involved in a migration from IIS 4.0 to IIS 6.0.

Many paths, one destination
There are several approaches you can take to migrating your Web services from IIS 4.0 to IIS 6.0. In almost every case, an in-place upgrade from Windows NT to Windows Server 2003 isn’t the best approach. Unless you've installed the server recently, its hardware is likely not up to today’s standards. Your Web presence is no doubt growing rather than waning, so this is the ideal time to install a new server to handle increased traffic and provide better throughput.

Availability is another, perhaps more important, reason to avoid in-place upgrades. Even if the upgrade goes as planned, the server will still be unavailable during much of the installation process. When you add the possibility, however remote, that Setup could fail and leave the server unusable and in need of a rollback or restore, an in-place upgrade just doesn’t make sense. In general, I recommend an in-place upgrade only if you can afford to have the server offline for a period of time that you can easily roll back if needed, and it is not running any custom Web applications.

The best approach is to install a new server in a lab setting, migrate the site to the new server, and perform extensive testing on the server before taking it live. Once you’ve worked out all of the bugs, a simple IP address, DNS, or NAT change can replace the old server with the new one. Let me emphasize that there is no substitute for extensive compatibility and performance testing in the lab before you take the server live.

Understanding IIS modes
The issue that figures most heavily in your ability to easily migrate your existing Web sites to IIS 6.0 is how the sites will function within IIS’s new architecture. IIS 6.0 supports two operating modes, IIS 5.0 Isolation Mode, and Worker Process Isolation Mode (also called IIS 6.0 Native Mode). In IIS 5.0 Isolation Mode, IIS uses the same process behavior and memory model used by IIS 5.0 for compatibility with older Web applications.

IIS 6.0 Worker Process Isolation Mode radically changes the way IIS functions. Where IIS 5.0 in Windows 2000 handles all request processing through a single service, IIS 6.0 splits it into two services. The Http.sys kernel mode driver listens for and processes HTTP requests, and the WWW Service Administration And Monitoring Component handles configuration, monitoring, and process management functions. Application pools comprising one or more Worker Processes run within the context of Http.sys, and each pool can service one or more Web applications. Isolating Worker Processes helps ensure that a single application can't crash another, and also isolates core IIS functions such as configuration and management from application code.

Splitting the services and isolating processes results in fewer crashes. These changes also create a Web server architecture that is more robust, provides better fault tolerance, and is much less susceptible to compromise than the previous versions. These architectural changes also enable IIS to clean up site and application crashes without rebooting.

If your sites do not use custom applications, it’s likely they will work with IIS 6.0 Native Mode without problems or changes. If you have developed custom applications, however, you should look closely at compatibility with Native Mode to determine whether you will need to run in IIS 5.0 Isolation Mode. There is no sure-fire way to determine application compatibility without actually deploying the application, so consider a lab deployment and extensive testing a necessity. However, there are several instances in which IIS 5.0 Isolation Mode is required. If your Web applications fall into any of the following categories, you will need to either update them or run them in IIS 5.0 Isolation Mode:
  • The application must run in the same process as Inetinfo.exe. W3wp.exe handles requests in Native Mode rather than Inetinfo.exe.
  • The application depends on Dllhost.exe to process Web requests. Dllhost.exe is not available in Native Mode.
  • The application uses an ISAPI raw data filter.
  • The application requires .NET Framework version 1.0.
  • The application requires ISAPI filters that expect an exclusive lock on a resource or run in multiple instances and expect to be recycled by the mechanisms in IIS 5.0.

If, after testing, you find that you do need to run your applications in IIS 5.0 Isolation Mode, you should do so only temporarily until you can rewrite or update the application to work with Native Mode. In any case, IIS 6.0 will run in only one mode on a target server, so you can’t run IIS 5.0 Isolation Mode and Worker Process Isolation Modes on the same server.

.NET Framework compatibility
Another issue to consider in addition to those I described above is the version of .NET Framework required by your Web applications. .NET Framework version 1.1 is included with Windows Server 2003. Most Web applications written prior to Windows Server 2003’s release use .NET Framework version 1.0. As I mentioned previously, version 1.0 is supported only in IIS 5.0 Isolation Mode. Version 1.1 is supported in both IIS 5.0 Isolation Mode and IIS 6.0 Worker Process Isolation Mode.

Whichever version of .NET Framework your applications require must be installed on the server. You can install multiple .NET Framework versions in a side-by-side configuration on the server to support those versions for your applications.

Using the IIS 6.0 Migration Tool
You have two primary options for migrating from IIS 4.0 to IIS 6.0—either perform a completely manual migration or use the IIS 6.0 Migration Tool to automate at least part of the process. You can use the Migration Tool to migrate sites from a source server to a target server. However, there are a few situations in which the Migration Tool won’t do the trick. For example, the Migration Tool will not migrate sites to a target server that is running IIS 5.0 Isolation Mode.

If the site’s applications use Setup programs, installation scripts, or provisioning scripts, the Migration Tool will not be able to initiate those applications and scripts. In addition, the Migration Tool migrates the site at the site level, which prevents the Migration Tool from selectively migrating specific virtual directories. In each of these situations, you will need to migrate the site manually. If you are migrating multiple FrontPage sites, you should also consider migrating the sites manually, publishing them from FrontPage to the new server to ensure that all of the necessary security settings are applied to the target sites.

If you decide that the Migration Tool will work for you, you’ll find it included with the Windows Server 2003 Deployment Kit companion CD and the Internet Information Services 6.0 Resource Kit companion CD. The tool doesn’t have a Setup file of its own. Instead, install the Deployment Kit or the Resource Kit, and then browse to the \Program Files\IIS Resources\IIS 6.0 Migration Tool folder. Create a folder on the target Web server (the one to which you are migrating your sites) and copy the contents of the IIS 6.0 Migration Tool folder to that target folder. These contents include the Migration Tool itself and a DOC file.

Before you fire up the Migration Tool to start the site migration, you need to ensure that the Migration Tool will have the necessary access to the source site and server. First, make sure that the source server’s local Administrators group can log on remotely to the source server. The Migration Tool must be able to access the server remotely as part of the source server’s local Administrators group. Also, make sure the administrative share on the source server where the site is located is available. For example, if the site is hosted in c:\inetpub\wwwroot, the administrative share C$ must exist. If you have disabled administrative shares, recreate the share.

Finally, if a firewall sits between the source and target servers, you will need to open the necessary DCOM ports in the firewall or establish a VPN tunnel between the two to allow the DCOM traffic between them.

The Migration Tool is a command-line utility that migrates sites one at a time. If the source server hosts multiple sites, you must run the tool once for each site you need to migrate. The Migration Tool backs up the metabase configuration on the target, migrates content from the source (or optionally just the metabase configuration), and copies ACLs from the source content to the target content. It also copies the source site’s IIS metabase configuration from the source to the target and maps IIS 4.0 application isolation settings to the IIS 6.0 application pool settings.

You can also direct the Migration Tool to change the Web root directory path used by the migrated site; have it re-extend FrontPage Server Extension sites; change the IP address, host header, or port for the target site; and change the site ID. Rather than explain the syntax or options for the Migration Tool here, I’ll just point you to the Migration Tool documentation located in the file iisTOOL_mig.doc, located in the same folder as the Migration Tool executable.

While the Migration Tool can handle some site migrations without additional follow-up tasks, in many cases the Migration Tool is simply one step in the migration. It’s likely that you will need to accomplish some additional tasks to complete the migration even if you use the Migration Tool. For example, your site might require some additional applications to be installed and registered, and registry entries added on the target server to support them.

If the site uses ODBC connections, you must migrate the databases (if they are not located within the site’s directory structure) and then create the necessary ODBC connections on the target server. Other things you might need to do include:
  • Copy other content that resides outside of the site’s root folder on the source server
  • Create accounts and groups
  • Fine-tune security on the target
  • Reconfigure FrontPage security settings on the target
  • Modify general site and virtual directory properties
  • Make other changes to the target server before it is ready to bring online

If the site uses SSL or certificate-based authentication, you’ll also need to install the certificates on the target server.

Before you run the Migration Tool, read through the IIS 6.0 Migration Tool User Guide to learn more about the types of post-migration tasks that will likely be required for your site. Also explore your source site’s configuration thoroughly before the migration to identify any items that will require manual migration and/or configuration. Accomplish these tasks after running the Migration Tool. and then perform extensive testing of the new target server and site before taking it live.

Performing a manual migration
While the Migration Tool can be an indispensable tool for migrating Web sites, there are many situations in which it won’t be the right solution for you. I identified many of these situations above. The type and structure of your site also has a bearing on whether the Migration Tool is the right migration mechanism. If you have a relatively simple site or one that does not rely on custom applications, a more direct route would be to simply publish your site to the new server.

Install IIS on the target server, create the site (using a temporary host header or IP address if needed), and create any required ODBC connections. Then publish the site to the target server from your development application (FrontPage, UltraDev, etc.). After you publish the site, perform any post-migration tasks required for the site.

Completing the migration
With the site in place on the new target server, there are three final steps you need to take: test, test again, and test some more. In addition to verifying the function of the site, also check security settings, permissions, and other site and virtual directory properties to make sure the site is secure.

The ease with which you can migrate a site from IIS 4.0 to IIS 6.0 depends entirely on the complexity of the site and the number and types of applications it uses. If your applications are not compatible with IIS 6.0 Native Mode, it’s extremely important that you rewrite them or obtain updates to make them compatible with Native Mode. Although you can run the server in IIS 5.0 Isolation Mode, you should do so only as a stopgap measure until you can make the switch to Native Mode. After you make the switch, you’ll enjoy better performance and much better reliability and recoverability.

Editor's Picks

Free Newsletters, In your Inbox