deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-06-15 18:33:43 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

Metadata update deployment/usmt 5

Browse Source
This commit is contained in:
Frank Rojas
2022-11-02 00:53:32 -04:00
parent 9eb95a00ab
commit db6fcb0139
13 changed files with 363 additions and 363 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
windows/deployment/usmt/getting-started-with-the-user-state-migration-tool.md
View File

@ -11,7 +11,8 @@ ms.technology: itpro-deploy
ms.date: 11/01/2022
---
# Getting Started with the User State Migration Tool (USMT)
# Getting started with the User State Migration Tool (USMT)
This article outlines the general process that you should follow to migrate files and settings.
## In this topic
@ -34,7 +35,7 @@ This article outlines the general process that you should follow to migrate file
5. Modify copies of the `Migration.xml` and `MigDocs.xml` files and create custom .xml files, if it's required. To modify the migration behavior, such as migrating the **Documents** folder but not the **Music** folder, you can create a custom .xml file or modify the rules in the existing migration .xml files. The document finder, or `MigXmlHelper.GenerateDocPatterns` helper function, can be used to automatically find user documents on a computer without creating extensive custom migration .xml files.
> [!Important]
> [!IMPORTANT]
> We recommend that you always make and modify copies of the .xml files included in User State Migration Tool (USMT) 10.0. Never modify the original .xml files.
You can use the `MigXML.xsd` file to help you write and validate the .xml files. For more information about how to modify these files, see [USMT XML Reference](usmt-xml-reference.md).
@ -51,14 +52,14 @@ This article outlines the general process that you should follow to migrate file
2. Close all applications. If some applications are running when you run the `Scanstate.exe` command, USMT might not migrate all of the specified data. For example, if Microsoft® Office Outlook® is open, USMT might not migrate PST files.
> [!Note]
> [!NOTE]
> USMT will fail if it cannot migrate a file or setting unless you specify the `/C` option. When you specify the `/C` option, USMT will ignore the errors, and log an error every time that it encounters a file that is being used that USMT did not migrate. You can use the `<ErrorControl>` section in the `Config.xml` file to specify which errors should be ignored, and which should cause the migration to fail.
3. Run the `Scanstate.exe` command on the source computer to collect files and settings. You should specify all of the .xml files that you want the `Scanstate.exe` command to use. For example,
`scanstate.exe \\server\migration\mystore /config:config.xml /i:migdocs.xml /i:migapp.xml /v:13 /l:scan.log`
> [!Note]
> [!NOTE]
> If the source computer is running Windows 7, or Windows 8, you must run the `Scanstate.exe` command in **Administrator** mode. To run in **Administrator** mode, right-click **Command Prompt**, and then select **Run As Administrator**. For more information about the how the `Scanstate.exe` command processes and stores the data, see [How USMT Works](usmt-how-it-works.md).
4. Run the `USMTUtils.exe` command with the `/Verify` option to ensure that the store you created isn't corrupted.
@ -69,12 +70,12 @@ This article outlines the general process that you should follow to migrate file
2. Install all applications that were on the source computer. Although it isn't always required, we recommend installing all applications on the destination computer before you restore the user state. This makes sure that migrated settings are preserved.
> [!Note]
> [!NOTE]
> The application version that is installed on the destination computer should be the same version as the one on the source computer. USMT does not support migrating the settings for an older version of an application to a newer version. The exception to this is Microsoft&reg; Office, which USMT can migrate from an older version to a newer version.
3. Close all applications. If some applications are running when you run the `Loadstate.exe` command, USMT might not migrate all of the specified data. For example, if Microsoft Office Outlook is open, USMT might not migrate PST files.
> [!Note]
> [!NOTE]
> Use `/C` to continue your migration if errors are encountered, and use the `<ErrorControl>` section in the `Config.xml` file to specify which errors should be ignored, and which errors should cause the migration to fail.
4. Run the `Loadstate.exe` command on the destination computer. Specify the same set of .xml files that you specified when you used the `Scanstate.exe` command. However, you don't have to specify the `Config.xml` file, unless you want to exclude some of the files and settings that you migrated to the store. For example, you might want to migrate the My Documents folder to the store, but not to the destination computer. To do this, modify the `Config.xml` file and specify the updated file by using the `Loadstate.exe` command. Then, the `Loadstate.exe` command will migrate only the files and settings that you want to migrate. For more information about how the `Loadstate.exe` command processes and migrates data, see [How USMT Works](usmt-how-it-works.md).
@ -83,7 +84,7 @@ This article outlines the general process that you should follow to migrate file
`loadstate.exe \\server\migration\mystore /config:config.xml /i:migdocs.xml /i:migapp.xml /v:13 /l:load.log`
> [!Note]
> [!NOTE]
> Run the `Loadstate.exe` command in administrator mode. To do this, right-click **Command Prompt**, and then click **Run As Administrator**.
5. Sign out after you run the `Loadstate.exe` command. Some settings (for example, fonts, wallpaper, and screen saver settings) won't take effect until the next time that the user logs on.

28
windows/deployment/usmt/migrate-application-settings.md
View File

@ -37,13 +37,13 @@ This article doesn't contain information about how to migrate applications that
You should identify a test computer that contains the operating system of your source computers, and the application whose settings you want to migrate. For example, if you're planning on migrating from Windows 7 to Windows 10, install Windows 7 on your test computer and then install the application.
## <a href="" id="bkmk-step1"></a>Step 1: Verify that the application is installed on the source computer, and that it's the same version as the version to be installed on the destination computer.
## <a href="" id="bkmk-step1"></a> Step 1: Verify that the application is installed on the source computer, and that it's the same version as the version to be installed on the destination computer
Before USMT migrates the settings, you need it to check whether the application is installed on the source computer, and that it's the correct version. If the application isn't installed on the source computer, you probably don't want USMT to spend time searching for the application's settings. More importantly, if USMT collects settings for an application that isn't installed, it may migrate settings that will cause the destination computer to function incorrectly. You should also investigate whether there's more than one version of the application because the new version may not store the settings in the same place. Mismatched application versions may lead to unexpected results on the destination computer.
There are many ways to detect if an application is installed. The best practice is to check for an application uninstall key in the registry, and then search the computer for the executable file that installed the application. It's important that you check for both of these items, because sometimes different versions of the same application share the same uninstall key. So even if the key is there, it may not correspond to the version of the application that you want.
### Check the registry for an application uninstall key.
### Check the registry for an application uninstall key
When many applications are installed (especially those installed using the Microsoft® Windows® Installer technology), an application uninstall key is created under:
@ -61,17 +61,15 @@ Usually, you can find this key by searching under
for the name of the application, the name of the application executable file, or for the name of the company that makes the application. You can use the Registry Editor, `Regedit.exe` located in the `%SystemRoot%`, to search the registry.
### Check the file system for the application executable file.
### Check the file system for the application executable file
You should also check the application binaries for the executable that installed the application. To check for application binaries, you'll first need to determine where the application is installed and what the name of the executable is. Most applications store the installation location of the application binaries in the registry. You should search the registry for the name of the application, the name of the application executable, or for the name of the company that makes the application, until you find the registry value that contains the installation path. Once you've determined the path to the application executable, you can use the `DoesFileVersionMatch` helper function to check for the correct version of the application executable. For an example of how to use the `DoesFileVersionMatch` helper function, see the Windows Live™ Messenger section of the `MigApp.xml` file.
## <a href="" id="bkmk-step2"></a>Step 2: Identify settings to collect and determine where each setting is stored on the computer.
## <a href="" id="bkmk-step2"></a> Step 2: Identify settings to collect and determine where each setting is stored on the computer
Next, you should go through the user interface and make a list of all of the available settings. You can reduce the list if there are settings that you don't want to migrate. To determine where each setting is stored, you'll need to change each setting and monitor the activity on the registry and the file system. You don't need to migrate the binary files and registry settings that are made when the application is installed because you'll need to reinstall the application onto the destination computer. You only need to migrate those settings that are customizable.
### <a href="" id="bkmkdetermine"></a>
**How To Determine Where Each Setting is Stored**
### How to determine where each setting is stored
1. Download a file and registry monitoring tool, such as the Regmon and Filemon tools, from the [Windows Sysinternals Web site](/sysinternals/).
@ -79,29 +77,29 @@ Next, you should go through the user interface and make a list of all of the ava
3. Filter the output of the tools so it only displays changes being made by the application.
> [!Note]
> [!NOTE]
> Most applications store their settings under the user profile. That is, the settings stored in the file system are under the `%UserProfile%` directory, and the settings stored in the registry are under the `HKEY_CURRENT_USER` hive. For these applications you can filter the output of the file and registry monitoring tools to show activity only under these locations. This will considerably reduce the amount of output that you will need to examine.
4. Start the monitoring tool(s), change a setting, and look for registry and file system writes that occurred when you changed the setting. Make sure the changes you make actually take effect. For example, if you're changing a setting in Microsoft Word by selecting a check box in the **Options** dialog box, the change typically won't take effect until you close the dialog box by clicking **OK**.
5. When the setting is changed, note the changes to the file system and registry. There may be more than one file or registry values for each setting. You should identify the minimal set of file and registry changes that are required to change this setting. This set of files and registry keys is what you will need to migrate in order to migrate the setting.
> [!Note]
> [!NOTE]
> Changing an application setting invariably leads to writing to registry keys. If possible, filter the output of the file and registry monitor tool to display only writes to files and registry keys/values.
## <a href="" id="bkmk-step3"></a>Step 3: Identify how to apply the gathered settings.
## <a href="" id="bkmk-step3"></a> Step 3: Identify how to apply the gathered settings
If the version of the application on the source computer is the same as the one on the destination computer, then you don't have to modify the collected files and registry keys. By default, USMT migrates the files and registry keys from the source location to the corresponding location on the destination computer. For example, if a file was collected from the `C:\Documents and Settings\User1\My Documents` folder and the profile directory on the destination computer is located at `D:\Users\User1`, then USMT will automatically migrate the file to `D:\Users\User1\My Documents`. However, you may need to modify the location of some settings in the following three cases:
### Case 1: The version of the application on the destination computer is newer than the one on the source computer.
### Case 1: The version of the application on the destination computer is newer than the one on the source computer
In this case, the newer version of the application may be able to read the settings from the source computer without modification. That is, the data collected from an older version of the application is sometimes compatible with the newer version of the application. However, you may need to modify the setting location if either of the following conditions is true:
- **The newer version of the application has the ability to import settings from an older version.** This mapping usually happens the first time a user runs the newer version after the settings have been migrated. Some applications import settings automatically after settings are migrated. However, other applications will only do import settings if the application was upgraded from the older version. When the application is upgraded, a set of files and/or registry keys is installed that indicates the older version of the application was previously installed. If you perform a clean installation of the newer version (which is the case in most migrations), the computer doesn't contain this set of files and registry keys so the mapping doesn't occur. In order to trick the newer version of the application into initiating this import process, your migration script may need to create these files and/or registry keys on the destination computer.
To identify which files and/or registry keys/values need to be created to cause the import, you should upgrade the older version of the application to the newer one and monitor the changes made to the file system and registry by using the same process described in [How To determine where each setting is stored](#bkmkdetermine). Once you know the set of files that the computer needs, you can use the **&lt;addObjects&gt;** element to add them to the destination computer.
To identify which files and/or registry keys/values need to be created to cause the import, you should upgrade the older version of the application to the newer one and monitor the changes made to the file system and registry by using the same process described in [How to determine where each setting is stored](#how-to-determine-where-each-setting-is-stored). Once you know the set of files that the computer needs, you can use the **&lt;addObjects&gt;** element to add them to the destination computer.
- [The newer version of the application can't read settings from the source computer and it's also unable to import the settings into the new format.](#bkmkdetermine) In this case, you'll need to create a mapping for each setting from the old locations to the new locations. To create the mapping, determine where the newer version stores each setting using the process described in [How To determine where each setting is stored](#bkmkdetermine). After you've created the mapping, apply the settings to the new location on the destination computer using the **&lt;locationModify&gt;** element, and the `RelativeMove` and `ExactMove` helper functions.
- **The newer version of the application can't read settings from the source computer and it's also unable to import the settings into the new format.** In this case, you'll need to create a mapping for each setting from the old locations to the new locations. To create the mapping, determine where the newer version stores each setting using the process described in [How to determine where each setting is stored](#how-to-determine-where-each-setting-is-stored). After you've created the mapping, apply the settings to the new location on the destination computer using the **&lt;locationModify&gt;** element, and the `RelativeMove` and `ExactMove` helper functions.
### Case 2: The destination computer already contains settings for the application.
@ -115,10 +113,10 @@ We recommend that you migrate the settings after you install the application, bu
After you have completed steps 1 through 3, you'll need to create a custom migration .xml file that migrates the application based on the information that you now have. You can use the `MigApp.xml` file as a model because it contains examples of many of the concepts discussed in this article. You can also see [Custom XML Examples](usmt-custom-xml-examples.md) for another sample .xml file.
> [!Note]
> [!NOTE]
> We recommend that you create a separate .xml file instead of adding your script to the `MigApp.xml` file. This is because the `MigApp.xml` file is a very large file and it will be difficult to read and edit. In addition, if you reinstall USMT for some reason, the `MigApp.xml` file will be overwritten by the default version of the file and you will lose your customized version.
> [!Important]
> [!IMPORTANT]
> Some applications store information in the user profile that should not be migrated (for example, application installation paths, the computer name, and so on). You should make sure to exclude these files and registry keys from the migration.
Your script should do the following actions:

2
windows/deployment/usmt/migration-store-types-overview.md
View File

@ -51,7 +51,7 @@ If you have enough space and you're migrating the user state back to the same co
If there isn't enough local disk space, or if you're moving the user state to another computer, then you must store the data remotely. For example, you can store it in on a shared folder, on removable media such as a UFD drive, or you can store it directly on the destination computer. For example, create and share `C:\store` on the destination computer. Then run the `ScanState.exe` command on the source computer and save the files and settings to `\\<DestinationComputerName>\store`. Then, run the `Loadstate.exe` command on the destination computer and specify `C:\Store` as the store location. By doing this process, you don't need to save the files to a server.
> [!Important]
> [!IMPORTANT]
> If possible, have users store their data within their `%UserProfile%\My Documents` and `%UserProfile%\Application Data` folders. This will reduce the chance of USMT missing critical user data that is located in a directory that USMT is not configured to check.
### <a href="" id="bkmk-localonly"></a> The /localonly Command-Line Option

2
windows/deployment/usmt/offline-migration-reference.md
View File

@ -68,7 +68,7 @@ The following table defines the supported combination of online and offline oper
|WinPE 5.0 or greater, with the MSXML library|Windows 7, Windows 8, Windows 10|
|Windows 7, Windows 8, Windows 10|Windows.old directory|
> [!Note]
> [!NOTE]
> It is possible to run the ScanState tool while the drive remains encrypted by suspending Windows BitLocker Drive Encryption before booting into WinPE. For more information, see [this Microsoft site](/previous-versions/windows/it-pro/windows-7/ee424315(v=ws.10)).
## <a href="" id="bkmk-usergroupmembership"></a> User-Group Membership and Profile Control

26
windows/deployment/usmt/understanding-migration-xml-files.md
View File

@ -58,7 +58,7 @@ When used this way, the `Config.xml` file tightly controls aspects of the migrat
The `MigApp.xml` file installed with USMT includes instructions to migrate the settings for the applications listed in [What Does USMT Migrate?](usmt-what-does-usmt-migrate.md). You must include the `MigApp.xml` file when using the ScanState and LoadState tools, by using the `/i` option in order to migrate application settings. The `MigDocs.xml` and `MigUser.xml` files don't migrate application settings. You can create a custom XML file to include additional applications. For more information, see [Customize USMT XML Files](usmt-customize-xml-files.md).
> [!Important]
> [!IMPORTANT]
> The MigApps.xml file will only detect and migrate .pst files that are linked to Microsoft Office Outlook. For more information about migrating .pst files that are not linked to Outlook, see the [Sample migration rules for customized versions of XML files](#bkmk-samples).
## <a href="" id="bkmk-migdocs"></a> Overview of the MigDocs.xml file
@ -67,13 +67,13 @@ The `MigDocs.xml` file uses the new `GenerateDocPatterns` helper function to cre
The default `MigDocs.xml` file migrates the following data:
- All files on the root of the drive except %WINDIR%, %PROGRAMFILES%, %PROGRAMDATA%, or %USERS%.
- All files on the root of the drive except `%WINDIR%`, `%PROGRAMFILES%`, `%PROGRAMDATA%`, or `%USERS%`.
- All folders in the root directory of all fixed drives. For example: c:\\data\_mail\\\*\[\*\]
- All folders in the root directory of all fixed drives. For example: `c:\data_mail\*[*]`
- All files from the root of the Profiles folder, except for files in the system profile. For example: c:\\users\\name\[mail.pst\]
- All files from the root of the Profiles folder, except for files in the system profile. For example: `c:\users\name[mail.pst]`
- All folders from the root of the Profiles folder, except for the system-profile folders. For example: c:\\users\\name\\new folder\\\*\[\*\]
- All folders from the root of the Profiles folder, except for the system-profile folders. For example: `c:\users\name\new folder\*[*]`
- Standard shared folders:
@ -291,7 +291,7 @@ To create exclude data patterns:
The migration XML files contain two &lt;component&gt; elements with different **context** settings. The system context applies to files on the computer that aren't stored in the User Profiles directory, while the user context applies to files that are particular to an individual user.
**System context**
#### System context
The system context includes rules for data outside of the User Profiles directory. For example, when called in a system context in the `MigDocs.xml` file, the `GenerateDocPatterns` function creates patterns for all common shell folders, files in the root directory of hard drives, and folders located at the root of hard drives. The following folders are included:
@ -309,7 +309,7 @@ The system context includes rules for data outside of the User Profiles director
- FOLDERID\_PublicDownloads
**User context**
#### User context
The user context includes rules for data in the User Profiles directory. When called in a user context in the `MigDocs.xml` file, the `GenerateDocPatterns` function creates patterns for all user shell folders, files located at the root of the profile, and folders located at the root of the profile. The following folders are included:
@ -358,7 +358,7 @@ In the examples below, the source computer has a .txt file called "new text docu
To exclude the new text document.txt file and any .txt files in "new folder", you can do the following modification:
**Example 1: Exclude all .txt files in a folder**
#### Example 1: Exclude all .txt files in a folder
To exclude Rule 1, there needs to be an exact match of the file name. However, for Rule 2, you can create a pattern to exclude files by using the file name extension.
@ -371,7 +371,7 @@ To exclude Rule 1, there needs to be an exact match of the file name. However, f
</exclude>
```
**Example 2: Use the UnconditionalExclude element to give a rule precedence over include rules**
#### Example 2: Use the UnconditionalExclude element to give a rule precedence over include rules
If you don't know the file name or location of the file, but you do know the file name extension, you can use the `GenerateDrivePatterns` function. However, the rule will be less specific than the default include rule generated by the `MigDocs.xml` file, so it will not have precedence. You must use the &lt;UnconditionalExclude&gt; element to give this rule precedence over the default include rule. For more information about the order of precedence for XML migration rules, see [Conflicts and Precedence](usmt-conflicts-and-precedence.md).
@ -383,9 +383,9 @@ If you don't know the file name or location of the file, but you do know the fil
</unconditionalExclude>
```
**Example 3 : Use a UserandSystem context component to run rules in both contexts**
#### Example 3 : Use a UserandSystem context component to run rules in both contexts
If you want the &lt;UnconditionalExclude&gt; element to apply to both the system and user context, you can create a third component using the **UserandSystem** context. Rules in this component will be run in both contexts.
If you want the **&lt;UnconditionalExclude&gt;** element to apply to both the system and user context, you can create a third component using the **UserandSystem** context. Rules in this component will be run in both contexts.
``` xml
<component type="Documents" context="UserandSystem">
@ -408,7 +408,7 @@ For more examples of exclude rules that you can use in custom migration XML file
The application data directory is the most common location that you would need to add an include rule for. The `GenerateDocPatterns` function excludes this location by default. If your company uses an application that saves important data to this location, you can create include rules to migrate the data. For example, the default location for .pst files is: `%CSIDL_LOCAL_APPDATA%\Microsoft\Outlook`. The `MigApp.xml` file contains migration rules to move only those .pst files that are linked to Microsoft Outlook. To include .pst files that aren't linked, you can do the following modification:
**Example 1: Include a file name extension in a known user folder**
#### Example 1: Include a file name extension in a known user folder
This rule will include .pst files that are located in the default location, but aren't linked to Microsoft Outlook. Use the user context to run this rule for each user on the computer.
@ -420,7 +420,7 @@ This rule will include .pst files that are located in the default location, but
</include>
```
**Example 2: Include a file name extension in Program Files**
#### Example 2: Include a file name extension in Program Files
For locations outside the user profile, such as the Program Files folder, you can add the rule to the system context component.

6
windows/deployment/usmt/usmt-best-practices.md
View File

@ -58,7 +58,7 @@ As the authorized administrator, it is your responsibility to protect the privac
Take extreme caution when migrating encrypted files, because the end user doesn't need to be logged on to capture the user state. By default, USMT fails if an encrypted file is found. For specific instructions about EFS best practices, see [Migrate EFS Files and Certificates](usmt-migrate-efs-files-and-certificates.md).
> [!Note]
> [!NOTE]
> If you migrate an encrypted file without also migrating the certificate, end users will not be able to access the file after the migration.
- **Encrypt the store**
@ -114,7 +114,7 @@ As the authorized administrator, it is your responsibility to protect the privac
In the **UserAndSystem** context, a rule is processed one time for each user on the system and one time for the system.
> [!Note]
> [!NOTE]
> The number of times a rule is processed does not affect the number of times a file is migrated. The USMT migration engine ensures that each file migrates only once.
- **We recommend that you create a separate .xml file instead of adding your .xml code to one of the existing migration .xml files**
@ -127,7 +127,7 @@ As the authorized administrator, it is your responsibility to protect the privac
- **You can use the asterisk (\*) wildcard character in any migration XML file that you create**
> [!Note]
> [!NOTE]
> The question mark is not valid as a wildcard character in USMT .xml files.
## Related articles

49
windows/deployment/usmt/usmt-common-issues.md
View File

@ -29,7 +29,7 @@ The following sections discuss common issues that you might see when you run the
[Hard Link Migration Problems](#bkmk-hardlink)
[USMT doesn't migrate the Start layout](#usmt-does-not-migrate-the-start-layout)
[USMT doesn't migrate the Start layout](#usmt-doesnt-migrate-the-start-layout)
## General Guidelines for Identifying Migration Problems
@ -39,7 +39,7 @@ When you encounter a problem or error message during migration, you can use the
In most cases, the ScanState and LoadState logs indicate why a USMT migration is failing. We recommend that you use the `/v:5` option when testing your migration. This verbosity level can be adjusted in a production migration; however, reducing the verbosity level might make it more difficult to diagnose failures that are encountered during production migrations. You can use a verbosity level higher than 5 if you want the log files output to go to a debugger.
> [!Note]
> [!NOTE]
> Running the ScanState and LoadState tools with the `/v:5` option creates a detailed log file. Although this option makes the log file large, the extra detail can help you determine where migration errors occurred.
- Use the `/Verify` option with the UsmtUtils tool to determine whether any files in a compressed migration store are corrupted. For more information, see [Verify the Condition of a Compressed Migration Store](verify-the-condition-of-a-compressed-migration-store.md).
@ -54,18 +54,18 @@ When you encounter a problem or error message during migration, you can use the
- Close all applications before running ScanState or LoadState tools. If some applications are running during the ScanState or LoadState process, USMT might not migrate some data. For example, if Microsoft Outlook® is open, USMT might not migrate PST files.
> [!Note]
> [!NOTE]
> USMT will fail if it can't migrate a file or setting unless you specify the `/c` option. When you specify the `/c` option, USMT ignores errors. However, it logs an error when it encounters a file that is in use that didn't migrate.
## <a href="" id="user"></a> User Account Problems
The following sections describe common user account problems. Expand the section to see recommended solutions.
### I'm having problems creating local accounts on the destination computer.
### I'm having problems creating local accounts on the destination computer
**Resolution:** For more information about creating accounts and migrating local accounts, see [Migrate User Accounts](usmt-migrate-user-accounts.md).
### Not all of the user accounts were migrated to the destination computer.
### Not all of the user accounts were migrated to the destination computer
**Causes/Resolutions** There are two possible causes for this problem:
@ -83,19 +83,19 @@ If you don't run USMT in Administrator mode, only the user profile that is logge
Any user accounts on the computer that haven't been used won't be migrated. For example, if you add User1 to the computer, but User1 never logs on, then USMT won't migrate the User1 account.
### User accounts that I excluded were migrated to the destination computer.
### User accounts that I excluded were migrated to the destination computer
**Cause:** The command that you specified might have had conflicting `ui` and `/ue` options. If a user is specified with the `/ui` option and with either the `/ue` or `/uel` options at the same time, 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](usmt-scanstate-syntax.md) article.
### I'm using the /uel option, but many accounts are still being included in the migration.
### I'm 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 might not match the users' last sign-in date.
**Resolution:** This is a limitation of the `/uel` option. You might need to exclude these users manually with the `/ue` option.
### The LoadState tool reports an error as return code 71 and fails to restore a user profile during a migration test.
### The LoadState tool reports an error as return 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 won't remove the registry key.
@ -109,7 +109,7 @@ Any user accounts on the computer that haven't been used won't be migrated. For
3. Delete the key for the user profile you're trying to remove.
### Files that weren't encrypted before the migration are now encrypted with the account used to run the LoadState tool.
### Files that weren't 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 Encrypting File System (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.
@ -117,7 +117,7 @@ Any user accounts on the computer that haven't been used won't be migrated. For
To remove encryption from files that have already been migrated incorrectly, you must sign into the computer with the account that you used to run the LoadState tool and then remove the encryption from the affected files.
### The LoadState tool reports an error as return code 71 and a Windows Error 2202 in the log file.
### The LoadState tool reports an error as return 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.
@ -146,7 +146,6 @@ The following sections describe common command-line problems. Expand the section
## <a href="" id="xml"></a> XML File Problems
The following sections describe common XML file problems. Expand the section to see recommended solutions.
### 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?
@ -157,7 +156,7 @@ The following sections describe common XML file problems. Expand the section to
`scanstate.exe /genconfig:config.xml /i:migdocs.xml /i:migapp.xml /v:5 /l:scanstate.log`
### I'm having problems with a custom .xml file that I authored, and I can't verify that the syntax is correct.
### I'm having problems with a custom .xml file that I authored, and I can't verify that the syntax is correct
**Resolution:** You can load the XML schema file `MigXML.xsd` into your XML authoring tool. `MigXML.xsd` is included with USMT. For examples, see the [Visual Studio Development Center](https://go.microsoft.com/fwlink/p/?LinkId=74513). Then, load your .xml file in the authoring tool to see if there's a syntax error. For more information about using the XML elements, see [USMT XML Reference](usmt-xml-reference.md).
@ -171,13 +170,13 @@ The following sections describe common XML file problems. Expand the section to
The following sections describe common migration problems. Expand the section to see recommended solutions.
### Files that I specified to exclude are still being migrated.
### Files that I specified to exclude are still being migrated
**Cause:** There might be another rule that is including the files. If there's a more specific rule or a conflicting rule, the files will be included in the migration.
**Resolution:** For more information, see [Conflicts and Precedence](usmt-conflicts-and-precedence.md) and the Diagnostic Log section in [Log Files](usmt-log-files.md).
### I specified rules to move a folder to a specific location on the destination computer, but it hasn't migrated correctly.
### I specified rules to move a folder to a specific location on the destination computer, but it hasn't migrated correctly
**Cause:** There might be an error in the XML syntax.
@ -193,7 +192,7 @@ The following sections describe common migration problems. Expand the section to
[Custom XML Examples](usmt-custom-xml-examples.md)
### After LoadState completes, the new desktop background doesn't appear on the destination computer.
### After LoadState completes, the new desktop background doesn't appear on the destination computer
There are three typical causes for this issue.
@ -211,7 +210,7 @@ There are three typical causes for this issue.
**Resolution:** Run the ScanState and LoadState tools from within an account with administrative credentials.
--->
### <a href="" id="i-included-migapp-xml-in-the-migration--but-some-pst-files-aren-t-migrating-"></a>I included MigApp.xml in the migration, but some PST files aren't migrating.
### <a href="" id="i-included-migapp-xml-in-the-migration--but-some-pst-files-aren-t-migrating-"></a> 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.
@ -227,13 +226,15 @@ There are three typical causes for this issue.
1. With the user signed in, back up the Start layout using the following Windows PowerShell command. You can specify a different path if desired:
```
```powershell
Export-StartLayout -Path "C:\Layout\user1.xml"
```
2. Migrate the user's profile with USMT.
3. Before the user signs in on the new device, import the Start layout using the following Windows PowerShell command:
```
```powershell
Import-StartLayout -LayoutPath "C:\Layout\user1.xml" -MountPath %systemdrive%
```
@ -243,19 +244,19 @@ This workaround changes the Default user's Start layout. The workaround doesn't
The following sections describe common offline migration problems. Expand the section to see recommended solutions.
### Some of my system settings don't migrate in an offline migration.
### Some of my system settings don't migrate in an offline migration
**Cause:** Some system settings, such as desktop backgrounds and network printers, aren't supported in an offline migration. For more information, see [What Does USMT Migrate?](usmt-what-does-usmt-migrate.md)
**Resolution:** In an offline migration, these system settings must be restored manually.
### The ScanState tool fails with return code 26.
### 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 that 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.
### Include and Exclude rules for migrating user profiles don't work the same offline as they do online.
### Include and Exclude rules for migrating user profiles don't work the same offline as they do online
**Cause:** When offline, the DNS server can't be queried to resolve the user name and SID mapping.
@ -269,7 +270,7 @@ The wild card (\*) at the end of the SID will migrate the *SID*\_Classes key as
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](/troubleshoot/windows-server/identity/security-identifiers-in-windows).
### My script to wipe the disk fails after running the ScanState tool on a 64-bit system.
### My script to wipe the disk fails after running the ScanState tool on a 64-bit system
**Cause:** The HKLM registry hive isn't unloaded after the ScanState tool has finished running.
@ -283,13 +284,13 @@ reg.exe unload hklm\$dest$software
The following sections describe common hard-link migration problems. Expand the section to see recommended solutions.
### EFS files aren't restored to the new partition.
### EFS files aren't restored to the new partition
**Cause:** EFS files can't 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.
### The ScanState tool can't delete a previous hard-link migration store.
### The ScanState tool can't delete a previous hard-link migration store
**Cause:** The migration store contains hard links to locked files.

1
windows/deployment/usmt/usmt-common-migration-scenarios.md
View File

@ -85,7 +85,6 @@ A company has decided to update the operating system on all of its computers to
## <a href="" id="bkmk-pcreplace"></a> PC-Replacement
The following diagram shows a PC-replacement migration. First, the administrator migrates the user state from the source computer to an intermediate store. After installing the operating system on the destination computer, the administrator migrates the user state from the store to the destination computer.
![usmt pc replace scenario.](images/dep-win8-l-usmt-pcreplace.jpg)

6
windows/deployment/usmt/usmt-configxml-file.md
View File

@ -13,8 +13,6 @@ ms.technology: itpro-deploy
# Config.xml File
## Config.xml File
The `Config.xml` file is an optional User State Migration Tool (USMT) 10.0 file that you can create using the `/genconfig` option with the ScanState tool. If you want to include all of the default components, and don't want to change the default store-creation or profile-migration behavior, you don't need to create a `Config.xml` file.
However, if you're satisfied with the default migration behavior defined in the `MigApp.xml`, `MigUser.xml` and `MigDocs.xml` files, but you want to exclude certain components, you can create and modify a `Config.xml` file and leave the other .xml files unchanged. For example, you must create and modify the `Config.xml` file if you want to exclude any of the operating-system settings that are migrated. It's necessary to create and modify this file if you want to change any of the default store-creation or profile-migration behavior.
@ -23,7 +21,7 @@ The `Config.xml` file has a different format than the other migration .xml files
For more information about using the `Config.xml` file with other migration files, such as the `MigDocs.xml` and `MigApps.xml` files, see [Understanding Migration XML Files](understanding-migration-xml-files.md).
> [!Note]
> [!NOTE]
> To exclude a component from the `Config.xml` file, set the **migrate** value to **no**. Deleting the XML tag for the component from the `Config.xml` file will not exclude the component from your migration.
## In this topic
@ -153,7 +151,7 @@ You use the **&lt;nonFatal&gt;** element to specify that errors matching a speci
## <a href="" id="bkmk-registryerror"></a> &lt;registryError&gt;
The <strong>&lt;registryError&gt;</strong> element isn't required.
The **&lt;registryError&gt;** element isn't required.
- **Number of occurrences**: Once for each component

16
windows/deployment/usmt/usmt-conflicts-and-precedence.md
View File

@ -193,17 +193,17 @@ When a collision is detected, USMT will select the most specific **&lt;merge&gt;
The source computer contains the following files:
- C:\\Data\\SampleA.txt
- `C:\Data\SampleA.txt`
- C:\\Data\\SampleB.txt
- `C:\Data\SampleB.txt`
- C:\\Data\\Folder\\SampleB.txt
- `C:\Data\Folder\SampleB.txt`
The destination computer contains the following files:
- C:\\Data\\SampleB.txt
- `C:\Data\SampleB.txt`
- C:\\Data\\Folder\\SampleB.txt
- `C:\Data\SampleB.txt`
You have a custom .xml file that contains the following code:
@ -217,7 +217,7 @@ You have a custom .xml file that contains the following code:
For this example, the following information describes the resulting behavior if you add the code to your custom .xml file.
**Example 1**
#### Example 1
```xml
<merge script="MigXmlHelper.DestinationPriority()">
@ -229,7 +229,7 @@ For this example, the following information describes the resulting behavior if
**Result**: During ScanState, all the files will be added to the store. During LoadState, only `C:\Data\SampleA.txt` will be restored.
**Example 2**
#### Example 2
```xml
<merge script="MigXmlHelper.SourcePriority()">
@ -242,7 +242,7 @@ For this example, the following information describes the resulting behavior if
**Result**: During ScanState, all the files will be added to the store.
During LoadState, all the files will be restored, overwriting the existing files on the destination computer.
**Example 3**
#### Example 3
```xml
<merge script="MigXmlHelper.SourcePriority()">

4
windows/deployment/usmt/usmt-custom-xml-examples.md
View File

@ -85,6 +85,7 @@ The following template is a template for the sections that you need to migrate y
</component>
</migration>
```
</details>
## <a href="" id="example2"></a> Example 2: Migrating the My Videos Folder
@ -132,6 +133,7 @@ The following sample is a custom .xml file named `CustomFile.xml` that migrates
</component>
</migration>
```
</details>
## <a href="" id="example3"></a> Example 3: Migrating Files and Registry Keys
@ -189,6 +191,7 @@ The sample patterns describe the behavior in the following example .xml file.
</component>
</migration>
```
</details>
## <a href="" id="example4"></a> Example 4: Migrating Specific Folders from Various Locations
@ -268,6 +271,7 @@ The behavior for this custom .xml file is described within the `<displayName>` t
</component>
</migration>
```
</details>
## Related articles

7
windows/deployment/usmt/usmt-customize-xml-files.md
View File

@ -51,7 +51,7 @@ For more information about excluding data, see the [Exclude Files and Settings](
This section describes the migration .xml files that are included with USMT. Each file contains migration rules that control which components are migrated and where they're migrated to on the destination computer.
> [!Note]
> [!NOTE]
> You can use the asterisk (\*) wildcard character in each of these files. However, you cannot use a question mark (?) as a wildcard character.
- **The MigApp.xml file.** Specify this file with both the `ScanState.exe` and `LoadState.exe` commands to migrate application settings.
@ -60,7 +60,7 @@ This section describes the migration .xml files that are included with USMT. Eac
- **The MigUser.xml file.** Specify this file with both the `ScanState.exe` and `LoadState.exe` commands to migrate user folders, files, and file types. You can modify the `MigUser.xml` file. This file doesn't contain rules that migrate specific user accounts. The only way to specify which user accounts to migrate is on the command line using the ScanState and the LoadState user options.
> [!Note]
> [!NOTE]
> Don't use the `MigUser.xml` and `MigDocs.xml` files together. For more information, see the [Identify File Types, Files, and Folders](usmt-identify-file-types-files-and-folders.md) and [USMT Best Practices](usmt-best-practices.md) articles.
## <a href="" id="bkmk-customxmlfiles"></a> Custom .xml Files
@ -85,7 +85,7 @@ In addition, note the following functionality with the `Config.xml` file:
- In USMT, there are several migration policies that can be configured in the `Config.xml` file. For example, you can configure additional **&lt;ErrorControl&gt;**, **&lt;ProfileControl&gt;**, and **&lt;HardLinkStoreControl&gt;** options. For more information, see the [Config.xml File](usmt-configxml-file.md) article.
> [!Note]
> [!NOTE]
> To exclude a component from the `Config.xml` file, set the **migrate** value to **"no"**. Deleting the XML tag for the component from the `Config.xml` file will not exclude the component from your migration.
### <a href="" id="bkmk-examples"></a> Examples
@ -104,7 +104,6 @@ In addition, note the following functionality with the `Config.xml` file:
## <a href="" id="bkmk-addlinfo"></a> Additional Information
- For more information about how to change the files and settings that are migrated, see the [User State Migration Tool (USMT) How-to topics](usmt-how-to.md).
- For more information about each .xml element, see the [XML Elements Library](usmt-xml-elements-library.md) article.