Translating and Relocating Registry Entries for Your Migration
Updated: March 28, 2003
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
Because the name or location of some registry entries for the operating system has been changed in later versions of Windows, many registry values must be translated during migration, and others must be relocated within the registry. This is also true with different versions of some applications. For example, copying the subkey HKEY_CURRENT_USER\Control Panel\Desktop\WindowsMetrics during migration causes problems, because entries such as IconFont are not translated correctly.
USMT automatically translates and relocates the operating system settings for the user state that it migrates. To prevent problems with custom settings, either do not migrate entries that are unique to a specific version of an application and cause problems, or use the renaming and relocating capabilities of USMT to adjust the entries. You cannot use USMT to translate registry values: The best solution for this type of change is to write custom code.
You can use tools such as Sysdiff.exe to compare before and after images of the registry. This tool helps in finding registry changes between versions of an application or between the same version of the application running on different versions of Windows. Sysdiff.exe is documented and available for download from the Resource Kit Tools link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources/.
Windows XP registry restrictions
The enhanced security of Windows XP can mean that registry settings that were accessible in the Microsoft® Windows® 95 or Microsoft® Windows® 98 operating systems are no longer accessible.
In Windows XP, a user with no administrative permissions has write access to only three locations (depending on default security settings): the HKEY_CURRENT_USER registry subtree, the User Profile, and a shared documents location. Users cannot change settings outside those locations without administrative permissions.
If an application writes settings outside HKEY_CURRENT_USER, users will not be able to run the application after migration. You should deal with these applications on a case-by-case basis. Sometimes it is acceptable to change the access rights to a part of the registry; at other times, this can grant to the user unacceptable access to the registry. The best solution is to work with the software vendor or in-house developer to determine migration requirements when introducing a revised version of an application.