Using the IIS Migration Tool

The IIS Migration Tool is designed to migrate Web sites from one machine to another. It can handle pretty much all source sites, including IIS 4.0, 5.0, and surprisingly 6.0, which can be useful if you want to move a Web site from one machine to another.

The IIS Migration Tool works by running on the destination server?running IIS 6.0?and the source server?running another version of IIS. It's therefore a combination of a migrating and copying tool. You can't use the IIS Migration Tool for migrating content between different versions of IIS on the same machine (which isn't technically possible anyway because the migration tool needs both machines to be working).

The migration tool cannot be used to migrate scripts and filter out all the bugs and problems for migrating from one scripting platform to another. It will migrate the scripts, but it won't fix incompatibilities between the two.

That doesn't make the tool completely useless?for the majority of sites, it's going to do the core work of migrating settings and files. The IIS Migration tool does all the following:

• Backs up the metabase configuration on the target server.

• Migrates the Web site content. You can also copy between different source and destination directories.

• Copies file system access control lists.

  WEB RESOURCE

  For more information on IIS and Access Control Lists, go to the Delta Guide series Web site at www.deltaguideseries.com and enter article ID# A020702.

  
  

• Copies the IIS metabase configuration and migrates the settings between the two servers.

• Maps IIS 4.0 and IIS 5.0 application isolation settings to the new IIS 6.0 application pool settings. What it doesn't do is make your Web site applications IIS 6.0 compatible, nor does it automatically make them Worker Process Isolation mode compatible.

You can also optionally apply the following settings:

• Change the Web root directory path in source files.

• Apply FrontPage Extensions to sites that use FrontPage Server extended sites.

• Change the IP address, port number, and host header (virtual server) to new settings. This is useful if you want to migrate the site to a new server for testing.

Requirements

Before you start, you need to make sure that both your source machine (the one currently holding your site) and the target machine are up and running and configured for network operation.

You also need to ensure that

• IIS is installed and running on both machines. Remember that IIS 6 is not running by default under Windows Server 2003?you must have configured the Application Server Role to install IIS 6.

• The IIS Admin service is running on both machines. You can check this by checking the services. Services was a control panel in Windows NT 4.0 (see Figure 7.4), but is part of the MMC and the Administrative tools folder within Windows 2000 Server and Windows Server 2003. (Figure 7.5 shows the Windows 2000 Services snap-in.)

  Figure 7.4. Services in Windows NT 4.0.

  

  Figure 7.5. Services in Windows 2000.

  

• Administrative file sharing is enabled on the source server. You must have remote access to the administrative file shares for each disk that holds IIS site information, including C$ for the metabase and any additional drives that hold site data. You might need to install/enable the File Sharing component on Windows 2000 to enable this setting.

• You must have administrator privileges for both the source and the target machine.

Finally, remember to have enough space to copy over the source files for the Web site content. Considering the size of disk drives today, this shouldn't be a problem.

Migrated Items and Limitations

During the migration, the tool migrates all the source data, configuration, and security settings that it is capable of migrating, with a few caveats and exceptions:

• The metabase file is migrated to the new XML format. The source metabase information is backed up by the tool using the location %systemroot%\System32\Inetsrv\Metaback\IIS Migration Tool Backup.MD##, where ## is an incremental number.

• The following directories and virtual directories are not migrated from IIS 4 and IIS 5:

  • IISSamples

  • IISHelp

  • IISAdmin

  • _vti_bin

  • Printers

  • MSADC

  • IISADMPWD

• Existing directories and files are not overwritten automatically unless you've told the tool to do so. Otherwise, it will prompt to confirm each file/directory to be overwritten during the migration process.

• Data is migrated to the same directory as the source unless you tell it to do otherwise through a command-line option. You cannot migrate the site data to a UNC path unless the UNC path has been mapped to a drive letter?that is, you must write to z:\WWWroot rather than \\WWWFileserver\WWWroot.

• Files from UNC shares on the source will be migrated providing that the current target server can still reach the original UNC share.

• Files and directory security is preserved providing that the machine, domain, and other account identifies can be found within the current security scope.

• Local users are not re-created, and access control lists are not configured for local users after migration. You will need to reset these settings once the migration has completed.

• Server settings (IP address, port number, and host header) are preserved. (Source IPs configured to act on all IP addresses are similarly configured on the destination.) You can change these parameters using a command-line option.

• Application pool settings are migrated according to the following rules:

  • In process applications are placed into an application pool named SourceServerName_InProcess.

  • Pooled applications are placed into an application pool named SourceServerName_Pooled.

  • Isolated applications are placed into a unique application pool called SourceServerName_ApplicationName.

Using the Tool

The migration works through the C$ drive mapping system reading the source configuration, Web site source, and security settings directly from the source file system, re-creating the various settings, migrating the metadata file from its binary format to XML, and then copying over the source files onto the target system.

To use, ideally you need to run it from the command line, although you could start it from the Start->Run system if you want.

The basic syntax for the command is

iismt.exe Server Website [options]

where Server is the name (or IP address) of the source server you are copying from, and Website is the name or metabase key (W3SVC/1) of the Web site you want to copy.

This is mildly annoying if you have a lot of Web sites configured, but it also has advantages in that it means we can migrate individual sites to different servers. The site-by-site approach also means that we can migrate a site, test it, and move on to the next, rather than having one big migration and testing phase.

Table 7.2 lists the additional optional command-line parameters and their syntax that you can use.

For example, to run the migration tool to migrate the site MCSLP from the server ntiis, you would run the following on the destination server:

Iismt.exe ntiis MCSLP

To add credentials to the source server and force it to overwrite any existing Web site source files, you would use

Iismt.exe ntiis MCSLP /user Administrator /password Pass /overwrite

Post Migration

Despite everything that the tool does during the migration process, there will be a few things you will need to do to ensure that your sites are up and running properly again.

In particular,

• Copy additional components? Any DLLs, applications, or other components not located within the Web site source directory will not be copied over. Also, remember that additional software and applications, such as Perl and Python, will need to be manually installed on the target?these are not migrated automatically.

• Register additional components? Specialist DLLs will need to be registered using the regsrvr32.exe tool, and then will need to be included within the Web services extensions if necessary. Also remember to update the COM+/MTS packages if they are used and set any registry values or other settings required by the DLLs.

• Re-create ODBC settings? Use the ODBC Manager to re-create ODBC connections.

• Code conversions? Not all code will run verbatim on the new platform. You will need to test and make appropriate changes before activating the site.

• Local security accounts? These are not migrated, so you will have to re-create them by hand. Also remember to reapply the ACLs for these local users and groups on the target machine.

• FrontPage? The FrontPage administrator account is not created on the target server automatically. You will also need to reset and re-apply FrontPage security settings.

• Windows directory location? You must manually adjust the Windows directory location for components that need it, such as the ScriptMaps and HTTPErrors properties of the Metabase.

• Virtual directory locations? Only the root directory of a Web site is updated; any virtual directory locations that are different will have to be updated.

• Security Certificates? SSL certificates must be migrated and re-imported manually.

• Log files? Log files for individual sites are not migrated; you must do these by hand.

• MIME types? MIME types must be reset or updated by hand.

• IP Address? If you are using multiple IP addresses on a single network interface and are using these additional IP addresses to serve Web sites, you will need to manually add the IP address to the card.