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

Metadata update deployment/usmt 2

Browse Source
This commit is contained in:
Frank Rojas
2022-11-01 11:45:19 -04:00
parent 8c2b1e1c8a
commit 7db47bb3b0
3 changed files with 73 additions and 105 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@ -12,9 +12,9 @@ ms.date: 11/01/2022
---
# Getting Started with the User State Migration Tool (USMT)
This topic outlines the general process that you should follow to migrate files and settings.
This article outlines the general process that you should follow to migrate files and settings.
## In this topic
## In this article
- [Step 1: Plan Your Migration](#step-1-plan-your-migration)
- [Step 2: Collect files and settings from the source computer](#step-2-collect-files-and-settings-from-the-source-computer)
@ -22,64 +22,67 @@ This topic outlines the general process that you should follow to migrate files
- [Step 3: Prepare the destination computer and restore files and settings](#step-3-prepare-the-destination-computer-and-restore-files-and-settings)
## Step 1: Plan your migration
1. [Plan Your Migration](usmt-plan-your-migration.md). Depending on whether your migration scenario is refreshing or replacing computers, you can choose an online migration or an offline migration using Windows Preinstallation Environment (WinPE) or the files in the Windows.old directory. For more information, see [Common Migration Scenarios](usmt-common-migration-scenarios.md).
2. [Determine What to Migrate](usmt-determine-what-to-migrate.md). Data you might consider migrating includes end-user information, applications settings, operating-system settings, files, folders, and registry keys.
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 is 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.
**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).
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:
`scanstate /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 do not 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.
**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.
> [!Note]
> USMT will fail if it cannot migrate a file or setting unless you specify the **/C** option. When you specify the **/C** option, USMT will ignore the errors, and log an error every time that it encounters a file that is being used that USMT did not migrate. You can use the **<ErrorControl>** section in the Config.xml file to specify which errors should be ignored, and which should cause the migration to fail.
3. Run the **ScanState** 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,
`scanstate \\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).
> [!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).
4. Run the **USMTUtils** command with the **/Verify** option to ensure that the store you created is not corrupted.
4. Run the **USMTUtils** 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
1. Install the operating system on the destination computer.
2. Install all applications that were on the source computer. Although it is not always required, we recommend installing all applications on the destination computer before you restore the user state. This makes sure that migrated settings are preserved.
2. Install all applications that were on the source computer. Although it isn't always required, we recommend installing all applications on the destination computer before you restore the user state. This makes sure that migrated settings are preserved.
**Note**  
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® Office, which USMT can migrate from an older version to a newer version.
> [!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® 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** 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 **<ErrorControl>** section in the Config.xml file to specify which errors should be ignored, and which errors should cause the migration to fail.
> [!Note]
> Use **/C** to continue your migration if errors are encountered, and use the **<ErrorControl>** section in the Config.xml file to specify which errors should be ignored, and which errors should cause the migration to fail.
4. Run the **LoadState** command on the destination computer. Specify the same set of .xml files that you specified when you used the **ScanState** command. However, you do not 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 the how the **LoadState** command processes and migrates data, see [How USMT Works](usmt-how-it-works.md).
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).
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`
**Note**  
Run the **LoadState** command in administrator mode. To do this, right-click **Command Prompt**, and then click **Run As Administrator**.
> [!Note]
> Run the **LoadState** 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) will not take effect until the next time that the user logs on.
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.

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

@ -13,19 +13,17 @@ ms.technology: itpro-deploy
# Migrate Application Settings
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.
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 topic defines how to author a custom migration .xml file that migrates the settings of an application that is not 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 topic does not 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 does not 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 topic does not discuss how to migrate the .doc files and templates themselves.
## <a href="" id="createxmlmigappsettings"></a>In this Topic
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.
## <a href="" id="createxmlmigappsettings"></a>In this article
- [Before You Begin](#bkmk-beforebegin)
- [Step 1: Verify that the application is installed on the source computer, and that it is the same version as the version to be installed on the destination computer](#bkmk-step1).
- [Step 1: Verify that the application is installed on the source computer, and that it's the same version as the version to be installed on the destination computer](#bkmk-step1).
- [Step 2: Identify settings to collect and determine where each setting is stored on the computer](#bkmk-step2).
@ -37,30 +35,27 @@ This topic does not contain information about how to migrate applications that s
## <a href="" id="bkmk-beforebegin"></a>Before You Begin
You should identify a test computer that contains the operating system of your source computers, and the application whose settings you want to migrate. For example, if you're planning on migrating from Windows 7 to Windows 10, install Windows 7 on your test computer and then install the application.
You should identify a test computer that contains the operating system of your source computers, and the application whose settings you want to migrate. For example, if you are planning on migrating from Windows 7 to Windows 10, install Windows 7 on your test computer and then install the application.
## <a href="" id="bkmk-step1"></a>Step 1: Verify that the application is installed on the source computer, and that it's the same version as the version to be installed on the destination computer.
## <a href="" id="bkmk-step1"></a>Step 1: Verify that the application is installed on the source computer, and that it is the same version as the version to be installed on the destination computer.
Before USMT migrates the settings, you need it to check whether the application is installed on the source computer, and that it's the correct version. If the application isn't installed on the source computer, you probably don't want USMT to spend time searching for the application's settings. More importantly, if USMT collects settings for an application that isn't installed, it may migrate settings that will cause the destination computer to function incorrectly. You should also investigate whether there's more than one version of the application because the new version may not store the settings in the same place. Mismatched application versions may lead to unexpected results on the destination computer.
Before USMT migrates the settings, you need it to check whether the application is installed on the source computer, and that it is the correct version. If the application is not installed on the source computer, you probably do not want USMT to spend time searching for the application’s settings. More importantly, if USMT collects settings for an application that is not installed, it may migrate settings that will cause the destination computer to function incorrectly. You should also investigate whether there is more than one version of the application. This is because the new version may not store the settings in the same place, which may lead to unexpected results on the destination computer.
There are many ways to detect if an application is installed. The best practice is to check for an application uninstall key in the registry, and then search the computer for the executable file that installed the application. It is important that you check for both of these items, because sometimes different versions of the same application share the same uninstall key. So even if the key is there, it may not correspond to the version of the application that you want.
There are many ways to detect if an application is installed. The best practice is to check for an application uninstall key in the registry, and then search the computer for the executable file that installed the application. It's important that you check for both of these items, because sometimes different versions of the same application share the same uninstall key. So even if the key is there, it may not correspond to the version of the application that you want.
### Check the registry for an application uninstall key.
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 **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 do this, you will 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 have 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 do this, 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.
Next, you should go through the user interface and make a list of all of the available settings. You can reduce the list if there are settings that you do not want to migrate. To determine where each setting is stored, you will need to change each setting and monitor the activity on the registry and the file system. You do not need to migrate the binary files and registry settings that are made when the application is installed. This is because you will need to reinstall the application onto the destination computer. You only need to migrate those settings that are customizable.
Next, you should go through the user interface and make a list of all of the available settings. You can reduce the list if there are settings that you don't want to migrate. To determine where each setting is stored, you'll need to change each setting and monitor the activity on the registry and the file system. You don't need to migrate the binary files and registry settings that are made when the application is installed because you'll need to reinstall the application onto the destination computer. You only need to migrate those settings that are customizable.
### <a href="" id="bkmkdetermine"></a>
@ -72,59 +67,49 @@ 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.
> [!Note]
> Most applications store their settings under the user profile. That is, the settings stored in the file system are under the %**UserProfile**% directory, and the settings stored in the registry are under the **HKEY\_CURRENT\_USER** hive. For these applications you can filter the output of the file and registry monitoring tools to show activity only under these locations. This will considerably reduce the amount of output that you will need to examine.
4. Start the monitoring tool(s), change a setting, and look for registry and file system writes that occurred when you changed the setting. Make sure the changes you make actually take effect. For example, if you are changing a setting in Microsoft Word by selecting a check box in the **Options** dialog box, the change typically will not take effect until you close the dialog box by clicking **OK**.
4. Start the monitoring tool(s), change a setting, and look for registry and file system writes that occurred when you changed the setting. Make sure the changes you make actually take effect. For example, if you're changing a setting in Microsoft Word by selecting a check box in the **Options** dialog box, the change typically won't take effect until you close the dialog box by clicking **OK**.
5. When the setting is changed, note the changes to the file system and registry. There may be more than one file or registry values for each setting. You should identify the minimal set of file and registry changes that are required to change this setting. This set of files and registry keys is what you will need to migrate in order to migrate the setting.
**Note**  
Changing an application setting invariably leads to writing to registry keys. If possible, filter the output of the file and registry monitor tool to display only writes to files and registry keys/values.
> [!Note]
> Changing an application setting invariably leads to writing to registry keys. If possible, filter the output of the file and registry monitor tool to display only writes to files and registry keys/values.
## <a href="" id="bkmk-step3"></a>Step 3: Identify how to apply the gathered settings.
If the version of the application on the source computer is the same as the one on the destination computer, then you do not 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.
In this case, the newer version of the application may be able to read the settings from the source computer without modification. That is, the data collected from an older version of the application is sometimes compatible with the newer version of the application. However, you may need to modify the setting location if either of the following is true:
In this case, the newer version of the application may be able to read the settings from the source computer without modification. That is, the data collected from an older version of the application is sometimes compatible with the newer version of the application. However, you may need to modify the setting location if either of the following conditions is true:
- **The newer version of the application has the ability to import settings from an older version.** This mapping usually happens the first time a user runs the newer version after the settings have been migrated. Some applications do this automatically after settings are migrated; however, other applications will only do this 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 does not contain this set of files and registry keys so the mapping does not 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.
- **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.
- [The newer version of the application cannot read settings from the source computer and it is also unable to import the settings into the new format.](#bkmkdetermine) In this case, you will need to create a mapping for each setting from the old locations to the new locations. To do this, determine where the newer version stores each setting using the process described in How to determine where each setting is stored. After you have 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 because this 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 is installed.
### Case 3: The application overwrites settings when it's installed.
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 because this ensures that there are no settings on the destination computer when you migrate the settings. Also, when some applications are installed, they overwrite any existing settings that are on the computer. In this scenario, if you migrated the data before you installed the application, your customized settings would be overwritten. This is common for applications that store settings in locations that are outside of the user profile (typically these are settings that apply to all users). These universal settings are sometimes overwritten when an application is installed, and they are replaced by default values. To avoid this, you must install these applications before migrating the files and settings to the destination computer. By default with USMT, data from the source computer overwrites data that already exists in the same location on the destination computer.
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. Also, when some applications are installed, they overwrite any existing settings that are on the computer. In this scenario, if you migrated the data before you installed the application, your customized settings would be overwritten. This scenario is common for applications that store settings in locations that are outside of the user profile (typically these settings are settings that apply to all users). These universal settings are sometimes overwritten when an application is installed, and they're replaced by default values. To avoid this problem, you must install these applications before migrating the files and settings to the destination computer. By default with USMT, data from the source computer overwrites data that already exists in the same location on the destination computer.
## <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 will 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 topic. 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.
**Note**  
We recommend that you create a separate .xml file instead of adding your script to the **MigApp.xml** file. This is because the **MigApp.xml** file is a very large file and it will be difficult to read and edit. In addition, if you reinstall USMT for some reason, the **MigApp.xml** file will be overwritten by the default version of the file and you will lose your customized version.
> [!Important]
> 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.
**Important**  
Some applications store information in the user profile that should not be migrated (for example, application installation paths, the computer name, and so on). You should make sure to exclude these files and registry keys from the migration.
Your script should do the following:
Your script should do the following actions:
1. Check whether the application and correct version is installed by:
@ -136,7 +121,7 @@ Your script should do the following:
- 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 cannot 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 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 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.
@ -144,13 +129,11 @@ For information about the .xml elements and helper functions, see [XML Elements
## <a href="" id="bkmk-step5"></a>Step 5: Test the application settings migration
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.
On a test computer, install the operating system that will be installed on the destination computers. For example, if you are 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 are 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) topic. 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 topics
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
[USMT XML Reference](usmt-xml-reference.md)
@ -158,7 +141,4 @@ To speed up the time it takes to collect and migrate the data, you can migrate o
[XML Elements Library](usmt-xml-elements-library.md)
[Log Files](usmt-log-files.md)
[Log Files](usmt-log-files.md)

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

@ -13,11 +13,9 @@ ms.technology: itpro-deploy
# Migration Store Types Overview
When planning your migration, you should 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. You should also determine the space needed to create and host the migration store, whether you're using a local share, network share, or storage device.
When planning your migration, you should 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. You should also determine the space needed to create and host the migration store, whether you are using a local share, network share, or storage device.
## In This Topic
## In this article
[Migration Store Types](#bkmk-types)
@ -27,22 +25,21 @@ When planning your migration, you should determine which migration store type be
## <a href="" id="bkmk-types"></a>Migration Store Types
This section describes the three migration store types available in USMT.
### Uncompressed (UNC)
The uncompressed (UNC) migration store is an uncompressed directory with a mirror image of the folder hierarchy being migrated. Each directory and file retains the same access permissions that it has on the local file system. You can use Windows Explorer to view this migration store type. Settings are stored in a catalog file that also describes how to restore files on the destination computer.
The uncompressed (UNC) migration store is an uncompressed directory with a mirror image of the folder hierarchy being migrated. Each directory and file retains the same access permissions that it has on the local file system. You can use Windows Explorer to view this migration store type. Settings are stored in a catalog file that also describes how to restore files on the destination computer.
### Compressed
The compressed migration store is a single image file that contains all files being migrated and a catalog file. This image file is often encrypted and protected with a password, and cannot be navigated with Windows Explorer.
The compressed migration store is a single image file that contains all files being migrated and a catalog file. This image file is often encrypted and protected with a password, and can't be navigated with Windows Explorer.
### Hard-Link
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. This is 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.
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 are not 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 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).
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.
@ -51,29 +48,17 @@ The following flowchart illustrates the procedural differences between a local m
## <a href="" id="bkmk-localvremote"></a>Local Store vs. Remote Store
If you have enough space and you are 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 are 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 is also good practice to ensure that the migration is the only task the server is performing.
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 is not enough local disk space, or if you are 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, you do not 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 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.
**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.
> [!Important]
> If possible, have users store their data within their %UserProfile%\\My Documents and %UserProfile%\\Application Data folders. This will reduce the chance of USMT missing critical user data that is located in a directory that USMT is not configured to check.
### <a href="" id="bkmk-localonly"></a>The /localonly Command-Line Option
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 topics
[Plan Your Migration](usmt-plan-your-migration.md)
## Related articles
[Plan Your Migration](usmt-plan-your-migration.md)