Migrating from IIS 4.0 to IIS 5.0

Believe it or not, you can make a smooth transition

I can barely keep track of all the Web server versions that Microsoft has paraded past us through the years. And each new iteration seems to require a move to a new OS. Is it any wonder that so many Microsoft Internet Information Server (IIS) 4.0 shops want to stay put? But no matter how much you want to hold on to IIS 4.0 (despite its quirks), I know of at least four reasons why you should move on to Internet Information Services (IIS) 5.0.

First, IIS 5.0 is no longer uncharted territory. The version has proved itself in high-volume situations at corporations such as Microsoft, Dell, Compaq, Nasdaq, and Ford Motor. Second, IIS 5.0 is more secure and stable (especially after you also install IIS 5.0 Service Pack 2—SP2), faster, and more feature-rich than IIS 4.0. Third, IIS 5.0 runs only on Windows 2000, so when you migrate, you also get the benefits of that OS's improved security and stability. Fourth—and most compelling—Microsoft isn't going to hold the boat for you: The company is moving ahead with IIS 6.0. Of course, you could maintain your IIS 4.0 installation until the IIS 6.0 service packs start appearing, but if you wait that long to migrate, the technology you'll need to leapfrog will likely complicate the job. (For a preview of some of IIS 6.0's enhancements, see the sidebar "IIS 6.0: The Next Generation," page 32.) Better to migrate now to IIS 5.0 and simplify the impending move to IIS 6.0.

Netcraft surveys have revealed that although thousands of organizations still use IIS 4.0, the number of active Web sites that use IIS 5.0 on Win2K has taken a leap. If your shop has yet to launch a migration, now seems to be the time to do so. You probably have several questions about the move from IIS 4.0 to IIS 5.0; the sidebar "IIS Upgrade FAQ," page 35, has answers to some of the most common questions.

When you finally decide to make the switch, you'll need to decide on an IIS migration strategy (i.e., in-place upgrade or migration upgrade). Also consider the pros and cons of various methods of migrating from a Windows NT machine running IIS 4.0 to a Win2K machine running IIS 5.0. Think through all aspects of the migration, including the transition of users and groups, Web content (i.e., HTML files, Active Server Pages—ASP—and graphics files that the Web server delivers), Web server structure, IIS databases, certificates, and Web applications. Being aware of common misconceptions and potential problems can help keep your migration from going astray.

In-Place Upgrade or Migration Upgrade?
IIS is inextricably tied to the OS, so switching to IIS 5.0 (or IIS 6.0, when it arrives) requires moving to an entirely new OS—no small matter. Two methodologies exist: an in-place upgrade (aka a direct upgrade) or a migration upgrade. To perform an in-place upgrade, you simply load Win2K on your existing NT 4.0 server and follow the installation steps for upgrading your existing OS. To perform a migration upgrade, you install Win2K on a separate server with a newly formatted hard disk, then migrate your NT 4.0 server's contents and IIS configuration to the new server.

In-place upgrade. Directly upgrading NT 4.0 and IIS 4.0 to Win2K and IIS 5.0 is convenient. Because you don't change machines, you don't need to worry about migrating local users and groups, NTFS permissions, ODBC connections, certificates, Web server structure, Web applications, or Web-based permissions (which you set through the Microsoft Management Console—MMC—Internet Information Services console). But convenience comes at a price. If your IIS 4.0 server has been around for a while, an in-place upgrade carries forward years of accumulated history: registry bloat, outdated user profiles, obsolete security patches, botched software installations, and so forth. This digital debris can—and does—complicate an otherwise quick and easy upgrade.

In-place upgrades can also carry over security flaws that you never even knew existed on your NT 4.0 system. This type of migration preserves users, groups, and associated NTFS permissions; consequently, if you don't examine these things first, weak passwords, outdated accounts, and inappropriate permissions can all carry forward. Worse yet, you might unknowingly negate security improvements that Microsoft has implemented in IIS 5.0. For example, a direct upgrade retains the Absent Directory Browser Argument vulnerability. Another potential security risk involves the IISADMPWD virtual directory, which IIS 4.0 installs by default and which points to .htr files in the C:winntsystem32inetsrviisadmpwd directory. Malicious users can use these infamous files to change user-account passwords and cause other mischief. (For information about these vulnerabilities, see "Microsoft Articles About IIS 4.0 Vulnerabilities," page 35.) Clean installations of IIS 5.0 don't install the IISADMPWD virtual directory during setup, which reduces the risk of someone misusing the .htr files. (For details, see the Microsoft article "IISADMPWD Virtual Directory Is Not Created During Clean Install of IIS 5.0" at http://support.microsoft.com/support/kb/articles/q269/0/82.asp.) However, an in-place upgrade carries forward the already-installed directory.

Despite these disadvantages, you might decide that the convenience of an in-place upgrade is more important than starting fresh on a new OS. For example, relatively simple IIS installations that don't involve complex configurations are good candidates for an in-place upgrade. Microsoft has extensively tested in-place upgrades from IIS 4.0 to IIS 5.0, so these moves often proceed without a hitch. If you do run into problems, however, troubleshooting can be more difficult than during a migration upgrade.

If you choose to perform an in-place upgrade, I advise you first to confirm that you have at least two good image backups of your existing system. Better yet, make two backups by using your primary backup method (e.g., drive imaging) and a third backup by using a different method (e.g., tape backup). That way, if the imaging process's mechanics are faulty, you still have a backup.

Migration upgrade. Upgrading to a clean Win2K and IIS 5.0 installation is the preferred migration method and results in the most stable and secure IIS 5.0 Web server possible. This type of migration involves more planning and migration of individual components such as user and group accounts, NTFS passwords, Web server structure (e.g., virtual Web sites, virtual directories), databases, certificates, and Web applications. In the planning process, however, you're likely to discover ways you can improve your Web server's security, administration, and performance. For each component that you must migrate, I offer recommendations and caveats that can smooth out your upgrade and help you create a stable and secure IIS 5.0 installation.

Before you begin moving these individual components, however, I suggest that you remove any existing Microsoft FrontPage Server Extensions from your Web sites and your NT Web server, especially if you're also migrating from FrontPage 98 to FrontPage 2000 or later. (These extensions can be touchy.) By default, Win2K installs the FrontPage Server Extensions 2000, so after you've completed your migration to IIS 5.0, you can reinstall the extensions on your Web sites. Following this procedure ensures that FrontPage 2000 or earlier clients can access your FrontPage-enabled Web sites after you migrate. Regardless of your migration method, be sure to update FrontPage Server Extensions with the most recent service release, which you can download at http://msdn.microsoft.com/workshop/c-frame.htm#/workshop/languages/fp/default.asp.

Migrating Accounts and Permissions
Microsoft recommends that you operate IIS on a standalone server. For a variety of reasons, however, not everyone follows this guideline. When you're ready to move your original Web server's user and group accounts, content, and NTFS permissions, you face one of several possible scenarios: standalone NT server to standalone Win2K server, NT domain controller (DC) to standalone Win2K server, NT DC to Win2K DC, or standalone NT server to Win2K DC.

Standalone NT server to standalone Win2K server. The traditional method of migrating from one standalone server to another involves using various tools to separately migrate the accounts and content (with NTFS permissions). First, you use a tool such as Addusers, which you can find in the Microsoft Windows 2000 Server Resource Kit, to export the user database to a text file. You then import the text file to your new system, thus creating an identical set of user and group names on the Win2K server. However, Addusers doesn't migrate passwords, so you must add a password for each user account, then require users to change that password at their next logon—quite an administrative chore. Furthermore, the new accounts, although identical in name to the original accounts, have new SIDs—which causes serious security complications after you migrate the Web server's content and related NTFS permissions.

The resource kit's Robocopy tool can copy your Web server's content and related NTFS permissions across the network. Although Robocopy can fail when copying large files, it does a great job overall and faithfully copies the original SIDs that the NTFS permissions use to reference user and group accounts. But because Addusers has given those accounts new SIDs, the NTFS permissions are ineffective on the new server. (Figure 1, page 36, illustrates this problem.) Similar tools, such as Adsonline's IIS Export Utility, also run into this problem.

One tool that overcomes the conflicting-SIDs problem is Small Wonders Software's Secure Copy. This product copies content between two standalone servers and reproduces local user and group accounts on the target server in a way that keeps NTFS permissions intact. (To read a review of this product, see Joshua Orrison, "Server Consolidation Software," http://www.win2000mag.com, InstantDoc ID 20652.)

NT DC to standalone Win2K server. You might see your migration as an opportunity to transfer your IIS implementation from a DC to a standalone server. Moving NT domain accounts to a standalone Win2K server entails essentially the same procedure as migrating from an NT member server to a standalone Win2K server and gives you the same choice of tools (i.e., Addusers or Secure Copy). However, Secure Copy can't migrate global groups to a member server as local groups.

Be forewarned: You're in for a surprise if you think you can migrate your NT 4.0 domain accounts to a Win2K DC, then run DCPROMO to remove Active Directory (AD) and thus make the transferred accounts into local accounts. AD user accounts don't convert to local user accounts when you demote a Win2K DC to a standalone server.

NT DC to Win2K DC. I advise you against configuring your new Web server as a Win2K DC strictly so that you can use AD for migration purposes. However, if you already plan to use IIS on a Win2K DC, you can take advantage of AD replication to move user and group accounts, thereby keeping intact the NTFS permissions for migrated content.

To take this approach, join your Win2K DC to the NT DC's domain. The NT users and groups will replicate automatically.

Another option is to use an AD migration tool from a vendor such as NetIQ, FastLane Technologies, BindView, or Aelita Software. These tools are designed to integrate an NT 4.0 domain structure into an AD-based network. Microsoft's Active Directory Migration Tool (ADMT) also offers basic capabilities for migrating NT 4.0 users and groups to a Win2K DC. However, ADMT doesn't migrate passwords. For more information about this tool, see the Microsoft articles "How to Set Up ADMT for Windows NT 4.0 to Windows 2000 Migration" (http://support.microsoft.com/support/kb/articles/q260/8/71.asp) and "Active Directory Migration Tool Overview" (http://www.microsoft.com/windows2000/techinfo/planning/activedirectory/admt.asp).

Standalone NT server to Win2K DC. What if your original Web server operates outside a domain, but you want to migrate to a Win2K DC? To take advantage of all those cool AD migration tools or AD replication, your source server needs to be a DC (or your accounts need to be domain based). If only you could somehow turn that NT 4.0 standalone server into a DC.

Every MCSE knows that Microsoft doesn't support such a promotion—but that doesn't mean it can't be done. You can use Algin Technology's UPromote to convert your NT 4.0 server to a DC in a single-machine domain, then use a replication strategy or AD migration tool. The downside, of course, is that if you have problems that result from this type of approach, you can't expect Microsoft to help you solve them.

Migrating Web Server Structure
After you migrate users and groups, permissions, and Web content, you need to migrate the IIS configuration information, which resides in the IIS metabase. (The metabase.bin file is in the C:winntsystem32inetsrv directory.) This metabase contains IIS configuration information for virtual SMTP, Network News Transfer Protocol (NNTP), and FTP servers; virtual Web servers; virtual directories; and other properties you set in the Internet Information Services console. The metabase is machine-specific, so you can't simply copy metabase.bin from one server to another. You can set up IIS manually or use Active Directory Service Interfaces (ADSI) to script a metabase migration, or you can enlist one of three tools—Metabase Editor (MetaEdit), IIS Export Utility, or IIS Migration Wizard—to help migrate your Web server's structure.

MetaEdit. You can use MetaEdit's import and export capabilities to export IIS configuration information to a text file. You can then move the export file to your target server and import the Web server configuration. MetaEdit, which Microsoft includes in the resource kit, is easy to use and works well—except for one problem: a bug that causes MetaEdit 2.0 and earlier to write hexadecimal values incorrectly.

You can download MetaEdit 2.2, which fixes the bug, from the Microsoft article "FILE: How to Download, Install, and Uninstall the IIS MetaEdit 2.2 Utility" (http://support.microsoft.com/support/kb/articles/q232/0/68.asp). This tool doesn't export machine-specific details such as the Anonymous access (i.e., IUSR) account name and password, so you can import your Web server structure safely, without fear of importing source server—specific information to the target server.

IIS Export Utility. IIS Export Utility is a useful shareware tool that you can find at http://www.adsonline.co.uk/iisexport. As I mentioned earlier, you can use this tool to copy content, including NTFS permissions, from one server to another. The product also has specific settings for migrating the metabase from IIS 4.0 to IIS 5.0.

IIS Migration Wizard. This resource kit application is Microsoft's most ambitious IIS-migration product to date. IIS Migration Wizard moves the IIS metabase configuration settings from an IIS 4.0 machine to an IIS 5.0 machine (or from one IIS 5.0 machine to another). The tool also migrates applications, content, permissions, and MIME types. My IIS Answers Web site (http://www.IISAnswers.com) features the article "Upgrading to IIS 5," which includes an IIS Migration Wizard demonstration.

IIS Migration Wizard holds promise. However, the tool also presents three problems: It won't transfer more than 4GB of information in one migration; because it's a bit buggy, some sites simply can't use it; and it takes liberties in naming virtual directories and Web sites and in relocating files. Also, Microsoft doesn't support this wizard. The rumor is that Microsoft is working on an updated version.

Migrating the Database
An advantage of keeping your Web applications' databases on one server and IIS on another is that you won't need to migrate the databases when you upgrade IIS. However, if your databases are file based (e.g., if you use Microsoft Access databases) and are part of your IIS Web tree's directory structure, you can move them when you move your Web content.

If you use Microsoft SQL Server databases that reside on the same server as IIS, you might be able to move the databases to your Win2K server and test the new database setup before you move your IIS configuration. That way, you can separate the database migration from the Web server migration—an approach that lets you more easily troubleshoot migration problems. You'll probably need to create Data Source Name (DSN) connections on the Win2K server for your migrated databases.

Migrating Certificates
To move a certificate from IIS 4.0 to IIS 5.0, open IIS 4.0's Key Manager, select the key you want to export (be sure the certificate was successfully installed), and select Export Key from the menu bar. This action saves your certificate and its key as a .key file to a location you specify.

On your Win2K Web server, open the Internet Information Services console. Expand the Web server object and right-click a Web site object. Select Properties from the context menu, then go to the Directory Security tab. Within the Secure communications section, click Server Certificate to start the Web Server Certificate Wizard (one of IIS 5.0's best additions). When prompted, select Import Key Manager backup file and enter the path to the .key file you exported from IIS 4.0. The wizard then binds the certificate to your Web site's IP address. (You can also install and manage certificates through the MMC Certificates snap-in, but the wizard is easier to manage.) This move is a one-way trip: After you install your certificates on IIS 5.0, you can't export them back to IIS 4.0.

Ideally, moving certificates is simple. However, you might encounter a few complications. For Web sites with multiple IP addresses, IIS 4.0 lets you bind a certificate to each address, but IIS 5.0 doesn't. Also, after you move your certificates to IIS 5.0, you might find that Secure Sockets Layer (SSL) won't work. If that should happen, refer to the Microsoft article "Cannot Make an SSL Connection After Exporting and Importing an SSL Certificate" (http://support.microsoft.com/support/kb/articles/q261/6/55.asp). Win2K SP2 provides a fix for the SSL problem.

When the time comes to renew your migrated certificates, I suggest you read VeriSign's Known Browser and Application Issues Web page (http://www.verisign.com/support/vendors/issues.html). Another helpful resource for answering your questions about IIS 5.0 and certificates is Thawte Consulting's IIS 5.0 FAQ Web page (http://www.thawte.com/support/server/msiis5.html).

Migrating Web Applications
If your IIS 4.0 Web server delivers dynamic content, you need to migrate your Web applications' scripts, Internet Server API (ISAPI) filters, ISAPI extensions, and COM objects. Although these items might already have moved as part of your migration of Web content or the IIS metabase, you might need to move certain other programs (e.g., script engines that reside outside the basic Web tree) separately.

In any event, a successful migration doesn't necessarily mean that your application will behave as it did in an IIS 4.0 environment. I can't overstate the importance of testing your migrated applications. Stress testing is essential for determining how your application will perform in its new environment. In most situations, your applications will run faster and more reliably on IIS 5.0. However, application weaknesses or development errors that went unnoticed in IIS 4.0 can come to light in IIS 5.0's less forgiving environment.

You should also be aware of changes to IIS 5.0 that might affect your applications. For example, in IIS 5.0, ASP 3.0 doesn't permit the use of include files between In some circumstances, the differences between IIS 4.0's Microsoft Transaction Services (MTS) and IIS 5.0's COM+ can result in lackluster performance after you migrate to IIS 5.0. An application's performance might decline if the application uses the single-threaded apartment (STA) model to create the COM objects that perform complex calculations or database sorts. To remedy the problem, Microsoft released an upgrade that lets COM+ behave as if it were IIS 4.0's MTS. COM+ SP3 will include this upgrade, which is currently available by request if you need it before the service pack is available. (To request the upgrade, call Microsoft Product Support Services—PSS—and ask for Com+ Rollup 10.)To keep Visual Basic (VB) components on their best behavior in a COM+ environment, enable Retained in Memory and Unattended Execution on your VB projects' Properties sheets before compilation. For additional tips about avoiding problems related to COM+, see Ken Spencer's MSDN Magazine article "Migrating from MTS to COM+" (July 2000) at http://msdn.microsoft.com/library/default.asp?url=/library/periodic/period00/serving0700.htm.Prevent Potential Problems
After you successfully migrate your users, content, metabase, permissions, certificates, and custom applications, what problems could occur? If you use third-party software on your IIS server, you need to check with the vendor for upgrades and for information about how the application works with IIS 5.0. For example, you can't use IIS 5.0's HTTP compression features with Allaire's ColdFusion. Also, installing Crystal Decisions' popular Crystal Reports 8 can cause problems accessing both IIS 4.0 and IIS 5.0 databases. (For more information about this problem, see the Microsoft article "0x80004005 ASP Error Message Occurs When You Connect to a Database After Crystal Reports 8 Installation" at http://support.microsoft.com/support/kb/articles/q272/6/93.asp.)My final tip is to back up the metabase after you finish your IIS migration. You can simply copy metabase.bin, or you can use MetaEdit, the Internet Information Services snap-in, or the metaback.vbs script (which you can find in the inetpubiissamplessdkadmin directory) to make this backup. Unlike the Windows Me or Windows 9x registry, which creates a system.da0 registry backup when you first install the OS, IIS 5.0 makes no such backup of its metabase. If your metabase becomes damaged and you don't have a backup, you can do little to recover your hard work.Have No Fear
Moving from IIS 4.0 on an NT server to IIS 5.0 on a Win2K server is a task thousands of administrators are facing. (For more information about this process, see "Microsoft Articles About IIS 5.0 and Domain Migration.") Although in-place upgrades are easy and generally reliable, migrating to a newly installed Win2K and IIS 5.0 configuration is the recommended route. With a little planning and research, you can make a smooth transition to a more secure, better-performing platform.MICROSOFT ARTICLES ABOUT IIS 5.0 AND DOMAIN MIGRATION"Contents of Internet Information Server 5.0 Release Notes"
http://support.microsoft.com/support/kb/
articles/q250/9/79.asp
q267/5/60.asp

"How to Migrate Objects from One Domain to Another Domain" http://support.microsoft.com/support/kb/articles/
q266/0/83.asp

"Migrating a Web Server to IIS 5.0: Basic Steps"
http://www.microsoft.com/technet/prodtechnol/iis/
deploy/rollout/steps.asp

"Resources for Installing and Using IIS 5.0"
http://support.microsoft.com/support/kb/articles/
q266/1/15.asp

"Step-by-Step Guide to End User Certificate
Management"
http://www.microsoft.com/technet/win2000/
enducert.asp

"Understanding the Migration Process"
http://www.microsoft.com/technet/prodtechnol/iis/
plan/process.asp