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:\winnt\system32\inetsrv\iisadmpwd 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.