User Account Problems

I am having problems creating local accounts on the destination computer.

Not all of the user accounts were migrated to the destination computer.

User accounts that I excluded were migrated to the destination computer.

I am using the /uel option, but many accounts are still being included in the migration.

The LoadState tool reports an error as return code 71 and fails to restore a user profile during a migration test.

Files that were not encrypted before the migration are now encrypted with the account used to run the LoadState tool.

Command-line Problems

I received the following error message: "Usage Error: You cannot specify a file path with any of the command-line options that exceeds 256 characters."

I received the following error message: "USMT was unable to create the log file(s). Ensure that you have write access to the log directory."

XML File Problems

I used the /genconfig option to create a Config.xml file, but I see only a few applications and components that are in the MigApp.xml file. Shouldn't the Config.xml file contain all of the applications that are in the MigApp.xml file?

I am having problems with a custom .xml file that I authored, and I cannot verify that the syntax is correct.

I am using a MigXML helper function but things aren’t working the way I expect.  How do I troubleshoot this issue?

Migration Problems

Files that I specified to exclude are still being migrated.

I specified rules to move a folder to a specific location on the destination computer, but it did not migrate correctly.

Some application settings are not migrating.

After the LoadState process completes, the new desktop background does not appear on the destination computer.

The MigApp.xml file is included in the migration, but some PST files are not migrating.

Offline Migration Problems

Hard Link Migration Problems

Problem: I'm having problems creating local accounts on the destination computer.

Resolution: For more information about creating accounts and migrating local accounts, see Migrating local and domain accounts and Migrate User Accounts.

Problem: Not all of the user accounts were migrated to the destination computer.

Causes/Resolutions: There are two possible causes for this problem:

When running the ScanState and LoadState tools on Windows Vista or Windows 7, you must run them in Administrator mode from an account with administrative credentials to ensure that all specified users are migrated. This is because User Access Control (UAC) is turned on in Windows Vista and Windows 7. To run in Administrator mode, click Start, click All Programs, click Accessories, right-click Command Prompt, click Run as administrator, and then specify your LoadState or ScanState command. If you do not run USMT in Administrator mode, only the user profile that is logged on will be included in the migration.

Any user accounts on the computer that have not been used will not be migrated. For example, if you add User1 to the computer, but User1 never logs on, then USMT will not migrate the User1 account.

Problem: User accounts that I excluded were migrated to the destination computer.

Cause: The command that you specified may have had conflicting /ui and /ue options. If a user is specified with the /ui option and is also specified to be excluded with either the /ue or /uel options, the user will be included in the migration. For example, if you specify /ui:domain1\* /ue:domain1\user1, then User1 will be migrated because the /ui option takes precedence.

Resolution: For more information about how to use the /ui and /ue options together, see the examples in the ScanState Syntax topic.

Problem: I am using the /uel option, but many accounts are still being included in the migration.

Cause: The /uel option depends on the last modified date of the users' NTUser.dat file. There are scenarios in which this last modified date may not match the users' last logon date.

Resolution: This is a limitation of the /uel option. You might need to exclude these users manually with the /ue option.

Problem: The LoadState tool reports an error as returns code 71 and fails to restore a user profile during a migration test.

Cause: During a migration test, if you run the ScanState tool on your test computer and then delete user profiles in order to test the LoadState tool on the same computer, you may have a conflicting key present in the registry. Using the net use command to remove a user profile will delete folders and files associated with that profile, but will not remove the registry key.

Resolution: To delete a user profile, use the User Accounts item in Control Panel. To correct an incomplete deletion of a user profile:

1. Open the registry editor by typing regedit at an elevated command prompt.
   
   
2. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList.
   
   Each user profile is stored in a System Identifier key under ProfileList.
   
   
3. Delete the key for the user profile you are trying to remove.
   
   

Problem: Files that were not encrypted before the migration are now encrypted with the account used to run the LoadState tool.

Cause: The ScanState tool was run using the /efs:copyraw option to migrate encrypted files and EFS certificates. The encryption attribute was set on a folder that was migrated, but the attribute was removed from file contents of that folder prior to migration.

Resolution: Before using the ScanState tool for a migration that includes encrypted files and EFS certificates, you can run the Cipher tool at the command prompt to review and change encryption settings on files and folders. You must remove the encryption attribute from folders that contain unencrypted files or encrypt the contents of all files within an encrypted folder.

To remove encryption from files that have already been migrated incorrectly, you must log on to the computer with the account that you used to run the LoadState tool and then remove the encryption from the affected files.

Problem: The LoadState tool reports an error as returns code 71 and a Windows Error 2202 in the log file.

Cause: The computer name was changed during an offline migration of a local user profile.

Resolution: You can use the /mu option when you run the LoadState tool to specify a new name for the user. For example,

loadstate /i:migapp.xml /i:miguser.xml \\fileserver\migration\mystore 
/progress:prog.log /l:load.log /mu:fareast\user1:farwest\user1

Problem: I received the following error message: "Usage Error: You cannot specify a file path with any of the command-line options that exceeds 256 characters."

Cause: You may receive this error message in some cases even if you do not specify a long store or file path. This is because the path length is calculated based on the absolute path. For example, if you run the scanstate.exe /o store command from C:\Program Files\USMT40, then each character in "C:\Program Files\USMT40" will be added to the length of "store" to get the length of the path.

Resolution: Ensure that the total path length (the store path plus the current directory) does not exceed 256 characters.

Problem: I received the following error message: "USMT was unable to create the log file(s). Ensure that you have write access to the log directory."

Cause: If you are running the ScanState or LoadState tools from a shared network resource, you will receive this error message if you do not specify /l.

Resolution: To fix this issue in this scenario, specify the /l:scan.log or /l:load.log option.

Problem: I used the /genconfig option to create a Config.xml file, but I see only a few applications and components that are in MigApp.xml. Why does Config.xml not contain all of the same applications?

Cause: Config.xml will contain only operating system components, applications, and the user document sections that are in both of the .xml files and are installed on the computer when you run the /genconfig option. Otherwise these applications and components will not appear in the Config.xml file.

Resolution: Install all of the desired applications on the computer before running the /genconfig option. Then run ScanState with all of the .xml files. For example, if the destination computer is running Windows Vista, run the following:

scanstate /genconfig:config.xml /i:miguser.xml /i:migapp.xml /v:13 /l:scanstate.log

Problem: I am having problems with a custom .xml file that I authored, and I cannot verify that the syntax is correct.

Resolution: You can load the XML schema (MigXML.xsd), included with USMT, into your XML authoring tool. For examples, see the Visual Studio Development Center at this Microsoft Web site. Then, load your .xml file in the authoring tool to see if there is a syntax error. In addition, see USMT 4.0 XML Referencefor more information about using the XML elements.

Problem: I am using a MigXML helper function, but the migration isn’t working the way I expected it to.  How do I troubleshoot this issue?

Cause: Typically, this issue is caused by incorrect syntax used in a helper function. You receive a Success return code, but the files you wanted to migrate did not get collected or applied, or weren’t collected or applied in the way you expected.

Resolution: You should search the ScanState or LoadState log for either the component name which contains the MigXML helper function, or the MigXML helper function title, so that you can locate the related warning in the log file.

Problem: Files that I specified to exclude are still being migrated.

Cause: There may be another rule that is including the files. If there is a more specific rule or a conflicting rule, the files will be included in the migration.

Resolution: For more information see Conflicts and Precedence and the Diagnostic Log section in Log Files.

Problem: I specified rules to move a folder to a specific location on the destination computer, but it has not migrated correctly.

Cause: There may be an error in the XML syntax.

Resolution: You can use the USMT XML schema (MigXML.xsd) to write and validate migration .xml files. Also see the XML examples in the following topics:

Conflicts and Precedence

Exclude Files and Settings

Reroute Files and Settings

Include Files and Settings

Custom XML Examples

Problem: After LoadState completes, the new desktop background does not appear on the destination computer.

There are three typical causes for this issue.

Cause #1: Some settings such as fonts, desktop backgrounds, and screen-saver settings are not applied by LoadState until after the destination computer has been restarted.

Resolution : To fix this issue, log off, and then log back on to see the migrated desktop background.

Cause #2: If the source computer was running Windows® XP and the desktop background was stored in the Drive:\WINDOWS\Web\Wallpaper folder (the default folder where desktop backgrounds are stored in Windows XP), the desktop background will not be migrated. Instead, the destination computer will have the default Windows Vista desktop background. This will occur even if the desktop background was a custom picture that was added to the \WINDOWS\Web\Wallpaper folder. However, if the end user sets a picture as the desktop background that was saved in another location (for example, My Pictures), then the desktop background will migrate.

Resolution: Ensure that the desktop background images that you want to migrate are not in the \WINDOWS\Web\Wallpaper folder on the source computer.

Cause #3: If ScanState was not run on Windows XP from an account with administrative credentials, some operating system settings will not migrate. For example, desktop background settings, screen-saver selections, modem options, media-player settings, and Remote Access Service (RAS) connection phone book (.pbk) files and settings will not migrate.

Resolution: Run the ScanState and LoadState tools from within an account with administrative credentials.

Problem: I included MigApp.xml in the migration, but some PST files aren’t migrating.

Cause: The MigApp.xml file migrates only the PST files that are linked to Outlook profiles.

Resolution: To migrate PST files that are not linked to Outlook profiles, you must create a separate migration rule to capture these files.

Problem: Some of my system settings do not migrate in an offline migration.

Cause: Some system settings, such as desktop backgrounds and network printers, are not supported in an offline migration. For more information, see What Does USMT Migrate?

Resolution: In an offline migration, these system settings must be restored manually.

Problem: The ScanState tool fails with return code 26.

Cause: A common cause of return code 26 is that a temp profile is active on the source computer. This profile maps to c:\users\temp. The ScanState log shows a MigStartupOfflineCaught exception which includes the message "User profile duplicate SID error."

Resolution: You can reboot the computer to get rid of the temp profile or you can set MIG_FAIL_ON_PROFILE_ERROR=0 to skip the error and exclude the temp profile.

Problem: Include and Exclude rules for migrating user profiles do not work the same offline as they do online.

Cause: When offline, the DNS server cannot be queried to resolve the user name and SID mapping.

Resolution: Use a Security Identifier (SID) to include a user when running the ScanState tool. For example,

Scanstate /ui:S1-5-21-124525095-708259637-1543119021*

The wild card (*) at the end of the SID will migrate the SID_Classes key as well.

You can also use patterns for SIDs that identify generic users or groups. For example, you can use the /ue:*-500 option to exclude the local administrator accounts. For more information about Windows SIDs, see this Microsoft Web site.

Problem: My script to wipe the disk fails after running the ScanState tool on a 64-bit system.

Cause: The HKLM registry hive is not unloaded after the ScanState tool has finished running.

Resolution: Reboot the computer or unload the registry hive at the command prompt after the ScanState tool has finished running. For example, at a command prompt, type:

reg.exe unload hklm\$dest$software

Problem: EFS files are not restored to the new partition.

Cause: EFS files cannot be moved to a new partition with a hard link. The /efs:hardlink command-line option is only applicable to files migrated on the same partition.

Resolution: Use the /efs:copyraw command-line option to copy EFS files during the migration instead of creating hard links, or manually copy the EFS files from the hard-link store.

Problem: The ScanState tool cannot delete a previous hard-link migration store.

Cause: The migration store contains hard links to locked files.

Resolution: Use the USMTutils tool to delete the store or change the store name. For example, at a command prompt, type:

USMTutils /rd <storedir>

You should also reboot the machine.

• Troubleshooting
• Frequently Asked Questions
• Return Codes