So you've finally decided to take the plunge and retire that old reliable Windows NT server. Here's how you migrate your IIS 4.0 Web site to IIS 6.0 under Windows Server 2003.
Although Windows NT and IIS 4.0 were great products in their day, they've become more than slightly outdated. If you're still hosting a Web site on IIS 4.0, you'll eventually be forced to upgrade to Windows Server 2003 and IIS 6.0. The need for an upgrade could be the result of Microsoft discontinuing support for Windows NT 4.0 and IIS 4.0; or it could be related to the unavailability of Windows NT hardware drivers for newer hardware; or to the fact that IIS 4.0 is really lacking when it comes to security.
Whatever the reason for migrating, moving a Web site from IIS 4.0 to IIS 6.0 is not a task to be taken lightly. There's a lot of room for things to go wrong throughout the migration process. In this article, I'll discuss some of the issues you'll face during the migration.
The IIS 6.0 Migration Tool
Microsoft has simplified the migration process by providing the IIS 6.0 Migration Tool. This tool is designed to help administrators migrate Web sites from IIS 4.0 or IIS 5.0 to IIS 6.0. You can download it from Microsoft's Web site. The download consists of a 378-KB MSI file.
Double-clicking the MSI file launches a standard Windows installation routine. When the installation process completes, the IIS 6.0 Migration Tool is installed into the C:\Program Files\IIS Resources\IIS 6.0 Migration Tool 1.1 folder. The actual migration tool is named iismt.exe. The syntax is as follows:
iismt <server> <website> [/user <username>
[/serverbindings <serverbindings string>][/siteid <<siteID> |
replace>] [/configonly] [/fpse] [/inherited][/verbose]
Switches for this command are:
- <server>ï¿?the name of your IIS 4.0 server.
- <website>ï¿?the name or metabase path of the Web site you're migrating.
- /user <username>ï¿?the username of the user you want to perform the operation.
- /password <password>ï¿?the password for the corresponding user account.
- /path <path>ï¿?the path to the Web root folder.
- /serverbindings <serverbindings>ï¿?the IP address and port number to be used by the server as a binding (IP:Port:Hostname).
- /siteid <<siteid> | replace>ï¿?the number of the Web site you are migrating. You may specify a numeric value to use as the site ID, or specify the keyword "replace" to use the existing siteID.
- /configonlyï¿?migrate IIS configuration only.
- /fpseï¿?re-extend FrontPage Server-extended Web sites.
- /verboseï¿?Verbose mode.
- /overwriteï¿?suppresses prompting to confirm that you want to overwrite an existing destination folder or file.
- /noninteractiveï¿?does not display messages that prompt the user for input. Program will exit on first error condition.
Some examples of how to use the IISMT command are as follows:
ï¿? iismt Server1
"My Web Site" /user Administrator /password pass /path
iismt Server1 w3svc/3 /path d:\MigratedWebs /fpse /serverbindings
The IIS 6.0 Migration Tool does a great job of migrating simple Web sites that are accessed only anonymously. If your Web site is more complex, you may still find the tool useful, but there will be a lot of manual work you'll have to do once the migration is complete.
When migrating a Web site, one of the first issues you need to consider is authentication. The migration tool makes two often-incorrect assumptions regarding any site that you're migrating. First, it assumes that visitors will be accessing the site anonymously. Second, it assumes that IIS will be using the IUSR_servername on behalf of anonymous users.
If you just have a basic Web site, these assumptions are probably okay. However, if your site requires users to authenticate using anything other than an authentication mechanism thatï¿?s built into your Web application, then youï¿?ve got some work ahead of you.
For example, if your site previously used basic authentication, you had to go into the Internet Services Manager once the migration had completed and enable basic authentication (and possibly disable anonymous access). In IIS 4.0, basic authentication compares a set of user login credentials to the credentials stored in the Windows NT Security Accounts Manager. In most cases, if you're migrating to IIS 6.0, you've probably also made the leap to Active Directory. You must verify that any user who needs access to the site has a valid user account within Active Directory.
While youï¿?re at it, itï¿?s important to review the NTFS permissions that apply to the site you're migrating on your IIS 4.0 server. It was once common practice to grant NTFS permissions to the IUSR_servername account. However, the IUSR_servername account that these permissions pertain to is often a local account rather than a domain account. Since the migration tool canï¿?t migrate a local account, it's possible that the migrated site is configured with insufficient permissions. Now it's up to you to go in and assign the appropriate NTFS permissions to an account thatï¿?s accessible from your IIS 6.0 server.
IIS 6.0 can run in two modes: Worker Process Isolation mode and IIS 5.0 Isolation mode. In Worker Process Isolation mode, all Web applications run in an isolated environment. This mode also uses the Network Service account rather than the Local System account because it has fewer permissions and is more secure.
Most Web sites should have no problem running in Worker Process Isolation mode. If a site won't run in this mode, you can switch to IIS 5.0 Isolation mode instead. This is a backward-compatibility mode that should be able to run any legacy Web site. Keep in mind that the IIS 5.0 Isolation mode is set at the server level, not at the Web-site level. Therefore, if your server is hosting multiple sites, and one site requires IIS 5.0 Isolation mode, then all of the sites on the server will have to run in IIS 5.0 Isolation mode.
If you need to revert to IIS 5.0 Isolation mode, you can do so by opening the Internet Services Manager, right-clicking on the Web Sites container, and selecting the Properties command from the resulting shortcut menu. On the Web Site Properties sheet, select the Service tab and then select the Run WWW Service In IIS 5.0 Isolation Mode check box. Click OK to complete the operation.
If your IIS 4.0 server uses an SSL certificate, the certificate won't be migrated automatically. You'll have to manually export the certificate, save it on a disk, and then import the certificate into the IIS 6.0 server once the site has been migrated.
In IIS, importing a certificate alone won't provide SSL encryption. You must also configure IIS to use port number 443 when SSL encryption is requested. To enable SSL encryption on the IIS 6.0 server, open the Internet Services Manager and navigate to your server | Web Sites | your Web site. Right-click on your Web site and select the Properties command from the resulting shortcut menu to reveal the server's properties sheet. Now, select the Directory Security tab and click the Server Certificate button. This will launch the Web Server Certificate Wizard. Click Next to bypass the wizard's welcome screen.
On the next screen that appears, choose the option to import a certificate from a .pfx file. Click Next and follow the prompts regarding the certificate's location.
As you import the certificate, note that it usually references the server's friendly name. If you've assigned the Web site a different friendly name on the IIS 6.0 server than it had on the IIS 4.0 server, the certificate may appear invalid.
The last step of the process is to assign the Web site a port to use for SSL communications. Select the Web Site tab on the Web site's properties sheet, enter 443 into the SSL Port field, and click OK.
Another manual adjustment that you'll likely have to make after the migration is to update the IIS metabase. This is important because the migration tool will migrate metabase properties referencing the %SYSTEMROOT% folder on the source server. However, it does not alter these metabase properties so that they point to %SYSTEMROOT% on the target server.
If, after migration is complete, the target server's metabase specifies the wrong location for %SYSTEMROOT%, the Web site might be inaccessible. Furthermore, there's a good chance you'll have a %SYSTEMROOT% mismatch because in Windows NT 4.0, %SYSTEMROOT% was mapped to C:\WINNT by default. In Windows Server 2003, on the other hand, the default mapping for %SYSTEMROOT% is to C:\WINDOWS.
To update the metabase on your IIS 6.0 server after migration, begin by verifying the actual name of the folder that Windows is installed into (usually C:\Windows). Next, open the Internet Services Manager on your Windows 2003 server, right-click the server name, and select the Properties command from the resulting shortcut menu. When the server's properties sheet appears, select the Enable Direct Metabase Edit check box and click OK.
Use Notepad to open the MetaBase.XML file. The default location for this file is %SYSTEMROOT%\system32\inetsrv\metabase.xml. Search the file for any references to %SYSTEMROOT% on your old IIS 4.0 server, and then replace those references with the %SYSTEMROOT% location that's valid for the IIS 6.0 server. For example, if your IIS 4.0 server used C:\WINNT as the %SYSTEMROOT% path, and your new server uses C:\Windows as its %SYSTEMROOT% path, you'd simply replace all occurrences of C:\WINNT with C:\Windows.
Once you've made the necessary edits, save your changes to the metabase file, go back into the Internet Services Manager, deselect the Enable Direct Metabase Edit check box, and click OK.
Dynamic site content
The migration tool assumes that the sites being migrated serve only static HTML pages. The migration tool will migrate other types of code such as ASP files and HTML code that references FrontPage extensions, but there's no guarantee that the code will function properly in the default IIS 6.0 environment.
IIS 6.0 fully supports ASP code and FrontPage server extensions, bur depending on how you installed IIS, those features may be disabled by default. A fundamental rule of computing states that the more code running on a machine, the greater chance a security vulnerability exists. In an effort to reduce the amount of code running on a server (and make the server more secure), Microsoft has disabled all of the Web service extensions by default, except in a few special cases.
To enable the Web service extensions that will allow you to run ASP code and reference FrontPage extensions and server-side includes, open the Internet Services Manager and navigate to your server | Web Service Extensions. The pane to the right will display a list of Web service extensions that you can choose to allow (enable) or prohibit (disable).
Enabling Web service extensions isn't the only consideration you need to take into account if your Web site uses dynamic content. You may find yourself having to modify your site's ASP source code to rid it of relative parent paths used in conjunction with server-side includes.
I'm always a little hesitant to get into a discussion of coding in an article that's primarily intended for administrators, but in this case, it's necessary. In ASP, an include statement tells IIS to link in code that is found within another file. The file being referenced can exist in a folder separate from the file that's currently being executed. In previous versions of IIS, a server-side include looked something like this:
The two dots in front of the slash indicate that the file being called exists at one level higher than the current file within the folder tree. However, this type of coding presents a security risk and isn't allowed by default in IIS 6.0. As an alternative, you should replace include file commands with include virtual commands. An include virtual command is very similar to an include file command, except that it references an absolute path rather than a relative path. An include virtual command might look something like this:
Another issue you need to consider in relation to Web services is that when a Web site is FrontPage-extended, users have sometimes been assigned various FrontPage roles. The migration tool will migrate FrontPage roles under two conditions: First, the roles cannot be assigned to local user accounts; they must be assigned to domain user accounts. Second, you must use the /FPSE switch in the IIS 6.0 Migration Tool.
If your FrontPage-extended Web site references local user accounts, you aren't completely out of luck. You'll simply have to create the accounts on the new server and then assign the new accounts the appropriate roles.
Oddly enough, in IIS 6.0, FrontPage server roles are managed through SharePoint. To assign a FrontPage role to a user account, select the Microsoft SharePoint Administration command from the server's Administrator Tools menu. When the Server Administration page opens, select the Web site you want to assign roles to. On the Web site's Site Administration page, click the Manage Users button. Select the users you need to establish roles for and click the Edit Role Membership button. Assign the appropriate roles and click Submit.
Start the migration
Although the migration tool helps you make the move from IIS 4.0 to IIS 6.0, you may have to manually do some cleanup work after a migration. After following the instructions in this article, you should be very close to having a functioning Web site. Keep in mind that traffic won't be diverted to the new site until you modify the DNS entries pertaining to the site's URL so that they reflect the new server's IP address. Of course, you should test the new server prior to diverting Web traffic to it. To test it, open a copy of Internet Explorer and enter http:// followed by the new server's IP address.