mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-16 10:53:43 +00:00
Metadata update deployment/usmt 7
This commit is contained in:
Frank Rojas
@ -21,23 +21,23 @@ This article doesn't contain information about how to migrate applications that
|
||||
|
||||
## In this topic
|
||||
|
||||
- [Before You Begin](#bkmk-beforebegin)
|
||||
- [Before You Begin](#before-you-begin)
|
||||
|
||||
- [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 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](#step-1-verify-that-the-application-is-installed-on-the-source-computer-and-that-its-the-same-version-as-the-version-to-be-installed-on-the-destination-computer).
|
||||
|
||||
- [Step 2: Identify settings to collect and determine where each setting is stored on the computer](#bkmk-step2).
|
||||
- [Step 2: Identify settings to collect and determine where each setting is stored on the computer](#step-2-identify-settings-to-collect-and-determine-where-each-setting-is-stored-on-the-computer).
|
||||
|
||||
- [Step 3: Identify how to apply the gathered settings](#bkmk-step3).
|
||||
- [Step 3: Identify how to apply the gathered settings](#step-3-identify-how-to-apply-the-gathered-settings).
|
||||
|
||||
- [Step 4: Create the migration XML component for the application](#bkmk-step4).
|
||||
- [Step 4: Create the migration XML component for the application](#step-4-create-the-migration-xml-component-for-the-application).
|
||||
|
||||
- [Step 5: Test the application settings migration](#bkmk-step5).
|
||||
- [Step 5: Test the application settings migration](#step-5-test-the-application-settings-migration).
|
||||
|
||||
## <a href="" id="bkmk-beforebegin"></a> Before You Begin
|
||||
## 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.
|
||||
|
||||
## <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
|
||||
## Step 1: Verify that the application is installed on the source computer, and that it's the same version as the version to be installed on the destination computer
|
||||
|
||||
Before USMT migrates the settings, you need it to check whether the application is installed on the source computer, and that it's the correct version. If the application isn't installed on the source computer, you probably don't want USMT to spend time searching for the application's settings. More importantly, if USMT collects settings for an application that isn't installed, it may migrate settings that will cause the destination computer to function incorrectly. You should also investigate whether there's more than one version of the application because the new version may not store the settings in the same place. Mismatched application versions may lead to unexpected results on the destination computer.
|
||||
|
||||
@ -65,7 +65,7 @@ for the name of the application, the name of the application executable file, or
|
||||
|
||||
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
|
||||
## Step 2: Identify settings to collect and determine where each setting is stored on the computer
|
||||
|
||||
Next, you should go through the user interface and make a list of all of the available settings. You can reduce the list if there are settings that you don't want to migrate. To determine where each setting is stored, you'll need to change each setting and monitor the activity on the registry and the file system. You don't need to migrate the binary files and registry settings that are made when the application is installed because you'll need to reinstall the application onto the destination computer. You only need to migrate those settings that are customizable.
|
||||
|
||||
@ -87,7 +87,7 @@ Next, you should go through the user interface and make a list of all of the ava
|
||||
> [!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
|
||||
## 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:
|
||||
|
||||
@ -101,15 +101,15 @@ In this case, the newer version of the application may be able to read the setti
|
||||
|
||||
- **The newer version of the application can't read settings from the source computer and it's also unable to import the settings into the new format.** In this case, you'll need to create a mapping for each setting from the old locations to the new locations. To create the mapping, determine where the newer version stores each setting using the process described in [How to determine where each setting is stored](#how-to-determine-where-each-setting-is-stored). After you've created the mapping, apply the settings to the new location on the destination computer using the **<locationModify>** element, and the `RelativeMove` and `ExactMove` helper functions.
|
||||
|
||||
### Case 2: The destination computer already contains settings for the application.
|
||||
### 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 **<destinationCleanup>** element. If for any reason you want to preserve the settings that are on the destination computer, you can use the **<merge>** element and `DestinationPriority` helper function.
|
||||
|
||||
### Case 3: The application overwrites settings when it's 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 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
|
||||
## 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.
|
||||
|
||||
@ -139,7 +139,7 @@ Your script should do the following actions:
|
||||
|
||||
For information about the .xml elements and helper functions, see [XML Elements Library](usmt-xml-elements-library.md).
|
||||
|
||||
## <a href="" id="bkmk-step5"></a>Step 5: Test the application settings migration
|
||||
## 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.
|
||||
|
||||
|
||||
@ -17,13 +17,13 @@ When planning your migration, you should determine which migration store type be
|
||||
|
||||
## In this topic
|
||||
|
||||
[Migration Store Types](#bkmk-types)
|
||||
[Migration Store Types](#migration-store-types)
|
||||
|
||||
[Local Store vs. Remote Store](#bkmk-localvremote)
|
||||
[Local Store vs. Remote Store](#local-store-vs-remote-store)
|
||||
|
||||
[The /localonly Command-Line Option](#bkmk-localonly)
|
||||
[The /localonly Command-Line Option](#the-localonly-command-line-option)
|
||||
|
||||
## <a href="" id="bkmk-types"></a> Migration Store Types
|
||||
## Migration store types
|
||||
|
||||
This section describes the three migration store types available in USMT.
|
||||
|
||||
@ -45,7 +45,7 @@ The following flowchart illustrates the procedural differences between a local m
|
||||
|
||||
|
||||
|
||||
## <a href="" id="bkmk-localvremote"></a> Local Store vs. Remote Store
|
||||
## Local store vs. remote store
|
||||
|
||||
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.
|
||||
|
||||
@ -54,7 +54,7 @@ If there isn't enough local disk space, or if you're moving the user state to an
|
||||
> [!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
|
||||
### 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).
|
||||
|
||||
|
||||
@ -29,19 +29,19 @@ When you use User State Migration Tool (USMT) 10.0 to gather and restore user st
|
||||
|
||||
## In this topic
|
||||
|
||||
- [What Will Migrate Offline?](#bkmk-whatwillmigrate)
|
||||
- [What Will Migrate Offline?](#what-will-migrate-offline)
|
||||
|
||||
- [What Offline Environments are Supported?](#bkmk-offlineenvironments)
|
||||
- [What Offline Environments are Supported?](#what-offline-environments-are-supported)
|
||||
|
||||
- [User-Group Membership and Profile Control](#bkmk-usergroupmembership)
|
||||
- [User-Group Membership and Profile Control](#user-group-membership-and-profile-control)
|
||||
|
||||
- [Command-Line Options](#bkmk-commandlineoptions)
|
||||
- [Command-Line Options](#command-line-options)
|
||||
|
||||
- [Environment Variables](#bkmk-environmentvariables)
|
||||
- [Environment Variables](#environment-variables)
|
||||
|
||||
- [Offline.xml Elements](#bkmk-offlinexml)
|
||||
- [Offline.xml Elements](#offlinexml-elements)
|
||||
|
||||
## <a href="" id="bkmk-whatwillmigrate"></a> What Will Migrate Offline?
|
||||
## What will migrate offline?
|
||||
|
||||
The following user data and settings migrate offline, similar to an online migration:
|
||||
|
||||
@ -59,7 +59,7 @@ The following user data and settings migrate offline, similar to an online migra
|
||||
|
||||
For exceptions to what you can migrate offline, see [What Does USMT Migrate?](usmt-what-does-usmt-migrate.md)
|
||||
|
||||
## <a href="" id="bkmk-offlineenvironments"></a> What Offline Environments are Supported?
|
||||
## What offline environments are supported?
|
||||
|
||||
The following table defines the supported combination of online and offline operating systems in USMT.
|
||||
|
||||
@ -71,7 +71,7 @@ The following table defines the supported combination of online and offline oper
|
||||
> [!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 and profile control
|
||||
|
||||
User-group membership isn't preserved during offline migrations. You must configure a **<ProfileControl>** 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:
|
||||
|
||||
@ -93,7 +93,7 @@ User-group membership isn't preserved during offline migrations. You must config
|
||||
|
||||
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
|
||||
## Command-line options
|
||||
|
||||
An offline migration can either be enabled by using a configuration file on the command line, or by using one of the following command line options:
|
||||
|
||||
@ -105,7 +105,7 @@ An offline migration can either be enabled by using a configuration file on the
|
||||
|
||||
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
|
||||
## Environment variables
|
||||
|
||||
The following system environment variables are necessary in the scenarios outlined below.
|
||||
|
||||
@ -114,23 +114,23 @@ The following system environment variables are necessary in the scenarios outlin
|
||||
|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
|
||||
## 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.
|
||||
|
||||
### <a href="" id="-offline-"></a><offline>
|
||||
### <offline>
|
||||
|
||||
This element contains other elements that define how an offline migration is to be performed.
|
||||
|
||||
Syntax: `<offline>` `</offline>`
|
||||
|
||||
### <a href="" id="-windir-"></a><winDir>
|
||||
### <winDir>
|
||||
|
||||
This element is a required child of **<offline>** and contains information about how the offline volume can be selected. The migration will be performed from the first element of **<winDir>** that contains a valid Windows system volume.
|
||||
|
||||
Syntax: `<winDir>` `</winDir>`
|
||||
|
||||
### <a href="" id="-path-"></a><path>
|
||||
### <path>
|
||||
|
||||
This element is a required child of **<winDir>** and contains a file path pointing to a valid Windows directory. Relative paths are interpreted from the ScanState tool's working directory.
|
||||
|
||||
@ -140,13 +140,13 @@ Syntax: `<path> C:\Windows </path>`
|
||||
|
||||
Syntax, when used with the **<mappings>** element: `<path> C:\, D:\ </path>`
|
||||
|
||||
### <a href="" id="-mappings-"></a><mappings>
|
||||
### <mappings>
|
||||
|
||||
This element is an optional child of **<offline>**. When specified, the **<mappings>** element will override the automatically detected WinPE drive mappings. Each child **<path>** 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: `<mappings>` `</mappings>`
|
||||
|
||||
### <a href="" id="-failonmultiplewindir-"></a><failOnMultipleWinDir>
|
||||
### <failOnMultipleWinDir>
|
||||
|
||||
This element is an optional child of **<offline>**. The **<failOnMultipleWinDir>** 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 **<failOnMultipleWinDir>** element isn't present, the default behavior is that the migration doesn't fail.
|
||||
|
||||
|
||||
@ -19,31 +19,31 @@ This article provides an overview of the default and custom migration XML files
|
||||
|
||||
## In this topic
|
||||
|
||||
[Overview of the Config.xml file](#bkmk-config)
|
||||
[Overview of the Config.xml file](#overview-of-the-configxml-file)
|
||||
|
||||
[Overview of the MigApp.xml file](#bkmk-migapp)
|
||||
[Overview of the MigApp.xml file](#overview-of-the-migappxml-file)
|
||||
|
||||
[Overview of the MigDocs.xml file](#bkmk-migdocs)
|
||||
[Overview of the MigDocs.xml file](#overview-of-the-migdocsxml-file)
|
||||
|
||||
[Overview of the MigUser.xml file](#bkmk-miguser)
|
||||
[Overview of the MigUser.xml file](#overview-of-the-miguserxml-file)
|
||||
|
||||
[Using multiple XML files](#bkmk-multiple)
|
||||
[Using multiple XML files](#using-multiple-xml-files)
|
||||
|
||||
[XML rules for migrating user files](#bkmk-userfiles)
|
||||
[XML rules for migrating user files](#xml-rules-for-migrating-user-files)
|
||||
|
||||
[The GenerateDocPatterns function](#bkmk-generate)
|
||||
[The GenerateDocPatterns function](#the-generatedocpatterns-function)
|
||||
|
||||
[Understanding the system and user context](#bkmk-context)
|
||||
[Understanding the system and user context](#understanding-the-system-and-user-context)
|
||||
|
||||
[Sample migration rules for customized versions of XML files](#bkmk-samples)
|
||||
[Sample migration rules for customized versions of XML files](#sample-migration-rules-for-customized-versions-of-xml-files)
|
||||
|
||||
[Exclude rules usage examples](#bkmk-exclude)
|
||||
[Exclude rules usage examples](#exclude-rules-usage-examples)
|
||||
|
||||
[Include rules usage examples](#bkmk-include)
|
||||
[Include rules usage examples](#include-rules-usage-examples)
|
||||
|
||||
[Next Steps](#bkmk-next)
|
||||
[Next Steps](#next-steps)
|
||||
|
||||
## <a href="" id="bkmk-config"></a> Overview of the Config.xml file
|
||||
## 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:
|
||||
|
||||
@ -54,14 +54,14 @@ When used this way, the `Config.xml` file tightly controls aspects of the migrat
|
||||
> [!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.
|
||||
|
||||
## <a href="" id="bkmk-migapp"></a> Overview of the MigApp.xml file
|
||||
## 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 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).
|
||||
> 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 [Sample migration rules for customized versions of XML files](#sample-migration-rules-for-customized-versions-of-xml-files).
|
||||
|
||||
## <a href="" id="bkmk-migdocs"></a> Overview of the MigDocs.xml file
|
||||
## 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.
|
||||
|
||||
@ -131,7 +131,7 @@ The default `MigDocs.xml` file won't migrate the following data:
|
||||
|
||||
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
|
||||
## 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.
|
||||
|
||||
@ -172,9 +172,9 @@ The default `MigUser.xml` file doesn't migrate the following data:
|
||||
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](#using-multiple-xml-files) section of this article.
|
||||
|
||||
## <a href="" id="bkmk-multiple"></a> Using multiple XML files
|
||||
## Using multiple XML files
|
||||
|
||||
You can use multiple XML files with the ScanState and LoadState tools. Each of the default XML files included with or generated by USMT is configured for a specific component of the migration. You can also use custom XML files to supplement these default files with more migration rules.
|
||||
|
||||
@ -191,16 +191,16 @@ For example, you can use all of the XML migration file types for a single migrat
|
||||
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
|
||||
### 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.
|
||||
|
||||
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.
|
||||
If you want more control over the migration, you can create custom XML files. See [Creating and editing a custom XML file](#creating-and-editing-a-custom-xml-file) for more information.
|
||||
|
||||
## <a href="" id="bkmk-createxml"></a> Creating and editing a custom XML file
|
||||
## 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.
|
||||
|
||||
@ -229,7 +229,7 @@ To generate the XML migration rules file for a source computer:
|
||||
scanstate.exe /genmigxml:"C:\Documents and Settings\USMT Tester\Desktop\genMig.xml"
|
||||
```
|
||||
|
||||
### <a href="" id="bkmk-generate"></a> The GenerateDocPatterns function
|
||||
### 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.
|
||||
|
||||
@ -287,7 +287,7 @@ To create exclude data patterns:
|
||||
</exclude>
|
||||
```
|
||||
|
||||
### <a href="" id="bkmk-context"></a> Understanding the system and user context
|
||||
### Understanding the system and user context
|
||||
|
||||
The migration XML files contain two <component> 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.
|
||||
|
||||
@ -342,12 +342,12 @@ The user context includes rules for data in the User Profiles directory. When ca
|
||||
> [!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.
|
||||
|
||||
### <a href="" id="bkmk-samples"></a> Sample migration rules for customized versions of XML files
|
||||
### Sample migration rules for customized versions of XML files
|
||||
|
||||
> [!NOTE]
|
||||
> For best practices and requirements for customized XML files in USMT, see [Customize USMT XML Files](usmt-customize-xml-files.md) and [General Conventions](usmt-general-conventions.md).
|
||||
|
||||
### <a href="" id="bkmk-exclude"></a> Exclude rules usage examples
|
||||
### 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:
|
||||
|
||||
@ -404,7 +404,7 @@ If you want the **<UnconditionalExclude>** element to apply to both the sy
|
||||
|
||||
For more examples of exclude rules that you can use in custom migration XML files, see [Exclude Files and Settings](usmt-exclude-files-and-settings.md).
|
||||
|
||||
### <a href="" id="bkmk-include"></a> Include rules usage examples
|
||||
### 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 aren't linked, you can do the following modification:
|
||||
|
||||
@ -437,7 +437,7 @@ For more examples of include rules that you can use in custom migration XML file
|
||||
> [!NOTE]
|
||||
> For more information about the order of precedence for XML migration rules, see [Conflicts and Precedence](usmt-conflicts-and-precedence.md).
|
||||
|
||||
## <a href="" id="bkmk-next"></a> Next steps
|
||||
## 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're applied to the destination computer.
|
||||
|
||||
|
||||
@ -81,7 +81,7 @@ As the authorized administrator, it is your responsibility to protect the privac
|
||||
|
||||
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
|
||||
## XML file best practices
|
||||
|
||||
- **Specify the same set of mig\*.xml files in both the ScanState and the LoadState tools**
|
||||
|
||||
|
||||
@ -17,17 +17,17 @@ The following sections discuss common issues that you might see when you run the
|
||||
|
||||
## In this topic
|
||||
|
||||
[User Account Problems](#user)
|
||||
[User account problems](#user-account-problems)
|
||||
|
||||
[Command-line Problems](#command)
|
||||
[Command-line problems](#command-line-problems)
|
||||
|
||||
[XML File Problems](#xml)
|
||||
[XML file problems](#xml-file-problems)
|
||||
|
||||
[Migration Problems](#migration)
|
||||
[Migration problems](#migration-problems)
|
||||
|
||||
[Offline Migration Problems](#bkmk-offline)
|
||||
[Offline migration problems](#offline-migration-problems)
|
||||
|
||||
[Hard Link Migration Problems](#bkmk-hardlink)
|
||||
[Hard link migration problems](#hard-link-migration-problems)
|
||||
|
||||
[USMT doesn't migrate the Start layout](#usmt-doesnt-migrate-the-start-layout)
|
||||
|
||||
@ -57,7 +57,7 @@ When you encounter a problem or error message during migration, you can use the
|
||||
> [!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
|
||||
## User account problems
|
||||
|
||||
The following sections describe common user account problems. Expand the section to see recommended solutions.
|
||||
|
||||
@ -128,7 +128,7 @@ 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
|
||||
## Command-line problems
|
||||
|
||||
The following sections describe common command-line problems. Expand the section to see recommended solutions.
|
||||
|
||||
@ -144,7 +144,7 @@ The following sections describe common command-line problems. Expand the section
|
||||
|
||||
**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
|
||||
## XML file problems
|
||||
|
||||
The following sections describe common XML file problems. Expand the section to see recommended solutions.
|
||||
|
||||
@ -160,13 +160,13 @@ The following sections describe common XML file problems. Expand the section to
|
||||
|
||||
**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'm using a MigXML helper function, but the migration isn't working the way I expected it to. How do I troubleshoot this issue?
|
||||
### 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 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 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
|
||||
## Migration problems
|
||||
|
||||
The following sections describe common migration problems. Expand the section to see recommended solutions.
|
||||
|
||||
@ -210,7 +210,7 @@ There are three typical causes for this issue.
|
||||
**Resolution:** Run the ScanState and LoadState tools from within an account with administrative credentials.
|
||||
--->
|
||||
|
||||
### <a href="" id="i-included-migapp-xml-in-the-migration--but-some-pst-files-aren-t-migrating-"></a> I included MigApp.xml in the migration, but some PST files aren't migrating
|
||||
### 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.
|
||||
|
||||
@ -240,7 +240,7 @@ There are three typical causes for this issue.
|
||||
|
||||
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
|
||||
## Offline migration problems
|
||||
|
||||
The following sections describe common offline migration problems. Expand the section to see recommended solutions.
|
||||
|
||||
@ -280,7 +280,7 @@ You can also use patterns for SIDs that identify generic users or groups. For ex
|
||||
reg.exe unload hklm\$dest$software
|
||||
```
|
||||
|
||||
## <a href="" id="bkmk-hardlink"></a> Hard-Link Migration Problems
|
||||
## Hard-Link Migration Problems
|
||||
|
||||
The following sections describe common hard-link migration problems. Expand the section to see recommended solutions.
|
||||
|
||||
|
||||
@ -15,35 +15,35 @@ ms.technology: itpro-deploy
|
||||
|
||||
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 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.
|
||||
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)
|
||||
[PC-refresh](#pc-refresh)
|
||||
|
||||
[Scenario One: PC-refresh offline using Windows PE and a hard-link migration store](#bkmk-onepcrefresh)
|
||||
[Scenario One: PC-refresh offline using Windows PE and a hard-link migration store](#scenario-one-pc-refresh-offline-using-windows-pe-and-a-hard-link-migration-store)
|
||||
|
||||
[Scenario Two: PC-refresh using a compressed migration store](#bkmk-twopcrefresh)
|
||||
[Scenario Two: PC-refresh using a compressed migration store](#scenario-two-pc-refresh-using-a-compressed-migration-store)
|
||||
|
||||
[Scenario Three: PC-refresh using a hard-link migration store](#bkmk-threepcrefresh)
|
||||
[Scenario Three: PC-refresh using a hard-link migration store](#scenario-three-pc-refresh-using-a-hard-link-migration-store)
|
||||
|
||||
[Scenario Four: PC-refresh using Windows.old folder and a hard-link migration store](#bkmk-fourpcrefresh)
|
||||
[Scenario Four: PC-refresh using Windows.old folder and a hard-link migration store](#scenario-four-pc-refresh-using-windowsold-folder-and-a-hard-link-migration-store)
|
||||
|
||||
[PC Replacement](#bkmk-pcreplace)
|
||||
[PC-replacement](#pc-replacement)
|
||||
|
||||
[Scenario One: Offline migration using Windows PE and an external migration store](#bkmk-onepcreplace)
|
||||
[Scenario One: Offline migration using Windows PE and an external migration store](#scenario-one-offline-migration-using-windows-pe-and-an-external-migration-store)
|
||||
|
||||
[Scenario Two: Manual network migration](#bkmk-twopcreplace)
|
||||
[Scenario Two: Manual network migration](#scenario-two-manual-network-migration)
|
||||
|
||||
[Scenario Three: Managed network migration](#bkmk-threepcreplace)
|
||||
[Scenario Three: Managed network migration](#scenario-three-managed-network-migration)
|
||||
|
||||
## <a href="" id="bkmk-pcrefresh"></a> PC-Refresh
|
||||
## 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.
|
||||
|
||||
|
||||
|
||||
### <a href="" id="bkmk-onepcrefresh"></a> Scenario One: PC-refresh offline using Windows PE and a hard-link migration store
|
||||
### Scenario One: PC-refresh offline using Windows PE and a hard-link migration store
|
||||
|
||||
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.
|
||||
|
||||
@ -53,7 +53,7 @@ A company has received funds to update the operating system on all of its comput
|
||||
|
||||
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
|
||||
### Scenario Two: PC-refresh using a compressed migration store
|
||||
|
||||
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.
|
||||
|
||||
@ -63,7 +63,7 @@ A company has received funds to update the operating system on all of its comput
|
||||
|
||||
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
|
||||
### Scenario Three: PC-refresh using a hard-link migration store
|
||||
|
||||
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.
|
||||
|
||||
@ -73,7 +73,7 @@ A company has received funds to update the operating system on all of its comput
|
||||
|
||||
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
|
||||
### 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.
|
||||
|
||||
@ -83,13 +83,13 @@ A company has decided to update the operating system on all of its computers to
|
||||
|
||||
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
|
||||
## 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.
|
||||
|
||||
|
||||
|
||||
### <a href="" id="bkmk-onepcreplace"></a> Scenario One: Offline migration using WinPE and an external migration store
|
||||
### Scenario One: Offline migration using Windows PE 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 offline, without a network connection.
|
||||
|
||||
@ -99,7 +99,7 @@ A company is allocating 20 new computers to users in the accounting department.
|
||||
|
||||
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
|
||||
### 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.
|
||||
|
||||
@ -111,7 +111,7 @@ A company receives 50 new laptops for their managers and needs to reallocate 50
|
||||
|
||||
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
|
||||
### 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 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.
|
||||
|
||||
|
||||
@ -28,47 +28,69 @@ For more information about using the `Config.xml` file with other migration file
|
||||
|
||||
In USMT there are new migration policies that can be configured in the `Config.xml` file. For example, you can configure additional **<ErrorControl>**, **<ProfileControl>**, and **<HardLinkStoreControl>** options. The following elements and parameters are for use in the `Config.xml` file only.
|
||||
|
||||
[<Policies>](#bkmk-policies)
|
||||
[<Policies>](#policies)
|
||||
|
||||
[<ErrorControl>](#errorcontrol)
|
||||
|
||||
<!--
|
||||
|
||||
[<ProfileControl>](#profilecontrol)
|
||||
|
||||
[<HardLinkStoreControl>](#hardlinkstorecontrol)
|
||||
|
||||
[<Components>](#components)
|
||||
|
||||
[<Component>](#component)
|
||||
|
||||
[<Applications>](#applications)
|
||||
|
||||
[<Application>](#application)
|
||||
|
||||
[<UserDocuments>](#userdocuments)
|
||||
|
||||
[<UserDocument>](#userdocument)
|
||||
|
||||
[<ErrorControl>](#bkmk-errorcontrol)
|
||||
|
||||
[<fatal>](#bkmk-fatal)
|
||||
-->
|
||||
|
||||
[<fileError>](#bkmk-fileerror)
|
||||
[<fatal>](#fatal)
|
||||
|
||||
[<nonfatal>](#bkmk-nonfatal)
|
||||
[<fileError>](#fileerror)
|
||||
|
||||
[<registryError>](#bkmk-registryerror)
|
||||
[<nonfatal>](#nonfatal)
|
||||
|
||||
[<HardLinkStoreControl>](#bkmk-hardlinkstorecontrol)
|
||||
[<registryError>](#registryerror)
|
||||
|
||||
[<fileLocked>](#bkmk-filelock)
|
||||
[<HardLinkStoreControl>](#hardlinkstorecontrol)
|
||||
|
||||
[<createHardLink>](#bkmk-createhardlink)
|
||||
[<fileLocked>](#filelocked)
|
||||
|
||||
[<errorHardLink>](#bkmk-errorhardlink)
|
||||
[<createHardLink>](#createhardlink)
|
||||
|
||||
[<ProfileControl>](#bkmk-profilecontrol)
|
||||
[<errorHardLink>](#errorhardlink)
|
||||
|
||||
[<localGroups>](#bkmk-localgroups)
|
||||
[<ProfileControl>](#profilecontrol)
|
||||
|
||||
[<mappings>](#bkmk-mappings)
|
||||
[<localGroups>](#localgroups)
|
||||
|
||||
[<changeGroup>](#bkmk-changegrou)
|
||||
[<mappings>](#mappings)
|
||||
|
||||
[<include>](#bkmk-include)
|
||||
[<changeGroup>](#changegroup)
|
||||
|
||||
[<exclude>](#bkmk-exclude)
|
||||
[<include>](#include)
|
||||
|
||||
[Sample Config.xml File](#bkmk-sampleconfigxjmlfile)
|
||||
[<exclude>](#exclude)
|
||||
|
||||
## <a href="" id="bkmk-policies"></a> <Policies>
|
||||
[Sample Config.xml File](#sample-configxml-file)
|
||||
|
||||
## <Policies>
|
||||
|
||||
The **<Policies>** element contains elements that describe the policies that USMT follows while creating a migration store. Valid children of the **<Policies>** element are **<ErrorControl>** and **<HardLinkStoreControl>**. The **<Policies>** element is a child of **<Configuration>**.
|
||||
|
||||
Syntax: `<Policies>` `</Policies>`
|
||||
|
||||
## <a href="" id="bkmk-errorcontrol"></a> <ErrorControl>
|
||||
## <ErrorControl>
|
||||
|
||||
The **<ErrorControl>** element is an optional element you can configure in the `Config.xml` file. The configurable **<ErrorControl>** 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.
|
||||
|
||||
@ -99,7 +121,7 @@ Additionally, the order in the **<ErrorControl>** section implies priority
|
||||
> [!IMPORTANT]
|
||||
> The configurable **<ErrorControl>** 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.
|
||||
|
||||
### <a href="" id="bkmk-fatal"></a> <fatal>
|
||||
### <fatal>
|
||||
|
||||
The **<fatal>** element isn't required.
|
||||
|
||||
@ -117,7 +139,7 @@ Syntax: `<fatal errorCode="any">` *<pattern>* `</fatal>`
|
||||
|
||||
You use the **<fatal>** element to specify that errors matching a specific pattern should cause USMT to halt the migration.
|
||||
|
||||
## <a href="" id="bkmk-fileerror"></a> <fileError>
|
||||
## <fileError>
|
||||
|
||||
The **<fileError>** element isn't required.
|
||||
|
||||
@ -131,7 +153,7 @@ Syntax: `<fileError>` `</fileError>`
|
||||
|
||||
You use the **<fileError>** element to represent the behavior associated with file errors.
|
||||
|
||||
## <a href="" id="bkmk-nonfatal"></a> <nonFatal>
|
||||
## <nonFatal>
|
||||
|
||||
The **<nonFatal>** element isn't required.
|
||||
|
||||
@ -149,7 +171,7 @@ Syntax: `<nonfatal errorCode="any">` *<pattern>* `</nonFatal>`
|
||||
|
||||
You use the **<nonFatal>** element to specify that errors matching a specific pattern shouldn't cause USMT to halt the migration.
|
||||
|
||||
## <a href="" id="bkmk-registryerror"></a> <registryError>
|
||||
## <registryError>
|
||||
|
||||
The **<registryError>** element isn't required.
|
||||
|
||||
@ -167,7 +189,7 @@ Syntax: `<registryError>` `</registryError>`
|
||||
|
||||
You use the **<registryError>** element to specify that errors matching a specific pattern shouldn't cause USMT to halt the migration.
|
||||
|
||||
## <a href="" id="bkmk-hardlinkstorecontrol"></a> <HardLinkStoreControl>
|
||||
## <HardLinkStoreControl>
|
||||
|
||||
The **<HardLinkStoreControl>** element contains elements that describe how to handle files during the creation of a hard-link migration store. Its only valid child is **<fileLocked>**.
|
||||
|
||||
@ -200,43 +222,43 @@ The **<HardLinkStoreControl>** sample code below specifies that hard links
|
||||
</Policy>
|
||||
```
|
||||
|
||||
## <a href="" id="bkmk-filelock"></a> <fileLocked>
|
||||
## <fileLocked>
|
||||
|
||||
The **<fileLocked>** element contains elements that describe how to handle files that are locked for editing. The rules defined by the **<fileLocked>** element are processed in the order in which they appear in the XML file.
|
||||
|
||||
Syntax: `<fileLocked>` `</fileLocked>`
|
||||
|
||||
## <a href="" id="bkmk-createhardlink"></a> <createHardLink>
|
||||
## <createHardLink>
|
||||
|
||||
The **<createHardLink>** element defines a standard MigXML pattern that describes file paths where hard links should be created, even if the file is locked for editing by another application.
|
||||
|
||||
Syntax: `<createHardLink>` *<pattern>* `</createHardLink>`
|
||||
|
||||
## <a href="" id="bkmk-errorhardlink"></a> <errorHardLink>
|
||||
## <errorHardLink>
|
||||
|
||||
The **<errorHardLink>** 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 **<ErrorControl>** section to either cause USMT to skip the file or abort the migration.
|
||||
|
||||
Syntax: `<errorHardLink>` *<pattern>* `</errorHardLink>`
|
||||
|
||||
## <a href="" id="bkmk-profilecontrol"></a> <ProfileControl>
|
||||
## <ProfileControl>
|
||||
|
||||
This element is used to contain other elements that establish rules for migrating profiles, users, and policies around local group membership during the migration. **<ProfileMigration>** is a child of **<Configuration>**.
|
||||
|
||||
Syntax: <`ProfileControl>` `</ProfileControl>`
|
||||
|
||||
## <a href="" id="bkmk-localgroups"></a> <localGroups>
|
||||
## <localGroups>
|
||||
|
||||
This element is used to contain other elements that establish rules for how to migrate local groups. **<localGroups>** is a child of **<ProfileControl>**.
|
||||
|
||||
Syntax: `<localGroups>` `</localGroups>`
|
||||
|
||||
## <a href="" id="bkmk-mappings"></a> <mappings>
|
||||
## <mappings>
|
||||
|
||||
This element is used to contain other elements that establish mappings between groups.
|
||||
|
||||
Syntax: `<mappings>` `</mappings>`
|
||||
|
||||
## <a href="" id="bkmk-changegrou"></a> <changeGroup>
|
||||
## <changeGroup>
|
||||
|
||||
This element describes the source and destination groups for a local group membership change during the migration. It's a child of **<localGroups>**. The following parameters are defined:
|
||||
|
||||
@ -250,19 +272,19 @@ The valid and required children of **<changeGroup>** are **<include>
|
||||
|
||||
Syntax: `<changeGroup From="Group1" To= "Group2">` `</changeGroup>`
|
||||
|
||||
## <a href="" id="bkmk-include"></a> <include>
|
||||
## <include>
|
||||
|
||||
This element specifies that its required child, *<pattern>*, should be included in the migration.
|
||||
|
||||
Syntax: `<include>` `</include>`
|
||||
|
||||
## <a href="" id="bkmk-exclude"></a> <exclude>
|
||||
## <exclude>
|
||||
|
||||
This element specifies that its required child, *<pattern>*, should be excluded from the migration.
|
||||
|
||||
Syntax: `<exclude>` `</exclude>`
|
||||
|
||||
## <a href="" id="bkmk-sampleconfigxjmlfile"></a> Sample Config.xml File
|
||||
## Sample Config.xml File
|
||||
|
||||
Refer to the following sample `Config.xml` file for more details about items you can choose to exclude from a migration.
|
||||
<br>
|
||||
|
||||
@ -15,7 +15,7 @@ ms.technology: itpro-deploy
|
||||
|
||||
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 **<unconditionalExclude>** 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.
|
||||
- **If there are conflicting rules within a component, the most specific rule is applied.** However, the **<unconditionalExclude>** 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?](#what-happens-when-there-are-conflicting-include-and-exclude-rules) and the first example in [<include> and <exclude> rules precedence examples](#include-and-exclude-rules-precedence-examples) later in this article.
|
||||
|
||||
- **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 **<unconditionalExclude>** rule.
|
||||
|
||||
@ -25,37 +25,37 @@ When you include, exclude, and reroute files and settings, it's important to kno
|
||||
|
||||
- **The ordering of the <include> and <exclude> rules within a component does not matter.**
|
||||
|
||||
- **You can use the <unconditionalExclude> element to globally exclude data.** This element excludes objects, regardless of any other **<include>** rules that are in the .xml files. For example, you can use the **<unconditionalExclude>** element to exclude all MP3 files on the computer or to exclude all files from **C:\\UserData**.
|
||||
- **You can use the <unconditionalExclude> element to globally exclude data.** This element excludes objects, regardless of any other **<include>** rules that are in the .xml files. For example, you can use the **<unconditionalExclude>** element to exclude all MP3 files on the computer or to exclude all files from `C:\UserData`.
|
||||
|
||||
## In this topic
|
||||
|
||||
**General**
|
||||
[General](#general)
|
||||
|
||||
- [What is the relationship between rules that are located within different components?](#bkmk2)
|
||||
- [What is the relationship between rules that are located within different components?](#what-is-the-relationship-between-rules-that-are-located-within-different-components)
|
||||
|
||||
- [How does precedence work with the Config.xml file?](#bkmk3)
|
||||
- [How does precedence work with the Config.xml file?](#how-does-precedence-work-with-the-configxml-file)
|
||||
|
||||
- [How does USMT process each component in an .xml file with multiple components?](#bkmk4)
|
||||
- [How does USMT process each component in an .xml file with multiple components?](#how-does-usmt-process-each-component-in-an-xml-file-with-multiple-components)
|
||||
|
||||
- [How are rules processed?](#bkmk5)
|
||||
- [How are rules processed?](#how-are-rules-processed)
|
||||
|
||||
- [How does USMT combine all of the .xml files that I specify on the command line?](#bkmk6)
|
||||
- [How does USMT combine all of the .xml files that I specify on the command line?](#how-does-usmt-combine-all-of-the-xml-files-that-i-specify-on-the-command-line)
|
||||
|
||||
**The <include> and <exclude> rules**
|
||||
[The <include> and <exclude> rules](#the-include-and-exclude-rules)
|
||||
|
||||
- [What happens when there are conflicting include and exclude rules?](#bkmk1)
|
||||
- [What happens when there are conflicting <include> and <exclude> rules?](#what-happens-when-there-are-conflicting-include-and-exclude-rules)
|
||||
|
||||
- [<include> and <exclude> precedence examples](#precexamples)
|
||||
- [<include> and <exclude> rules precedence examples](#include-and-exclude-rules-precedence-examples)
|
||||
|
||||
**File collisions**
|
||||
[File collisions](#file-collisions)
|
||||
|
||||
- [What is the default behavior when there are file collisions?](#collisions)
|
||||
- [What is the default behavior when there are file collisions?](#what-is-the-default-behavior-when-there-are-file-collisions)
|
||||
|
||||
- [How does the <merge> rule work when there are file collisions?](#bkmk11)
|
||||
- [How does the <merge> rule work when there are file collisions?](#how-does-the-merge-rule-work-when-there-are-file-collisions)
|
||||
|
||||
## General
|
||||
|
||||
### <a href="" id="bkmk2"></a> What is the relationship between rules that are located within different components?
|
||||
### 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 **<unconditionalExclude>** rule. Rules that are in different components don't affect each other. If there's an **<include>** rule in one component and an identical **<exclude>** rule in another component, the data will be migrated because the two rules are independent of each other.
|
||||
|
||||
@ -93,7 +93,7 @@ The following .xml file migrates all files from C:\\Userdocs, including .mp3 fil
|
||||
</migration>
|
||||
```
|
||||
|
||||
### <a href="" id="bkmk3"></a> How does precedence work with the Config.xml file?
|
||||
### 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.
|
||||
|
||||
@ -105,11 +105,11 @@ Specifying `migrate="no"` in the `Config.xml` file is the same as deleting the c
|
||||
</include>
|
||||
```
|
||||
|
||||
### <a href="" id="bkmk4"></a> How does USMT process each component in an .xml file with multiple components?
|
||||
### How does USMT process each component in an .xml file with multiple components?
|
||||
|
||||
The ordering of components doesn't matter. Each component is processed independently of other components. For example, if you have an **<include>** rule in one component and a **<locationModify>** 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 **<include>** rule, and it will be migrated based on the **<locationModify>** rule.
|
||||
|
||||
### <a href="" id="bkmk5"></a> How are rules processed?
|
||||
### How are rules processed?
|
||||
|
||||
There are two broad categories of rules.
|
||||
|
||||
@ -117,13 +117,13 @@ There are two broad categories of rules.
|
||||
|
||||
- **Rules that affect the behavior of only the LoadState tool**. For example, the **<locationModify>**, **<contentModify>**, and **<destinationCleanup>** 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 **<locationModify>** and **<contentModify>** rules. Then, LoadState processes all of the **<destinationCleanup>** 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?
|
||||
### How does USMT combine all of the .xml files that I specify on the command line?
|
||||
|
||||
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 <include> and <exclude> rules
|
||||
## The <include> and <exclude> rules
|
||||
|
||||
### <a href="" id="bkmk1"></a> What happens when there are conflicting <include> and <exclude> rules?
|
||||
### What happens when there are conflicting <include> and <exclude> rules?
|
||||
|
||||
If there are conflicting rules within a component, the most specific rule is applied, except with the **<unconditionalExclude>** 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.
|
||||
|
||||
@ -142,15 +142,15 @@ In the following example, mp3 files won't be excluded from the migration. The mp
|
||||
</exclude>
|
||||
```
|
||||
|
||||
### <a href="" id="precexamples"></a> <include> and **<exclude>** rules precedence examples
|
||||
### <include> and <exclude> rules precedence examples
|
||||
|
||||
These examples explain how USMT deals with **<include>** and **<exclude>** 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)
|
||||
- [Including and excluding files](#including-and-excluding-files)
|
||||
|
||||
- [Including and excluding registry objects](#regex)
|
||||
- [Including and excluding registry objects](#including-and-excluding-registry-objects)
|
||||
|
||||
### <a href="" id="filesex"></a> Including and excluding files
|
||||
### Including and excluding files
|
||||
|
||||
| If you have the following code in the same component | Resulting behavior | Explanation |
|
||||
|-----|-----|-----|
|
||||
@ -167,7 +167,7 @@ These examples explain how USMT deals with **<include>** and **<exclude
|
||||
| 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 doesn't contain an **<include>** rule, so the **<exclude>** rule isn't processed. |
|
||||
|
||||
### <a href="" id="regex"></a> Including and excluding registry objects
|
||||
### Including and excluding registry objects
|
||||
|
||||
| If you have the following code in the same component | Resulting behavior | Explanation |
|
||||
|-----|-----|-----|
|
||||
@ -181,11 +181,11 @@ These examples explain how USMT deals with **<include>** and **<exclude
|
||||
|
||||
## File collisions
|
||||
|
||||
### <a href="" id="collisions"></a> What is the default behavior when there are file collisions?
|
||||
### What is the default behavior when there are file collisions?
|
||||
|
||||
If there isn't a **<merge>** 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 <merge> rule work when there are file collisions?
|
||||
### How does the <merge> rule work when there are file collisions?
|
||||
|
||||
When a collision is detected, USMT will select the most specific **<merge>** rule and apply it to resolve the conflict. For example, if you have a **<merge>** rule for **C:\\\* \[\*\]** set to **sourcePriority()** and another **<merge>** rule for **C:\\subfolder\\\* \[\*\]** set to **destinationPriority()** , then USMT uses the **destinationPriority()** rule because it's the most specific.
|
||||
|
||||
|
||||
@ -13,7 +13,7 @@ ms.date: 11/01/2022
|
||||
|
||||
# Custom XML Examples
|
||||
|
||||
## <a href="" id="example"></a> Example 1: Migrating an Unsupported Application
|
||||
## Example 1: Migrating an unsupported application
|
||||
|
||||
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.
|
||||
|
||||
@ -88,7 +88,7 @@ The following template is a template for the sections that you need to migrate y
|
||||
|
||||
</details>
|
||||
|
||||
## <a href="" id="example2"></a> Example 2: Migrating the My Videos Folder
|
||||
## 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.
|
||||
|
||||
@ -136,7 +136,7 @@ The following sample is a custom .xml file named `CustomFile.xml` that migrates
|
||||
|
||||
</details>
|
||||
|
||||
## <a href="" id="example3"></a> Example 3: Migrating Files and Registry Keys
|
||||
## Example 3: Migrating files and registry keys
|
||||
|
||||
The sample patterns describe the behavior in the following example .xml file.
|
||||
|
||||
@ -194,7 +194,7 @@ The sample patterns describe the behavior in the following example .xml file.
|
||||
|
||||
</details>
|
||||
|
||||
## <a href="" id="example4"></a> Example 4: Migrating Specific Folders from Various Locations
|
||||
## Example 4: Migrating specific folders from various locations
|
||||
|
||||
The behavior for this custom .xml file is described within the `<displayName>` tags in the code.
|
||||
|
||||
|
||||
@ -15,19 +15,19 @@ ms.technology: itpro-deploy
|
||||
|
||||
## In This Topic
|
||||
|
||||
[Overview](#bkmk-overview)
|
||||
[Overview](#overview)
|
||||
|
||||
[Migration .xml Files](#bkmk-migxml)
|
||||
[Migration .xml files](#migration-xml-files)
|
||||
|
||||
[Custom .xml Files](#bkmk-customxmlfiles)
|
||||
[Custom .xml files](#custom-xml-files)
|
||||
|
||||
[The Config.xml File](#bkmk-configxml)
|
||||
[The Config.xml file](#the-configxml-file)
|
||||
|
||||
[Examples](#bkmk-examples)
|
||||
[Examples](#examples)
|
||||
|
||||
[Additional Information](#bkmk-addlinfo)
|
||||
[Additional Information](#additional-information)
|
||||
|
||||
## <a href="" id="bkmk-overview"></a> Overview
|
||||
## 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.
|
||||
|
||||
@ -39,15 +39,15 @@ 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.** 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.
|
||||
- **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) article.
|
||||
|
||||
## <a href="" id="bkmk-migxml"></a> Migration .xml Files
|
||||
## 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.
|
||||
|
||||
@ -63,11 +63,11 @@ This section describes the migration .xml files that are included with USMT. Eac
|
||||
> [!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
|
||||
## 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.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
|
||||
|
||||
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.
|
||||
|
||||
@ -88,7 +88,7 @@ In addition, note the following functionality with the `Config.xml` file:
|
||||
> [!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
|
||||
### Examples
|
||||
|
||||
- The following command creates a `Config.xml` file in the current directory, but it doesn't create a store:
|
||||
|
||||
@ -102,7 +102,7 @@ In addition, note the following functionality with the `Config.xml` file:
|
||||
|
||||
`loadstate \\server\share\migration\mystore /i:migapp.xml /i:migdocs.xml /v:5 /decrypt /key:"mykey"`
|
||||
|
||||
## <a href="" id="bkmk-addlinfo"></a> Additional Information
|
||||
## Additional Information
|
||||
|
||||
- For more information about how to change the files and settings that are migrated, see the [User State Migration Tool (USMT) How-to topics](usmt-how-to.md).
|
||||
|
||||
|
||||
@ -21,7 +21,7 @@ The disk space requirements for a migration are dependent on the size of the mig
|
||||
|
||||
- [Calculate Disk Space Requirements Using the ScanState Tool](#calculate-disk-space-requirements-using-the-scanstate-tool): Describes how to use the ScanState tool to determine how large the migration store will be on a particular computer.
|
||||
|
||||
- [Estimate Migration Store Size](#estimate-migration-store-size): Describes how to estimate the average size of migration stores for the computers in your organization, based on your infrastructure.
|
||||
- [Estimating Migration Store Size](#estimating-migration-store-size): Describes how to estimate the average size of migration stores for the computers in your organization, based on your infrastructure.
|
||||
|
||||
## Hard disk space requirements
|
||||
|
||||
@ -96,7 +96,7 @@ The space requirements report provides two elements, <**storeSize**> and &
|
||||
|
||||
Additionally, USMT performs a compliance check for a required minimum of 250 MB of available disk space and won't create a store if the compliance check fails.
|
||||
|
||||
## Estimate migration store size
|
||||
## Estimating migration store size
|
||||
|
||||
Determine how much space you'll need to store the migrated data. You should base your calculations on the volume of e-mail, personal documents, and system settings for each user. The best way to estimate the required space is to survey several computers to arrive at an average for the size of the store that you'll need.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user