deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-12 13:27:23 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

USMT Refresh 12

Browse Source
This commit is contained in:
Frank Rojas 2024-01-02 15:07:14 -05:00
parent f741c889e9
commit 1b13b80157
17 changed files with 117 additions and 111 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -82,7 +82,7 @@ Next, go through the user interface and make a list of all of the available sett
## 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 the collected files and registry keys don't need to be modified. 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 automatically migrates the file to `D:\Users\User1\My Documents`. However, the location of some settings might need to be modified 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 the collected files and registry keys don't need to be modified. 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:\Users\User1\Documents` folder and the profile directory on the destination computer is located at `D:\Users\User1`, then USMT automatically migrates the file to `D:\Users\User1\Documents`. However, the location of some settings might need to be modified in the following three cases:
### Case 1: The version of the application on the destination computer is newer than the one on the source computer ### Case 1: The version of the application on the destination computer is newer than the one on the source computer

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

@ -58,7 +58,7 @@ By doing this process, you don't need to save the files to a server.
> [!IMPORTANT] > [!IMPORTANT]
> >
> If possible, have users store their data within their `%UserProfile%\My Documents` and `%UserProfile%\Application Data` folders. Having users store their data at these locations reduces the chance of USMT missing critical user data that is located in a directory that USMT isn't configured to check. > If possible, have users store their data within their `%UserProfile%\Documents` and `%UserProfile%\Application Data` folders. Having users store their data at these locations reduces the chance of USMT missing critical user data that is located in a directory that USMT isn't configured to check.
### The /localonly command-line option ### The /localonly command-line option

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

@ -217,7 +217,7 @@ To generate the XML migration rules file for a source computer:
```cmd ```cmd
cd /d c:\USMT cd /d c:\USMT
ScanState.exe /genmigxml:"C:\Documents and Settings\USMT Tester\Desktop\genMig.xml" ScanState.exe /genmigxml:"C:\Users\USMT Tester\Desktop\genMig.xml"
``` ```
### The GenerateDocPatterns function ### The GenerateDocPatterns function

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

@ -16,120 +16,120 @@ This article discusses general and security-related best practices when using Us
## General best practices ## General best practices
- **Install applications before running the LoadState tool** - **Install applications before running the LoadState tool.**
Though it isn't always essential, it's best practice to install all applications on the destination computer before restoring the user state. Installing applications before restoring user state helps ensure that migrated settings are preserved. Though it isn't always essential, it's best practice to install all applications on the destination computer before restoring the user state. Installing applications before restoring user state helps ensure that migrated settings are preserved.
- **Don't use MigUser.xml and MigDocs.xml together** - **Don't use MigUser.xml and MigDocs.xml together.**
If you use both **.xml** files, some migrated files can be duplicated if conflicting instructions are given about target locations. You can use the `/genmigxml` command-line option to determine which files are included in your migration, and to determine if any modifications are necessary. For more information, see [Identify file types, files, and folders](usmt-identify-file-types-files-and-folders.md). If you use both **.xml** files, some migrated files can be duplicated if conflicting instructions are given about target locations. You can use the `/genmigxml` command-line option to determine which files are included in your migration, and to determine if any modifications are necessary. For more information, see [Identify file types, files, and folders](usmt-identify-file-types-files-and-folders.md).
- **Use MigDocs.xml for a better migration experience** - **Use MigDocs.xml for a better migration experience.**
If your data set is unknown or if many files are stored outside of the standard user-profile folders, the `MigDocs.xml` file is a better choice than the `MigUser.xml` file, because the `MigDocs.xml` file gathers a broader scope of data. The `MigDocs.xml` file migrates folders of data based on location, and on registered file type by querying the registry for registered application extensions. The `MigUser.xml` file migrates only the files with the specified file extensions. If your data set is unknown or if many files are stored outside of the standard user-profile folders, the `MigDocs.xml` file is a better choice than the `MigUser.xml` file, because the `MigDocs.xml` file gathers a broader scope of data. The `MigDocs.xml` file migrates folders of data based on location, and on registered file type by querying the registry for registered application extensions. The `MigUser.xml` file migrates only the files with the specified file extensions.
- **Close all applications before running either the ScanState or LoadState tools** - **Close all applications before running either the ScanState or LoadState tools.**
Although using the `/vsc` switch can allow the migration of many files that are open with another application, it's a best practice to close all applications in order to ensure all files and settings migrate. Without the `/vsc` or `/c` switch, USMT fails when it can't migrate a file or setting. When you use the `/c` option, USMT ignores any files or settings that it can't migrate and log an error each time. Although using the `/vsc` switch can allow the migration of many files that are open with another application, it's a best practice to close all applications in order to ensure all files and settings migrate. Without the `/vsc` or `/c` switch, USMT fails when it can't migrate a file or setting. When you use the `/c` option, USMT ignores any files or settings that it can't migrate and log an error each time.
- **Log off after you run the LoadState** - **Log off after you run the LoadState.**
Some settings, such as fonts, wallpaper, and screensaver settings, won't take effect until the next time the user logs on. For this reason, you should sign out after you run the LoadState tool. Some settings, such as fonts, wallpaper, and screensaver settings, won't take effect until the next time the user logs on. For this reason, you should sign out after you run the LoadState tool.
- **Managed environment** - **Managed environment.**
To create a managed environment, you can move all of the end user's documents into My Documents (%CSIDL\_PERSONAL%). We recommend that you migrate files into the smallest-possible number of folders on the destination computer. Minimizing folders helps to clean up files on the destination computer if the `LoadState.exe` command fails before completion. To create a managed environment, you can move all of the end user's documents into **Documents** folder (%CSIDL\_PERSONAL%). We recommend that you migrate files into the smallest-possible number of folders on the destination computer. Minimizing folders helps to clean up files on the destination computer if the `LoadState.exe` command fails before completion.
- **Chkdsk.exe** - **Chkdsk.exe.**
We recommend that you run **Chkdsk.exe** before running the ScanState and LoadState tools. **Chkdsk.exe** creates a status report for a hard disk drive and lists and corrects common errors. For more information about the **Chkdsk.exe** tool, see [Chkdsk](/previous-versions/windows/it-pro/windows-xp/bb490876(v=technet.10)). We recommend that you run **Chkdsk.exe** before running the ScanState and LoadState tools. **Chkdsk.exe** creates a status report for a hard disk drive and lists and corrects common errors. For more information about the **Chkdsk.exe** tool, see [Chkdsk](/previous-versions/windows/it-pro/windows-xp/bb490876(v=technet.10)).
- **Migrate in groups** - **Migrate in groups.**
If you decide to perform the migration while users are using the network, it's best to migrate user accounts in groups. To minimize the effect on network performance, determine the size of the groups based on the size of each user account. Migrating in phases also allows you to make sure each phase is successful before starting the next phase. Using this method, you can make any necessary modifications to your plan between groups. If you decide to perform the migration while users are using the network, it's best to migrate user accounts in groups. To minimize the effect on network performance, determine the size of the groups based on the size of each user account. Migrating in phases also allows you to make sure each phase is successful before starting the next phase. Using this method, you can make any necessary modifications to your plan between groups.
## Security best practices ## Security best practices
As the authorized administrator, it is your responsibility to protect the privacy of the users and maintain security during and after the migration. In particular, you must consider the following issues: As the authorized administrator, it is your responsibility to protect the privacy of the users and maintain security during and after the migration. In particular, you must consider the following issues:
- **Encrypting File System (EFS)** - **Encrypting File System (EFS).**
Take extreme caution when migrating encrypted files, because the end user doesn't need to be logged on to capture the user state. By default, USMT fails if an encrypted file is found. For specific instructions about EFS best practices, see [Migrate EFS Files and Certificates](usmt-migrate-efs-files-and-certificates.md). Take extreme caution when migrating encrypted files, because the end user doesn't need to be logged on to capture the user state. By default, USMT fails if an encrypted file is found. For specific instructions about EFS best practices, see [Migrate EFS Files and Certificates](usmt-migrate-efs-files-and-certificates.md).
> [!NOTE] > [!NOTE]
> >
> If you migrate an encrypted file without also migrating the certificate, end users won't be able to access the file after the migration. > If you migrate an encrypted file without also migrating the certificate, end users won't be able to access the file after the migration.
- **Encrypt the store** - **Encrypt the store.**
Consider using the `/encrypt` option with the `ScanState.exe` command and the `/decrypt` option with the `LoadState.exe` command. However, use extreme caution with this set of options, because anyone who has access to the `ScanState.exe` command-line script also has access to the encryption key. Consider using the `/encrypt` option with the `ScanState.exe` command and the `/decrypt` option with the `LoadState.exe` command. However, use extreme caution with this set of options, because anyone who has access to the `ScanState.exe` command-line script also has access to the encryption key.
- **Virus Scan** - **Virus Scan.**
We recommend that you scan both the source and destination computers for viruses before running USMT. In addition, you should scan the destination computer image. To help protect data from viruses, we strongly recommend running an antivirus utility before migration. We recommend that you scan both the source and destination computers for viruses before running USMT. In addition, you should scan the destination computer image. To help protect data from viruses, we strongly recommend running an antivirus utility before migration.
- **Maintain security of the file server and the deployment server** - **Maintain security of the file server and the deployment server.**
We recommend that you manage the security of the file and deployment servers. It's important to make sure that the file server where you save the store is secure. You must also secure the deployment server, to ensure that the user data that is in the log files isn't exposed. We also recommend that you only transmit data over a secure Internet connection, such as a virtual private network. For more information about network security, see [Microsoft Security Compliance Manager](https://www.microsoft.com/download/details.aspx?id=53353). We recommend that you manage the security of the file and deployment servers. It's important to make sure that the file server where you save the store is secure. You must also secure the deployment server, to ensure that the user data that is in the log files isn't exposed. We also recommend that you only transmit data over a secure Internet connection, such as a virtual private network. For more information about network security, see [Microsoft Security Compliance Manager](https://www.microsoft.com/download/details.aspx?id=53353).
- **Password Migration** - **Password Migration.**
To ensure the privacy of the end users, USMT doesn't migrate passwords, including passwords for applications or mapped network drives. It's important to make sure that end users know their passwords. To ensure the privacy of the end users, USMT doesn't migrate passwords, including passwords for applications or mapped network drives. It's important to make sure that end users know their passwords.
- **Local Account Creation** - **Local Account Creation.**
Before you migrate local accounts, see the Migrating Local Accounts section in the [Identify Users](usmt-identify-users.md) article. Before you migrate local accounts, see the Migrating Local Accounts section in the [Identify Users](usmt-identify-users.md) article.
## XML file best practices ## XML file best practices
- **Specify the same set of mig\*.xml files in both the ScanState and the LoadState tools** - **Specify the same set of mig\*.xml files in both the ScanState and the LoadState tools.**
If you used a particular set of mig\*.xml files in the ScanState tool, either called through the `/auto` option, or individually through the `/i` option, then you should use same option to call the exact same mig\*.xml files in the LoadState tool. If you used a particular set of mig\*.xml files in the ScanState tool, either called through the `/auto` option, or individually through the `/i` option, then you should use same option to call the exact same mig\*.xml files in the LoadState tool.
- **The \<CustomFileName\> in the migration urlid should match the name of the file** - **The \<CustomFileName\> in the migration urlid should match the name of the file.**
Although it isn't a requirement, it's good practice for **\<CustomFileName\>** to match the name of the file. For example, the following example is from the `MigApp.xml` file: Although it isn't a requirement, it's good practice for **\<CustomFileName\>** to match the name of the file. For example, the following example is from the `MigApp.xml` file:
```xml ```xml
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/migapp"> <migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/migapp">
``` ```
- **Use the XML Schema (MigXML.xsd) when authoring .xml files to validate syntax** - **Use the XML Schema (MigXML.xsd) when authoring .xml files to validate syntax.**
The `MigXML.xsd` schema file shouldn't be included on the command line or in any of the **.xml** files. The `MigXML.xsd` schema file shouldn't be included on the command line or in any of the **.xml** files.
- **Use the default migration XML files as models** - **Use the default migration XML files as models.**
To create a custom **.xml** file, you can use the migration **.xml** files as models to create your own. If you need to migrate user data files, model your custom **.xml** file on `MigUser.xml`. To migrate application settings, model your custom **.xml** file on the `MigApp.xml` file. To create a custom **.xml** file, you can use the migration **.xml** files as models to create your own. If you need to migrate user data files, model your custom **.xml** file on `MigUser.xml`. To migrate application settings, model your custom **.xml** file on the `MigApp.xml` file.
- **Consider the impact on performance when using the \<context\> parameter** - **Consider the impact on performance when using the \<context\> parameter.**
Your migration performance can be affected when you use the **\<context\>** element with the **\<component\>** element; for example, as in when you want to encapsulate logical units of file- or path-based **\<include\>** and **\<exclude\>** rules. Your migration performance can be affected when you use the **\<context\>** element with the **\<component\>** element; for example, as in when you want to encapsulate logical units of file- or path-based **\<include\>** and **\<exclude\>** rules.
In the **User** context, a rule is processed one time for each user on the system. In the **User** context, a rule is processed one time for each user on the system.
In the **System** context, a rule is processed one time for the system.
In the **System** context, a rule is processed one time for the system. In the **UserAndSystem** context, a rule is processed one time for each user on the system and one time for the system.
In the **UserAndSystem** context, a rule is processed one time for each user on the system and one time for the system. > [!NOTE]
>
> The number of times a rule is processed doesn't affect the number of times a file is migrated. The USMT migration engine ensures that each file migrates only once.
> [!NOTE] - **We recommend that you create a separate .xml file instead of adding your .xml code to one of the existing migration .xml files.**
>
> The number of times a rule is processed doesn't affect the number of times a file is migrated. The USMT migration engine ensures that each file migrates only once.
- **We recommend that you create a separate .xml file instead of adding your .xml code to one of the existing migration .xml files** For example, if you have code that migrates the settings for an application, you shouldn't just add the code to the `MigApp.xml` file.
For example, if you have code that migrates the settings for an application, you shouldn't just add the code to the `MigApp.xml` file. - **You should not create custom .xml files to alter the operating system settings that are migrated.**
- **You should not create custom .xml files to alter the operating system settings that are migrated** Manifest files determine what settings are migrated. Manifest files can't be modified. Since manifest files can't be modified, to exclude certain operating system settings from the migration, create and modify a `Config.xml` file instead.
Manifest files determine what settings are migrated. Manifest files can't be modified. Since manifest files can't be modified, to exclude certain operating system settings from the migration, create and modify a `Config.xml` file instead. - **You can use the asterisk (\*) wildcard character in any migration XML file that you create.**
- **You can use the asterisk (\*) wildcard character in any migration XML file that you create** > [!NOTE]
>
> [!NOTE] > The question mark isn't valid as a wildcard character in USMT **.xml** files.
>
> The question mark isn't valid as a wildcard character in USMT **.xml** files.
## Related articles ## Related articles

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

@ -68,7 +68,7 @@ The following **.xml** file migrates all files from C:\\Userdocs, including .mp3
### 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. 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 the **Documents** folder, but you have a rule similar to the one shown below in a migration **.xml** file (which includes all of the .doc files from the **Documents** folder), then only the .doc files will be migrated, and all other files will be excluded.
```xml ```xml
<include> <include>

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

@ -1,6 +1,6 @@
--- ---
title: Custom XML Examples title: Custom XML Examples
description: Use custom XML examples to learn how to migrate an unsupported application, migrate files and registry keys, and migrate the My Videos folder. description: Use custom XML examples to learn how to migrate an unsupported application, migrate files and registry keys, and migrate the Videos folder.
manager: aaroncz manager: aaroncz
ms.author: frankroj ms.author: frankroj
ms.prod: windows-client ms.prod: windows-client
@ -89,19 +89,19 @@ The following template is a template for the sections that you need to migrate y
## 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. The following sample is a custom **.xml** file named `CustomFile.xml` that migrates the **Videos** folder for all users, if the folder exists on the source computer.
- **Sample condition**: Verifies that **My Videos** exists on the source computer: - **Sample condition**: Verifies that the **Videos** folder exists on the source computer:
`<condition>MigXmlHelper.DoesObjectExist("File","%CSIDL_MYVIDEO%")</condition>` `<condition>MigXmlHelper.DoesObjectExist("File","%CSIDL_MYVIDEO%")</condition>`
- **Sample filter**: Filters out the shortcuts in **My Videos** that don't resolve on the destination computer: - **Sample filter**: Filters out the shortcuts in the **Videos** folder that don't resolve on the destination computer:
`<include filter='MigXmlHelper.IgnoreIrrelevantLinks()'>` `<include filter='MigXmlHelper.IgnoreIrrelevantLinks()'>`
This filter has no effect on files that aren't shortcuts. For example, if there's a shortcut in **My Videos** on the source computer that points to `C:\Folder1`, that shortcut is migrated only if `C:\Folder1` exists on the destination computer. However, all other files, such as .mp3 files, migrate without any filtering. This filter has no effect on files that aren't shortcuts. For example, if there's a shortcut in the **Videos** folder on the source computer that points to `C:\Folder1`, that shortcut is migrated only if `C:\Folder1` exists on the destination computer. However, all other files, such as .mp3 files, migrate without any filtering.
- **Sample pattern**: Migrates **My Videos** for all users: - **Sample pattern**: Migrates the **Videos** folder for all users:
`<pattern type="File">%CSIDL_MYVIDEO%* [*]</pattern>` `<pattern type="File">%CSIDL_MYVIDEO%* [*]</pattern>`

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

@ -14,7 +14,7 @@ ms.technology: itpro-deploy
## 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, the `Config.xml` file with the `/config` option doesn't need to be specified, unless some of the migrated files and settings from the store need to be excluded. 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. The `LoadState.exe` command then migrates only the files and settings that you want to migrate. If you want the ScanState and LoadState tools to use any of the migration **.xml** files, specify these files at the command line using the `/i` option. Because the ScanState and LoadState tools need the **.xml** files to control the migration, specify the same set of **.xml** files for both the `ScanState.exe` and `LoadState.exe` commands. However, the `Config.xml` file with the `/config` option doesn't need to be specified, unless some of the migrated files and settings from the store need to be excluded. For example, you might want to migrate the **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. The `LoadState.exe` command then migrates only the files and settings that you want to migrate.
If you leave out an **.xml** file from the `LoadState.exe` command, all of the data in the store that was migrated with the missing **.xml** files are migrated. However, the migration rules that were specified with the `ScanState.exe` command don't apply. For example, if you leave out an **.xml** file, and it contains a rerouting rule such as: If you leave out an **.xml** file from the `LoadState.exe` command, all of the data in the store that was migrated with the missing **.xml** files are migrated. However, the migration rules that were specified with the `ScanState.exe` command don't apply. For example, if you leave out an **.xml** file, and it contains a rerouting rule such as:
@ -28,7 +28,7 @@ To modify the migration, do one or more of the following.
- **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 **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. For more information about excluding data, see the [Exclude Files and Settings](usmt-exclude-files-and-settings.md) article.
@ -62,7 +62,7 @@ If you want to include all of the default components, you don't need to create t
When you run the `ScanState.exe` command with the `/genconfig` option, `ScanState.exe` reads the other **.xml** files that you specify using the `/i` option to create a custom list of components that can be migrated from the computer. This file contains only operating system components, applications, and the user document sections that are in both of the **.xml** files and that are installed on the computer when you run the `ScanState.exe` command with the `/genconfig` option. Therefore, you should create this file on a source computer that contains all of the components, applications, and settings that are present on the destination computers. Creating the file on the source computer ensures that this file contains every component that can be migrated. The components are organized into sections: \<Applications\>, \<WindowsComponents\>, and \<Documents\>. To choose not to migrate a component, change its entry to `migrate="no"`. When you run the `ScanState.exe` command with the `/genconfig` option, `ScanState.exe` reads the other **.xml** files that you specify using the `/i` option to create a custom list of components that can be migrated from the computer. This file contains only operating system components, applications, and the user document sections that are in both of the **.xml** files and that are installed on the computer when you run the `ScanState.exe` command with the `/genconfig` option. Therefore, you should create this file on a source computer that contains all of the components, applications, and settings that are present on the destination computers. Creating the file on the source computer ensures that this file contains every component that can be migrated. The components are organized into sections: \<Applications\>, \<WindowsComponents\>, and \<Documents\>. To choose not to migrate a component, change its entry to `migrate="no"`.
After you create this file, you need to specify it only with the `ScanState.exe` command using the `/Config` option for it to affect the migration. However, if additional data that was migrated to the store needs to be excluded, modify the `Config.xml` file and specify the updated file with the `LoadState.exe` command. For example, if you collected the My Documents folder in the store, but you decide that you don't want to migrate the My Documents folder to a destination computer, you can modify the `Config.xml` file to indicate `migrate="no"` before you run the `LoadState.exe` command, and the file aren't be migrated. For more information about the precedence that takes place when excluding data, see the [Exclude files and settings](usmt-exclude-files-and-settings.md) article. After you create this file, you need to specify it only with the `ScanState.exe` command using the `/Config` option for it to affect the migration. However, if additional data that was migrated to the store needs to be excluded, modify the `Config.xml` file and specify the updated file with the `LoadState.exe` command. For example, if you collected the **Documents** folder in the store, but you decide that you don't want to migrate the **Documents** folder to a destination computer, you can modify the `Config.xml` file to indicate `migrate="no"` before you run the `LoadState.exe` command, and the file aren't be migrated. For more information about the precedence that takes place when excluding data, see the [Exclude files and settings](usmt-exclude-files-and-settings.md) article.
In addition, note the following functionality with the `Config.xml` file: In addition, note the following functionality with the `Config.xml` file:

2
windows/deployment/usmt/usmt-estimate-migration-store-size.md
View File

@ -71,7 +71,7 @@ To run the ScanState tool on the source computer with USMT installed:
Although a migration store isn't created by running this command, the *\<StorePath\>* is still a required parameter. Although a migration store isn't created by running this command, the *\<StorePath\>* is still a required parameter.
The ScanState tool also allows you to estimate disk space requirements based on a customized migration. For example, you might not want to migrate the My Documents folder to the destination computer. You can specify this condition in a configuration file when you run the ScanState tool. For more information, see [Customize USMT XML files](usmt-customize-xml-files.md). The ScanState tool also allows you to estimate disk space requirements based on a customized migration. For example, you might not want to migrate the **Documents** folder to the destination computer. You can specify this condition in a configuration file when you run the ScanState tool. For more information, see [Customize USMT XML files](usmt-customize-xml-files.md).
> [!NOTE] > [!NOTE]
> >

2
windows/deployment/usmt/usmt-exclude-files-and-settings.md
View File

@ -276,7 +276,7 @@ You can create and modify a `Config.xml` file if you want to exclude components
- **To exclude an operating system setting:** Specify `migrate="no"` for the setting under the **\<WindowsComponents\>** section. - **To exclude an operating system setting:** Specify `migrate="no"` for the setting under the **\<WindowsComponents\>** section.
- **To exclude My Documents:** Specify `migrate="no"` for **My Documents** under the **\<Documents\>** section. Any **\<include\>** rules in the **.xml** files are still applied. For example, if you have a rule that includes all the .docx files in My Documents, then .docx files are still migrated. However, any additional files that aren't .docx aren't migrated. - **To exclude the Documents folder:** Specify `migrate="no"` for the **Documents** folder under the **\<Documents\>** section. Any **\<include\>** rules in the **.xml** files are still applied. For example, if you have a rule that includes all the .docx files in the **Documents** folder, then .docx files are still migrated. However, any additional files that aren't .docx aren't migrated.
For more information, see [Config.xml File](usmt-configxml-file.md). For more information, see [Config.xml File](usmt-configxml-file.md).

2
windows/deployment/usmt/usmt-faq.yml
View File

@ -115,7 +115,7 @@ sections:
- question: | - question: |
Why must I list the **.xml** files with both the `ScanState.exe` and `LoadState.exe` commands? Why must I list the **.xml** files with both the `ScanState.exe` and `LoadState.exe` commands?
answer: | answer: |
The **.xml** files aren't copied to the store as in previous versions of USMT. Because the **ScanState** and **LoadState** tools need the **.xml** files to control the migration, you must specify the same set of **.xml** files for the `ScanState.exe` and `LoadState.exe` commands. If you used a particular set of mig\*.xml files in the **ScanState** tool, either called through the `/auto` option, or individually through the `/i` option, then you should use same option to call the exact same mig\*.xml files in the **LoadState** tool. However, the `Config.xml` file doesn't need to be specified, unless files and settings that were migrated to the store need to be excluded. For example, you might want to migrate the **My Documents** folder to the store, but not to the destination computer. To do this type of migration, modify the `Config.xml` file and specify the updated file with the `LoadState.exe` command. **LoadState** migrates only the files and settings that you want to migrate. The **.xml** files aren't copied to the store as in previous versions of USMT. Because the **ScanState** and **LoadState** tools need the **.xml** files to control the migration, you must specify the same set of **.xml** files for the `ScanState.exe` and `LoadState.exe` commands. If you used a particular set of mig\*.xml files in the **ScanState** tool, either called through the `/auto` option, or individually through the `/i` option, then you should use same option to call the exact same mig\*.xml files in the **LoadState** tool. However, the `Config.xml` file doesn't need to be specified, unless files and settings that were migrated to the store need to be excluded. For example, you might want to migrate the **Documents** folder to the store, but not to the destination computer. To do this type of migration, modify the `Config.xml` file and specify the updated file with the `LoadState.exe` command. **LoadState** migrates only the files and settings that you want to migrate.
If you exclude an **.xml** file from the `LoadState.exe` command, then all of the data that is in the store that was migrated with the missing **.xml** files are migrated. However, the migration rules that were specified for the `ScanState.exe` command don't apply. For example, if you exclude a `MigApp.xml` file that has a rerouting rule such as `MigsysHelperFunction.RelativeMove("c:\data", "%CSIDL_PERSONAL%")`, USMT doesn't reroute the files. Instead, it migrates them to `C:\data`. If you exclude an **.xml** file from the `LoadState.exe` command, then all of the data that is in the store that was migrated with the missing **.xml** files are migrated. However, the migration rules that were specified for the `ScanState.exe` command don't apply. For example, if you exclude a `MigApp.xml` file that has a rerouting rule such as `MigsysHelperFunction.RelativeMove("c:\data", "%CSIDL_PERSONAL%")`, USMT doesn't reroute the files. Instead, it migrates them to `C:\data`.

4
windows/deployment/usmt/usmt-identify-file-types-files-and-folders.md
View File

@ -12,13 +12,13 @@ ms.technology: itpro-deploy
# Identify file types, files, and folders # Identify file types, files, and folders
When planning for your migration, if not using MigDocs.xml, you should identify the file types, files, folders, and settings that you want to migrate. First, you should determine the standard file locations on each computer, such as **My Documents** , `C:\Data` , and company-specified locations, such as `\\EngineeringDrafts`. Next, you should determine and locate the non-standard locations. For non-standard locations, consider the following items: When planning for your migration, if not using MigDocs.xml, you should identify the file types, files, folders, and settings that you want to migrate. First, you should determine the standard file locations on each computer, such as the **Documents** folder, `C:\Data` , and company-specified locations, such as `\\EngineeringDrafts`. Next, you should determine and locate the non-standard locations. For non-standard locations, consider the following items:
- **File types**: Consider which file types need to be included and excluded from the migration. You can create this list based on common applications used in your organization. Applications normally use specific file name extensions. For example, Microsoft Office Word primarily uses `.doc`, `.docx` and `.dotx` file name extension. However, it also uses other file types, such as templates (`.dot` files), on a less frequent basis. - **File types**: Consider which file types need to be included and excluded from the migration. You can create this list based on common applications used in your organization. Applications normally use specific file name extensions. For example, Microsoft Office Word primarily uses `.doc`, `.docx` and `.dotx` file name extension. However, it also uses other file types, such as templates (`.dot` files), on a less frequent basis.
- **Excluded locations**: Consider the locations on the computer that should be excluded from the migration (for example, `%WINDIR%` and **Program Files**). - **Excluded locations**: Consider the locations on the computer that should be excluded from the migration (for example, `%WINDIR%` and **Program Files**).
- **New locations**: Decide where files should be migrated to on the destination computer, such as **My Documents**, a designated folder, or a folder matching the files' name and location on the source computer. For example, shared data might exist on the source machine or documents outside the user profiles on the source system might need to be cleaned up. Identify any data that needs to be redirected to a new location in the Apply phase. Redirection can be accomplished with location modify rules. - **New locations**: Decide where files should be migrated to on the destination computer, such as the **Documents** folder, a designated folder, or a folder matching the files' name and location on the source computer. For example, shared data might exist on the source machine or documents outside the user profiles on the source system might need to be cleaned up. Identify any data that needs to be redirected to a new location in the Apply phase. Redirection can be accomplished with location modify rules.
Once which files and file types that the end users work with regularly is verified, locate the files and file types. Files might be saved to a single folder or scattered across a drive. A good starting point for finding files types to include is to look at the registered file types on the computer. Once which files and file types that the end users work with regularly is verified, locate the files and file types. Files might be saved to a single folder or scattered across a drive. A good starting point for finding files types to include is to look at the registered file types on the computer.

2
windows/deployment/usmt/usmt-include-files-and-settings.md
View File

@ -128,7 +128,7 @@ The following **.xml** file migrates `.mp3` files located in the specified drive
```xml ```xml
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test"> <migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test">
<component type="Documents" context="System"> <component type="Documents" context="System">
<displayName>All .mp3 files to My Documents</displayName> <displayName>All .mp3 files to the Documents folder</displayName>
<role role="Data"> <role role="Data">
<rules> <rules>
<include> <include>

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

@ -29,7 +29,7 @@ The following table describes the command-line encryption options in USMT.
> [!IMPORTANT] > [!IMPORTANT]
> >
> Some encryption algorithms may not be available on your systems. You can verify which algorithms are available by running the `UsmtUtils.exe` command with the `/ec` option. For more information, see [UsmtUtils syntax](usmt-utilities.md). > Some encryption algorithms might not be available on your systems. You can verify which algorithms are available by running the `UsmtUtils.exe` command with the `/ec` option. For more information, see [UsmtUtils syntax](usmt-utilities.md).
## Related articles ## Related articles

22
windows/deployment/usmt/usmt-recognized-environment-variables.md
View File

@ -15,7 +15,7 @@ ms.collection:
# Recognized environment variables # Recognized environment variables
When using the XML files `MigDocs.xml`, `MigApp.xml`, and `MigUser.xml`, you can use environment variables to identify folders that can be different on different computers. Constant special item ID list (CSIDL) values provide a way to identify folders that applications use frequently but could have different names or locations on any given computer. For example, the **Documents** folder could be `C:\Users\<Username>\My Documents` on one computer and `C:\Documents and Settings\<username>\My Documents` on another. You can use the asterisk (\*) wildcard character in `MigUser.xml`, `MigApp.xml` and `MigDoc.xml` files. However, you can't use the asterisk (\*) wildcard characters in the `Config.xml` file. When using the XML files `MigDocs.xml`, `MigApp.xml`, and `MigUser.xml`, you can use environment variables to identify folders that can be different on different computers. Constant special item ID list (CSIDL) values provide a way to identify folders that applications use frequently but could have different names or locations on any given computer. For example, the **Documents** folder could be `C:\Users\<Username>\Documents` on one computer and `C:\Users\<Username>\My Documents` on another. You can use the asterisk (\*) wildcard character in `MigUser.xml`, `MigApp.xml` and `MigDoc.xml` files. However, you can't use the asterisk (\*) wildcard characters in the `Config.xml` file.
## Variables that are processed for the operating system and in the context of each user ## Variables that are processed for the operating system and in the context of each user
@ -50,10 +50,10 @@ You can use these variables within sections in the **.xml** files with `context=
|*CSIDL_DEFAULT_HISTORY*|Refers to the History folder inside `%DEFAULTUSERPROFILE%`.| |*CSIDL_DEFAULT_HISTORY*|Refers to the History folder inside `%DEFAULTUSERPROFILE%`.|
|*CSIDL_DEFAULT_INTERNET_CACHE*|Refers to the Internet Cache folder inside `%DEFAULTUSERPROFILE%`.| |*CSIDL_DEFAULT_INTERNET_CACHE*|Refers to the Internet Cache folder inside `%DEFAULTUSERPROFILE%`.|
|*CSIDL_DEFAULT_PERSONAL*|Refers to the Personal folder inside `%DEFAULTUSERPROFILE%`.| |*CSIDL_DEFAULT_PERSONAL*|Refers to the Personal folder inside `%DEFAULTUSERPROFILE%`.|
|*CSIDL_DEFAULT_MYDOCUMENTS*|Refers to the My Documents folder inside `%DEFAULTUSERPROFILE%`.| |*CSIDL_DEFAULT_MYDOCUMENTS*|Refers to the Documents folder inside `%DEFAULTUSERPROFILE%`.|
|*CSIDL_DEFAULT_MYPICTURES*|Refers to the My Pictures folder inside `%DEFAULTUSERPROFILE%`.| |*CSIDL_DEFAULT_MYPICTURES*|Refers to the Pictures folder inside `%DEFAULTUSERPROFILE%`.|
|*CSIDL_DEFAULT_MYMUSIC*|Refers to the My Music folder inside `%DEFAULTUSERPROFILE%`.| |*CSIDL_DEFAULT_MYMUSIC*|Refers to the Music folder inside `%DEFAULTUSERPROFILE%`.|
|*CSIDL_DEFAULT_MYVIDEO*|Refers to the My Videos folder inside `%DEFAULTUSERPROFILE%`.| |*CSIDL_DEFAULT_MYVIDEO*|Refers to the Videos folder inside `%DEFAULTUSERPROFILE%`.|
|*CSIDL_DEFAULT_RECENT*|Refers to the Recent folder inside `%DEFAULTUSERPROFILE%`.| |*CSIDL_DEFAULT_RECENT*|Refers to the Recent folder inside `%DEFAULTUSERPROFILE%`.|
|*CSIDL_DEFAULT_SENDTO*|Refers to the Send To folder inside `%DEFAULTUSERPROFILE%`.| |*CSIDL_DEFAULT_SENDTO*|Refers to the Send To folder inside `%DEFAULTUSERPROFILE%`.|
|*CSIDL_DEFAULT_STARTMENU*|Refers to the Start Menu folder inside `%DEFAULTUSERPROFILE%`.| |*CSIDL_DEFAULT_STARTMENU*|Refers to the Start Menu folder inside `%DEFAULTUSERPROFILE%`.|
@ -99,20 +99,20 @@ You can use these variables in the **.xml** files within sections with `context=
|*CSIDL_COOKIES*|The file-system directory that serves as a common repository for Internet cookies. A typical path is `C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Cookies`.| |*CSIDL_COOKIES*|The file-system directory that serves as a common repository for Internet cookies. A typical path is `C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Cookies`.|
|*CSIDL_DESKTOP*|The virtual folder representing the Windows desktop.| |*CSIDL_DESKTOP*|The virtual folder representing the Windows desktop.|
|*CSIDL_DESKTOPDIRECTORY*|The file-system directory used to physically store file objects on the desktop, which shouldn't be confused with the desktop folder itself. A typical path is `C:\Users\<username>\Desktop`.| |*CSIDL_DESKTOPDIRECTORY*|The file-system directory used to physically store file objects on the desktop, which shouldn't be confused with the desktop folder itself. A typical path is `C:\Users\<username>\Desktop`.|
|*CSIDL_DRIVES*|The virtual folder representing My Computer that contains everything on the local computer: storage devices, printers, and Control Panel. The folder could also contain mapped network drives.| |*CSIDL_DRIVES*|The virtual folder representing **This PC** that contains everything on the local computer: storage devices, printers, and Control Panel. The folder could also contain mapped network drives.|
|*CSIDL_FAVORITES*|The file-system directory that serves as a common repository for the user's favorites. A typical path is `C:\Users\<username>\Favorites`.| |*CSIDL_FAVORITES*|The file-system directory that serves as a common repository for the user's favorites. A typical path is `C:\Users\<username>\Favorites`.|
|*CSIDL_HISTORY*|The file-system directory that serves as a common repository for Internet history items.| |*CSIDL_HISTORY*|The file-system directory that serves as a common repository for Internet history items.|
|*CSIDL_INTERNET*|A virtual folder for Internet Explorer.| |*CSIDL_INTERNET*|A virtual folder for Internet Explorer.|
|*CSIDL_INTERNET_CACHE*|The file-system directory that serves as a common repository for temporary Internet files. A typical path is `C:\Users\<username>\AppData\Local\Microsoft\Windows\Temporary Internet Files`| |*CSIDL_INTERNET_CACHE*|The file-system directory that serves as a common repository for temporary Internet files. A typical path is `C:\Users\<username>\AppData\Local\Microsoft\Windows\Temporary Internet Files`|
|*CSIDL_LOCAL_APPDATA*|The file-system directory that serves as a data repository for local, non-roaming applications. A typical path is `C:\Users\<username>\AppData\Local`.| |*CSIDL_LOCAL_APPDATA*|The file-system directory that serves as a data repository for local, non-roaming applications. A typical path is `C:\Users\<username>\AppData\Local`.|
|*CSIDL_MYDOCUMENTS*|The virtual folder representing My Documents.A typical path is `C:\Users\<username>\Documents`.| |*CSIDL_MYDOCUMENTS*|The virtual folder representing the **Documents** folder.A typical path is `C:\Users\<username>\Documents`.|
|*CSIDL_MYMUSIC*|The file-system directory that serves as a common repository for music files. A typical path is `C:\Users\<username>\Music`.| |*CSIDL_MYMUSIC*|The file-system directory that serves as a common repository for music files. A typical path is `C:\Users\<username>\Music`.|
|*CSIDL_MYPICTURES*|The file-system directory that serves as a common repository for image files. A typical path is `C:\Users\<username>\Pictures`.| |*CSIDL_MYPICTURES*|The file-system directory that serves as a common repository for image files. A typical path is `C:\Users\<username>\Pictures`.|
|*CSIDL_MYVIDEO*|The file-system directory that serves as a common repository for video files. A typical path is `C:\Users\<username>\Videos`.| |*CSIDL_MYVIDEO*|The file-system directory that serves as a common repository for video files. A typical path is `C:\Users\<username>\Videos`.|
|*CSIDL_NETHOOD*|A file-system directory that contains the link objects that could exist in the My Network Places virtual folder. It isn't the same as *CSIDL_NETWORK*, which represents the network namespace root. A typical path is `C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Network Shortcuts`.| |*CSIDL_NETHOOD*|A file-system directory that contains the link objects that could exist in the **Network** virtual folder. It isn't the same as *CSIDL_NETWORK*, which represents the network namespace root. A typical path is `C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Network Shortcuts`.|
|*CSIDL_NETWORK*|A virtual folder representing My Network Places, the root of the network namespace hierarchy.| |*CSIDL_NETWORK*|A virtual folder representing the **Network** desktop item, the root of the network namespace hierarchy.|
|*CSIDL_PERSONAL*|The virtual folder representing the My Documents desktop item. This value is equivalent to **CSIDL_MYDOCUMENTS**. A typical path is `C:\Documents and Settings\<username>\My Documents`.| |*CSIDL_PERSONAL*|The virtual folder representing the **\<User\>** desktop item. This value is equivalent to **CSIDL_MYDOCUMENTS**. A typical path is `C:\User\<username>\Documents`.|
|*CSIDL_PLAYLISTS*|The virtual folder used to store play albums, typically `C:\Users\<username>\My Music\Playlists`.| |*CSIDL_PLAYLISTS*|The virtual folder used to store play albums, typically `C:\Users\<username>\Music\Playlists`.|
|*CSIDL_PRINTERS*|The virtual folder that contains installed printers.| |*CSIDL_PRINTERS*|The virtual folder that contains installed printers.|
|*CSIDL_PRINTHOOD*|The file-system directory that contains the link objects that can exist in the Printers virtual folder. A typical path is `C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Printer Shortcuts`.| |*CSIDL_PRINTHOOD*|The file-system directory that contains the link objects that can exist in the Printers virtual folder. A typical path is `C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Printer Shortcuts`.|
|*CSIDL_PROFILE*|The user's profile folder. A typical path is `C:\Users\<username>`.| |*CSIDL_PROFILE*|The user's profile folder. A typical path is `C:\Users\<username>`.|

8
windows/deployment/usmt/usmt-reroute-files-and-settings.md
View File

@ -16,7 +16,7 @@ To reroute files and settings, create a custom **.xml** file and specify the **.
## Reroute a folder ## Reroute a folder
The following custom **.xml** file migrates the directories and files from `C:\EngineeringDrafts` into the **My Documents** folder of every user. **%CSIDL_PERSONAL%** is the virtual folder representing the **My Documents** desktop item, which is equivalent to **CSIDL_MYDOCUMENTS**. The following custom **.xml** file migrates the directories and files from `C:\EngineeringDrafts` into the **Documents** folder of every user. **%CSIDL_PERSONAL%** is the virtual folder representing the **\<User\>** desktop item, which is equivalent to **CSIDL_MYDOCUMENTS**.
```xml ```xml
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test"> <migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test">
@ -49,7 +49,7 @@ The following custom **.xml** file reroutes .mp3 files located in the fixed driv
```xml ```xml
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test"> <migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test">
<component type="Documents" context="System"> <component type="Documents" context="System">
<displayName>All .mp3 files to My Documents</displayName> <displayName>All .mp3 files to the Documents folder</displayName>
<role role="Data"> <role role="Data">
<rules> <rules>
<include> <include>
@ -71,12 +71,12 @@ The following custom **.xml** file reroutes .mp3 files located in the fixed driv
## Reroute a specific file ## Reroute a specific file
The following custom **.xml** file migrates the `Sample.doc` file from `C:\EngineeringDrafts` into the **My Documents** folder of every user. **%CSIDL_PERSONAL%** is the virtual folder representing the **My Documents** desktop item, which is equivalent to **CSIDL_MYDOCUMENTS**. The following custom **.xml** file migrates the `Sample.doc` file from `C:\EngineeringDrafts` into the **Documents** folder of every user. **%CSIDL_PERSONAL%** is the virtual folder representing the **\<User\>** desktop item, which is equivalent to **CSIDL_MYDOCUMENTS**.
```xml ```xml
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test"> <migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test">
<component type="Documents" context="User"> <component type="Documents" context="User">
<displayName>Sample.doc into My Documents</displayName> <displayName>Sample.doc into the Documents folder</displayName>
<role role="Data"> <role role="Data">
<rules> <rules>
<include> <include>

20
windows/deployment/usmt/usmt-what-does-usmt-migrate.md
View File

@ -33,15 +33,15 @@ The User State Migration Tool (USMT) is designed so that an IT engineer can prec
This section describes the user data that USMT migrates by default, using the `MigUser.xml` file. It also defines how to migrate access control lists (ACLs). This section describes the user data that USMT migrates by default, using the `MigUser.xml` file. It also defines how to migrate access control lists (ACLs).
- **Folders from each user profile.** When the `MigUser.xml` file is specified, USMT migrates everything in a user's profiles including the following items: - **Folders from each user profile.** When the `MigUser.xml` file is specified, USMT migrates everything in a user's profiles including the following folder items:
- My Documents. - Documents.
- My Video. - Videos.
- My Music. - Music.
- My Pictures. - Pictures.
- Desktop files. - Desktop files.
@ -109,7 +109,13 @@ USMT migrates operating-system components to a destination computer. The followi
- Fonts. - Fonts.
- Group membership. USMT migrates users' group settings. The groups to which a user belongs can be found by right-clicking **My Computer** on the Start menu and then selecting **Manage**. The use of a **\<ProfileControl\>** section in the `Config.xml` file is required when running an offline migration. - Group membership. USMT migrates users' group settings. To view what groups a user belongs to:
1. Right-clicking on the Start menu and then selecting **Computer Management**.
1. In the **Computer Management** console, expand **System tools** > **Local Users and Groups** > **Groups**.
1. Inspect the individual groups in the results pane to see what users belong to what groups.
The use of a **\<ProfileControl\>** section in the `Config.xml` file is required when running an offline migration.
- Windows Internet Explorer® settings. **¹** - Windows Internet Explorer® settings. **¹**
@ -196,7 +202,7 @@ USMT doesn't migrate the following operating-system settings.
Also note the following items: Also note the following items:
- Run USMT from an account with administrative credentials. Otherwise, some data doesn't migrate. When running the **ScanState** and **LoadState** tools, the tools must be run in Administrator mode from an account with administrative credentials. If USMT isn't run in Administrator mode, only the user profile that is logged on is included in the migration. - Run USMT from an account with administrative credentials. Otherwise, some data doesn't migrate. When the **ScanState** and **LoadState** tools are run, the tools must be run in Administrator mode from an account with administrative credentials. If USMT isn't run in Administrator mode, only the user profile that is logged on is included in the migration.
- Use the `/localonly` option to exclude the data from removable drives and network drives mapped on the source computer. For more information about what is excluded when `/localonly` is specified, see [ScanState syntax](usmt-scanstate-syntax.md). - Use the `/localonly` option to exclude the data from removable drives and network drives mapped on the source computer. For more information about what is excluded when `/localonly` is specified, see [ScanState syntax](usmt-scanstate-syntax.md).

18
windows/deployment/usmt/usmt-xml-elements-library.md
View File

@ -1035,7 +1035,7 @@ Example:
```xml ```xml
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/miguser"> <migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/miguser">
<!-- This component migrates My Video files --> <!-- This component migrates the files in the Video folder -->
<component type="System" context="System"> <component type="System" context="System">
<displayName>System Data</displayName> <displayName>System Data</displayName>
<role role="Data"> <role role="Data">
@ -1507,9 +1507,9 @@ These functions control how collisions are resolved.
```xml ```xml
<merge script="MigXmlHelper.DestinationPriority()"> <merge script="MigXmlHelper.DestinationPriority()">
<objectSet> <objectSet>
<pattern type="Registry">HKCU\Software\Microsoft\Office\9.0\PhotoDraw\ [MyPictures]</pattern> <pattern type="Registry">HKCU\Software\Microsoft\Office\16.0\PhotoDraw\ [MyPictures]</pattern>
<pattern type="Registry">HKCU\Software\Microsoft\Office\9.0\PhotoDraw\Settings\ [PicturesPath]</pattern> <pattern type="Registry">HKCU\Software\Microsoft\Office\16.0\PhotoDraw\Settings\ [PicturesPath]</pattern>
<pattern type="Registry">HKCU\Software\Microsoft\Office\9.0\PhotoDraw\Settings\ [AdditionalPlugInPath]</pattern> <pattern type="Registry">HKCU\Software\Microsoft\Office\16.0\PhotoDraw\Settings\ [AdditionalPlugInPath]</pattern>
</objectSet> </objectSet>
</merge> </merge>
``` ```
@ -2017,13 +2017,13 @@ These functions return either a string or a pattern.
- **GenerateUserPatterns** - **GenerateUserPatterns**
The `GenerateUserPatterns` function iterates through all users that are being migrated, excluding the currently processed user if **\<ProcessCurrentUser\>** is **FALSE**, and expands the specified pattern in the context of each user. For example, if users A, B, and C have profiles in `C:\Documents and Settings`, by calling `GenerateUserPattens('File','%userprofile% [*.doc]','TRUE')`, the helper function generates the following three patterns: The `GenerateUserPatterns` function iterates through all users that are being migrated, excluding the currently processed user if **\<ProcessCurrentUser\>** is **FALSE**, and expands the specified pattern in the context of each user. For example, if users A, B, and C have profiles in `C:\Users`, by calling `GenerateUserPattens('File','%userprofile% [*.doc]','TRUE')`, the helper function generates the following three patterns:
- "C:\\Documents and Settings\\A\\\* \[\*.doc\]" - "C:\\Users\\A\\\* \[\*.doc\]"
- "C:\\Documents and Settings\\B\\\* \[\*.doc\]" - "C:\\Users\\B\\\* \[\*.doc\]"
- "C:\\Documents and Settings\\C\\\* \[\*.doc\]" - "C:\\Users\\C\\\* \[\*.doc\]"
Syntax: `GenerateUserPatterns("ObjectType","EncodedLocationPattern","ProcessCurrentUser")` Syntax: `GenerateUserPatterns("ObjectType","EncodedLocationPattern","ProcessCurrentUser")`
@ -2037,7 +2037,7 @@ These functions return either a string or a pattern.
If `GenerateUserPattens('File','%userprofile% [*.doc]','FALSE')` is called while USMT is processing user A, then this function only generates patterns for users B and C. This helper function can be used to build complex rules. For example, to migrate all `.doc` files from the source computer - but if user X isn't migrated, then don't migrate any of the `.doc` files from user X's profile. If `GenerateUserPattens('File','%userprofile% [*.doc]','FALSE')` is called while USMT is processing user A, then this function only generates patterns for users B and C. This helper function can be used to build complex rules. For example, to migrate all `.doc` files from the source computer - but if user X isn't migrated, then don't migrate any of the `.doc` files from user X's profile.
The following example is example code for this scenario. The first **\<rules\>** element migrates all `.doc` files on the source computer except for those inside `C:\Documents and Settings`. The second **\<rules\>** elements migrate all `.doc` files from `C:\Documents and Settings` except for the `.doc` files in the profiles of the other users. Because the second **\<rules\>** element is processed in each migrated user context, the end result is the desired behavior. The end result is the one we expected. The following example is example code for this scenario. The first **\<rules\>** element migrates all `.doc` files on the source computer except for those inside `C:\Users`. The second **\<rules\>** elements migrate all `.doc` files from `C:\Users` except for the `.doc` files in the profiles of the other users. Because the second **\<rules\>** element is processed in each migrated user context, the end result is the desired behavior. The end result is the one we expected.
```xml ```xml
<rules context="System"> <rules context="System">