The Internet Information Services (IIS) 6.0 Migration Tool (IISMT) is a free command-line utility from Microsoft that allows you to automate the migration of one or more Web sites or Web applications from IIS 4.0/5.0/6.0 to an IIS 6.0 computer running on Windows Server 2003. In this article we will focus on the limitations of IISMT so you can determine if the tool is going to be an appropriate solution for your particular environment. For information on how the tool works and the command-line syntax, check out the documentation that comes with the tool.

Downloading Migration Tool
IISMT is included in the IIS 6.0 Resource Kit. You can download the IIS 6.0 Resource Kit Tools from Microsoft at no charge. You can also download just the IIS 6.0 Migration Tool if you don’t need all the other utilities in the Resource Kit. I recommend that you download the Migration Tool directly even if you are going to download the Resource Kit because the Resource Kit contains the older version 1.0 of the Migration Tool. The new IIS 6.0 Migration Tool version 1.1 includes several enhancements to the tool and fixes the bugs in the older version.

NOTE: IISMT requires IIS 6.0 running in a worker process mode on a Windows Server 2003.

Post Migration Tasks
Microsoft warns us that IISMT is not an end-to-end migration solution. In other words, you can use it to migrate Web applications but not Web application-related components, such as database tables, stored procedures, or software. In addition, IISMT is not meant to be used to migrate standard applications, such as Microsoft Office applications or third-party software that’s not Web-based.
IISMT is helpful in automating many of the processes related to migrating Web sites but it leaves several additional steps for you to perform manually. Here's a list of major post-migration tasks that are required after you migrate your Web sites to IIS 6.0. Needless to say not all of these post-migration tasks will necessarily apply to your environment. Depending on your applications, Web sites, and the content, you may need to perform a limited number of these tasks. The post migration tasks can be broken down into four categories.

    • FrontPage Server Extensions
    • IIS configuration
    • Web Applications
    • Web Site Content

Let’s look at each one of these categories and the associated tasks in more detail.

Tasks Related to FrontPage Server Extensions
1. The FrontPage Server Extensions administrator account is not migrated by the IISMT tool so you'll have to migrate it manually. If you were using a local account, you'll need to recreate that account on the target server.

2. If there were any custom FrontPage Server Extensions security settings configured for a Web site, they may not be transferred properly so you may have to configure those settings manually on the target server.

Tasks Related to IIS Configuration
3. You may have to reset the username and password for the application identity on the target server For example, if the properties for WAMUserName and WAMUserPass were configured to use a local account and password for a Web site or virtual directory on the source server, you need to make sure that when you migrate that site or virtual directory that you specify a user (and password) that exists on the target server. If not, you can always create a new user and configure the properties using its name and password.

4. Similar to the step above, you may have to reset the anonymous user name and password for local accounts because the IISMT doesn’t create anonymous user accounts on the target server if they don’t already exist. For example, if the properties for AnonymousUserName and AnonymousUserPass were configured to use a local account and password for a Web site or virtual directory on the source server, you need to make sure that when you migrate that site or virtual directory that you specify a user (and password) that exists on the target server. If not, you can always create a new user and configure the properties using its name and password.

5. Any IIS 5.0 settings that are stored in the registry are not migrated by IISMT, only the settings stored in the metabase are migrated. Therefore, you must migrate IIS 5.0 registry settings manually.

6. MIME-type properties are not migrated by IISMT so they must be reset on the target server manually.

7. The digital certificates on the source server are not migrated automatically so you must ensure that you manually migrate or reinstall the digital certificates. Due to the importance of security, you should take extra care when migrating the digital certificates and make sure that they are properly transferred and tested before you deploy the Web sites.
 

8. ISAPI extensions or filters that do not reside within the migrated content must be installed manually.
 

9. If the Windows directory on the target server was installed in a different folder than the source server, you must manually change the properties in the metabase that refer to the old folder. For example, if Windows was installed in a folder called \WINNT on the source server but \Windows on the target server, you need to manually update all the references to \WINNT and replace it with \WINDOWS in the metabase. Basically you need to make sure that properties, such as HTTPErrors and ScriptMaps, are pointing to the correct location.
 

10. The Migration Tool doesn't allow you to change the paths of virtual directories under the site root virtual directory; it only allows you to change the site root directory itself. In situations where you have virtual directories on the source server that were pointing to locations on a different drive, you’ll need to manually copy all the content to the target server and then reset the path on the target server so they are pointing to the correct location. Also, there’s another situation that needs special attention. In order to avoid IISMT overriding contents of multiple virtual directories with the same path, you should ensure that the destination path already exists on the target server. For example, if there’s no E: drive on the target server and the source server was pointing to E:\VirtualDir then either you need to create an E: drive or point the virtual directory to a different location and update the metabase.
 

11. If you migrate an ASP Web site (ASP is not enabled by default in IIS 6.0), or migrate an application that requires a custom ISAPI extension then you must enable (or add) those Web service extensions manually in IIS 6.0.
 

12. The IIS log files are not migrated by IISMT so they must be copied manually from the source server to the target server.

Tasks Related to Web Applications
13. After the migration you must manually register any DLLs that need to be registered using regsvr32.exe.
 

14. When migrating from IIS 5.0 to IIS 6.0 you'll need to manually recreate any ASP.NET process model settings, such as recycling, health detection or Web garden configuration information.

15. If the code needs to be changed or recompiled to run on Windows Server 2003, you need to make the changes manually.

16. You must manually copy the files that do not reside inside the Web site root directory, from the source server to the destination server. Otherwise, your Web site may appear broken.

17. All ODBC connections required by applications must be created manually on the target server.
 

18. All application-specific registry settings need to be created manually. This could be quite a chore but the migration tool can’t handle this.

19. Any third-party dependent software, such as Perl, must be installed manually.

Tasks Related to Web Site Content
20. If the source server was configured for file permissions using local users or groups, you must recreate those users or groups and configure matching Access Control Lists on the target server.

21. Any content on the source server (such as ASP code that uses Server-Side Include files) that may be used by application but is located outside the Web root or virtual directories must be migrated manually.
Conclusion

Conclusion
IIS 6.0 Migration Tool can be a useful utility that can save you hours of work by automating certain tasks when migrating from IIS 4.0/5.0/6.0 to a clean installation of IIS 6.0 on Windows Server 2003. Although the tool can transfer Web site content, Web application settings, and configuration data to an IIS 6.0 server, as you can see there are up to 21 different tasks that the tool is not able to perform. The administrators must perform these steps manually.

In this article we’ve looked at various post-migration tasks that you may have to manually perform. Since every environment is different, you should take a closer look at all these tasks before you decide to use this tool. If the tasks can be easily handled then this tool will be helpful, otherwise you could end up spending too much time resolving the issues and even risk your security. Some of the manual tasks may seem to be rather daunting, such as manually migrating all IIS 5.0 registry settings, modifying the code, creating application-specific registry entries, creating ODBC connections, and registering the DLLs. A lot will depend on the type of applications and the number of servers that you are running. You could always automate some of these 21 tasks, such as writing scripts to import the information into the registry, or manually copying content. IISMT may not be a viable solution for every environment but after reading this article you should be able to make an informed decision as to the capacity in which this tool can be beneficial to you.

As mentioned earlier, the newer IISMT version 1.1 fixes several bugs in the older version so if you decide to use this tool make sure you are using the newer version. However, even the newer version has several limitations. For a list of limitations in both versions of IISMT, check out the article Limitations of IIS 6.0 Migration Tool. You definitely want to check this list out if you have any inclination of using this tool.