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

Metadata update deployment/usmt 4

Browse Source
This commit is contained in:
Frank Rojas
2022-11-01 21:09:40 -04:00
parent d602eaecfb
commit 6efaa1d806
15 changed files with 430 additions and 446 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@ -30,38 +30,38 @@ This article outlines the general process that you should follow to migrate file
3. Determine where to store data. Depending on the size of your migration store, you can store the data remotely, locally in a hard-link migration store or on a local external storage device, or directly on the destination computer. For more information, see [Choose a Migration Store Type](usmt-choose-migration-store-type.md).
4. Use the **/GenMigXML** command-line option to determine which files will be included in your migration, and to determine whether any modifications are necessary. For more information, see [ScanState Syntax](usmt-scanstate-syntax.md)
4. Use the `/GenMigXML` command-line option to determine which files will be included in your migration, and to determine whether any modifications are necessary. For more information, see [ScanState Syntax](usmt-scanstate-syntax.md)
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.
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]
> 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).
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).
6. Create a [Config.xml File](usmt-configxml-file.md) if you want to exclude any components from the migration. To create this file, use the [ScanState Syntax](usmt-scanstate-syntax.md) option together with the other .xml files when you use the **ScanState** command. For example, the following command creates a Config.xml file by using the MigDocs and MigApp.xml files:
6. Create a [Config.xml File](usmt-configxml-file.md) if you want to exclude any components from the migration. To create this file, use the [ScanState Syntax](usmt-scanstate-syntax.md) option together with the other .xml files when you use the `ScanState.exe` command. For example, the following command creates a `Config.xml` file by using the `MigDocs.xml` and `MigApp.xml` files:
`scanstate /genconfig:config.xml /i:migdocs.xml /i:migapp.xml /v:13 /l:scanstate.log`
`scanstate.exe /genconfig:config.xml /i:migdocs.xml /i:migapp.xml /v:13 /l:scanstate.log`
7. Review the migration state of the components listed in the Config.xml file, and specify `migrate=no` for any components that you don't want to migrate.
7. Review the migration state of the components listed in the `Config.xml` file, and specify `migrate=no` for any components that you don't want to migrate.
## Step 2: Collect files and settings from the source computer
1. Back up the source computer.
2. Close all applications. If some applications are running when you run the **ScanState** command, USMT might not migrate all of the specified data. For example, if Microsoft® Office Outlook® is open, USMT might not migrate PST files.
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]
> 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.
> 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** command on the source computer to collect files and settings. You should specify all of the .xml files that you want the **ScanState** command to use. For example,
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 \\server\migration\mystore /config:config.xml /i:migdocs.xml /i:migapp.xml /v:13 /l:scan.log`
`scanstate.exe \\server\migration\mystore /config:config.xml /i:migdocs.xml /i:migapp.xml /v:13 /l:scan.log`
> [!Note]
> If the source computer is running Windows 7, or Windows 8, you must run the **ScanState** command in **Administrator** mode. To run in **Administrator** mode, right-click **Command Prompt**, and then click **Run As Administrator**. If the source computer is running Windows XP, you must run the **ScanState** command from an account that has administrative credentials. For more information about the how the **ScanState** command processes and stores the data, see [How USMT Works](usmt-how-it-works.md).
> 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** command with the **/Verify** option to ensure that the store you created isn't corrupted.
4. Run the `USMTUtils.exe` command with the `/Verify` option to ensure that the store you created isn't corrupted.
## Step 3: Prepare the destination computer and restore files and settings
@ -72,18 +72,18 @@ This article outlines the general process that you should follow to migrate file
> [!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** command, USMT might not migrate all of the specified data. For example, if Microsoft Office Outlook is open, USMT might not migrate PST files.
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]
> Use **/C** to continue your migration if errors are encountered, and use the **&lt;ErrorControl&gt;** section in the Config.xml file to specify which errors should be ignored, and which errors should cause the migration to fail.
> 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** command on the destination computer. Specify the same set of .xml files that you specified when you used the **ScanState** 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** command. Then, the **LoadState** command will migrate only the files and settings that you want to migrate. For more information about how the **LoadState** command processes and migrates data, see [How USMT Works](usmt-how-it-works.md).
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).
For example, the following command migrates the files and settings:
`loadstate \\server\migration\mystore /config:config.xml /i:migdocs.xml /i:migapp.xml /v:13 /l:load.log`
`loadstate.exe \\server\migration\mystore /config:config.xml /i:migdocs.xml /i:migapp.xml /v:13 /l:load.log`
> [!Note]
> Run the **LoadState** command in administrator mode. To do this, right-click **Command Prompt**, and then click **Run As Administrator**.
> Run the `Loadstate.exe` command in administrator mode. To do this, right-click **Command Prompt**, and then click **Run As Administrator**.
5. Log off after you run the **LoadState** command. Some settings (for example, fonts, wallpaper, and screen saver settings) won't take effect until the next time that the user logs on.
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.

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

@ -15,7 +15,7 @@ ms.technology: itpro-deploy
You can create a custom .xml file to migrate specific line-of-business application settings or to change the default migration behavior of the User State Migration Tool (USMT) 10.0. For ScanState and LoadState to use this file, you must specify the custom .xml file on both command lines.
This article defines how to author a custom migration .xml file that migrates the settings of an application that isn't migrated by default using MigApp.xml. You should migrate the settings after you install the application, but before the user runs the application for the first time.
This article defines how to author a custom migration .xml file that migrates the settings of an application that isn't migrated by default using `MigApp.xml`. You should migrate the settings after you install the application, but before the user runs the application for the first time.
This article doesn't contain information about how to migrate applications that store settings in an application-specific store, only the applications that store the information in files or in the registry. It also doesn't contain information about how to migrate the data that users create using the application. For example, if the application creates .doc files using a specific template, this article doesn't discuss how to migrate the .doc files and templates themselves.
@ -45,13 +45,25 @@ There are many ways to detect if an application is installed. The best practice
### 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 **HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall**. For example, when Adobe Acrobat Reader 7 is installed, it creates a key named **HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall \\{AC76BA86-7AD7-1033-7B44-A70000000000}**. Therefore, if a computer contains this key, then Adobe Acrobat Reader 7 is installed on the computer. You can check for the existence of a registry key using the **DoesObjectExist** helper function.
When many applications are installed (especially those installed using the Microsoft® Windows® Installer technology), an application uninstall key is created under:
Usually, you can find this key by searching under **HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall** 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.
`HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall`
For example, when Adobe Acrobat Reader 7 is installed, it creates a key named:
`HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall \{AC76BA86-7AD7-1033-7B44-A70000000000}`
Therefore, if a computer contains this key, then Adobe Acrobat Reader 7 is installed on the computer. You can check for the existence of a registry key using the `DoesObjectExist` helper function.
Usually, you can find this key by searching under
`HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall`
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.
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.
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.
@ -68,7 +80,7 @@ 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]
> 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.
> 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**.
@ -79,7 +91,7 @@ Next, you should go through the user interface and make a list of all of the ava
## <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:
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.
@ -87,13 +99,13 @@ In this case, the newer version of the application may be able to read the setti
- **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](#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.
- [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.](#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.
### Case 2: The destination computer already contains settings for the application.
We recommend that you migrate the settings after you install the application, but before the user runs the application for the first time. We recommend this process because this process ensures that there are no settings on the destination computer when you migrate the settings. If you must install the application before the migration, you should delete any existing settings using the &lt;`destinationCleanup`&gt; element. If for any reason you want to preserve the settings that are on the destination computer, you can use the &lt;`merge`&gt; element and **DestinationPriority** helper function.
We recommend that you migrate the settings after you install the application, but before the user runs the application for the first time. We recommend this process because this process ensures that there are no settings on the destination computer when you migrate the settings. If you must install the application before the migration, you should delete any existing settings using the **&lt;destinationCleanup&gt;** element. If for any reason you want to preserve the settings that are on the destination computer, you can use the **&lt;merge&gt;** element and `DestinationPriority` helper function.
### Case 3: The application overwrites settings when it's installed.
@ -101,10 +113,10 @@ We recommend that you migrate the settings after you install the application, bu
## <a href="" id="bkmk-step4"></a>Step 4: Create the migration XML component for the application
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.
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]
> 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.
> 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]
> 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.
@ -113,17 +125,19 @@ Your script should do the following actions:
1. Check whether the application and correct version is installed by:
- Searching for the installation uninstall key under **HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall** using the **DoesObjectExist** helper function.
- Searching for the installation uninstall key under `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall` using the `DoesObjectExist` helper function.
- Checking for the correct version of the application executable file using the **DoesFileVersionMatch** helper function.
- Checking for the correct version of the application executable file using the `DoesFileVersionMatch` helper function.
2. If the correct version of the application is installed, then ensure that each setting is migrated to the appropriate location on the destination computer.
- If the versions of the applications are the same on both the source and destination computers, migrate each setting using the &lt;`include`&gt; and &lt;`exclude`&gt; elements.
- If the versions of the applications are the same on both the source and destination computers, migrate each setting using the **&lt;include&gt;** and **&lt;exclude&gt;** elements.
- If the version of the application on the destination computer is newer than the one on the source computer, and the application can't import the settings, your script should either 1) add the set of files that trigger the import using the &lt;`addObjects`&gt; element or 2) create a mapping that applies the old settings to the correct location on the destination computer using the &lt;`locationModify`&gt; element, and the **RelativeMove** and **ExactMove** helper functions.
- If the version of the application on the destination computer is newer than the one on the source computer, and the application can't import the settings, your script should either:
1. Add the set of files that trigger the import using the **&lt;addObjects&gt;** element
2. Create a mapping that applies the old settings to the correct location on the destination computer using the **&lt;locationModify&gt;** element, and the `RelativeMove` and `ExactMove` helper functions.
- If you must install the application before migrating the settings, delete any settings that are already on the destination computer using the &lt;`destinationCleanup`&gt; element.
- If you must install the application before migrating the settings, delete any settings that are already on the destination computer using the **&lt;destinationCleanup&gt;** element.
For information about the .xml elements and helper functions, see [XML Elements Library](usmt-xml-elements-library.md).
@ -131,7 +145,7 @@ For information about the .xml elements and helper functions, see [XML Elements
On a test computer, install the operating system that will be installed on the destination computers. For example, if you're planning on migrating from Windows 7 to Windows 10, install Windows 10 and the application. Next, run LoadState on the test computer and verify that all settings migrate. Make corrections if necessary and repeat the process until all the necessary settings are migrated correctly.
To speed up the time it takes to collect and migrate the data, you can migrate only one user at a time, and you can exclude all other components from the migration except the application that you're testing. To specify only User1 in the migration, type: **/ue:\*\\\* /ui:user1**. For more information, see [Exclude Files and Settings](usmt-exclude-files-and-settings.md) and User options in the [ScanState Syntax](usmt-scanstate-syntax.md) article. To troubleshoot a problem, check the progress log, and the ScanState and LoadState logs, which contain warnings and errors that may point to problems with the migration.
To speed up the time it takes to collect and migrate the data, you can migrate only one user at a time, and you can exclude all other components from the migration except the application that you're testing. To specify only User1 in the migration, type: `/ue:*\* /ui:user1`. For more information, see [Exclude Files and Settings](usmt-exclude-files-and-settings.md) and User options in the [ScanState Syntax](usmt-scanstate-syntax.md) article. To troubleshoot a problem, check the progress log, and the ScanState and LoadState logs, which contain warnings and errors that may point to problems with the migration.
## Related articles

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

@ -39,7 +39,7 @@ The compressed migration store is a single image file that contains all files be
A hard-link migration store functions as a map that defines how a collection of bits on the hard disk are "wired" into the file system. You use the new USMT hard-link migration store in the PC Refresh scenario only. You only use hard-link migration stores in Refresh scenarios because the hard-link migration store is maintained on the local computer while the old operating system is removed and the new operating system is installed. Using a hard-link migration store saves network bandwidth and minimizes the server use needed to accomplish the migration.
You use a command-line option,**/hardlink** , to create a hard-link migration store, which functions the same as an uncompressed migration store. Files aren't duplicated on the local computer when user state is captured, nor are they duplicated when user state is restored. For more information, see [Hard-Link Migration Store](usmt-hard-link-migration-store.md).
You use the command-line option `/hardlink` to create a hard-link migration store, which functions the same as an uncompressed migration store. Files aren't duplicated on the local computer when user state is captured, nor are they duplicated when user state is restored. For more information, see [Hard-Link Migration Store](usmt-hard-link-migration-store.md).
The following flowchart illustrates the procedural differences between a local migration store and a remote migration store. In this example, a hard-link migration store is used for the local store.
@ -49,14 +49,14 @@ The following flowchart illustrates the procedural differences between a local m
If you have enough space and you're migrating the user state back to the same computer, storing data on a local device is normally the best option to reduce server storage costs and network performance issues. You can store the data locally either on a different partition or on a removable device such as a USB flash drive (UFD). Also, depending on the imaging technology that you're using, you might be able to store the data on the partition that is being re-imaged, if the data will be protected from deletion during the process. To increase performance, store the data on high-speed drives that use a high-speed network connection. It's also good practice to ensure that the migration is the only task the server is performing.
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 command on the source computer and save the files and settings to \\\\*DestinationComputerName*\\store. Then, run the **LoadState** 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.
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]
> 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.
> 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
You should use this option to exclude the data from removable drives and network drives mapped on the source computer. For more information about what is excluded when you specify **/LocalOnly**, see [ScanState Syntax](usmt-scanstate-syntax.md).
You should use this option to exclude the data from removable drives and network drives mapped on the source computer. For more information about what is excluded when you specify `/LocalOnly`, see [ScanState Syntax](usmt-scanstate-syntax.md).
## Related articles

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

@ -15,15 +15,15 @@ ms.technology: itpro-deploy
Offline migration enables the ScanState tool to run inside a different Windows&reg; operating system than the Windows operating system from which ScanState is gathering files and settings. There are two primary offline scenarios:
- **Windows PE.** The ScanState tool can be run from within Windows PE, gathering files and settings from the offline Windows operating system on that machine.
- **Windows PE.** The ScanState tool can be run from within Windows PE, gathering files and settings from the offline Windows operating system on that machine.
- **Windows.old.** The ScanState tool can now gather files and settings from the Windows.old directory that is created during Windows installation on a partition that contains a previous installation of Windows. For example, the ScanState tool can run in Windows 10, gathering files from a previous Windows 7or Windows 8 installation contained in the Windows.old directory.
- **Windows.old.** The ScanState tool can now gather files and settings from the Windows.old directory that is created during Windows installation on a partition that contains a previous installation of Windows. For example, the ScanState tool can run in Windows 10, gathering files from a previous Windows 7or Windows 8 installation contained in the Windows.old directory.
When you use User State Migration Tool (USMT) 10.0 to gather and restore user state, offline migration reduces the cost of deployment by:
When you use User State Migration Tool (USMT) 10.0 to gather and restore user state, offline migration reduces the cost of deployment by:
- **Reducing complexity.** In computer-refresh scenarios, migrations from the Windows.old directory reduce complexity by eliminating the need for the ScanState tool to be run before the operating system is deployed. Also, migrations from the Windows.old directory enable ScanState and LoadState to be run successively.
- **Improving performance.** When USMT runs in an offline Windows Preinstallation Environment (WinPE) environment, it has better access to the hardware resources. This may increase performance on older machines with limited hardware resources and numerous installed software applications.
- **Improving performance.** When USMT runs in an offline Windows Preinstallation Environment (WinPE) environment, it has better access to the hardware resources. Running USMT in WinPE may increase performance on older machines with limited hardware resources and numerous installed software applications.
- **New recovery scenario.** In scenarios where a machine no longer restarts properly, it might be possible to gather user state with the ScanState tool from within WinPE.
@ -65,15 +65,15 @@ The following table defines the supported combination of online and offline oper
|Running Operating System|Offline Operating System|
|--- |--- |
|WinPE 5.0 or greater, with the MSXML library|Windows Vista, Windows 7, Windows 8, Windows 10|
|Windows 7, Windows 8, Windows 10|Windows.old directory|
|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**  
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)).
> [!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
User-group membership is not preserved during offline migrations. You must configure a **&lt;ProfileControl&gt;** section in the Config.xml file to specify the groups that the migrated users should be made members of. The following example places all migrated users into the Users group:
User-group membership isn't preserved during offline migrations. You must configure a **&lt;ProfileControl&gt;** section in the `Config.xml` file to specify the groups that the migrated users should be made members of. The following example places all migrated users into the Users group:
``` xml
<Configuration>
@ -91,7 +91,7 @@ User-group membership is not preserved during offline migrations. You must confi
</Configuration>
```
For information about the format of a Config.xml file, see [Config.xml File](usmt-configxml-file.md).
For information about the format of a `Config.xml` file, see [Config.xml File](usmt-configxml-file.md).
## <a href="" id="bkmk-commandlineoptions"></a>Command-Line Options
@ -100,10 +100,10 @@ An offline migration can either be enabled by using a configuration file on the
|Component|Option|Description|
|--- |--- |--- |
|ScanState.exe|**/offline:***&lt;path to offline.xml&gt;*|This command-line option enables the offline-migration mode and requires a path to an Offline.xml configuration file.|
|ScanState.exe|**/offlineWinDir:***&lt;Windows directory&gt;*|This command-line option enables the offline-migration mode and starts the migration from the location specified. It is only for use in WinPE offline scenarios where the migration is occurring from a Windows directory.|
|ScanState.exe|**/OfflineWinOld:***&lt;Windows.old directory&gt;*|This command-line option enables the offline migration mode and starts the migration from the location specified. It is only intended to be used in Windows.old migration scenarios, where the migration is occurring from a Windows.old directory.|
|ScanState.exe|**/offlineWinDir:***&lt;Windows directory&gt;*|This command-line option enables the offline-migration mode and starts the migration from the location specified. It's only for use in WinPE offline scenarios where the migration is occurring from a Windows directory.|
|ScanState.exe|**/OfflineWinOld:***&lt;Windows.old directory&gt;*|This command-line option enables the offline migration mode and starts the migration from the location specified. It's only intended to be used in Windows.old migration scenarios, where the migration is occurring from a Windows.old directory.|
You can use only one of the **/offline**, **/offlineWinDir**, or **/OfflineWinOld** command-line options at a time; USMT does not support using more than one together.
You can use only one of the `/offline`, `/offlineWinDir`, or `/OfflineWinOld` command-line options at a time. USMT doesn't support using more than one together.
## <a href="" id="bkmk-environmentvariables"></a>Environment Variables
@ -111,50 +111,54 @@ The following system environment variables are necessary in the scenarios outlin
|Variable|Value|Scenario|
|--- |--- |--- |
|USMT_WORKING_DIR|Full path to a working directory|Required when USMT binaries are located on read-only media, which does not support the creation of log files or temporary storage. To set the system environment variable, at a command prompt type the following: <br/><pre class="syntax"><code>Set USMT_WORKING_DIR=[path to working directory]</code></pre>|
|MIG_OFFLINE_PLATFORM_ARCH|32 or 64|While operating offline, this environment variable defines the architecture of the offline system, if the system does not match the WinPE and Scanstate.exe architecture. This environment variable enables the 32-bit ScanState application to gather data from a computer with 64-bit architecture, or the 64-bit ScanState application to gather data from a computer with 32-bit architecture. This is required when auto-detection of the offline architecture doesn't function properly, for example, when the source system is running a 64-bit version of Windows XP. For example, to set this system environment variable for a 32-bit architecture, at a command prompt type the following: <br/><pre class="syntax"><code>Set MIG_OFFLINE_PLATFORM_ARCH=32</code></pre>|
|USMT_WORKING_DIR|Full path to a working directory|Required when USMT binaries are located on read-only media, which doesn't support the creation of log files or temporary storage. To set the system environment variable, at a command prompt type the following command: <br/><pre class="syntax"><code>Set USMT_WORKING_DIR=[path to working directory]</code></pre>|
|MIG_OFFLINE_PLATFORM_ARCH|32 or 64|While operating offline, this environment variable defines the architecture of the offline system, if the system doesn't match the WinPE and `Scanstate.exe` architecture. This environment variable enables the 32-bit ScanState application to gather data from a computer with 64-bit architecture, or the 64-bit ScanState application to gather data from a computer with 32-bit architecture. Specifying the architecture is required when auto-detection of the offline architecture doesn't function properly. For example, to set this system environment variable for a 32-bit architecture, at a command prompt type the following command: <br/><pre class="syntax"><code>Set MIG_OFFLINE_PLATFORM_ARCH=32</code></pre>|
## <a href="" id="bkmk-offlinexml"></a>Offline.xml Elements
Use an offline.xml file when running the ScanState tool on a computer that has multiple Windows directories. The offline.xml file specifies which directories to scan for windows files. An offline.xml file can be used with the /offline option as an alternative to specifying a single Windows directory path with the /offlineDir option.
Use an `offline.xml` file when running the ScanState tool on a computer that has multiple Windows directories. The `offline.xml` file specifies which directories to scan for windows files. An `offline.xml` file can be used with the `/offline` option as an alternative to specifying a single Windows directory path with the `/offlineDir` option.
### <a href="" id="-offline-"></a>&lt;offline&gt;
This element contains other elements that define how an offline migration is to be performed.
Syntax: &lt;offline&gt; &lt;/offline&gt;
Syntax: `<offline>` `</offline>`
### <a href="" id="-windir-"></a>&lt;winDir&gt;
This element is a required child of **&lt;offline&gt;** and contains information about how the offline volume can be selected. The migration will be performed from the first element of **&lt;winDir&gt;** that contains a valid Windows system volume.
Syntax: &lt; winDir &gt; &lt;/ winDir &gt;
Syntax: `<winDir>` `</winDir>`
### <a href="" id="-path-"></a>&lt;path&gt;
This element is a required child of **&lt;winDir&gt;** and contains a file path pointing to a valid Windows directory. Relative paths are interpreted from the ScanState tool's working directory.
Syntax: &lt;path&gt; c:\\windows &lt;/path&gt;
Syntax: `<path> C:\Windows </path>`
-or-
Syntax, when used with the **&lt;mappings&gt;** element: &lt;path&gt; C:\\, D:\\ &lt;/path&gt;
Syntax, when used with the **&lt;mappings&gt;** element: `<path> C:\, D:\ </path>`
### <a href="" id="-mappings-"></a>&lt;mappings&gt;
This element is an optional child of **&lt;offline&gt;**. When specified, the **&lt;mappings&gt;** element will override the automatically detected WinPE drive mappings. Each child **&lt;path&gt;** element will provide a mapping from one system volume to another. Additionally, mappings between folders can be provided, since an entire volume can be mounted to a specific folder.
Syntax: &lt;mappings&gt; &lt;/mappings&gt;
Syntax: `<mappings>` `</mappings>`
### <a href="" id="-failonmultiplewindir-"></a>&lt;failOnMultipleWinDir&gt;
This element is an optional child of **&lt;offline&gt;**. The **&lt;failOnMultipleWinDir&gt;** element allows the user to specify that the migration should fail when USMT detects that there are multiple instances of Windows installed on the source machine. When the **&lt;failOnMultipleWinDir&gt;** element isn't present, the default behavior is that the migration does not fail.
This element is an optional child of **&lt;offline&gt;**. The **&lt;failOnMultipleWinDir&gt;** element allows the user to specify that the migration should fail when USMT detects that there are multiple instances of Windows installed on the source machine. When the **&lt;failOnMultipleWinDir&gt;** element isn't present, the default behavior is that the migration doesn't fail.
Syntax: &lt;failOnMultipleWinDir&gt;1&lt;/failOnMultipleWinDir&gt; or Syntax: &lt;failOnMultipleWinDir&gt;0&lt;/failOnMultipleWinDir&gt;
Syntax: `<failOnMultipleWinDir>1</failOnMultipleWinDir>`
-or-
Syntax: `<failOnMultipleWinDir>0</failOnMultipleWinDir>`
### Offline .xml Example
The following XML example illustrates some of the elements discussed earlier in this topic.
The following XML example illustrates some of the elements discussed earlier in this article.
``` xml
<offline>
@ -167,6 +171,6 @@ The following XML example illustrates some of the elements discussed earlier in
</offline>
```
## Related topics
## Related articles
[Plan Your Migration](usmt-plan-your-migration.md)

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

@ -13,9 +13,9 @@ ms.technology: itpro-deploy
# Understanding Migration XML Files
You can modify the behavior of a basic User State Migration Tool (USMT) 10.0 migration by using XML files; these files provide instructions on where and how the USMT tools should gather and apply files and settings. USMT includes three XML files that you can use to customize a basic migration: the MigDocs.xml and MigUser.xml files, which modify how files are discovered on the source computer, and the MigApps.xml file, which is required in order to migrate supported application settings. You can also create and edit custom XML files and a Config.xml file to further customize your migration.
You can modify the behavior of a basic User State Migration Tool (USMT) 10.0 migration by using XML files; these files provide instructions on where and how the USMT tools should gather and apply files and settings. USMT includes three XML files that you can use to customize a basic migration: the `MigDocs.xml` and `MigUser.xml` files, which modify how files are discovered on the source computer, and the MigApps.xml file, which is required in order to migrate supported application settings. You can also create and edit custom XML files and a `Config.xml` file to further customize your migration.
This topic provides an overview of the default and custom migration XML files and includes guidelines for creating and editing a customized version of the MigDocs.xml file. The MigDocs.xml file uses the new **GenerateDocPatterns** function available in USMT to automatically find user documents on a source computer.
This article provides an overview of the default and custom migration XML files and includes guidelines for creating and editing a customized version of the `MigDocs.xml` file. The `MigDocs.xml` file uses the new `GenerateDocPatterns` function available in USMT to automatically find user documents on a source computer.
## In this topic
@ -45,23 +45,27 @@ This topic provides an overview of the default and custom migration XML files an
## <a href="" id="bkmk-config"></a>Overview of the Config.xml file
The Config.xml file is the configuration file created by the `/genconfig` option of the ScanState tool; it can be used to modify which operating-system components are migrated by USMT. The Config.xml file can be used with other XML files, such as in the following example: `scanstate /i:migapps.xml /i:migdocs.xml /genconfig:c:\myFolder\config.xml`. When used this way, the Config.xml file tightly controls aspects of the migration, including user profiles, data, and settings, without modifying or creating other XML files. For more information about the Config.xml file, see [Customize USMT XML Files](usmt-customize-xml-files.md) and [Config.xml File](usmt-configxml-file.md).
The `Config.xml` file is the configuration file created by the `/genconfig` option of the ScanState tool; it can be used to modify which operating-system components are migrated by USMT. The `Config.xml` file can be used with other XML files, such as in the following example:
`scanstate.exe /i:migapps.xml /i:migdocs.xml /genconfig:c:\myFolder\Config.xml`
When used this way, the `Config.xml` file tightly controls aspects of the migration, including user profiles, data, and settings, without modifying or creating other XML files. For more information about the `Config.xml` file, see [Customize USMT XML Files](usmt-customize-xml-files.md) and [Config.xml File](usmt-configxml-file.md).
> [!NOTE]
> When modifying the XML elements in the Config.xml file, you should edit an element and set the **migrate** property to **no**, rather than deleting the element from the file. If you delete the element instead of setting the property, the component may still be migrated by rules in other XML files.
> When modifying the XML elements in the `Config.xml` file, you should edit an element and set the **migrate** property to **no**, rather than deleting the element from the file. If you delete the element instead of setting the property, the component may still be migrated by rules in other XML files.
## <a href="" id="bkmk-migapp"></a>Overview of the MigApp.xml file
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 do not 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).
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]
> 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
The MigDocs.xml file uses the new **GenerateDocPatterns** helper function to create instructions for USMT to migrate files from the source computer, based on the location of the files. You can use the MigDocs.xml file with the ScanState and LoadState tools to perform a more targeted migration than using USMT without XML instructions.
The `MigDocs.xml` file uses the new `GenerateDocPatterns` helper function to create instructions for USMT to migrate files from the source computer, based on the location of the files. You can use the `MigDocs.xml` file with the ScanState and LoadState tools to perform a more targeted migration than using USMT without XML instructions.
The default MigDocs.xml file migrates the following:
The default `MigDocs.xml` file migrates the following data:
- All files on the root of the drive except %WINDIR%, %PROGRAMFILES%, %PROGRAMDATA%, or %USERS%.
@ -115,7 +119,7 @@ The default MigDocs.xml file migrates the following:
- FOLDERID\_RecordedTV
The default MigDocs.xml file will not migrate the following:
The default `MigDocs.xml` file won't migrate the following data:
- Files tagged with both the **hidden** and **system** attributes.
@ -125,13 +129,13 @@ The default MigDocs.xml file will not migrate the following:
- Folders that contain installed applications.
You can also use the **/genmigxml** option with the ScanState tool to review and modify what files will be migrated.
You can also use the `/genmigxml` option with the ScanState tool to review and modify what files will be migrated.
## <a href="" id="bkmk-miguser"></a>Overview of the MigUser.xml file
The MigUser.xml file includes instructions for USMT to migrate user files based on file name extensions. You can use the MigUser.xml file with the ScanState and LoadState tools to perform a more targeted migration than using USMT without XML instructions. The MigUser.xml file will gather all files from the standard user-profile folders, and any files on the computer with the specified file name extensions.
The `MigUser.xml` file includes instructions for USMT to migrate user files based on file name extensions. You can use the `MigUser.xml` file with the ScanState and LoadState tools to perform a more targeted migration than using USMT without XML instructions. The `MigUser.xml` file will gather all files from the standard user-profile folders, and any files on the computer with the specified file name extensions.
The default MigUser.xml file migrates the following:
The default `MigUser.xml` file migrates the following data:
- All files from the standard user-profile folders, which are described as:
@ -153,9 +157,9 @@ The default MigUser.xml file migrates the following:
- Files with the following extensions:
`.qdf`, `.qsd`, `.qel`, `.qph`, `.doc\*`, `.dot\*`, `.rtf`, `.mcw`, `.wps`, `.scd`, `.wri`, `.wpd`, `.xl\*`, `.csv`, `.iqy`, `.dqy`, `.oqy`, `.rqy`, `.wk\*`, `.wq1`, `.slk`, `.dif`, `.ppt\*`, `.pps\*`, `.pot\*`, `.sh3`, `.ch3`, `.pre`, `.ppa`, `.txt`, `.pst`, `.one\*`, `.vl\*`, `.vsd`, `.mpp`, `.or6`, `.accdb`, `.mdb`, `.pub`
`.qdf`, `.qsd`, `.qel`, `.qph`, `.doc*`, `.dot*`, `.rtf`, `.mcw`, `.wps`, `.scd`, `.wri`, `.wpd`, `.xl*`, `.csv`, `.iqy`, `.dqy`, `.oqy`, `.rqy`, `.wk*`, `.wq1`, `.slk`, `.dif`, `.ppt*`, `.pps*`, `.pot*`, `.sh3`, `.ch3`, `.pre`, `.ppa`, `.txt`, `.pst`, `.one*`, `.vl*`, `.vsd`, `.mpp`, `.or6`, `.accdb`, `.mdb`, `.pub`
The default MigUser.xml file does not migrate the following:
The default `MigUser.xml` file doesn't migrate the following data:
- Files tagged with both the **hidden** and **system** attributes.
@ -165,10 +169,10 @@ The default MigUser.xml file does not migrate the following:
- ACLS for files in folders outside the user profile.
You can make a copy of the MigUser.xml file and modify it to include or exclude standard user-profile folders and file name extensions. If you know all of the extensions for the files you want to migrate from the source computer, use the MigUser.xml file to move all of your relevant data, regardless of the location of the files. However, this provision may result in a migration that contains more files than intended. For example, if you choose to migrate all .jpg files, you may migrate image files such as thumbnails and logos from legacy applications that are installed on the source computer.
You can make a copy of the `MigUser.xml` file and modify it to include or exclude standard user-profile folders and file name extensions. If you know all of the extensions for the files you want to migrate from the source computer, use the `MigUser.xml` file to move all of your relevant data, regardless of the location of the files. However, this provision may result in a migration that contains more files than intended. For example, if you choose to migrate all .jpg files, you may migrate image files such as thumbnails and logos from legacy applications that are installed on the source computer.
> [!NOTE]
> Each file name extension you include in the rules within the MigUser.xml file increases the amount of time needed for the ScanState tool to gather the files for the migration. If you are migrating more than 300 file types, you may experience a slow migration. For more information about other ways to organize the migration of your data, see the [Using multiple XML files](#bkmk-multiple) section of this document.
> Each file name extension you include in the rules within the `MigUser.xml` file increases the amount of time needed for the ScanState tool to gather the files for the migration. If you are migrating more than 300 file types, you may experience a slow migration. For more information about other ways to organize the migration of your data, see the [Using multiple XML files](#bkmk-multiple) section of this document.
## <a href="" id="bkmk-multiple"></a>Using multiple XML files
@ -178,45 +182,47 @@ You can use multiple XML files with the ScanState and LoadState tools. Each of t
|--- |--- |
|Config.xml file|Operating-system components such as desktop wallpaper and background theme. <br/>You can also overload config.xml to include some application and document settings by generating the config.xml file with the other default XML files. For more information, see [Customize USMT XML Files](usmt-customize-xml-files.md) and [Config.xml File](usmt-configxml-file.md).|
|MigApps.xml file|Applications settings.|
|MigUser.xml or MigDocs.xml files|User files and profile settings.|
|MigUser.xml or `MigDocs.xml` files|User files and profile settings.|
|Custom XML files|Application settings, user profile settings, or user files, beyond the rules contained in the other XML files.|
For example, you can use all of the XML migration file types for a single migration, as in the following example:
```console
Scanstate <store> /config:c:\myFolder\config.xml /i:migapps.xml /i:migdocs.xml /i:customrules.xml
Scanstate.exe <store> /config:c:\myFolder\config.xml /i:migapps.xml /i:migdocs.xml /i:customrules.xml
```
### <a href="" id="bkmk-userfiles"></a>XML rules for migrating user files
> [!IMPORTANT]
> You should not use the MigUser.xml and MigDocs.xml files together in the same command. Using both XML files can result in duplication of some migrated files. This occurs when conflicting target-location instructions are given in each XML file. The target file will be stored once during the migration, but will be applied by each XML file to a different location on the destination computer.
> You should not use the `MigUser.xml` and `MigDocs.xml` files together in the same command. Using both XML files can result in duplication of some migrated files. This occurs when conflicting target-location instructions are given in each XML file. The target file will be stored once during the migration, but will be applied by each XML file to a different location on the destination computer.
If your data set is unknown or if many files are stored outside of the standard user-profile folders, the MigDocs.xml is a better choice than the MigUser.xml file, because the MigDocs.xml file will gather a broader scope of data. The MigDocs.xml file migrates folders of data based on location. The MigUser.xml file migrates only the files with the specified file name extensions.
If your data set is unknown or if many files are stored outside of the standard user-profile folders, the `MigDocs.xml` is a better choice than the `MigUser.xml` file, because the `MigDocs.xml` file will gather a broader scope of data. The `MigDocs.xml` file migrates folders of data based on location. The `MigUser.xml` file migrates only the files with the specified file name extensions.
If you want more control over the migration, you can create custom XML files. See the [Creating and editing a custom ,xml file](#bkmk-createxml) section of this document.
## <a href="" id="bkmk-createxml"></a>Creating and editing a custom XML file
You can use the **/genmigxml** command-line option to determine which files will be included in your migration. The **/genmigxml** option creates a file in a location you specify, so that you can review the XML rules and make modifications as necessary.
You can use the `/genmigxml` command-line option to determine which files will be included in your migration. The `/genmigxml` option creates a file in a location you specify, so that you can review the XML rules and make modifications as necessary.
> [!NOTE]
> If you reinstall USMT, the default migration XML files will be overwritten and any customizations you make directly to these files will be lost. Consider creating separate XML files for your custom migration rules and saving them in a secure location.
To generate the XML migration rules file for a source computer:
1. Click **Start**, click **All Programs**, click **Accessories**, right-click **Command Prompt**, and then click **Run as**.
1. Select **Start** > **All Programs** > **Accessories**
2. Select an account with administrator privileges, supply a password, and then click **OK**.
2. Right-click **Command Prompt**, and then select **Run as**.
3. At the command prompt, type:
3. Select an account with administrator privileges, supply a password, and then select **OK**.
4. At the command prompt, type:
```console
cd /d <USMTpath>
scanstate.exe /genmigxml: <filepath.xml>
```
Where *&lt;USMTpath&gt;* is the location on your source computer where you have saved the USMT files and tools, and *&lt;filepath.xml&gt;* is the full path to a file where you can save the report. For example, type:
Where *&lt;USMTpath&gt;* is the location on your source computer where you've saved the USMT files and tools, and *&lt;filepath.xml&gt;* is the full path to a file where you can save the report. For example, type:
```console
cd /d c:\USMT
@ -225,19 +231,19 @@ To generate the XML migration rules file for a source computer:
### <a href="" id="bkmk-generate"></a>The GenerateDocPatterns function
The MigDocs.xml file calls the **GenerateDocPatterns** function, which takes three Boolean values. You can change the settings to modify the way the MigDocs.xml file generates the XML rules for migration.
The `MigDocs.xml` file calls the `GenerateDocPatterns` function, which takes three Boolean values. You can change the settings to modify the way the `MigDocs.xml` file generates the XML rules for migration.
- `ScanProgramFiles`: This argument is valid only when the **GenerateDocPatterns** function is called in a system context. This argument determines whether or not to scan the Program Files directory to gather registered file name extensions for known applications.
- `ScanProgramFiles`: This argument is valid only when the `GenerateDocPatterns` function is called in a system context. This argument determines whether or not to scan the Program Files directory to gather registered file name extensions for known applications.
**Default value**: False
For example, when set to **TRUE**, the function discovers and migrates .doc files under the Microsoft Office directory, because .doc is a file name extension registered to a Microsoft Office application. The **GenerateDocPatterns** function generates this inclusion pattern for `.doc` files:
For example, when set to **TRUE**, the function discovers and migrates .doc files under the Microsoft Office directory, because .doc is a file name extension registered to a Microsoft Office application. The `GenerateDocPatterns` function generates this inclusion pattern for `.doc` files:
`<pattern type="File">C:\Program Files\Microsoft Office[.doc]</pattern>`
If a child folder of an included folder contains an installed application, ScanProgramFiles will also create an exclusion rule for the child folder. All folders under the application folder will be scanned recursively for registered file name extensions.
- `IncludePatterns`: This argument determines whether to generate exclude or include patterns in the XML. When this argument is set to **TRUE**, the **GenerateDocPatterns** function generates include patterns and the function must be added under the `<include>` element. Changing this argument to **FALSE** generates exclude patterns and the function must be added under the `<exclude>` element.
- `IncludePatterns`: This argument determines whether to generate exclude or include patterns in the XML. When this argument is set to **TRUE**, the `GenerateDocPatterns` function generates include patterns, and the function must be added under the `<include>` element. Changing this argument to **FALSE** generates exclude patterns and the function must be added under the `<exclude>` element.
**Default value**: True
@ -283,11 +289,11 @@ To create exclude data patterns:
### <a href="" id="bkmk-context"></a>Understanding the system and user context
The migration XML files contain two &lt;component&gt; elements with different **context** settings. The system context applies to files on the computer that are not stored in the User Profiles directory, while the user context applies to files that are particular to an individual user.
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**
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:
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:
- CSIDL\_COMMON\_DESKTOPDIRECTORY
@ -305,7 +311,7 @@ The system context includes rules for data outside of the User Profiles director
**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:
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:
- CSIDL\_MYDOCUMENTS
@ -334,7 +340,7 @@ The user context includes rules for data in the User Profiles directory. When ca
- FOLDERID\_RecordedTV
> [!NOTE]
> Rules contained in a component that is assigned the user context will be run for each user profile on the computer. Files that are scanned multiple times by the MigDocs.xml files will only be copied to the migration store once; however, a large number of rules in the user context can slow down the migration. Use the system context when it is applicable.
> Rules contained in a component that is assigned the user context will be run for each user profile on the computer. Files that are scanned multiple times by the `MigDocs.xml` files will only be copied to the migration store once; however, a large number of rules in the user context can slow down the migration. Use the system context when it is applicable.
### <a href="" id="bkmk-samples"></a>Sample migration rules for customized versions of XML files
@ -343,14 +349,14 @@ The user context includes rules for data in the User Profiles directory. When ca
### <a href="" id="bkmk-exclude"></a>Exclude rules usage examples
In the examples below, the source computer has a .txt file called "new text document" in a directory called "new folder". The default MigDocs.xml behavior migrates the new text document.txt file and all files contained in the "new folder" directory. The rules generated by the function are:
In the examples below, the source computer has a .txt file called "new text document" in a directory called "new folder". The default `MigDocs.xml` behavior migrates the new text document.txt file and all files contained in the "new folder" directory. The rules generated by the function are:
| Rule | Syntax |
|--- |--- |
|Rule 1|`<pattern type="File">d:\new folder[new text document.txt]</pattern>`|
|Rule 2|`<pattern type="File">d:\new folder[]</pattern>`|
To exclude the new text document.txt file and any .txt files in "new folder", you can do the following:
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**
@ -367,7 +373,7 @@ To exclude Rule 1, there needs to be an exact match of the file name. However, f
**Example 2: Use the UnconditionalExclude element to give a rule precedence over include rules**
If you do not 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).
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).
``` xml
<unconditionalExclude>
@ -400,11 +406,11 @@ For more examples of exclude rules that you can use in custom migration XML file
### <a href="" id="bkmk-include"></a>Include rules usage examples
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 are not linked, you can do the following:
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**
This rule will include .pst files that are located in the default location, but are not linked to Microsoft Outlook. Use the user context to run this rule for each user on the computer.
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.
``` xml
<include filter='MigXmlHelper.IgnoreIrrelevantLinks()'>
@ -433,11 +439,11 @@ For more examples of include rules that you can use in custom migration XML file
## <a href="" id="bkmk-next"></a>Next steps
You can include additional rules for the migration in the MigDocs.xml file or other XML migration files. For example, you can use the `<locationModify>` element to move files from the folder where they were gathered to a different folder, when they are applied to the destination computer.
You can include additional rules for the migration in the `MigDocs.xml` file or other XML migration files. For example, you can use the `<locationModify>` element to move files from the folder where they were gathered to a different folder, when they're applied to the destination computer.
You can use an XML schema (MigXML.xsd) file to validate the syntax of your customized XML files. For more information, see [USMT Resources](usmt-resources.md).
## Related topics
## Related articles
[Exclude Files and Settings](usmt-exclude-files-and-settings.md)

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

@ -1,6 +1,6 @@
---
title: USMT Best Practices (Windows 10)
description: This article discusses general and security-related best practices when using User State Migration Tool (USMT) 10.0.
description: This article discusses general and security-related best practices when using User State Migration Tool (USMT) 10.0.
ms.custom: seo-marvel-apr2020
ms.reviewer:
manager: aaroncz
@ -14,61 +14,56 @@ ms.technology: itpro-deploy
# USMT Best Practices
This topic discusses general and security-related best practices when using User State Migration Tool (USMT) 10.0.
This article discusses general and security-related best practices when using User State Migration Tool (USMT) 10.0.
## General Best Practices
- **Install applications before running the LoadState tool**
Though it is not always essential, it is best practice to install all applications on the destination computer before restoring the user state. This helps ensure that migrated settings are preserved.
Though it isn't always essential, it's best practice to install all applications on the destination computer before restoring the user state. Installing applications before restoring user state helps ensure that migrated settings are preserved.
- **Do not use MigUser.xml and MigDocs.xml together**
- **Don't use MigUser.xml and MigDocs.xml together**
If you use both .xml files, some migrated files may be duplicated if conflicting instructions are given about target locations. You can use the **/genmigxml** command-line option to determine which files will be included in your migration, and to determine if any modifications are necessary. For more information, see [Identify File Types, Files, and Folders](usmt-identify-file-types-files-and-folders.md).
If you use both .xml files, some migrated files may be duplicated if conflicting instructions are given about target locations. You can use the `/genmigxml` command-line option to determine which files will be included in your migration, and to determine if any modifications are necessary. For more information, see [Identify File Types, Files, and Folders](usmt-identify-file-types-files-and-folders.md).
- **Use MigDocs.xml for a better migration experience**
If your data set is unknown or if many files are stored outside of the standard user-profile folders, the MigDocs.xml file is a better choice than the MigUser.xml file, because the MigDocs.xml file will gather a broader scope of data. The MigDocs.xml file migrates folders of data based on location, and on registered file type by querying the registry for registered application extensions. The MigUser.xml file migrates only the files with the specified file extensions.
If your data set is unknown or if many files are stored outside of the standard user-profile folders, the `MigDocs.xml` file is a better choice than the `MigUser.xml` file, because the `MigDocs.xml` file will gather a broader scope of data. The `MigDocs.xml` file migrates folders of data based on location, and on registered file type by querying the registry for registered application extensions. The `MigUser.xml` file migrates only the files with the specified file extensions.
- **Close all applications before running either the ScanState or LoadState tools**
Although using the **/vsc** switch can allow the migration of many files that are open with another application it is a best practice to close all applications in order to ensure all files and settings migrate. Without the **/vsc** or **/c** switch USMT will fail when it cannot migrate a file or setting. When you use the **/c** option USMT will ignore any files or settings that it cannot migrate and log an error each time.
Although using the `/vsc` switch can allow the migration of many files that are open with another application, it's a best practice to close all applications in order to ensure all files and settings migrate. Without the `/vsc` or `/c` switch USMT will fail when it can't migrate a file or setting. When you use the `/c` option, USMT will ignore any files or settings that it can't migrate and log an error each time.
- **Log off after you run the LoadState**
Some settings, such as fonts, wallpaper, and screensaver settings, will not take effect until the next time the user logs on. For this reason, you should log off after you run the LoadState tool.
Some settings, such as fonts, wallpaper, and screensaver settings, won't take effect until the next time the user logs on. For this reason, you should sign out after you run the LoadState tool.
- **Managed environment**
To create a managed environment, you can move all of the end user’s documents into My Documents (%CSIDL\_PERSONAL%). We recommend that you migrate files into the smallest-possible number of folders on the destination computer. This will help you to clean up files on the destination computer, if the LoadState command fails before completion.
To create a managed environment, you can move all of the end user's documents into My Documents (%CSIDL\_PERSONAL%). We recommend that you migrate files into the smallest-possible number of folders on the destination computer. Minimizing folders will help you to clean up files on the destination computer, if the `LoadState.exe` command fails before completion.
- **Chkdsk.exe**
We recommend that you run Chkdsk.exe before running the ScanState and LoadState tools. Chkdsk.exe creates a status report for a hard disk drive and lists and corrects common errors. For more information about the Chkdsk.exe tool, see [Chkdsk](/previous-versions/windows/it-pro/windows-xp/bb490876(v=technet.10)).
We recommend that you run **Chkdsk.exe** before running the ScanState and LoadState tools. **Chkdsk.exe** creates a status report for a hard disk drive and lists and corrects common errors. For more information about the **Chkdsk.exe** tool, see [Chkdsk](/previous-versions/windows/it-pro/windows-xp/bb490876(v=technet.10)).
- **Migrate in groups**
If you decide to perform the migration while users are using the network, it is best to migrate user accounts in groups. To minimize the impact on network performance, determine the size of the groups based on the size of each user account. Migrating in phases also allows you to make sure each phase is successful before starting the next phase. Using this method, you can make any necessary modifications to your plan between groups.
If you decide to perform the migration while users are using the network, it's best to migrate user accounts in groups. To minimize the impact on network performance, determine the size of the groups based on the size of each user account. Migrating in phases also allows you to make sure each phase is successful before starting the next phase. Using this method, you can make any necessary modifications to your plan between groups.
## Security Best Practices
As the authorized administrator, it is your responsibility to protect the privacy of the users and maintain security during and after the migration. In particular, you must consider the following issues:
- **Encrypting File System (EFS)**
Take extreme caution when migrating encrypted files, because the end user does not 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).
**Important**  
If you migrate an encrypted file without also migrating the certificate, end users will not be able to access the file after the migration.
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]
> 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**
Consider using the **/encrypt** option with the ScanState command and the **/decrypt** option with the LoadState command. However, use extreme caution with this set of options, because anyone who has access to the ScanState command-line script also has access to the encryption key.
Consider using the `/encrypt` option with the `ScanState.exe` command and the `/decrypt` option with the `LoadState.exe` command. However, use extreme caution with this set of options, because anyone who has access to the `ScanState.exe` command-line script also has access to the encryption key.
- **Virus Scan**
@ -76,26 +71,25 @@ As the authorized administrator, it is your responsibility to protect the privac
- **Maintain security of the file server and the deployment server**
We recommend that you manage the security of the file and deployment servers. It is important to make sure that the file server where you save the store is secure. You must also secure the deployment server, to ensure that the user data that is in the log files is not exposed. We also recommend that you only transmit data over a secure Internet connection, such as a virtual private network. For more information about network security, see [Microsoft Security Compliance Manager](https://go.microsoft.com/fwlink/p/?LinkId=215657).
We recommend that you manage the security of the file and deployment servers. It's important to make sure that the file server where you save the store is secure. You must also secure the deployment server, to ensure that the user data that is in the log files isn't exposed. We also recommend that you only transmit data over a secure Internet connection, such as a virtual private network. For more information about network security, see [Microsoft Security Compliance Manager](https://go.microsoft.com/fwlink/p/?LinkId=215657).
- **Password Migration**
To ensure the privacy of the end users, USMT does not migrate passwords, including those for applications such as Windows Live™ Mail, Microsoft Internet Explorer®, as well as Remote Access Service (RAS) connections and mapped network drives. It is important to make sure that end users know their passwords.
To ensure the privacy of the end users, USMT doesn't migrate passwords, including passwords for applications such as Windows Live™ Mail, Microsoft Internet Explorer®, and Remote Access Service (RAS) connections and mapped network drives. It's important to make sure that end users know their passwords.
- **Local Account Creation**
Before you migrate local accounts, see the Migrating Local Accounts section in the [Identify Users](usmt-identify-users.md) topic.
Before you migrate local accounts, see the Migrating Local Accounts section in the [Identify Users](usmt-identify-users.md) article.
## <a href="" id="bkmk-bestpractices"></a>XML File Best Practices
- **Specify the same set of mig\*.xml files in both the ScanState and the LoadState tools**
If you used a particular set of mig\*.xml files in the ScanState tool, either called through the "/auto" option, or individually through the "/i" option, then you should use same option to call the exact same mig\*.xml files in the LoadState tool.
If you used a particular set of mig\*.xml files in the ScanState tool, either called through the `/auto` option, or individually through the `/i` option, then you should use same option to call the exact same mig\*.xml files in the LoadState tool.
- **The &lt;CustomFileName&gt; in the migration urlid should match the name of the file**
Although it is not a requirement, it is good practice for &lt;CustomFileName&gt; to match the name of the file. For example, the following is from the MigApp.xml file:
Although it isn't a requirement, it's good practice for **&lt;CustomFileName&gt;** to match the name of the file. For example, the following example is from the `MigApp.xml` file:
``` xml
<?xml version="1.0" encoding="UTF-8"?>
@ -104,15 +98,15 @@ As the authorized administrator, it is your responsibility to protect the privac
- **Use the XML Schema (MigXML.xsd) when authoring .xml files to validate syntax**
The MigXML.xsd schema file should not be included on the command line or in any of the .xml files.
The `MigXML.xsd` schema file shouldn't be included on the command line or in any of the .xml files.
- **Use the default migration XML files as models**
To create a custom .xml file, you can use the migration .xml files as models to create your own. If you need to migrate user data files, model your custom .xml file on MigUser.xml. To migrate application settings, model your custom .xml file on the MigApp.xml file.
To create a custom .xml file, you can use the migration .xml files as models to create your own. If you need to migrate user data files, model your custom .xml file on `MigUser.xml`. To migrate application settings, model your custom .xml file on the `MigApp.xml` file.
- **Consider the impact on performance when using the &lt;context&gt; parameter**
Your migration performance can be affected when you use the &lt;context&gt; element with the &lt;component&gt; element; for example, as in when you want to encapsulate logical units of file- or path-based &lt;include&gt; and &lt;exclude&gt; rules.
Your migration performance can be affected when you use the **&lt;context&gt;** element with the **&lt;component&gt;** element; for example, as in when you want to encapsulate logical units of file- or path-based **&lt;include&gt;** and **&lt;exclude&gt;** rules.
In the **User** context, a rule is processed one time for each user on the system.
@ -120,32 +114,24 @@ 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**  
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.
> [!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**
For example, if you have code that migrates the settings for an application, you should not just add the code to the MigApp.xml file.
For example, if you have code that migrates the settings for an application, you shouldn't just add the code to the `MigApp.xml` file.
- **You should not create custom .xml files to alter the operating system settings that are migrated**
These settings are migrated by manifests and you cannot modify those files. If you want to exclude certain operating system settings from the migration, you should create and modify a Config.xml file.
These settings are migrated by manifests and you can't modify those files. If you want to exclude certain operating system settings from the migration, you should create and modify a `Config.xml` file.
- **You can use the asterisk (\*) wildcard character in any migration XML file that you create**
**Note**  
The question mark is not valid as a wildcard character in USMT .xml files.
## Related topics
> [!Note]
> The question mark is not valid as a wildcard character in USMT .xml files.
## Related articles
[Migration Store Encryption](usmt-migration-store-encryption.md)
[Plan Your Migration](usmt-plan-your-migration.md)

6
windows/deployment/usmt/usmt-choose-migration-store-type.md
View File

@ -13,7 +13,7 @@ ms.technology: itpro-deploy
# Choose a Migration Store Type
One of the main considerations for planning your migration is to determine which migration store type best meets your needs. As part of these considerations, determine how much space is required to run the User State Migration Tool (USMT) 10.0 components on your source and destination computers, and how much space is needed to create and host the migration store, whether you are using a local share, network share, or storage device. The final consideration is ensuring that user date integrity is maintained by encrypting the migration store.
One of the main considerations for planning your migration is to determine which migration store type best meets your needs. As part of these considerations, determine how much space is required to run the User State Migration Tool (USMT) 10.0 components on your source and destination computers, and how much space is needed to create and host the migration store, whether you're using a local share, network share, or storage device. The final consideration is ensuring that user date integrity is maintained by encrypting the migration store.
## In This Section
@ -21,10 +21,10 @@ One of the main considerations for planning your migration is to determine which
|--- |--- |
|[Migration Store Types Overview](migration-store-types-overview.md)|Choose the migration store type that works best for your needs and migration scenario.|
|[Estimate Migration Store Size](usmt-estimate-migration-store-size.md)|Estimate the amount of disk space needed for computers in your organization based on information about your organization's infrastructure.|
|[Hard-Link Migration Store](usmt-hard-link-migration-store.md)|Learn about hard-link migration stores and the scenarios in which they are used.|
|[Hard-Link Migration Store](usmt-hard-link-migration-store.md)|Learn about hard-link migration stores and the scenarios in which they're used.|
|[Migration Store Encryption](usmt-migration-store-encryption.md)|Learn about the using migration store encryption to protect user data integrity during a migration.|
## Related topics
## Related articles
[Plan Your Migration](usmt-plan-your-migration.md)

2
windows/deployment/usmt/usmt-command-line-syntax.md
View File

@ -13,7 +13,7 @@ ms.technology: itpro-deploy
# User State Migration Tool (USMT) Command-line Syntax
The User State Migration Tool (USMT) 10.0 migrates user files and settings during large deployments of Windows. To improve and simplify the migration process, USMT captures desktop, network, and application settings in addition to a user's files. USMT then migrates these items to a new Windows installation.
The User State Migration Tool (USMT) 10.0 migrates user files and settings during large deployments of Windows. To improve and simplify the migration process, USMT captures desktop, network, and application settings in addition to a user's files. USMT then migrates these items to a new Windows installation.
## In This Section

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

@ -1,6 +1,6 @@
---
title: Common Issues (Windows 10)
description: Learn about common issues that you might see when you run the User State Migration Tool (USMT) 10.0 tools.
description: Learn about common issues that you might see when you run the User State Migration Tool (USMT) 10.0 tools.
ms.reviewer:
manager: aaroncz
ms.author: frankroj
@ -13,12 +13,10 @@ ms.technology: itpro-deploy
# Common Issues
The following sections discuss common issues that you might see when you run the User State Migration Tool (USMT) 10.0 tools. USMT produces log files that describe in further detail any errors that occurred during the migration process. These logs can be used to troubleshoot migration failures.
The following sections discuss common issues that you might see when you run the User State Migration Tool (USMT) 10.0 tools. USMT produces log files that describe in further detail any errors that occurred during the migration process. These logs can be used to troubleshoot migration failures.
## In this topic
[User Account Problems](#user)
[Command-line Problems](#command)
@ -31,42 +29,36 @@ The following sections discuss common issues that you might see when you run the
[Hard Link Migration Problems](#bkmk-hardlink)
[USMT does not migrate the Start layout](#usmt-does-not-migrate-the-start-layout)
[USMT doesn't migrate the Start layout](#usmt-does-not-migrate-the-start-layout)
## General Guidelines for Identifying Migration Problems
When you encounter a problem or error message during migration, you can use the following general guidelines to help determine the source of the problem:
- Examine the ScanState, LoadState, and UsmtUtils logs to obtain the exact USMT error messages and Windows® application programming interface (API) error messages. For more information about USMT return codes and error messages, see [Return Codes](usmt-return-codes.md). For more information about Windows API error messages, type **nethelpmsg** on the command line.
In most cases, the ScanState and LoadState logs indicate why a USMT migration is failing. We recommend that you use the **/v**<em>:5</em> 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.
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**
Running the ScanState and LoadState tools with the **/v**<em>:5</em> 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.
> [!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).
- Use the `/Extract` option with the UsmtUtils tool to extract files from a compressed migration store. For more information, see [Extract Files from a Compressed USMT Migration Store](usmt-extract-files-from-a-compressed-migration-store.md).
- Use the **/Verify** option in 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).
- Use the **/Extract** option in the UsmtUtils tool to extract files from a compressed migration store. For more information, see [Extract Files from a Compressed USMT Migration Store](usmt-extract-files-from-a-compressed-migration-store.md).
- Create a progress log using the **/Progress** option to monitor your migration.
- Create a progress log using the `/Progress` option to monitor your migration.
- For the source and destination computers, obtain operating system information, and versions of applications such as Internet Explorer and any other relevant programs. Then verify the exact steps that are needed to reproduce the problem. This information might help you to understand what is wrong and to reproduce the issue in your testing environment.
- Log off after you run the LoadState tool. Some settings—for example, fonts, desktop backgrounds, and screen-saver settings—will not take effect until the next time the end user logs on.
- Sign out after you run the LoadState tool. Some settings such as fonts, desktop backgrounds, and screen-saver settings won't take effect until the next time the end user logs on.
- 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**
USMT will fail if it cannot 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 did not migrate.
> [!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.
@ -77,37 +69,35 @@ The following sections describe common user account problems. Expand the section
**Causes/Resolutions** There are two possible causes for this problem:
When running the ScanState tool on Windows Vista, or the ScanState and LoadState tools on Windows 7, Windows 8, or Windows 10, you must run them in Administrator mode from an account with administrative credentials to ensure that all specified users are migrated. To run in Administrator mode:
When running the ScanState and LoadState tools on Windows 7, Windows 8, or Windows 10, you must run them in Administrator mode from an account with administrative credentials to ensure that all specified users are migrated. To run in Administrator mode:
1. Click **Start**.
1. Select **Start** > **All Programs** > **Accessories**.
2. Click **All Programs**.
2. Right-click **Command Prompt**.
3. Click **Accessories**.
3. Select **Run as administrator**.
4. Right-click **Command Prompt**.
4. Specify the `LoadState.exe` or `ScanState.exe` command.
5. Click **Run as administrator**.
If you don't run USMT in Administrator mode, only the user profile that is logged on will be included in the migration.
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.
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.
**Cause:** The command that you specified might 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.
**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) topic.
**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 am 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 logon date.
**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.
**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.
**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.
**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.
**Resolution:** To delete a user profile, use the **User Accounts** item in Control Panel. To correct an incomplete deletion of a user profile:
@ -117,43 +107,42 @@ Any user accounts on the computer that have not been used will not be migrated.
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.
3. Delete the key for the user profile you're trying to remove.
### Files that were not 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.
**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.
**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.
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.
**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,
**Resolution:** You can use the `/mu` option when you run the LoadState tool to specify a new name for the user. For example,
``` syntax
loadstate /i:migapp.xml /i:migdocs.xml \\server\share\migration\mystore
loadstate.exe /i:migapp.xml /i:migdocs.xml \\server\share\migration\mystore
/progress:prog.log /l:load.log /mu:fareast\user1:farwest\user1
```
## <a href="" id="command"></a>Command-line Problems
The following sections describe common command-line problems. Expand the section to see recommended solutions.
### 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: "Usage Error: You can't specify a file path with any of the command-line options that exceeds 256 characters."
**Cause:** You might receive this error message in some cases even if you do not specify a long store or file path, 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.
**Cause:** You might receive this error message in some cases even if you don't specify a long store or file path, 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.
**Resolution:** Ensure that the total path length doesn't exceed 256 characters. The total path length includes the store path plus the current directory.
### 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**.
**Cause:** If you're running the ScanState or LoadState tools from a shared network resource, you'll receive this error message if you don't specify `/l`.
**Resolution:** To fix this issue in this scenario, specify the **/l:scan.log** or **/l:load.log** option.
**Resolution:** To fix this issue in this scenario, specify the `/l:scan.log` or `/l:load.log` option.
## <a href="" id="xml"></a>XML File Problems
@ -162,38 +151,37 @@ The following sections describe common XML file problems. Expand the section to
### 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.
**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 won't 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, run the following:
**Resolution:** Install all of the desired applications on the computer before running the `/genconfig` option. Then run `ScanState.exe` with all of the .xml files. For example, run the following command:
`scanstate /genconfig:config.xml /i:migdocs.xml /i:migapp.xml /v:5 /l:scanstate.log`
`scanstate.exe /genconfig:config.xml /i:migdocs.xml /i:migapp.xml /v:5 /l:scanstate.log`
### I am having problems with a custom .xml file that I authored, and I cannot 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 (MigXML.xsd), included with USMT, into your XML authoring tool. 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 is a syntax error. In addition, see [USMT XML Reference](usmt-xml-reference.md) for more information about using the XML elements.
**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).
### <a href="" id="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-"></a>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?
### <a href="" id="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-"></a>I'm 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.
**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 didn't 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.
**Resolution:** You should search the ScanState or LoadState log for either the component name that contains the MigXML helper function, or the MigXML helper function title, so that you can locate the related warning in the log file.
## <a href="" id="migration"></a>Migration Problems
The following sections describe common migration problems. Expand the section to see recommended solutions.
### Files that I specified to exclude are still being migrated.
**Cause:** There might 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.
**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 has not 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.
**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:
**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 articles:
[Conflicts and Precedence](usmt-conflicts-and-precedence.md)
@ -205,31 +193,33 @@ 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 does not 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.
**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.
**Cause**: Some settings such as fonts, desktop backgrounds, and screen-saver settings aren't 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.
**Resolution:** To fix this issue, sign out, 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® 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.
<!---
**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 won't be migrated. Instead, the destination computer will have the default Windows® desktop background. This issue 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.
**Resolution:** Ensure that the desktop background images that you want to migrate aren't 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.
**Cause \#3:** If ScanState wasn't run on Windows XP from an account with administrative credentials, some operating system settings won't 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 won't migrate.
**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.
**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.
**Resolution:** To migrate PST files that aren't linked to Outlook profiles, you must create a separate migration rule to capture these files.
### USMT does not migrate the Start layout
### USMT doesn't migrate the Start layout
**Description:** You are using USMT to migrate profiles from one installation of Windows 10 to another installation of Windows 10 on different hardware. After migration, the user signs in on the new device and does not have the Start menu layout they had previously configured.
**Description:** You're using USMT to migrate profiles from one installation of Windows 10 to another installation of Windows 10 on different hardware. After migration, the user signs in on the new device and doesn't have the Start menu layout they had previously configured.
**Cause:** A code change in the Start Menu with Windows 10 version 1607 and later is incompatible with this USMT function.
@ -244,19 +234,18 @@ There are three typical causes for this issue.
3. Before the user signs in on the new device, import the Start layout using the following Windows PowerShell command:
```
Import-StartLayout –LayoutPath "C:\Layout\user1.xml" –MountPath %systemdrive%
Import-StartLayout -LayoutPath "C:\Layout\user1.xml" -MountPath %systemdrive%
```
This workaround changes the Default user's Start layout. The workaround does not scale to a mass migrations or multiuser devices, but it can potentially unblock some scenarios. If other users will sign on to the device you should delete layoutmodification.xml from the Default user profile. Otherwise, all users who sign on to that device will use the imported Start layout.
This workaround changes the Default user's Start layout. The workaround doesn't scale to a mass migrations or multiuser devices, but it can potentially unblock some scenarios. If other users will sign on to the device, you should delete layoutmodification.xml from the Default user profile. Otherwise, all users who sign on to that device will use the imported Start layout.
## <a href="" id="bkmk-offline"></a>Offline Migration Problems
The following sections describe common offline migration problems. Expand the section to see recommended solutions.
### Some of my system settings do not 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, are not supported in an offline migration. For more information, see [What Does USMT Migrate?](usmt-what-does-usmt-migrate.md)
**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.
@ -266,23 +255,23 @@ The following sections describe common offline migration problems. Expand the se
**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 do not 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 cannot be queried to resolve the user name and SID mapping.
**Cause:** When offline, the DNS server can't 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:
``` syntax
Scanstate /ui:S1-5-21-124525095-708259637-1543119021*
Scanstate.exe /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](/troubleshoot/windows-server/identity/security-identifiers-in-windows).
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.
**Cause:** The HKLM registry hive is not unloaded after the ScanState tool has finished running.
**Cause:** The HKLM registry hive isn't 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:
@ -292,33 +281,27 @@ reg.exe unload hklm\$dest$software
## <a href="" id="bkmk-hardlink"></a>Hard-Link Migration Problems
The following sections describe common hard-link migration problems. Expand the section to see recommended solutions.
### EFS files are not restored to the new partition.
### EFS files aren't 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.
**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.
**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 cannot 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.
**Resolution:** Use the UsmtUtils tool to delete the store or change the store name. For example, at a command prompt, type:
``` syntax
USMTutils /rd <storedir>
USMTutils.exe /rd <storedir>
```
You should also reboot the machine.
## Related topics
## Related articles
[User State Migration Tool (USMT) Troubleshooting](usmt-troubleshooting.md)
@ -327,6 +310,3 @@ You should also reboot the machine.
[Return Codes](usmt-return-codes.md)
[UsmtUtils Syntax](usmt-utilities.md)

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

@ -1,6 +1,6 @@
---
title: Common Migration Scenarios (Windows 10)
description: See how the User State Migration Tool (USMT) 10.0 is used when planning hardware and/or operating system upgrades.
description: See how the User State Migration Tool (USMT) 10.0 is used when planning hardware and/or operating system upgrades.
ms.reviewer:
manager: aaroncz
ms.author: frankroj
@ -13,14 +13,12 @@ ms.technology: itpro-deploy
# Common Migration Scenarios
You use the User State Migration Tool (USMT) 10.0 when hardware and/or operating system upgrades are planned for a large number of computers. USMT manages the migration of an end-user's digital identity by capturing the user's operating-system settings, application settings, and personal files from a source computer and reinstalling them on a destination computer after the upgrade has occurred.
You use the User State Migration Tool (USMT) 10.0 when hardware and/or operating system upgrades are planned for a large number of computers. USMT manages the migration of an end-user's digital identity by capturing the user's operating-system settings, application settings, and personal files from a source computer and reinstalling them on a destination computer after the upgrade has occurred.
One common scenario when only the operating system, and not the hardware, is being upgraded is referred to as *PC refresh*. A second common scenario is known as *PC replacement*, where one piece of hardware is being replaced, typically by newer hardware and a newer operating system.
One common scenario is when the operating system is upgraded on existing hardware without the hardware being replaced. This scenario is referred to as *PC refresh*. A second common scenario is known as *PC replacement*, where one piece of hardware is being replaced, typically by newer hardware and a newer operating system.
**In this article:**
[PC Refresh](#bkmk-pcrefresh)
[Scenario One: PC-refresh offline using Windows PE and a hard-link migration store](#bkmk-onepcrefresh)
@ -41,112 +39,93 @@ One common scenario when only the operating system, and not the hardware, is bei
## <a href="" id="bkmk-pcrefresh"></a>PC-Refresh
The following diagram shows a PC-refresh migration, also known as a computer refresh migration. First, the administrator migrates the user state from a source computer to an intermediate store. After installing the operating system, the administrator migrates the user state back to the source computer.
 
![usmt pc refresh scenario.](images/dep-win8-l-usmt-pcrefresh.jpg)
 
### <a href="" id="bkmk-onepcrefresh"></a>Scenario One: PC-refresh offline using Windows PE and a hard-link migration store
A company has just received funds to update the operating system on all of its computers in the accounting department to Windows 10. Each employee will keep the same computer, but the operating system on each computer will be updated. In this scenario, the update is being handled completely offline, without a network connection. An administrator uses Windows Preinstallation Environment (WinPE) and a hard-link migration store to save each user state to their respective computer.
A company has received funds to update the operating system on all of its computers in the accounting department to Windows 10. Each employee will keep the same computer, but the operating system on each computer will be updated. In this scenario, the update is being handled offline, without a network connection. An administrator uses Windows Preinstallation Environment (WinPE) and a hard-link migration store to save each user state to their respective computer.
1. On each computer, the administrator boots the machine into WinPE and runs the ScanState command-line tool, specifying the **/hardlink /nocompress** command-line options. ScanState saves the user state to a hard-link migration store on each computer, improving performance by minimizing network traffic as well as minimizing migration failures on computers with very limited space available on the hard drive.
1. On each computer, the administrator boots the machine into WinPE and runs the ScanState command-line tool, specifying the `/hardlink /nocompress` command-line options. ScanState saves the user state to a hard-link migration store on each computer, improving performance by minimizing network traffic and minimizing migration failures on computers with limited space available on the hard drive.
2. On each computer, the administrator installs the company's standard operating environment (SOE) which includes Windows 10 and other company applications.
2. On each computer, the administrator installs the company's standard operating environment (SOE) which includes Windows 10 and other company applications.
3. The administrator runs the LoadState command-line tool on each computer. LoadState restores each user state back to each computer.
### <a href="" id="bkmk-twopcrefresh"></a>Scenario Two: PC-refresh using a compressed migration store
A company has just received funds to update the operating system on all of its computers to Windows 10. Each employee will keep the same computer, but the operating system on each computer will be updated. In this scenario, an administrator uses a compressed migration store to save the user states to a server.
A company has received funds to update the operating system on all of its computers to Windows 10. Each employee will keep the same computer, but the operating system on each computer will be updated. In this scenario, an administrator uses a compressed migration store to save the user states to a server.
1. The administrator runs the ScanState command-line tool on each computer. ScanState saves each user state to a server.
2. On each computer, the administrator installs the company's standard SOE which includes Windows 10 and other company applications.
2. On each computer, the administrator installs the company's standard SOE that includes Windows 10 and other company applications.
3. The administrator runs the LoadState command-line tool on each source computer, and LoadState restores each user state back to the computer.
### <a href="" id="bkmk-threepcrefresh"></a>Scenario Three: PC-refresh using a hard-link migration store
A company has just received funds to update the operating system on all of its computers to Windows 10. Each employee will keep the same computer, but the operating system on each computer will be updated. In this scenario, an administrator uses a hard-link migration store to save each user state to their respective computer.
A company has received funds to update the operating system on all of its computers to Windows 10. Each employee will keep the same computer, but the operating system on each computer will be updated. In this scenario, an administrator uses a hard-link migration store to save each user state to their respective computer.
1. The administrator runs the ScanState command-line tool on each computer, specifying the **/hardlink /nocompress** command-line options. ScanState saves the user state to a hard-link migration store on each computer, improving performance by minimizing network traffic as well as minimizing migration failures on computers with very limited space available on the hard drive.
1. The administrator runs the ScanState command-line tool on each computer, specifying the `/hardlink /nocompress` command-line options. ScanState saves the user state to a hard-link migration store on each computer, improving performance by minimizing network traffic and minimizing migration failures on computers with limited space available on the hard drive.
2. On each computer, the administrator installs the company's SOE which includes Windows 10 and other company applications.
2. On each computer, the administrator installs the company's SOE that includes Windows 10 and other company applications.
3. The administrator runs the LoadState command-line tool on each computer. LoadState restores each user state back on each computer.
### <a href="" id="bkmk-fourpcrefresh"></a>Scenario Four: PC-refresh using Windows.old folder and a hard-link migration store
A company has decided to update the operating system on all of its computers to Windows 10. Each employee will keep the same computer, but the operating system on each computer will be updated. In this scenario, an administrator uses Windows.old and a hard-link migration store to save each user state to their respective computer.
A company has decided to update the operating system on all of its computers to Windows 10. Each employee will keep the same computer, but the operating system on each computer will be updated. In this scenario, an administrator uses Windows.old and a hard-link migration store to save each user state to their respective computer.
1. The administrator clean installs Windows 10 on each computer, making sure that the Windows.old directory is created by installing Windows 10 without formatting or repartitioning and by selecting a partition that contains the previous version of Windows.
1. The administrator clean installs Windows 10 on each computer, making sure that the Windows.old directory is created by installing Windows 10 without formatting or repartitioning and by selecting a partition that contains the previous version of Windows.
2. On each computer, the administrator installs the company's SOE which includes company applications.
2. On each computer, the administrator installs the company's SOE that includes company applications.
3. The administrator runs the ScanState and LoadState command-line tools successively on each computer while specifying the **/hardlink /nocompress** command-line options.
3. The administrator runs the ScanState and LoadState command-line tools successively on each computer while specifying the `/hardlink /nocompress` command-line options.
## <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)
 
### <a href="" id="bkmk-onepcreplace"></a>Scenario One: Offline migration using WinPE and an external migration store
A company is allocating 20 new computers to users in the accounting department. The users each have a source computer with their files and settings. In this scenario, migration is being handled completely offline, without a network connection.
A company is allocating 20 new computers to users in the accounting department. The users each have a source computer with their files and settings. In this scenario, migration is being handled offline, without a network connection.
1. On each source computer, an administrator boots the machine into WinPE and runs ScanState to collect the user state to either a server or an external hard disk.
2. On each new computer, the administrator installs the company's SOE which includes Windows 10 and other company applications.
2. On each new computer, the administrator installs the company's SOE that includes Windows 10 and other company applications.
3. On each of the new computers, the administrator runs the LoadState tool, restoring each user state from the migration store to one of the new computers.
### <a href="" id="bkmk-twopcreplace"></a>Scenario Two: Manual network migration
A company receives 50 new laptops for their managers and needs to reallocate 50 older laptops to new employees. In this scenario, an administrator runs the ScanState tool from the cmd prompt on each computer to collect the user states and save them to a server in a compressed migration store.
A company receives 50 new laptops for their managers and needs to reallocate 50 older laptops to new employees. In this scenario, an administrator runs the ScanState tool from the cmd prompt on each computer to collect the user states and save them to a server in a compressed migration store.
1. The administrator runs the ScanState tool on each of the manager's old laptops, and saves each user state to a server.
2. On the new laptops, the administrator installs the company's SOE, which includes Windows 10 and other company applications.
2. On the new laptops, the administrator installs the company's SOE, which includes Windows 10 and other company applications.
3. The administrator runs the LoadState tool on the new laptops to migrate the managers' user states to the appropriate computer. The new laptops are now ready for the managers to use.
4. On the old computers, the administrator installs the company's SOE, which includes Windows 10, Microsoft Office, and other company applications. The old computers are now ready for the new employees to use.
4. On the old computers, the administrator installs the company's SOE, which includes Windows 10, Microsoft Office, and other company applications. The old computers are now ready for the new employees to use.
### <a href="" id="bkmk-threepcreplace"></a>Scenario Three: Managed network migration
A company is allocating 20 new computers to users in the accounting department. The users each have a source computer that contains their files and settings. An administrator uses a management technology such as a logon script or a batch file to run ScanState on each source computer to collect the user states and save them to a server in a compressed migration store.
A company is allocating 20 new computers to users in the accounting department. The users each have a source computer that contains their files and settings. An administrator uses a management technology such as a sign-in script or a batch file to run ScanState on each source computer to collect the user states and save them to a server in a compressed migration store.
1. On each source computer, the administrator runs the ScanState tool using Microsoft Endpoint Configuration Manager, Microsoft Deployment Toolkit (MDT), a logon script, a batch file, or a non-Microsoft management technology. ScanState collects the user state from each source computer and then saves it to a server.
1. On each source computer, the administrator runs the ScanState tool using Microsoft Configuration Manager, Microsoft Deployment Toolkit (MDT), a sign-in script, a batch file, or a non-Microsoft management technology. ScanState collects the user state from each source computer and then saves it to a server.
2. On each new computer, the administrator installs the company's SOE, which includes Windows 10 and other company applications.
2. On each new computer, the administrator installs the company's SOE, which includes Windows 10 and other company applications.
3. On each of the new computers, the administrator runs the LoadState tool using Microsoft Endpoint Configuration Manager, a logon script, a batch file, or a non-Microsoft management technology. LoadState migrates each user state from the migration store to one of the new computers.
## Related topics
3. On each of the new computers, the administrator runs the LoadState tool using Microsoft Configuration Manager, a sign-in script, a batch file, or a non-Microsoft management technology. LoadState migrates each user state from the migration store to one of the new computers.
## Related articles
[Plan Your Migration](usmt-plan-your-migration.md)
[Choose a Migration Store Type](usmt-choose-migration-store-type.md)
[Offline Migration Reference](offline-migration-reference.md)
 
 

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

@ -1,6 +1,6 @@
---
title: Config.xml File (Windows 10)
description: Learn how 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.exe tool.
description: Learn how 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.exe tool.
ms.reviewer:
manager: aaroncz
ms.author: frankroj
@ -15,20 +15,20 @@ ms.technology: itpro-deploy
## 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.exe tool. If you want to include all of the default components, and do not want to change the default store-creation or profile-migration behavior, you do not need to create a 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 are 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 is necessary to create and modify this file if you want to change any of the default store-creation or profile-migration behavior.
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.
The Config.xml file has a different format than the other migration .xml files, because it does not contain any migration rules. It contains only a list of the operating-system components, applications, user documents that can be migrated, as well as user-profile policy and error-control policy. For this reason, excluding components using the Config.xml file is easier than modifying the migration .xml files, because you do not need to be familiar with the migration rules and syntax. However, you cannot use wildcard characters in this file.
The `Config.xml` file has a different format than the other migration .xml files, because it doesn't contain any migration rules. It contains only a list of the operating-system components, applications, user documents that can be migrated, and user-profile policy and error-control policy. For this reason, excluding components using the `Config.xml` file is easier than modifying the migration .xml files, because you don't need to be familiar with the migration rules and syntax. However, you can't use wildcard characters in this file.
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).
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**  
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.
> [!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
In USMT there are new 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. The following elements and parameters are for use in the Config.xml file only.
In USMT there are new 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. The following elements and parameters are for use in the `Config.xml` file only.
[&lt;Policies&gt;](#bkmk-policies)
@ -68,11 +68,11 @@ In USMT there are new migration policies that can be configured in the Config.xm
The **&lt;Policies&gt;** element contains elements that describe the policies that USMT follows while creating a migration store. Valid children of the **&lt;Policies&gt;** element are **&lt;ErrorControl&gt;** and **&lt;HardLinkStoreControl&gt;**. The **&lt;Policies&gt;** element is a child of **&lt;Configuration&gt;**.
Syntax: `<Policies> </Policies>`
Syntax: `<Policies>` `</Policies>`
## <a href="" id="bkmk-errorcontrol"></a>&lt;ErrorControl&gt;
The **&lt;ErrorControl&gt;** element is an optional element you can configure in the Config.xml file. The configurable **&lt;ErrorControl&gt;** rules support only the environment variables for the operating system that is running and the currently logged-on user. As a workaround, you can specify a path using the (\*) wildcard character.
The **&lt;ErrorControl&gt;** element is an optional element you can configure in the `Config.xml` file. The configurable **&lt;ErrorControl&gt;** rules support only the environment variables for the operating system that is running and the currently logged-on user. As a workaround, you can specify a path using the (\*) wildcard character.
- **Number of occurrences**: Once for each component
@ -80,9 +80,9 @@ The **&lt;ErrorControl&gt;** element is an optional element you can configure in
- **Child elements**: The **&lt;fileError&gt;** and **&lt;registryError&gt;** element
Syntax: `<ErrorControl></ErrorControl>`
Syntax: `<ErrorControl>` `</ErrorControl>`
The following example specifies that all locked files, regardless of their location (including files in C:\\Users), should be ignored. However, the migration fails if any file in C:\\Users cannot be accessed because of any other reason. In the example below, the **&lt;ErrorControl&gt;** element ignores any problems in migrating registry keys that match the supplied pattern, and it resolves them to an **Access denied** error.
The following example specifies that all locked files, regardless of their location (including files in C:\\Users), should be ignored. However, the migration fails if any file in C:\\Users can't be accessed because of any other reason. In the example below, the **&lt;ErrorControl&gt;** element ignores any problems in migrating registry keys that match the supplied pattern, and it resolves them to an **Access denied** error.
Additionally, the order in the **&lt;ErrorControl&gt;** section implies priority. In this example, the first **&lt;nonFatal&gt;** tag takes precedence over the second **&lt;fatal&gt;** tag. This precedence is applied, regardless of how many tags are listed.
@ -103,7 +103,7 @@ Additionally, the order in the **&lt;ErrorControl&gt;** section implies priority
### <a href="" id="bkmk-fatal"></a>&lt;fatal&gt;
The **&lt;fatal&gt;** element is not required.
The **&lt;fatal&gt;** element isn't required.
- **Number of occurrences**: Once for each component
@ -121,7 +121,7 @@ You use the **&lt;fatal&gt;** element to specify that errors matching a specific
## <a href="" id="bkmk-fileerror"></a>&lt;fileError&gt;
The **&lt;fileError&gt;** element is not required.
The **&lt;fileError&gt;** element isn't required.
- **Number of occurrences**: Once for each component
@ -129,13 +129,13 @@ The **&lt;fileError&gt;** element is not required.
- **Child elements**: **&lt;nonFatal&gt;** and **&lt;fatal&gt;**
Syntax: `<fileError></fileError>`
Syntax: `<fileError>` `</fileError>`
You use the **&lt;fileError&gt;** element to represent the behavior associated with file errors.
## <a href="" id="bkmk-nonfatal"></a>&lt;nonFatal&gt;
The **&lt;nonFatal&gt;** element is not required.
The **&lt;nonFatal&gt;** element isn't required.
- **Number of occurrences**: Once for each component
@ -147,13 +147,13 @@ Syntax: `<nonfatal errorCode="any">`*&lt;pattern&gt;*`</nonFatal>`
|Parameter|Required|Value|
|--- |--- |--- |
|**&lt;errorCode&gt;**|No|"any" or "*specify system error message here*". If system error messages are not specified, the default behavior applies the parameter to all system error messages.|
|**&lt;errorCode&gt;**|No|"any" or "*specify system error message here*". If system error messages aren't specified, the default behavior applies the parameter to all system error messages.|
You use the **&lt;nonFatal&gt;** element to specify that errors matching a specific pattern should not cause USMT to halt the migration.
You use the **&lt;nonFatal&gt;** element to specify that errors matching a specific pattern shouldn't cause USMT to halt the migration.
## <a href="" id="bkmk-registryerror"></a>&lt;registryError&gt;
The <strong>&lt;registryError&gt;</strong>element is not required.
The <strong>&lt;registryError&gt;</strong> element isn't required.
- **Number of occurrences**: Once for each component
@ -161,19 +161,19 @@ The <strong>&lt;registryError&gt;</strong>element is not required.
- **Child elements**: **&lt;nonfatal&gt;** and **&lt;fatal&gt;**
Syntax: `<registryError></registryError>`
Syntax: `<registryError>` `</registryError>`
|Parameter|Required|Value|
|--- |--- |--- |
|**&lt;errorCode&gt;**|No|"any" or "*specify system error message here*". If system error messages are not specified, the default behavior applies the parameter to all system error messages.|
|**&lt;errorCode&gt;**|No|"any" or "*specify system error message here*". If system error messages aren't specified, the default behavior applies the parameter to all system error messages.|
You use the **&lt;registryError&gt;** element to specify that errors matching a specific pattern should not cause USMT to halt the migration.
You use the **&lt;registryError&gt;** element to specify that errors matching a specific pattern shouldn't cause USMT to halt the migration.
## <a href="" id="bkmk-hardlinkstorecontrol"></a>&lt;HardLinkStoreControl&gt;
The **&lt;HardLinkStoreControl&gt;** element contains elements that describe how to handle files during the creation of a hard-link migration store. Its only valid child is **&lt;fileLocked&gt;**.
Syntax: `<HardLinkStoreControl> </HardLinkStoreControl>`
Syntax: `<HardLinkStoreControl>` `</HardLinkStoreControl>`
- **Number of occurrences**: Once for each component
@ -181,12 +181,12 @@ Syntax: `<HardLinkStoreControl> </HardLinkStoreControl>`
- **Child elements**: **&lt;fileLocked&gt;**
Syntax: `<HardLinkStoreControl></HardLinkStoreControl>`
Syntax: `<HardLinkStoreControl>` `</HardLinkStoreControl>`
The **&lt;HardLinkStoreControl&gt;** sample code below specifies that hard links can be created to locked files only if the locked file resides somewhere under C:\\Users\\. Otherwise, a file-access error occurs when a locked file is encountered that cannot be copied, even though is technically possible for the link to be created.
The **&lt;HardLinkStoreControl&gt;** sample code below specifies that hard links can be created to locked files only if the locked file resides somewhere under C:\\Users\\. Otherwise, a file-access error occurs when a locked file is encountered that can't be copied, even though is technically possible for the link to be created.
> [!IMPORTANT]
> The **&lt;ErrorControl&gt;** section can be configured to conditionally ignore file access errors, based on the file’s location.
> The **&lt;ErrorControl&gt;** section can be configured to conditionally ignore file access errors, based on the file's location.
``` xml
<Policy>
@ -206,7 +206,7 @@ The **&lt;HardLinkStoreControl&gt;** sample code below specifies that hard links
The **&lt;fileLocked&gt;** element contains elements that describe how to handle files that are locked for editing. The rules defined by the **&lt;fileLocked&gt;** element are processed in the order in which they appear in the XML file.
Syntax: `<fileLocked></fileLocked>`
Syntax: `<fileLocked>` `</fileLocked>`
## <a href="" id="bkmk-createhardlink"></a>&lt;createHardLink&gt;
@ -216,7 +216,7 @@ Syntax: `<createHardLink>`*&lt;pattern&gt;*`</createHardLink>`
## <a href="" id="bkmk-errorhardlink"></a>&lt;errorHardLink&gt;
The **&lt;errorHardLink&gt;** element defines a standard MigXML pattern that describes file paths where hard links should not be created if the file is locked for editing by another application. USMT will attempt to copy files under these paths into the migration store. However, if that is not possible, **Error\_Locked** is thrown. This is a standard Windows application programming interface (API) error that can be captured by the **&lt;ErrorControl&gt;** section to either cause USMT to skip the file or abort the migration.
The **&lt;errorHardLink&gt;** element defines a standard MigXML pattern that describes file paths where hard links shouldn't be created if the file is locked for editing by another application. USMT will attempt to copy files under these paths into the migration store. However, if that isn't possible, **Error\_Locked** is thrown. This error is a standard Windows application programming interface (API) error that can be captured by the **&lt;ErrorControl&gt;** section to either cause USMT to skip the file or abort the migration.
Syntax: `<errorHardLink>` *&lt;pattern&gt;* `</errorHardLink>`
@ -224,23 +224,23 @@ Syntax: `<errorHardLink>`*&lt;pattern&gt;*`</errorHardLink>`
This element is used to contain other elements that establish rules for migrating profiles, users, and policies around local group membership during the migration. **&lt;ProfileMigration&gt;** is a child of **&lt;Configuration&gt;**.
Syntax: &lt;`ProfileControl> </ProfileControl>`
Syntax: &lt;`ProfileControl>` `</ProfileControl>`
## <a href="" id="bkmk-localgroups"></a>&lt;localGroups&gt;
This element is used to contain other elements that establish rules for how to migrate local groups. **&lt;localGroups&gt;** is a child of **&lt;ProfileControl&gt;**.
Syntax: `<localGroups> </localGroups>`
Syntax: `<localGroups>` `</localGroups>`
## <a href="" id="bkmk-mappings"></a>&lt;mappings&gt;
This element is used to contain other elements that establish mappings between groups.
Syntax: `<mappings> </mappings>`
Syntax: `<mappings>` `</mappings>`
## <a href="" id="bkmk-changegrou"></a>&lt;changeGroup&gt;
This element describes the source and destination groups for a local group membership change during the migration. It is a child of **&lt;localGroups&gt;**. The following parameters are defined:
This element describes the source and destination groups for a local group membership change during the migration. It's a child of **&lt;localGroups&gt;**. The following parameters are defined:
|Parameter|Required|Value|
|--- |--- |--- |
@ -250,7 +250,7 @@ This element describes the source and destination groups for a local group membe
The valid and required children of **&lt;changeGroup&gt;** are **&lt;include&gt;** and **&lt;exclude&gt;**. Although both can be children at the same time, only one is required.
Syntax: `<changeGroup From="Group1" To= "Group2"> </changeGroup>`
Syntax: `<changeGroup From="Group1" To= "Group2">` `</changeGroup>`
## <a href="" id="bkmk-include"></a>&lt;include&gt;
@ -266,7 +266,11 @@ Syntax: `<exclude>`` </exclude>`
## <a href="" id="bkmk-sampleconfigxjmlfile"></a>Sample Config.xml File
Refer to the following sample Config.xml file for additional details about items you can choose to exclude from a migration.
Refer to the following sample `Config.xml` file for more details about items you can choose to exclude from a migration.
<br>
<br>
<details>
<summary>Expand for sample Config.xml file:</summary>
```xml
<?xml version="1.0" encoding="UTF-8"?>
@ -459,6 +463,8 @@ Refer to the following sample Config.xml file for additional details about items
</Configuration>
```
## Related topics
</details>
## Related articles
[USMT XML Reference](usmt-xml-reference.md)

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

@ -1,6 +1,6 @@
---
title: Conflicts and Precedence (Windows 10)
description: In this article, learn how User State Migration Tool (USMT) 10.0 deals with conflicts and precedence.
description: In this article, learn how User State Migration Tool (USMT) 10.0 deals with conflicts and precedence.
ms.reviewer:
manager: aaroncz
ms.author: frankroj
@ -13,19 +13,19 @@ ms.technology: itpro-deploy
# Conflicts and Precedence
When you include, exclude, and reroute files and settings, it is important to know how User State Migration Tool (USMT) 10.0 deals with conflicts and precedence. When working with USMT, the following are the most important conflicts and precedence guidelines to keep in mind.
When you include, exclude, and reroute files and settings, it's important to know how User State Migration Tool (USMT) 10.0 deals with conflicts and precedence. When working with USMT, the following are the most important conflicts and precedence guidelines to keep in mind.
- **If there are conflicting rules within a component, the most specific rule is applied.** However, the &lt;unconditionalExclude&gt; rule is an exception because it takes precedence over all others. Directory names take precedence over file extensions. For examples, see [What happens when there are conflicting include and exclude rules?](#bkmk1) and the first example in [Include and exclude precedence examples](#precexamples)****later in this topic.
- **If there are conflicting rules within a component, the most specific rule is applied.** However, the **&lt;unconditionalExclude&gt;** rule is an exception because it takes precedence over all others. Directory names take precedence over file extensions. For examples, see [What happens when there are conflicting include and exclude rules?](#bkmk1) and the first example in [Include and exclude precedence examples](#precexamples) later in this article.
- **Only rules inside the same component can affect each other, depending on specificity.** Rules that are in different components do not affect each other, except for the &lt;unconditionalExclude&gt; rule.
- **Only rules inside the same component can affect each other, depending on specificity.** Rules that are in different components don't affect each other, except for the **&lt;unconditionalExclude&gt;** rule.
- **If the rules are equally specific, &lt;exclude&gt; takes precedence over &lt;include&gt;.** For example, if you use the &lt;exclude&gt; rule to exclude a file and use the &lt;include&gt; rule to include the same file, the file will be excluded.
- **If the rules are equally specific, &lt;exclude&gt; takes precedence over &lt;include&gt;.** For example, if you use the **&lt;exclude&gt;** rule to exclude a file and use the **&lt;include&gt;** rule to include the same file, the file will be excluded.
- **The ordering of components does not matter.** It does not matter which components are listed in which .xml file, because each component is processed independently of the other components across all of the .xml files.
- **The ordering of components does not matter.** It doesn't matter which components are listed in which .xml file, because each component is processed independently of the other components across all of the .xml files.
- **The ordering of the &lt;include&gt; and &lt;exclude&gt; rules within a component does not matter.**
- **You can use the &lt;unconditionalExclude&gt; element to globally exclude data.** This element excludes objects, regardless of any other &lt;include&gt; rules that are in the .xml files. For example, you can use the &lt;unconditionalExclude&gt; element to exclude all MP3 files on the computer or to exclude all files from C:\\UserData.
- **You can use the &lt;unconditionalExclude&gt; element to globally exclude data.** This element excludes objects, regardless of any other **&lt;include&gt;** rules that are in the .xml files. For example, you can use the **&lt;unconditionalExclude&gt;** element to exclude all MP3 files on the computer or to exclude all files from **C:\\UserData**.
## In this topic
@ -57,11 +57,11 @@ When you include, exclude, and reroute files and settings, it is important to kn
### <a href="" id="bkmk2"></a>What is the relationship between rules that are located within different components?
Only rules inside the same component can affect each other, depending on specificity, except for the &lt;unconditionalExclude&gt; rule. Rules that are in different components do not affect each other. If there is an &lt;include&gt; rule in one component and an identical &lt;exclude&gt; rule in another component, the data will be migrated because the two rules are independent of each other.
Only rules inside the same component can affect each other, depending on specificity, except for the **&lt;unconditionalExclude&gt;** rule. Rules that are in different components don't affect each other. If there's an **&lt;include&gt;** rule in one component and an identical **&lt;exclude&gt;** rule in another component, the data will be migrated because the two rules are independent of each other.
If you have an &lt;include&gt; rule in one component and a &lt;locationModify&gt; rule in another component for the same file, the file will be migrated in both places. That is, it will be included based on the &lt;include&gt; rule, and it will be migrated based on the &lt;locationModify&gt; rule.
If you have an **&lt;include&gt;** rule in one component and a **&lt;locationModify&gt;** rule in another component for the same file, the file will be migrated in both places. That is, it will be included based on the **&lt;include&gt;** rule, and it will be migrated based on the **&lt;locationModify&gt;** rule.
The following .xml file migrates all files from C:\\Userdocs, including .mp3 files, because the &lt;exclude&gt; rule is specified in a separate component.
The following .xml file migrates all files from C:\\Userdocs, including .mp3 files, because the **&lt;exclude&gt;** rule is specified in a separate component.
``` xml
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/UserDocs">
@ -95,7 +95,7 @@ The following .xml file migrates all files from C:\\Userdocs, including .mp3 fil
### <a href="" id="bkmk3"></a>How does precedence work with the Config.xml file?
Specifying `migrate="no"` in the Config.xml file is the same as deleting the corresponding component from the migration .xml file. However, if you set `migrate="no"` for My Documents, but you have a rule similar to the one shown below in a migration .xml file (which includes all of the .doc files from My Documents), then only the .doc files will be migrated, and all other files will be excluded.
Specifying `migrate="no"` in the `Config.xml` file is the same as deleting the corresponding component from the migration .xml file. However, if you set `migrate="no"` for My Documents, but you have a rule similar to the one shown below in a migration .xml file (which includes all of the .doc files from My Documents), then only the .doc files will be migrated, and all other files will be excluded.
``` xml
<include>
@ -107,27 +107,27 @@ Specifying `migrate="no"` in the Config.xml file is the same as deleting the cor
### <a href="" id="bkmk4"></a>How does USMT process each component in an .xml file with multiple components?
The ordering of components does not matter. Each component is processed independently of other components. For example, if you have an &lt;include&gt; rule in one component and a &lt;locationModify&gt; rule in another component for the same file, the file will be migrated in both places. That is, it will be included based on the &lt;include&gt; rule, and it will be migrated based on the &lt;locationModify&gt; rule.
The ordering of components doesn't matter. Each component is processed independently of other components. For example, if you have an **&lt;include&gt;** rule in one component and a **&lt;locationModify&gt;** rule in another component for the same file, the file will be migrated in both places. That is, it will be included based on the **&lt;include&gt;** rule, and it will be migrated based on the **&lt;locationModify&gt;** rule.
### <a href="" id="bkmk5"></a>How are rules processed?
There are two broad categories of rules.
- **Rules that affect the behavior of both the ScanState and LoadState tools**. For example, the &lt;include&gt;, &lt;exclude&gt;, and &lt;unconditionalExclude&gt; rules are processed for each component in the .xml files. For each component, USMT creates an include list and an exclude list. Some of the rules in the component might be discarded due to specificity, but all of the remaining rules are processed. For each &lt;include&gt; rule, USMT iterates through the elements to see if any of the locations need to be excluded. USMT enumerates all of the objects and creates a list of objects it is going to collect for each user. Once the list is complete, each of the objects is stored or migrated to the destination computer.
- **Rules that affect the behavior of both the ScanState and LoadState tools**. For example, the **&lt;include&gt;**, **&lt;exclude&gt;**, and **&lt;unconditionalExclude&gt;** rules are processed for each component in the .xml files. For each component, USMT creates an include list and an exclude list. Some of the rules in the component might be discarded due to specificity, but all of the remaining rules are processed. For each **&lt;include&gt;** rule, USMT iterates through the elements to see if any of the locations need to be excluded. USMT enumerates all of the objects and creates a list of objects it's going to collect for each user. Once the list is complete, each of the objects is stored or migrated to the destination computer.
- **Rules that affect the behavior of only the LoadState tool**. For example, the &lt;locationModify&gt;, &lt;contentModify&gt;, and &lt;destinationCleanup&gt; rules do not affect ScanState. They are processed only with LoadState. First, the LoadState tool determines the content and location of each component based on the &lt;locationModify&gt;and &lt;contentModify&gt; rules. Then, LoadState processes all of the &lt;destinationCleanup&gt; rules and deletes data from the destination computer. Lastly, LoadState applies the components to the computer.
- **Rules that affect the behavior of only the LoadState tool**. For example, the **&lt;locationModify&gt;**, **&lt;contentModify&gt;**, and **&lt;destinationCleanup&gt;** rules don't affect ScanState. They're processed only with LoadState. First, the LoadState tool determines the content and location of each component based on the **&lt;locationModify&gt;** and **&lt;contentModify&gt;** rules. Then, LoadState processes all of the **&lt;destinationCleanup&gt;** rules and deletes data from the destination computer. Lastly, LoadState applies the components to the computer.
### <a href="" id="bkmk6"></a>How does USMT combine all of the .xml files that I specify on the command line?
USMT does not distinguish the .xml files based on their name or content. It processes each component within the files separately. USMT supports multiple .xml files only to make it easier to maintain and organize the components within them. Because USMT uses a urlid to distinguish each component from the others, be sure that each .xml file that you specify on the command line has a unique migration urlid.
USMT doesn't distinguish the .xml files based on their name or content. It processes each component within the files separately. USMT supports multiple .xml files only to make it easier to maintain and organize the components within them. Because USMT uses a urlid to distinguish each component from the others, be sure that each .xml file that you specify on the command line has a unique migration urlid.
## <a href="" id="the--include--and--exclude--rules"></a>The &lt;include&gt; and &lt;exclude&gt; rules
### <a href="" id="bkmk1"></a>What happens when there are conflicting &lt;include&gt; and &lt;exclude&gt; rules?
If there are conflicting rules within a component, the most specific rule is applied, except with the &lt;unconditionalExclude&gt; rule, which takes precedence over all other rules. If the rules are equally specific, then the data will be not be migrated. For example if you exclude a file, and include the same file, the file will not be migrated. If there are conflicting rules within different components, the rules do not affect each other because each component is processed independently.
If there are conflicting rules within a component, the most specific rule is applied, except with the **&lt;unconditionalExclude&gt;** rule, which takes precedence over all other rules. If the rules are equally specific, then the data won't be migrated. For example if you exclude a file, and include the same file, the file won't be migrated. If there are conflicting rules within different components, the rules don't affect each other because each component is processed independently.
In the following example, mp3 files will not be excluded from the migration. This is because directory names take precedence over the file extensions.
In the following example, mp3 files won't be excluded from the migration. The mp3 files won't be excluded because directory names take precedence over the file extensions.
``` xml
<include>
@ -142,9 +142,9 @@ In the following example, mp3 files will not be excluded from the migration. Thi
</exclude>
```
### <a href="" id="precexamples"></a>&lt;include&gt; and &lt;exclude&gt; rules precedence examples
### <a href="" id="precexamples"></a>&lt;include&gt; and **&lt;exclude&gt;** rules precedence examples
These examples explain how USMT deals with &lt;include&gt; and &lt;exclude&gt; rules. When the rules are in different components, the resulting behavior will be the same regardless of whether the components are in the same or in different migration .xml files.
These examples explain how USMT deals with **&lt;include&gt;** and **&lt;exclude&gt;** rules. When the rules are in different components, the resulting behavior will be the same regardless of whether the components are in the same or in different migration .xml files.
- [Including and excluding files](#filesex)
@ -154,40 +154,40 @@ These examples explain how USMT deals with &lt;include&gt; and &lt;exclude&gt; r
| If you have the following code in the same component | Resulting behavior | Explanation |
|-----|-----|-----|
| <ul><li>Include rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1* []&lt;/pattern&gt;</li><li>Exclude rule: &lt;pattern type=&quot;File&quot;&gt;C:* [.txt]&lt;/pattern&gt;</li></ul> | Migrates all files and subfolders in Dir1 (including all .txt files in C:). | The &lt;exclude&gt; rule does not affect the migration because the &lt;include&gt; rule is more specific. |
| <ul><li>Include rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1* []&lt;/pattern&gt;</li><li>Exclude rule: &lt;pattern type=&quot;File&quot;&gt;C:* [.txt]&lt;/pattern&gt;</li></ul> | Migrates all files and subfolders in Dir1 (including all .txt files in C:). | The **&lt;exclude&gt;** rule doesn't affect the migration because the **&lt;include&gt;** rule is more specific. |
| <ul><li>Include rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1* []&lt;/pattern&gt;</li><li>Exclude rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1\Dir2* [.txt]&lt;/pattern&gt;</li></ul> | Migrates all files and subfolders in C:\Dir1, except the .txt files in C:\Dir1\Dir2 and its subfolders. | Both rules are processed as intended. |
| <ul><li>Include rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1* []&lt;/pattern&gt;</li><li>Exclude rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1\ * [.txt]&lt;/pattern&gt;</li></ul> | Migrates all files and subfolders in C:\Dir1, except the .txt files in C:\Dir1 and its subfolders. | Both rules are processed as intended. |
| <ul><li>Include rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1\Dir2* [.txt]&lt;/pattern&gt;</li><li>Exclude rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1\Dir2* [.txt]&lt;/pattern&gt;</li></ul> | Nothing will be migrated. | The rules are equally specific, so the &lt;exclude&gt; rule takes precedence over the &lt;include&gt; rule. |
| <ul><li>Include rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1\Dir2* [.txt]&lt;/pattern&gt;</li><li>Exclude rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1\Dir2* [.txt]&lt;/pattern&gt;</li></ul> | Nothing will be migrated. | The rules are equally specific, so the **&lt;exclude&gt;** rule takes precedence over the **&lt;include&gt;** rule. |
| <ul><li>Include rule: C:\Dir1* [.txt]</li><li>Exclude rule: C:\Dir1\Dir2* []</li></ul> | Migrates the .txt files in Dir1 and the .txt files from subfolders other than Dir2. <br/>No files are migrated from Dir2 or its subfolders. | Both rules are processed as intended. |
| <ul><li>Include rule: C:\Dir1\Dir2* []</li><li>Exclude rule: C:\Dir1* [.txt]</li></ul> | Migrates all files and subfolders of Dir2, except the .txt files from Dir1 and any subfolders of Dir1 (including Dir2). | Both rules are processed as intended. |
| If you have the following code in different components | Resulting behavior | Explanation |
|-----|----|----|
| Component 1:<ul><li>Include rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1* []&lt;/pattern&gt;</li><li>Exclude rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1\Dir2* [.txt]&lt;/pattern&gt;</li></ul> <br/>Component 2:<ul><li>Include rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1\Dir2* [.txt]&lt;/pattern&gt;</li><li>Exclude rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1* []&lt;/pattern&gt;</li></ul> | Migrates all files and subfolders of C:\Dir1\ (including C:\Dir1\Dir2). | Rules that are in different components do not affect each other, except for the &lt;unconditionalExclude&gt; rule. Therefore, in this example, although some .txt files were excluded when Component 1 was processed, they were included when Component 2 was processed. |
| Component 1:<ul><li>Include rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1* []&lt;/pattern&gt;</li><li>Exclude rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1\Dir2* [.txt]&lt;/pattern&gt;</li></ul> <br/>Component 2:<ul><li>Include rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1\Dir2* [.txt]&lt;/pattern&gt;</li><li>Exclude rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1* []&lt;/pattern&gt;</li></ul> | Migrates all files and subfolders of C:\Dir1\ (including C:\Dir1\Dir2). | Rules that are in different components don't affect each other, except for the **&lt;unconditionalExclude&gt;** rule. Therefore, in this example, although some .txt files were excluded when Component 1 was processed, they were included when Component 2 was processed. |
| Component 1:<ul><li>Include rule: C:\Dir1\Dir2* []</li></ul> <br/>Component 2:<ul><li>Exclude rule: C:\Dir1* [.txt]</li></ul> | Migrates all files and subfolders from Dir2 except the .txt files in C:\Dir1 and its subfolders. | Both rules are processed as intended. |
| Component 1:<ul><li>Exclude rule: C:\Dir1\Dir2* []</li></ul> <br/>Component 2:<ul><li>Include rule: C:\Dir1* [.txt]</li></ul> | Migrates all .txt files in Dir1 and any subfolders. | Component 1 does not contain an &lt;include&gt; rule, so the &lt;exclude&gt; rule is not processed. |
| Component 1:<ul><li>Exclude rule: C:\Dir1\Dir2* []</li></ul> <br/>Component 2:<ul><li>Include rule: C:\Dir1* [.txt]</li></ul> | Migrates all .txt files in Dir1 and any subfolders. | Component 1 doesn't contain an **&lt;include&gt;** rule, so the **&lt;exclude&gt;** rule isn't processed. |
### <a href="" id="regex"></a>Including and excluding registry objects
| If you have the following code in the same component | Resulting behavior | Explanation |
|-----|-----|-----|
| <ul><li>Include rule: <br/>HKLM\Software\Microsoft\Command Processor* []</li><li>Exclude Rule: <br/>HKLM\Software\Microsoft\Command Processor [DefaultColor]</li></ul> | Migrates all keys in HKLM\Software\Microsoft\Command Processor except DefaultColor. | Both rules are processed as intended. |
| <ul><li>Include rule: <br/>HKLM\Software\Microsoft\Command Processor [DefaultColor]</li><li>Exclude Rule: <br/>HKLM\Software\Microsoft\Command Processor* []</li></ul> | Migrates only DefaultColor in HKLM\Software\Microsoft\Command Processor. | DefaultColor is migrated because the &lt;include&gt; rule is more specific than the &lt;exclude&gt; rule. |
| <ul><li>Include rule: <br/>HKLM\Software\Microsoft\Command Processor [DefaultColor]</li><li>Exclude rule: <br/>HKLM\Software\Microsoft\Command Processor [DefaultColor]</li></ul> | Does not migrate DefaultColor. | The rules are equally specific, so the &lt;exclude&gt; rule takes precedence over the &lt;include&gt; rule. |
| <ul><li>Include rule: <br/>HKLM\Software\Microsoft\Command Processor [DefaultColor]</li><li>Exclude Rule: <br/>HKLM\Software\Microsoft\Command Processor* []</li></ul> | Migrates only DefaultColor in HKLM\Software\Microsoft\Command Processor. | DefaultColor is migrated because the **&lt;include&gt;** rule is more specific than the **&lt;exclude&gt;** rule. |
| <ul><li>Include rule: <br/>HKLM\Software\Microsoft\Command Processor [DefaultColor]</li><li>Exclude rule: <br/>HKLM\Software\Microsoft\Command Processor [DefaultColor]</li></ul> | Doesn't migrate DefaultColor. | The rules are equally specific, so the **&lt;exclude&gt;** rule takes precedence over the &lt;include&gt; rule. |
| If you have the following code in different components | Resulting behavior | Explanation |
|-----|-----|-----|
| Component 1:<ul><li>Include rule: <br/>HKLM\Software\Microsoft\Command Processor [DefaultColor]</li><li>Exclude rule: <br/>HKLM\Software\Microsoft\Command Processor* []</li></ul> <br/>Component 2:<ul><li>Include rule: <br/>HKLM\Software\Microsoft\Command Processor* []</li><li>Exclude rule: <br/>HKLM\Software\Microsoft\Command Processor [DefaultColor]</li></ul> | Migrates all the keys/values under HKLM\Software\Microsoft\Command Processor. | Rules that are in different components do not affect each other, except for the &lt;unconditionalExclude&gt; rule. Therefore, in this example, the objects that were excluded when Component 1 was processed were included when Component 2 was processed. |
| Component 1:<ul><li>Include rule: <br/>HKLM\Software\Microsoft\Command Processor [DefaultColor]</li><li>Exclude rule: <br/>HKLM\Software\Microsoft\Command Processor* []</li></ul> <br/>Component 2:<ul><li>Include rule: <br/>HKLM\Software\Microsoft\Command Processor* []</li><li>Exclude rule: <br/>HKLM\Software\Microsoft\Command Processor [DefaultColor]</li></ul> | Migrates all the keys/values under HKLM\Software\Microsoft\Command Processor. | Rules that are in different components don't affect each other, except for the **&lt;unconditionalExclude&gt;** rule. Therefore, in this example, the objects that were excluded when Component 1 was processed were included when Component 2 was processed. |
## File collisions
### <a href="" id="collisions"></a>What is the default behavior when there are file collisions?
If there is not a &lt;merge&gt; rule, the default behavior for the registry is for the source to overwrite the destination. The default behavior for files is for the source to be renamed incrementally: for example, OriginalFileName(1).OriginalExtension, OriginalFileName(2).OriginalExtension, and so on.
If there isn't a **&lt;merge&gt;** rule, the default behavior for the registry is for the source to overwrite the destination. The default behavior for files is for the source to be renamed incrementally: for example, OriginalFileName(1).OriginalExtension, OriginalFileName(2).OriginalExtension, and so on.
### <a href="" id="bkmk11"></a>How does the &lt;merge&gt; rule work when there are file collisions?
When a collision is detected, USMT will select the most specific &lt;merge&gt; rule and apply it to resolve the conflict. For example, if you have a &lt;merge&gt; rule for C:\\\* \[\*\] set to **sourcePriority()** and another &lt;merge&gt; rule for C:\\subfolder\\\* \[\*\] set to **destinationPriority()** , then USMT uses the destinationPriority() rule because it is the most specific.
When a collision is detected, USMT will select the most specific **&lt;merge&gt;** rule and apply it to resolve the conflict. For example, if you have a **&lt;merge&gt;** rule for **C:\\\* \[\*\]** set to **sourcePriority()** and another **&lt;merge&gt;** rule for **C:\\subfolder\\\* \[\*\]** set to **destinationPriority()** , then USMT uses the **destinationPriority()** rule because it's the most specific.
### Example scenario
@ -227,7 +227,7 @@ For this example, the following information describes the resulting behavior if
</merge>
```
**Result**: During ScanState, all the files will be added to the store. During LoadState, only C:\Data\SampleA.txt will be restored.
**Result**: During ScanState, all the files will be added to the store. During LoadState, only `C:\Data\SampleA.txt` will be restored.
**Example 2**
@ -252,12 +252,12 @@ During LoadState, all the files will be restored, overwriting the existing files
</merge>
```
**Result**: During ScanState, all the files will be added to the store. During LoadState, the following will occur:
**Result**: During ScanState, all the files will be added to the store. During LoadState, the following actions will occur:
- C:\Data\SampleA.txt will be restored.
- C:\Data\SampleB.txt will be restored, overwriting the existing file on the destination computer.
- C:\Data\Folder\SampleB.txt will not be restored.
- `C:\Data\SampleA.txt` will be restored.
- `C:\Data\SampleB.txt` will be restored, overwriting the existing file on the destination computer.
- `C:\Data\Folder\SampleB.txt` won't be restored.
## Related topics
## Related articles
[USMT XML Reference](usmt-xml-reference.md)

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

@ -15,7 +15,12 @@ ms.date: 11/01/2022
## <a href="" id="example"></a>Example 1: Migrating an Unsupported Application
The following is a template for the sections that you need to migrate your application. The template isn't functional on its own, but you can use it to write your own .xml file.
The following template is a template for the sections that you need to migrate your application. The template isn't functional on its own, but you can use it to write your own .xml file.
**Template**
<br>
<details>
<summary>Expand to show Example 1 application template:</summary>
``` xml
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/migtestapp">
@ -80,26 +85,30 @@ The following is a template for the sections that you need to migrate your appli
</component>
</migration>
```
</details>
## <a href="" id="example2"></a>Example 2: Migrating the My Videos Folder
The following sample is a custom .xml file named CustomFile.xml that migrates My Videos for all users, if the folder exists on the source computer.
The following sample is a custom .xml file named `CustomFile.xml` that migrates **My Videos** for all users, if the folder exists on the source computer.
- **Sample condition**: Verifies that My Videos exists on the source computer:
- **Sample condition**: Verifies that **My Videos** exists on the source computer:
`<condition>MigXmlHelper.DoesObjectExist("File","%CSIDL_MYVIDEO%")</condition>`
- **Sample filter**: Filters out the shortcuts in My Videos that don't resolve on the destination computer:
- **Sample filter**: Filters out the shortcuts in **My Videos** that don't resolve on the destination computer:
`<include filter='MigXmlHelper.IgnoreIrrelevantLinks()'>`
This has no effect on files that aren't shortcuts. For example, if there's a shortcut in My Videos on the source computer that points to C:\Folder1, that shortcut will be migrated only if C:\Folder1 exists on the destination computer. However, all other files, such as .mp3 files, migrate without any filtering.
This filter has no effect on files that aren't shortcuts. For example, if there's a shortcut in **My Videos** on the source computer that points to `C:\Folder1`, that shortcut will be migrated only if `C:\Folder1` exists on the destination computer. However, all other files, such as .mp3 files, migrate without any filtering.
- **Sample pattern**: Migrates My Videos for all users:
- **Sample pattern**: Migrates **My Videos** for all users:
`<pattern type="File">%CSIDL_MYVIDEO%* [*]</pattern>`
**XML file**
<br>
<details>
<summary>Expand to show Example 2 XML file:</summary>
```xml
<?xml version="1.0" encoding="UTF-8"?>
@ -123,12 +132,13 @@ The following sample is a custom .xml file named CustomFile.xml that migrates My
</component>
</migration>
```
</details>
## <a href="" id="example3"></a>Example 3: Migrating Files and Registry Keys
The sample patterns describe the behavior in the following example .xml file.
- **Sample pattern**: Migrates all instances of the file Usmttestfile.txt from all subdirectories under `%ProgramFiles%\USMTTestFolder`:
- **Sample pattern**: Migrates all instances of the file `Usmttestfile.txt` from all subdirectories under `%ProgramFiles%\USMTTestFolder`:
`<pattern type="File">%ProgramFiles%\USMTTestFolder* [USMTTestFile.txt]</pattern>`
@ -145,6 +155,9 @@ The sample patterns describe the behavior in the following example .xml file.
`<pattern type="Registry">HKLM\Software\USMTTESTKEY* []</pattern>`
**XML file**
<br>
<details>
<summary>Expand to show Example 3 XML file:</summary>
``` xml
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/testfilemig">
@ -176,12 +189,17 @@ 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
The behavior for this custom .xml file is described within the `<displayName>` tags in the code.
**XML file**
<br>
<details>
<summary>Expand to show Example 4 XML file:</summary>
``` xml
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test">
@ -250,8 +268,9 @@ The behavior for this custom .xml file is described within the `<displayName>` t
</component>
</migration>
```
</details>
## Related topics
## Related articles
[USMT XML Reference](usmt-xml-reference.md)

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

@ -13,10 +13,8 @@ ms.technology: itpro-deploy
# Customize USMT XML Files
## In This Topic
[Overview](#bkmk-overview)
[Migration .xml Files](#bkmk-migxml)
@ -31,78 +29,72 @@ ms.technology: itpro-deploy
## <a href="" id="bkmk-overview"></a>Overview
If you want the ScanState and LoadState tools to use any of the migration .xml files, specify these files at the command line using the `/i` option. Because the ScanState and LoadState tools need the .xml files to control the migration, specify the same set of .xml files for both the `ScanState.exe` and `LoadState.exe` commands. However, you don't have to specify the `Config.xml` file with the `/config` option, 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 achieve this scenario, modify the `Config.xml` file and specify the updated file with the `LoadState.exe` command. Then the `LoadState.exe` command will migrate only the files and settings that you want to migrate.
If you want the **ScanState** and **LoadState** tools to use any of the migration .xml files, specify these files at the command line using the **/i** option. Because the **ScanState** and **LoadState** tools need the .xml files to control the migration, specify the same set of .xml files for both the **ScanState** and **LoadState** commands. However, you do not have to specify the Config.xml file with the **/config** option, 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 with the **LoadState** command. Then the **LoadState** command will migrate only the files and settings that you want to migrate.
If you leave out an .xml file from the `LoadState.exe` command, all of the data in the store that was migrated with the missing .xml files will be migrated. However, the migration rules that were specified with the `ScanState.exe` command won't apply. For example, if you leave out an .xml file, and it contains a rerouting rule such as:
If you leave out an .xml file from the **LoadState** command, all of the data in the store that was migrated with the missing .xml files will be migrated. However, the migration rules that were specified with the **ScanState** command will not apply. For example, if you leave out an .xml file, and it contains a rerouting rule such as: `MigsysHelperFunction.RelativeMove("c:\data", "%CSIDL_PERSONAL%")`, USMT will not reroute the files, and they will be migrated to C:\\data.
`MigsysHelperFunction.RelativeMove("c:\data", "%CSIDL_PERSONAL%")`
USMT won't reroute the files, and they'll be migrated to `C:\data`.
To modify the migration, do one or more of the following.
- **Modify the migration .xml files.** If you want to exclude a portion of a component—for example, you want to migrate C:\\ but exclude all of the .mp3 files—or if you want to move data to a new location on the destination computer, modify the .xml files. To modify these files, you must be familiar with the migration rules and syntax. If you want **ScanState** and **LoadState** to use these files, specify them at the command line when each command is entered.
- **Modify the migration .xml files.** If you want to exclude a portion of a component—for example, you want to migrate C:\\ but exclude all of the .mp3 files—or if you want to move data to a new location on the destination computer, modify the .xml files. To modify these files, you must be familiar with the migration rules and syntax. If you want ScanState and LoadState to use these files, specify them at the command line when each command is entered.
- **Create a custom .xml file.** You can also create a custom .xml file to migrate settings for another application, or to change the migration behavior to suit your needs. For **ScanState** and **LoadState** to use this file, specify them on both command lines.
- **Create a custom .xml file.** You can also create a custom .xml file to migrate settings for another application, or to change the migration behavior to suit your needs. For ScanState and LoadState to use this file, specify them on both command lines.
- **Create and modify a Config.xml file.** Do this if you want to exclude an entire component from the migration. For example, you can use a Config.xml file to exclude the entire My Documents folder, or exclude the settings for an application. Excluding components using a Config.xml file is easier than modifying the migration .xml files because you do not need to be familiar with the migration rules and syntax. In addition, using a Config.xml file is the only way to exclude the operating system settings from being migrated.
- **Create and modify a Config.xml file.** Create and modify a `Config.xml` file if you want to exclude an entire component from the migration. For example, you can use a `Config.xml` file to exclude the entire My Documents folder, or exclude the settings for an application. Excluding components using a `Config.xml` file is easier than modifying the migration .xml files because you don't need to be familiar with the migration rules and syntax. In addition, using a `Config.xml` file is the only way to exclude the operating system settings from being migrated.
For more information about excluding data, see the [Exclude Files and Settings](usmt-exclude-files-and-settings.md) topic.
For more information about excluding data, see the [Exclude Files and Settings](usmt-exclude-files-and-settings.md) article.
## <a href="" id="bkmk-migxml"></a>Migration .xml Files
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.
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 are migrated to on the destination computer.
> [!Note]
> You can use the asterisk (\*) wildcard character in each of these files. However, you cannot use a question mark (?) as a wildcard character.
**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.
- **The MigDocs.xml file.** Specify this file with both the ScanState and LoadState tools to migrate all user folders and files that are found by the **MigXmlHelper.GenerateDocPatterns** helper function. This helper function finds user data that resides on the root of any drive and in the Users directory. However, it doesn't find and migrate any application data, program files, or any files in the Windows directory. You can modify the `MigDocs.xml` file.
- **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.
- **The MigApp.xml file.** Specify this file with both the **ScanState** and **LoadState** commands to migrate application settings.
- **The MigDocs.xml file.** Specify this file with both the **ScanState** and **LoadState** tools to migrate all user folders and files that are found by the **MigXmlHelper.GenerateDocPatterns** helper function. This helper function finds user data that resides on the root of any drive and in the Users directory. However, it does not find and migrate any application data, program files, or any files in the Windows directory. You can modify the MigDocs.xml file.
- **The MigUser.xml file.** Specify this file with both the **ScanState** and **LoadState** commands to migrate user folders, files, and file types. You can modify the MigUser.xml file. This file does not 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**  
Do not 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) topics.
> [!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
You can create custom .xml files to customize the migration for your unique needs. For example, you may want to create a custom file to migrate a line-of-business application or to modify the default migration behavior. If you want **ScanState** and **LoadState** to use this file, specify it with both commands. For more information, see the How to Create a Custom .xml File topic.
You can create custom .xml files to customize the migration for your unique needs. For example, you may want to create a custom file to migrate a line-of-business application or to modify the default migration behavior. If you want `ScanState.exe` and `LoadState.exe` to use this file, specify it with both commands. For more information, see the [Custom XML Examples](usmt-custom-xml-examples.md) article.
## <a href="" id="bkmk-configxml"></a>The Config.xml File
The `Config.xml` file is an optional file that you create using the `/genconfig` option with the `ScanState.exe` command. You should create and modify this file if you want to exclude certain components from the migration. In addition, you must create and modify this file if you want to exclude any of the operating system settings from being migrated. The `Config.xml` file format is different from the migration .xml files because it doesn't contain any migration rules. It contains only a list of the operating system components, applications, and the user documents that can be migrated. For an example, see the [Config.xml File](usmt-configxml-file.md) article. For this reason, excluding components using this file is easier than modifying the migration .xml files because you don't need to be familiar with the migration rules and syntax. However, you can't use wildcard characters in a `Config.xml` file.
The Config.xml file is an optional file that you create using the **/genconfig** option with the **ScanState** command. You should create and modify this file if you want to exclude certain components from the migration. In addition, you must create and modify this file if you want to exclude any of the operating system settings from being migrated. The Config.xml file format is different from that of the migration .xml files because it does not contain any migration rules. It contains only a list of the operating system components, applications, and the user documents that can be migrated. For an example, see the [Config.xml File](usmt-configxml-file.md) topic. For this reason, excluding components using this file is easier than modifying the migration .xml files because you do not need to be familiar with the migration rules and syntax. However, you cannot use wildcard characters in a Config.xml file.
If you want to include all of the default components, you don't need to create the `Config.xml` file. Alternatively, if you're satisfied with the default migration behavior defined in the `MigApp.xml`, `MigDocs.xml`, and `MigUser.xml` files, and you want to exclude only some components, you can create and modify a `Config.xml` file and leave the other .xml files in their original state.
If you want to include all of the default components, you do not need to create the Config.xml file. Alternatively, if you are satisfied with the default migration behavior defined in the MigApp.xml, MigDocs.xml, and MigUser.xml files, and you want to exclude only some components, you can create and modify a Config.xml file and leave the other .xml files in their original state.
When you run the `ScanState.exe` command with the `/genconfig` option, `ScanState.exe` reads the other .xml files that you specify using the `/i` option to create a custom list of components that can be migrated from the computer. This file will contain only operating system components, applications, and the user document sections that are in both of the .xml files and that are installed on the computer when you run the `ScanState.exe` command with the `/genconfig` option. Therefore, you should create this file on a source computer that contains all of the components, applications, and settings that will be present on the destination computers. Creating the file on the source computer will ensure that this file contains every component that can be migrated. The components are organized into sections: &lt;Applications&gt;, &lt;WindowsComponents&gt;, and &lt;Documents&gt;. To choose not to migrate a component, change its entry to `migrate="no"`.
When you run the **ScanState** command with the **/genconfig** option, **ScanState** reads the other .xml files that you specify using the **/i** option to create a custom list of components that can be migrated from the computer. This file will contain only operating system components, applications, and the user document sections that are in both of the .xml files and that are installed on the computer when you run the **ScanState** command with the **/genconfig** option. Therefore, you should create this file on a source computer that contains all of the components, applications, and settings that will be present on the destination computers. This will ensure that this file contains every component that can be migrated. The components are organized into sections: &lt;Applications&gt;, &lt;WindowsComponents&gt;, and &lt;Documents&gt;. To choose not to migrate a component, change its entry to `migrate="no"`.
After you create this file, you need to specify it only with the `ScanState.exe` command using the `/Config` option for it to affect the migration. However, if you want to exclude additional data that you migrated to the store, modify the `Config.xml` file and specify the updated file with the `LoadState.exe` command. For example, if you collected the My Documents folder in the store, but you decide that you don't want to migrate the My Documents folder to a destination computer, you can modify the `Config.xml` file to indicate `migrate="no"` before you run the `LoadState.exe` command, and the file won't be migrated. For more information about the precedence that takes place when excluding data, see the [Exclude Files and Settings](usmt-exclude-files-and-settings.md) article.
After you create this file, you need to specify it only with the **ScanState** command using the **/Config** option for it to affect the migration. However, if you want to exclude additional data that you migrated to the store, modify the Config.xml file and specify the updated file with the **LoadState** command. For example, if you collected the My Documents folder in the store, but you decide that you do not want to migrate the My Documents folder to a destination computer, you can modify the Config.xml file to indicate `migrate="no"` before you run the **LoadState** command, and the file will not be migrated. For more information about the precedence that takes place when excluding data, see the [Exclude Files and Settings](usmt-exclude-files-and-settings.md) topic.
In addition, note the following functionality with the `Config.xml` file:
In addition, note the following functionality with the Config.xml file:
- If a parent component is removed from the migration in the Config.xml file by specifying `migrate="no"`, all of its child components will automatically be removed from the migration, even if the child component is set to `migrate="yes"`.
- If a parent component is removed from the migration in the `Config.xml` file by specifying `migrate="no"`, all of its child components will automatically be removed from the migration, even if the child component is set to `migrate="yes"`.
- If you mistakenly have two lines of code for the same component where one line specifies `migrate="no"` and the other line specifies `migrate="yes"`, the component will be migrated.
- 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) topic.
**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 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]
> 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
- The following command creates a Config.xml file in the current directory, but it does not create a store:
- The following command creates a `Config.xml` file in the current directory, but it doesn't create a store:
`scanstate /i:migapp.xml /i:migdocs.xml /genconfig:config.xml /v:5`
- The following command creates an encrypted store using the Config.xml file and the default migration .xml files:
- The following command creates an encrypted store using the `Config.xml` file and the default migration .xml files:
`scanstate \\server\share\migration\mystore /i:migapp.xml /i:migdocs.xml /o /config:config.xml /v:5 /encrypt /key:"mykey"`
@ -115,22 +107,12 @@ To exclude a component from the Config.xml file, set the **migrate** value to **
- 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) topic.
- For more information about each .xml element, see the [XML Elements Library](usmt-xml-elements-library.md) article.
- For answers to common questions, see ".xml files" in the [Frequently Asked Questions](usmt-faq.yml) topic.
## Related topics
- For answers to common questions, see ".xml files" in the [Frequently Asked Questions](usmt-faq.yml) article.
## Related articles
[User State Migration Tool (USMT) Command-line Syntax](usmt-command-line-syntax.md)
[USMT Resources](usmt-resources.md)

16
windows/deployment/usmt/usmt-determine-what-to-migrate.md
View File

@ -1,6 +1,6 @@
---
title: Determine What to Migrate (Windows 10)
description: Determine migration settings for standard or customized for the User State Migration Tool (USMT) 10.0.
description: Determine migration settings for standard or customized for the User State Migration Tool (USMT) 10.0.
ms.reviewer:
manager: aaroncz
ms.author: frankroj
@ -13,11 +13,19 @@ ms.technology: itpro-deploy
# Determine What to Migrate
By default, User State Migration Tool (USMT) 10.0 migrates the items listed in [What Does USMT Migrate?](usmt-what-does-usmt-migrate.md), depending on the migration .xml files you specify. These default settings are often enough for a basic migration.
By default, User State Migration Tool (USMT) 10.0 migrates the items listed in [What Does USMT Migrate?](usmt-what-does-usmt-migrate.md), depending on the migration .xml files you specify. These default settings are often enough for a basic migration.
However, when considering what settings to migrate, you should also consider what settings you would like the user to be able to configure, if any, and what settings you would like to standardize. Many organizations use their migration as an opportunity to create and begin enforcing a better-managed environment. Some of the settings that users can configure on unmanaged computers prior to the migration can be locked on the new, managed computers. For example, standard wallpaper, Internet Explorer security settings, and desktop configuration are some of the items you can choose to standardize.
To reduce complexity and increase standardization, your organization should consider creating a *standard operating environment (SOE)*. An SOE is a combination of hardware and software that you distribute to all users. This means selecting a baseline for all computers, including standard hardware drivers; core operating system features; core productivity applications, especially if they are under volume licensing; and core utilities. This environment should also include a standard set of security features, as outlined in the organization’s corporate policy. Using a standard operating environment can vastly simplify the migration and reduce overall deployment challenges.
To reduce complexity and increase standardization, your organization should consider creating a *standard operating environment (SOE)*. An SOE is a combination of hardware and software that you distribute to all users. Creating an SOE means selecting:
- A baseline for all computers, including standard hardware drivers
- Core operating system features
- Core productivity applications, especially if they are under volume licensing
- Core utilities.
- A standard set of security features, as outlined in the organization's corporate policy
Using an SOE can vastly simplify the migration and reduce overall deployment challenges.
## In This Section
@ -28,6 +36,6 @@ To reduce complexity and increase standardization, your organization should cons
|[Identify Operating System Settings](usmt-identify-operating-system-settings.md)|Use migration to create a new standard environment on each of the destination computers.|
|[Identify File Types, Files, and Folders](usmt-identify-file-types-files-and-folders.md)|Determine and locate the standard, company-specified, and non-standard locations of the file types, files, folders, and settings that you want to migrate.|
## Related topics
## Related articles
[What Does USMT Migrate?](usmt-what-does-usmt-migrate.md)