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

Metadata update deployment/usmt 9

Browse Source
This commit is contained in:
Frank Rojas 2022-11-02 16:25:10 -04:00
parent 9e5f6be85c
commit 02a9c2476c
10 changed files with 215 additions and 226 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -77,47 +77,47 @@ The default `MigDocs.xml` file migrates the following data:
- Standard shared folders:
- CSIDL\_COMMON\_DESKTOPDIRECTORY
- CSIDL_COMMON_DESKTOPDIRECTORY
- CSIDL\_COMMON\_FAVORITES
- CSIDL_COMMON_FAVORITES
- CSIDL\_COMMON\_DOCUMENTS
- CSIDL_COMMON_DOCUMENTS
- CSIDL\_COMMON\_MUSIC
- CSIDL_COMMON_MUSIC
- CSIDL\_COMMON\_PICTURES
- CSIDL_COMMON_PICTURES
- CSIDL\_COMMON\_VIDEO
- CSIDL_COMMON_VIDEO
- FOLDERID\_PublicDownloads
- FOLDERID_PublicDownloads
- Standard user-profile folders for each user:
- CSIDL\_MYDOCUMENTS
- CSIDL_MYDOCUMENTS
- CSIDL\_MYPICTURES
- CSIDL_MYPICTURES
- FOLDERID\_OriginalImages
- FOLDERID_OriginalImages
- CSIDL\_MYMUSIC
- CSIDL_MYMUSIC
- CSIDL\_MYVIDEO
- CSIDL_MYVIDEO
- CSIDL\_FAVORITES
- CSIDL_FAVORITES
- CSIDL\_DESKTOP
- CSIDL_DESKTOP
- CSIDL\_QUICKLAUNCH
- CSIDL_QUICKLAUNCH
- FOLDERID\_Contacts
- FOLDERID_Contacts
- FOLDERID\_Libraries
- FOLDERID_Libraries
- FOLDERID\_Downloads
- FOLDERID_Downloads
- FOLDERID\_SavedGames
- FOLDERID_SavedGames
- FOLDERID\_RecordedTV
- FOLDERID_RecordedTV
The default `MigDocs.xml` file won't migrate the following data:
@ -139,21 +139,21 @@ The default `MigUser.xml` file migrates the following data:
- All files from the standard user-profile folders, which are described as:
- CSIDL\_MYVIDEO
- CSIDL_MYVIDEO
- CSIDL\_MYMUSIC
- CSIDL_MYMUSIC
- CSIDL\_DESKTOP
- CSIDL_DESKTOP
- CSIDL\_STARTMENU
- CSIDL_STARTMENU
- CSIDL\_PERSONAL
- CSIDL_PERSONAL
- CSIDL\_MYPICTURES
- CSIDL_MYPICTURES
- CSIDL\_FAVORITES
- CSIDL_FAVORITES
- CSIDL\_QUICK LAUNCH
- CSIDL_QUICK LAUNCH
- Files with the following extensions:
@ -295,49 +295,49 @@ The migration XML files contain two <component> elements with different **
The system context includes rules for data outside of the User Profiles directory. For example, when called in a system context in the `MigDocs.xml` file, the `GenerateDocPatterns` function creates patterns for all common shell folders, files in the root directory of hard drives, and folders located at the root of hard drives. The following folders are included:
- CSIDL\_COMMON\_DESKTOPDIRECTORY
- CSIDL_COMMON_DESKTOPDIRECTORY
- CSIDL\_COMMON\_FAVORITES
- CSIDL_COMMON_FAVORITES
- CSIDL\_COMMON\_DOCUMENTS
- CSIDL_COMMON_DOCUMENTS
- CSIDL\_COMMON\_MUSIC
- CSIDL_COMMON_MUSIC
- CSIDL\_COMMON\_PICTURES
- CSIDL_COMMON_PICTURES
- CSIDL\_COMMON\_VIDEO
- CSIDL_COMMON_VIDEO
- FOLDERID\_PublicDownloads
- FOLDERID_PublicDownloads
#### User context
The user context includes rules for data in the User Profiles directory. When called in a user context in the `MigDocs.xml` file, the `GenerateDocPatterns` function creates patterns for all user shell folders, files located at the root of the profile, and folders located at the root of the profile. The following folders are included:
- CSIDL\_MYDOCUMENTS
- CSIDL_MYDOCUMENTS
- CSIDL\_MYPICTURES
- CSIDL_MYPICTURES
- FOLDERID\_OriginalImages
- FOLDERID_OriginalImages
- CSIDL\_MYMUSIC
- CSIDL_MYMUSIC
- CSIDL\_MYVIDEO
- CSIDL_MYVIDEO
- CSIDL\_FAVORITES
- CSIDL_FAVORITES
- CSIDL\_DESKTOP
- CSIDL_DESKTOP
- CSIDL\_QUICKLAUNCH
- CSIDL_QUICKLAUNCH
- FOLDERID\_Contacts
- FOLDERID_Contacts
- FOLDERID\_Libraries
- FOLDERID_Libraries
- FOLDERID\_Downloads
- FOLDERID_Downloads
- FOLDERID\_SavedGames
- FOLDERID_SavedGames
- FOLDERID\_RecordedTV
- FOLDERID_RecordedTV
> [!NOTE]
> Rules contained in a component that is assigned the user context will be run for each user profile on the computer. Files that are scanned multiple times by the `MigDocs.xml` files will only be copied to the migration store once; however, a large number of rules in the user context can slow down the migration. Use the system context when it is applicable.

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

@ -19,10 +19,10 @@ One of the main considerations for planning your migration is to determine which
| Link | Description |
|--- |--- |
|[Migration Store Types Overview](migration-store-types-overview.md)|Choose the migration store type that works best for your needs and migration scenario.|
|[Estimate Migration Store Size](usmt-estimate-migration-store-size.md)|Estimate the amount of disk space needed for computers in your organization based on information about your organization's infrastructure.|
|[Hard-Link Migration Store](usmt-hard-link-migration-store.md)|Learn about hard-link migration stores and the scenarios in which they're used.|
|[Migration Store Encryption](usmt-migration-store-encryption.md)|Learn about the using migration store encryption to protect user data integrity during a migration.|
|[Migration store types overview](migration-store-types-overview.md)|Choose the migration store type that works best for your needs and migration scenario.|
|[Estimate migration store size](usmt-estimate-migration-store-size.md)|Estimate the amount of disk space needed for computers in your organization based on information about your organization's infrastructure.|
|[Hard-link migration store](usmt-hard-link-migration-store.md)|Learn about hard-link migration stores and the scenarios in which they're used.|
|[Migration store encryption](usmt-migration-store-encryption.md)|Learn about the using migration store encryption to protect user data integrity during a migration.|
## Related articles

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

@ -61,11 +61,11 @@ This section describes the migration .xml files that are included with USMT. Eac
- **The MigUser.xml file.** Specify this file with both the `ScanState.exe` and `LoadState.exe` commands to migrate user folders, files, and file types. You can modify the `MigUser.xml` file. This file doesn't contain rules that migrate specific user accounts. The only way to specify which user accounts to migrate is on the command line using the ScanState and the LoadState user options.
> [!NOTE]
> 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.
> 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.
## 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.
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.
## The Config.xml file
@ -75,7 +75,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 will contain only operating system components, applications, and the user document sections that are in both of the .xml files and that are installed on the computer when you run the `ScanState.exe` command with the `/genconfig` option. Therefore, you should create this file on a source computer that contains all of the components, applications, and settings that will be present on the destination computers. Creating the file on the source computer will ensure that this file contains every component that can be migrated. The components are organized into sections: <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 you want to exclude additional data that you migrated to the store, modify the `Config.xml` file and specify the updated file with the `LoadState.exe` command. For example, if you collected the My Documents folder in the store, but you decide that you don't want to migrate the My Documents folder to a destination computer, you can modify the `Config.xml` file to indicate `migrate="no"` before you run the `LoadState.exe` command, and the file won't be migrated. For more information about the precedence that takes place when excluding data, see the [Exclude Files and Settings](usmt-exclude-files-and-settings.md) article.
After you create this file, you need to specify it only with the `ScanState.exe` command using the `/Config` option for it to affect the migration. However, if you want to exclude additional data that you migrated to the store, modify the `Config.xml` file and specify the updated file with the `LoadState.exe` command. For example, if you collected the My Documents folder in the store, but you decide that you don't want to migrate the My Documents folder to a destination computer, you can modify the `Config.xml` file to indicate `migrate="no"` before you run the `LoadState.exe` command, and the file won't be migrated. For more information about the precedence that takes place when excluding data, see the [Exclude files and settings](usmt-exclude-files-and-settings.md) article.
In addition, note the following functionality with the `Config.xml` file:
@ -104,11 +104,11 @@ In addition, note the following functionality with the `Config.xml` file:
## Additional information
- For more information about how to change the files and settings that are migrated, see the [User State Migration Tool (USMT) How-to topics](usmt-how-to.md).
- For more information about how to change the files and settings that are migrated, see the [User State Migration Tool (USMT) how-to topics](usmt-how-to.md).
- For more information about each .xml element, see the [XML Elements Library](usmt-xml-elements-library.md) article.
- For more information about each .xml element, see the [XML elements library](usmt-xml-elements-library.md) article.
- For answers to common questions, see ".xml files" in the [Frequently Asked Questions](usmt-faq.yml) article.
- For answers to common questions, see ".xml files" in the [Frequently asked questions](usmt-faq.yml) article.
## Related articles

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

@ -13,7 +13,7 @@ ms.technology: itpro-deploy
# Determine what to migrate
By default, User State Migration Tool (USMT) 10.0 migrates the items listed in [What Does USMT Migrate?](usmt-what-does-usmt-migrate.md), depending on the migration .xml files you specify. These default settings are often enough for a basic migration.
By default, User State Migration Tool (USMT) 10.0 migrates the items listed in [What does USMT migrate?](usmt-what-does-usmt-migrate.md), depending on the migration .xml files you specify. These default settings are often enough for a basic migration.
However, when considering what settings to migrate, you should also consider what settings you would like the user to be able to configure, if any, and what settings you would like to standardize. Many organizations use their migration as an opportunity to create and begin enforcing a better-managed environment. Some of the settings that users can configure on unmanaged computers prior to the migration can be locked on the new, managed computers. For example, standard wallpaper, Internet Explorer security settings, and desktop configuration are some of the items you can choose to standardize.
@ -31,10 +31,10 @@ Using an SOE can vastly simplify the migration and reduce overall deployment cha
| Link | Description |
|--- |--- |
|[Identify Users](usmt-identify-users.md)|Use command-line options to specify which users to migrate and how they should be migrated.|
|[Identify Applications Settings](usmt-identify-application-settings.md)|Determine which applications you want to migrate and prepare a list of application settings to be migrated.|
|[Identify Operating System Settings](usmt-identify-operating-system-settings.md)|Use migration to create a new standard environment on each of the destination computers.|
|[Identify File Types, Files, and Folders](usmt-identify-file-types-files-and-folders.md)|Determine and locate the standard, company-specified, and non-standard locations of the file types, files, folders, and settings that you want to migrate.|
|[Identify users](usmt-identify-users.md)|Use command-line options to specify which users to migrate and how they should be migrated.|
|[Identify applications settings](usmt-identify-application-settings.md)|Determine which applications you want to migrate and prepare a list of application settings to be migrated.|
|[Identify operating system settings](usmt-identify-operating-system-settings.md)|Use migration to create a new standard environment on each of the destination computers.|
|[Identify file types, files, and folders](usmt-identify-file-types-files-and-folders.md)|Determine and locate the standard, company-specified, and non-standard locations of the file types, files, folders, and settings that you want to migrate.|
## Related articles

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

@ -17,11 +17,11 @@ The disk space requirements for a migration are dependent on the size of the mig
## In this topic
- [Hard Disk Space Requirements](#hard-disk-space-requirements): Describes the disk space requirements for the migration store and other considerations on the source and destination computers.
- [Hard disk space requirements](#hard-disk-space-requirements): Describes the disk space requirements for the migration store and other considerations on the source and destination computers.
- [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.
- [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.
- [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.
- [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
@ -75,7 +75,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.
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 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).
> [!NOTE]
> To preserve the functionality of existing applications or scripts that require the previous behavior of USMT, the `/p` option is still available in USMT without having to specify the path to a file. See [Monitoring Options](usmt-scanstate-syntax.md#monitoring-options) for more information.

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

@ -13,7 +13,7 @@ ms.technology: itpro-deploy
# Exclude files and settings
When you specify the migration .xml files, `MigApp.xml`, `Migdocs.xml`, and `MigUser.xml`, the User State Migration Tool (USMT) 10.0 migrates the settings and components listed, as discussed in [What Does USMT Migrate?](usmt-what-does-usmt-migrate.md) You can create a custom .xml file to further specify what to include or exclude in the migration. In addition you can create a `Config.xml` file to exclude an entire component from a migration. You can't, however, exclude users by using the migration .xml files or the `Config.xml` file. The only way to specify which users to include and exclude is by using the User options on the command line in the ScanState tool. For more information, see [ScanState Syntax](usmt-scanstate-syntax.md).
When you specify the migration .xml files, `MigApp.xml`, `Migdocs.xml`, and `MigUser.xml`, the User State Migration Tool (USMT) 10.0 migrates the settings and components listed, as discussed in [What Does USMT Migrate?](usmt-what-does-usmt-migrate.md) You can create a custom .xml file to further specify what to include or exclude in the migration. In addition you can create a `Config.xml` file to exclude an entire component from a migration. You can't, however, exclude users by using the migration .xml files or the `Config.xml` file. The only way to specify which users to include and exclude is by using the User options on the command line in the ScanState tool. For more information, see [ScanState syntax](usmt-scanstate-syntax.md).
## In this topic
@ -23,7 +23,7 @@ When you specify the migration .xml files, `MigApp.xml`, `Migdocs.xml`, and `Mig
- [unconditionalExclude](#example-1-how-to-migrate-all-files-from-c-except-mp3-files): You can use the **<unconditionalExclude>** element to globally exclude data. This element takes precedence over all other include and exclude rules in the .xml files. Therefore, this element excludes objects regardless of any other **<include>** rules that are in the .xml files. For example, you can exclude all .mp3 files on the computer, or you can exclude all files from C:\\UserData.
- [Create a Config.xml File](#create-a-config-xml-file): You can create and modify a `Config.xml` file to exclude an entire component from the migration. For example, you can use this file to exclude the settings for one of the default applications. In addition, creating and modifying a `Config.xml` file is the only way to exclude the operating-system settings that are migrated to computers running Windows. 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.
- [Create a Config.xml file](#create-a-config-xml-file): You can create and modify a `Config.xml` file to exclude an entire component from the migration. For example, you can use this file to exclude the settings for one of the default applications. In addition, creating and modifying a `Config.xml` file is the only way to exclude the operating-system settings that are migrated to computers running Windows. 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.
## Create a custom .xml file

126
windows/deployment/usmt/usmt-hard-link-migration-store.md
View File

@ -13,158 +13,156 @@ ms.technology: itpro-deploy
# Hard-Link Migration Store
A *hard-link migration store* enables you to perform an in-place migration where all user state is maintained on the computer while the old operating system is removed and the new operating system is installed; this functionality is what makes *hard-link migration store* best suited for the computer-refresh scenario. Use of a hard-link migration store for a computer-refresh scenario drastically improves migration performance and significantly reduces hard-disk utilization, reduces deployment costs, and enables entirely new migration scenarios.
A **hard-link migration store** enables you to perform an in-place migration where all user state is maintained on the computer while the old operating system is removed and the new operating system is installed. This functionality is what makes **hard-link migration store** best suited for the computer-refresh scenario. Use of a hard-link migration store for a computer-refresh scenario drastically improves migration performance and significantly reduces hard-disk utilization, reduces deployment costs, and enables entirely new migration scenarios.
## In this topic
[When to Use a Hard-Link Migration](#bkmk-when)
[When to use a hard-link migration](#when-to-use-a-hard-link-migration)
[Understanding a Hard-Link Migration](#bkmk-understandhardlinkmig)
[Understanding a hard-link migration](#understanding-a-hard-link-migration)
[Scenario](#bkmk-scenario)
[Hard-Link migration store details](#hard-link-migration-store-details)
[Hard-Link Migration Store Details](#bkmk-hardlinkstoredetails)
[Hard disk space](#hard-disk-space)
[Hard Disk Space](#bkmk-harddiskspace)
[Hard-Link store size estimation](#hard-link-store-size-estimation)
[Hard-Link Store Size Estimation](#bkmk-hardlinkstoresizeest)
[Migration store path on multiple volumes](#migration-store-path-on-multiple-volumes)
[Migration Store Path on Multiple Volumes](#bkmk-migstoremultvolumes)
[Location modifications](#location-modifications)
[Location Modifications](#bkmk-locationmodify)
[Migrating Encrypting File System (EFS) certificates and files](#migrating-encrypting-file-system-efs-certificates-and-files)
[Migrating Encrypting File System (EFS) Certificates and Files](#bkmk-efs)
[Migrating locked files with the hard-link migration store](#migrating-locked-files-with-the-hard-link-migration-store)
[Migrating Locked Files With the Hard-Link Migration Store](#bkmk-miglockedfiles)
[XML elements in the Config.xml file](#xml-elements-in-the-configxml-file)
[XML Elements in the Config.xml File](#bkmk-xmlelementsinconfig)
## <a href="" id="bkmk-when"></a>When to Use a Hard-Link Migration
## When to use a hard-link migration
You can use a hard-link migration store when your planned migration meets both of the following criteria:
- You are upgrading the operating system on existing hardware rather than migrating to new computers.
- You're upgrading the operating system on existing hardware rather than migrating to new computers.
- You are upgrading the operating system on the same volume of the computer.
- You're upgrading the operating system on the same volume of the computer.
You cannot use a hard-link migration store if your planned migration includes any of the following tasks:
You can't use a hard-link migration store if your planned migration includes any of the following tasks:
- You are migrating data from one computer to a second computer.
- You're migrating data from one computer to a second computer.
- You are migrating data from one volume on a computer to another volume, for example from `C:` to `D:`.
- You're migrating data from one volume on a computer to another volume, for example from `C:` to `D:`.
- You are formatting or repartitioning the disk outside of Windows Setup, or specifying a disk format or repartition during Windows Setup that will remove the migration store.
- You're formatting or repartitioning the disk outside of Windows Setup, or specifying a disk format or repartition during Windows Setup that will remove the migration store.
## <a href="" id="bkmk-understandhardlinkmig"></a>Understanding a Hard-Link Migration
## Understanding a hard-link migration
The hard-link migration store is created using the command-line option, **/hardlink**, and is equivalent to other migration-store types. However, it differs in that hard links are utilized to keep files stored on the source computer during the migration. Keeping the files in place on the source computer eliminates the redundant work of duplicating files. It also enables the performance benefits and reduction in disk utilization that define this scenario.
The hard-link migration store is created using the command-line option, `/hardlink`, and is equivalent to other migration-store types. However, it differs in that hard links are utilized to keep files stored on the source computer during the migration. Keeping the files in place on the source computer eliminates the redundant work of duplicating files. It also enables the performance benefits and reduction in disk utilization that define this scenario.
When you create a hard link, you give an existing file one more path. For instance, you could create a hard link to c:\\file1.txt called c:\\hard link\\myFile.txt. These two paths relate to the same file. If you open c:\\file1.txt, make changes, and save the file, you will see those changes when you open c:\\hard link\\myFile.txt. If you delete c:\\file1.txt, the file still exists on your computer as c:\\hardlink\\myFile.txt. You must delete both references to the file in order to delete the file.
When you create a hard link, you give an existing file one more path. For instance, you could create a hard link to `c:\file1.txt` called `c:\hard link\myFile.txt`. These two paths relate to the same file. If you open `c:\file1.txt`, make changes, and save the file, you'll see those changes when you open `c:\hard link\myFile.txt`. If you delete `c:\file1.txt`, the file still exists on your computer as `c:\hardlink\myFile.txt`. You must delete both references to the file in order to delete the file.
> [!NOTE]
> A hard link can only be created for a file on the same volume. If you copy a hard-link migration store to another drive or external device, the files, and not the links, are copied, as in a non-compressed migration-store scenario.
For more information about hard links, see [Hard Links and Junctions](/windows/win32/fileio/hard-links-and-junctions)
In most aspects, a hard-link migration store is identical to an uncompressed migration store. It is located where specified by the Scanstate command-line tool and you can view the contents of the store by using Windows&reg; Explorer. Once created, it can be deleted or copied to another location without changing user state. Restoring a hard-link migration store is similar to restoring any other migration store; however, as with creating the store, the same hard-link functionality is used to keep files in-place.
In most aspects, a hard-link migration store is identical to an uncompressed migration store. It's located where specified by the **Scanstate** command-line tool and you can view the contents of the store by using Windows&reg; Explorer. Once created, it can be deleted or copied to another location without changing user state. Restoring a hard-link migration store is similar to restoring any other migration store. However, as with creating the store, the same hard-link functionality is used to keep files in-place.
As a best practice, we recommend that you delete the hard-link migration store after you confirm that the Loadstate tool has successfully migrated the files. Since Loadstate has created new paths to the files on your new installation of a Windows operating system, deleting the hard links in the migration store will only delete one path to the files and will not delete the actual files or the paths to them from your new operating system.
As a best practice, it is recommended that you delete the hard-link migration store after you confirm that the **Loadstate** tool has successfully migrated the files. Since **Loadstate** has created new paths to the files on the new installation of a Windows operating system, deleting the hard links in the migration store will only delete one path to the files, and won't delete the actual files or the paths to them from the new operating system.
> [!IMPORTANT]
> Using the **/c** option will force the Loadstate tool to continue applying files when non-fatal errors occur. If you use the **/c** option, you should verify that no errors are reported in the logs before deleting the hard-link migration store in order to avoid data loss.
> Using the `/c` option will force the **Loadstate** tool to continue applying files when non-fatal errors occur. If you use the `/c` option, you should verify that no errors are reported in the logs before deleting the hard-link migration store in order to avoid data loss.
Keeping the hard-link migration store can result in extra disk space being consumed or problems with some applications for the following reasons:
- Applications reporting file-system statistics, for example, space used and free space, might incorrectly report these statistics while the hard-link migration store is present. The file may be reported twice because of the two paths that reference that file.
- A hard link may lose its connection to the original file. Some applications save changes to a file by creating a temporary file and then renaming the original to a backup filename. The path that was not used to open the file in this application will continue to refer to the unmodified file. The unmodified file that is not in use is taking up more disk space. You should create the hard-link migration store just before you perform the migration, and not use applications once the store is created, in order to make sure you are migrating the latest versions of all files.
- A hard link may lose its connection to the original file. Some applications save changes to a file by creating a temporary file and then renaming the original to a backup filename. The path that wasn't used to open the file in this application will continue to refer to the unmodified file. The unmodified file that isn't in use is taking up more disk space. You should create the hard-link migration store just before you perform the migration, and not use applications once the store is created, in order to make sure you're migrating the latest versions of all files.
- Editing the file by using different paths simultaneously may result in data corruption.
> [!IMPORTANT]
> The read-only file attribute on migrated files is lost when the hard-link migration store is deleted. This is due to a limitation in NTFS file system hard links.
## <a href="" id="bkmk-scenario"></a>Hard-Link Migration Scenario
## Hard-link migration scenario
For example, a company has decided to deploy Windows 10 on all of their computers. Each employee will keep the same computer, but the operating system on each computer will be updated.
For example, a company has decided to deploy Windows 10 on all of their computers. Each employee will keep the same computer, but the operating system on each computer will be updated.
1. An administrator runs the ScanState command-line tool on each computer, specifying the **/hardlink** command-line option. The ScanState tool saves the user state to a hard-link migration store on each computer, improving performance by reducing file duplication, except in certain specific instances.
1. An administrator runs the **ScanState** command-line tool on each computer, specifying the `/hardlink` command-line option. The **ScanState** tool saves the user state to a hard-link migration store on each computer, improving performance by reducing file duplication, except in certain specific instances.
> [!NOTE]
> As a best practice, we recommend that you do not create your hard-link migration store until just before you perform the migration in order to migrate the latest versions of your files. You should not use your software applications on the computer after creating the migration store until you have finished migrating your files with Loadstate.
> As a best practice, we recommend that you do not create your hard-link migration store until just before you perform the migration in order to migrate the latest versions of your files. You should not use your software applications on the computer after creating the migration store until you have finished migrating your files with **LoadState**.
2. On each computer, an administrator installs the company's standard operating environment (SOE), which includes Windows 7 and other applications the company currently uses.
2. On each computer, an administrator installs the company's standard operating environment (SOE), which includes Windows 7 and other applications the company currently uses.
3. An administrator runs the LoadState command-line tool on each computer. The LoadState tool restores user state back on each computer.
3. An administrator runs the **LoadState** command-line tool on each computer. The **LoadState** tool restores user state back on each computer.
> [!NOTE]
> During the update of a domain-joined computer, the profiles of users whose SID cannot be resolved will not be migrated. When using a hard-link migration store, it could cause a data loss.
## <a href="" id="bkmk-hardlinkstoredetails"></a>Hard-Link Migration Store Details
## Hard-link migration store details
This section provides details about hard-link migration stores.
### <a href="" id="bkmk-harddiskspace"></a>Hard Disk Space
### Hard disk space
The **/hardlink** command-line option proceeds with creating the migration store only if there are 250 megabytes (MB) of free space on the hard disk. If every volume involved in the migration is formatted as NTFS, 250 MB should be enough space to ensure success for almost every hard-link migration, regardless on the size of the migration.
The `/hardlink` command-line option proceeds with creating the migration store only if there are 250 megabytes (MB) of free space on the hard disk. If every volume involved in the migration is formatted as NTFS, 250 MB should be enough space to ensure success for almost every hard-link migration, regardless on the size of the migration.
### <a href="" id="bkmk-hardlinkstoresizeest"></a>Hard-Link Store Size Estimation
### Hard-link store size estimation
It is not necessary to estimate the size of a hard-link migration store. Estimating the size of a migration store is only useful in scenarios where the migration store is large, and on NTFS volumes the hard-link migration store will require much less incremental space than other store options. The only case where the local store can be large is when non-NTFS file systems exist on the system and contain data being migrated. Since NTFS has been the default file system format for Windows XP and newer operating systems, this situation is unusual.
It isn't necessary to estimate the size of a hard-link migration store. Estimating the size of a migration store is only useful in scenarios where the migration store is large, and on NTFS volumes the hard-link migration store will require much less incremental space than other store options. The only case where the local store can be large is when non-NTFS file systems exist on the system and contain data being migrated. Since NTFS has been the default file system format for Windows XP and newer operating systems, this situation is unusual.
### <a href="" id="bkmk-migstoremultvolumes"></a>Migration Store Path on Multiple Volumes
### Migration store path on multiple volumes
Separate hard-link migration stores are created on each NTFS volume that contain data being migrated. In this scenario, the primary migration-store location will be specified on the command line, and should be the operating-system volume. Migration stores with identical names and directory names will be created on every volume containing data being migrated. For example:
`Scanstate /hardlink c:\USMTMIG […]`
`Scanstate.exe /hardlink c:\USMTMIG […]`
Running this command on a system that contains the operating system on the C: drive and the user data on the D: drive will generate migration stores in the following locations, assuming that both drives are NTFS:
C:\\USMTMIG\\
`C:\USMTMIG\`
D:\\USMTMIG\\
`D:\USMTMIG\`
The drive you specify on the command line for the hard-link migration store is important, because it defines where the *master migration store* should be placed. The *master migration store* is the location where data migrating from non-NTFS volumes is stored. This volume must have enough space to contain all of the data that comes from non-NTFS volumes. As in other scenarios, if a migration store already exists at the specified path, the **/o** option must be used to overwrite the existing data in the store.
The drive you specify on the command line for the hard-link migration store is important, because it defines where the **master migration store** should be placed. The **master migration store** is the location where data migrating from non-NTFS volumes is stored. This volume must have enough space to contain all of the data that comes from non-NTFS volumes. As in other scenarios, if a migration store already exists at the specified path, the `/o` option must be used to overwrite the existing data in the store.
### <a href="" id="bkmk-locationmodify"></a>Location Modifications
### Location modifications
Location modifications that redirect migrated content from one volume to a different volume have an adverse impact on the performance of a hard-link migration. This impact is because the migrating data that must cross system volumes cannot remain in the hard-link migration store, and must be copied across the system volumes.
Location modifications that redirect migrated content from one volume to a different volume have an adverse impact on the performance of a hard-link migration. This impact is because the migrating data that must cross system volumes can't remain in the hard-link migration store, and must be copied across the system volumes.
### <a href="" id="bkmk-efs"></a>Migrating Encrypting File System (EFS) Certificates and Files
### Migrating Encrypting File System (EFS) certificates and files
To migrate Encrypting File System (EFS) files to a new installation of an operating system on the same volume of the computer, specify the **/efs:hardlink** option in the Scanstate command-line syntax.
To migrate Encrypting File System (EFS) files to a new installation of an operating system on the same volume of the computer, specify the `/efs:hardlink` option in the `Scanstate.exe` command-line syntax.
If the EFS files are being restored to a different partition, you should use the **/efs:copyraw** option instead of the **/efs:hardlink** option. Hard links can only be created for files on the same volume. Moving the files to another partition during the migration requires a copy of the files to be created on the new partition. The **/efs:copyraw** option will copy the files to the new partition in encrypted format.
If the EFS files are being restored to a different partition, you should use the `/efs:copyraw` option instead of the `/efs:hardlink` option. Hard links can only be created for files on the same volume. Moving the files to another partition during the migration requires a copy of the files to be created on the new partition. The `/efs:copyraw` option will copy the files to the new partition in encrypted format.
For more information, see [Migrate EFS Files and Certificates](usmt-migrate-efs-files-and-certificates.md) and the Encrypted File Options in [ScanState Syntax](usmt-scanstate-syntax.md).
For more information, see [Migrate EFS files and certificates](usmt-migrate-efs-files-and-certificates.md) and [Encrypted file options](usmt-scanstate-syntax.md#encrypted-file-options).
### <a href="" id="bkmk-miglockedfiles"></a>Migrating Locked Files with the Hard-Link Migration Store
### Migrating locked files with the hard-link migration store
Files that are locked by an application or the operating system are handled differently when using a hard-link migration store.
Files that are locked by the operating system cannot remain in place and must be copied into the hard-link migration store. As a result, selecting many operating-system files for migration significantly reduces performance during a hard-link migration. As a best practice, we recommend that you do not migrate any files out of the \\Windows directory, which minimizes performance-related issues.
Files that are locked by the operating system can't remain in place and must be copied into the hard-link migration store. As a result, selecting many operating-system files for migration significantly reduces performance during a hard-link migration. As a best practice, we recommend that you don't migrate any files out of the `\Windows directory`, which minimizes performance-related issues.
Files that are locked by an application are treated the same in hard-link migrations as in other scenarios when the volume shadow-copy service is not being utilized. The volume shadow-copy service cannot be used with hard-link migrations. However, by modifying the new `<HardLinkStoreControl>` section in the Config.xml file, it is possible to enable the migration of files locked by an application.
Files that are locked by an application are treated the same in hard-link migrations as in other scenarios when the volume shadow-copy service isn't being utilized. The volume shadow-copy service can't be used with hard-link migrations. However, by modifying the new **&lt;HardLinkStoreControl&gt;** section in the `Config.xml` file, it's possible to enable the migration of files locked by an application.
> [!IMPORTANT]
> There are some scenarios in which modifying the `<HardLinkStoreControl>` section in the Config.xml file makes it more difficult to delete a hard-link migration store. In these scenarios, you must use USMTutils.exe to schedule the migration store for deletion on the next restart.
> There are some scenarios in which modifying the **&lt;HardLinkStoreControl&gt;** section in the `Config.xml` file makes it more difficult to delete a hard-link migration store. In these scenarios, you must use `USMTutils.exe` to schedule the migration store for deletion on the next restart.
## <a href="" id="bkmk-xmlelementsinconfig"></a>XML Elements in the Config.xml File
## XML elements in the Config.xml file
A new section in the Config.xml file allows optional configuration of some of the hard-link migration behavior introduced with the **/HardLink** option.
A new section in the `Config.xml` file allows optional configuration of some of the hard-link migration behavior introduced with the `/HardLink` option.
| Element | Description |
|--- |--- |
| `<Policies>` | This element contains elements that describe the policies that USMT follows while creating a migration store. |
| `<HardLinkStoreControl>` | This element contains elements that describe how to handle files during the creation of a hard link migration store. |
| `<fileLocked>` | This element contains elements that describe how to handle files that are locked for editing. |
| `<createHardLink>` | This 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. <br/><br/>Syntax: `<createHardLink>` [pattern] `</createHardLink>` |
| `<errorHardLink>` | This element defines a standard MigXML pattern that describes file paths where hard links should not be created, if the file is locked for editing by another application. <br/><br/>`<errorHardLink>` [pattern] `</errorHardLink>` |
| **&lt;Policies&gt;** | This element contains elements that describe the policies that USMT follows while creating a migration store. |
| **&lt;HardLinkStoreControl&gt;** | This element contains elements that describe how to handle files during the creation of a hard link migration store. |
| **&lt;fileLocked&gt;** | This element contains elements that describe how to handle files that are locked for editing. |
| **&lt;createHardLink&gt;** | This 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. <br/><br/>Syntax: `<createHardLink>` [pattern] `</createHardLink>` |
| **&lt;errorHardLink&gt;** | This 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. <br/><br/>`<errorHardLink>` [pattern] `</errorHardLink>` |
> [!IMPORTANT]
> You must use the **/nocompress** option with the **/HardLink** option.
> You must use the `/nocompress` option with the `/HardLink` option.
The following XML sample specifies that files locked by an application under the \\Users directory can remain in place during the migration. It also specifies that locked files that are not located in the \\Users directory should result in the **File in Use** error. It is important to exercise caution when specifying the paths using the **File in Use`<createhardlink>`** tag in order to minimize scenarios that make the hard-link migration store more difficult to delete.
The following XML sample specifies that files locked by an application under the `\Users` directory can remain in place during the migration. It also specifies that locked files that aren't located in the `\Users` directory should result in the **File in Use** error. It's important to exercise caution when specifying the paths using the `<createhardlink>`** tag in order to minimize scenarios that make the hard-link migration store more difficult to delete.
``` xml
<Policies>
@ -177,6 +175,6 @@ The following XML sample specifies that files locked by an application under the
</Policies>
```
## Related topics
## Related articles
[Plan Your Migration](usmt-plan-your-migration.md)
[Plan your migration](usmt-plan-your-migration.md)

125
windows/deployment/usmt/usmt-how-it-works.md
View File

@ -11,123 +11,112 @@ ms.technology: itpro-deploy
ms.date: 11/01/2022
---
# How USMT Works
# How USMT works
USMT includes two tools that migrate settings and data: **ScanState** and **LoadState**. **ScanState** collects information from the source computer, and **LoadState** applies that information to the destination computer.
USMT includes two tools that migrate settings and data: ScanState and LoadState. ScanState collects information from the source computer, and LoadState applies that information to the destination computer.
- [How USMT works](#how-usmt-works)
- [The ScanState process](#the-scanstate-process)
- [The LoadState process](#the-loadstate-process)
- [Related articles](#related-articles)
- [ScanState Process](#the-scanstate-process)
- [LoadState Process](#the-loadstate-process)
> [!NOTE]
> For more information about how USMT processes the rules and the XML files, see [Conflicts and precedence](usmt-conflicts-and-precedence.md).
**Note**  
For more information about how USMT processes the rules and the XML files, see [Conflicts and Precedence](usmt-conflicts-and-precedence.md).
## The ScanState process
## The ScanState Process
When you run the **ScanState** tool on the source computer, it goes through the following process:
When you run the ScanState tool on the source computer, it goes through the following process:
1. It parses and validates the command-line parameters, creates the ScanState.log file, and then begins logging.
1. It parses and validates the command-line parameters, creates the `ScanState.log` file, and then begins logging.
2. It collects information about all of the migration components that need to be migrated. A *migration component* is a logical group of files, registry keys, and values. For example, the set of files, registry keys, and values that store the settings of Adobe Acrobat is grouped into a single migration component.
There are three types of components:
- Components that migrate the operating system settings
- Components that migrate application settings
- Components that migrate users’ files
The ScanState tool collects information about the application settings and user data components from the .xml files that are specified on the command line.
- Components that migrate users' files
In Windows 7, and Windows 8, the manifest files control how the operating-system settings are migrated. You cannot modify these files. If you want to exclude certain operating-system settings, you must create and modify a Config.xml file.
The **ScanState** tool collects information about the application settings and user data components from the .xml files that are specified on the command line.
3. ScanState determines which user profiles should be migrated. By default, all user profiles on the source computer are migrated. However, you can include and exclude users using the User Options. The public profile in a source computer running Windows 7, Windows 8, and Windows 10 is always migrated, and you cannot exclude these profiles from the migration.
In Windows 7, and Windows 8, the manifest files control how the operating-system settings are migrated. You can't modify these files. If you want to exclude certain operating-system settings, you must create and modify a `Config.xml` file.
4. In the "Scanning" phase, ScanState does the following for each user profile selected for migration:
3. **ScanState** determines which user profiles should be migrated. By default, all user profiles on the source computer are migrated. However, you can include and exclude users using the User Options. The public profile in a source computer running Windows 7, Windows 8, and Windows 10 is always migrated, and you can't exclude these profiles from the migration.
1. For each component, ScanState checks the type of the component. If the current user profile is the system profile and the component type is “System” or “UserAndSystem”, the component is selected for this user. Otherwise, the component is ignored. Alternatively, if the current user profile is not the system profile and the component type is “User” or “UserAndSystem”, the component is selected for this user. Otherwise, this component is ignored.
4. In the **Scanning** phase, **ScanState** does the following for each user profile selected for migration:
**Note**  
From this point on, ScanState does not distinguish between components that migrate operating-system settings, those that migrate application settings, and those that migrate users’ files. ScanState processes all components in the same way.
1. For each component, **ScanState** checks the type of the component. If the current user profile is the system profile and the component type is **System** or **UserAndSystem**, the component is selected for this user. Otherwise, the component is ignored. Alternatively, if the current user profile isn't the system profile and the component type is **User** or **UserAndSystem**, the component is selected for this user. Otherwise, this component is ignored.
2. Each component that is selected in the previous step is processed further. Any profile-specific variables (such as CSIDL\_PERSONAL) are evaluated in the context of the current profile. For example, if the profile that is being processed belongs to “User1”, then CSIDL\_PERSONAL would expand to C:\\Users\\User1\\Documents, assuming that the user profiles are stored in the C:\\Users directory.
> [!NOTE]
> From this point on, **ScanState** does not distinguish between components that migrate operating-system settings, those that migrate application settings, and those that migrate users' files. **ScanState** processes all components in the same way.
3. For each selected component, ScanState evaluates the &lt;detects&gt; section. If the condition in the &lt;detects&gt; section evaluates to false, the component is not processed any further. Otherwise, the processing of this component continues.
2. Each component that is selected in the previous step is processed further. Any profile-specific variables (such as **CSIDL_PERSONAL**) are evaluated in the context of the current profile. For example, if the profile that is being processed belongs to **User1**, then **CSIDL_PERSONAL** would expand to `C:\Users\User1\Documents`, assuming that the user profiles are stored in the `C:\Users` directory.
4. For each selected component, ScanState evaluates the &lt;rules&gt; sections. For each &lt;rules&gt; section, if the current user profile is the system profile and the context of the &lt;rules&gt; section is “System” or “UserAndSystem”, the rule is processed further. Otherwise, this rule is ignored. Alternatively, if the current user profile is not the system profile and the context of the &lt;rules&gt; section is “User” or “UserAndSystem”, the rule is processed further. Otherwise, this rule is ignored.
3. For each selected component, **ScanState** evaluates the **&lt;detects&gt;** section. If the condition in the **&lt;detects&gt;** section evaluates to false, the component isn't processed any further. Otherwise, the processing of this component continues.
5. ScanState creates a list of migration units that need to be migrated by processing the various subsections under this &lt;rules&gt; section. Each unit is collected if it is mentioned in an &lt;include&gt; subsection, as long as there is not a more specific rule for it in an &lt;exclude&gt; subsection in the same &lt;rules&gt; section. For more information about precedence in the .xml files, see [Conflicts and Precedence](usmt-conflicts-and-precedence.md).
4. For each selected component, **ScanState** evaluates the **&lt;rules&gt;** sections. For each **&lt;rules&gt;** section, if the current user profile is the system profile and the context of the **&lt;rules&gt;** section is **System** or **UserAndSystem**, the rule is processed further. Otherwise, this rule is ignored. Alternatively, if the current user profile isn't the system profile and the context of the **&lt;rules&gt;** section is **User** or **UserAndSystem**, the rule is processed further. Otherwise, this rule is ignored.
In addition, any migration unit (such as a file, registry key, or set of registry values) that is in an &lt;UnconditionalExclude&gt; section is not migrated.
5. **ScanState** creates a list of migration units that need to be migrated by processing the various subsections under this **&lt;rules&gt;** section. Each unit is collected if it's mentioned in an **&lt;include&gt;** subsection, as long as there isn't a more specific rule for it in an **&lt;exclude&gt;** subsection in the same **&lt;rules&gt;** section. For more information about precedence in the .xml files, see [Conflicts and precedence](usmt-conflicts-and-precedence.md).
**Note**  
ScanState ignores some subsections such as &lt;destinationCleanup&gt; and &lt;locationModify&gt;. These sections are evaluated only on the destination computer.
In addition, any migration unit (such as a file, registry key, or set of registry values) that is in an &lt;UnconditionalExclude&gt; section isn't migrated.
5. In the "Collecting" phase, ScanState creates a master list of the migration units by combining the lists that were created for each selected user profile.
> [!NOTE]
> **ScanState** ignores some subsections such as &lt;destinationCleanup&gt; and &lt;locationModify&gt;. These sections are evaluated only on the destination computer.
6. In the "Saving" phase, ScanState writes the migration units that were collected to the store location.
5. In the **Collecting** phase, **ScanState** creates a master list of the migration units by combining the lists that were created for each selected user profile.
**Note**  
ScanState does not modify the source computer in any way.
6. In the **Saving** phase, **ScanState** writes the migration units that were collected to the store location.
## The LoadState Process
> [!NOTE]
> **ScanState** does not modify the source computer in any way.
## The LoadState process
The LoadState process is very similar to the ScanState process. The ScanState tool collects migration units such as file, registry key, or registry values from the source computer and saves them to the store. Similarly, the LoadState tool collects migration units from the store and applies them to the destination computer.
The **LoadState** process is similar to the **ScanState** process. The **ScanState** tool collects migration units such as file, registry key, or registry values from the source computer and saves them to the store. Similarly, the **LoadState** tool collects migration units from the store and applies them to the destination computer.
1. ScanState parses and validates the command-line parameters, creates the ScanState.log file, and then begins logging.
1. **ScanState** parses and validates the command-line parameters, creates the `ScanState.log` file, and then begins logging.
2. LoadState collects information about the migration components that need to be migrated.
2. **LoadState** collects information about the migration components that need to be migrated.
LoadState obtains information for the application-settings components and user-data components from the migration .xml files that are specified by the LoadState command.
**LoadState** obtains information for the application-settings components and user-data components from the migration .xml files that are specified by the `LoadState.exe` command.
In Windows 7, and Windows 8, the manifest files control how the operating-system settings are migrated. You cannot modify these files. If you want to exclude certain operating-system settings, you must create and modify a Config.xml file.
In Windows 7, Windows 8, and Windows 10, the manifest files control how the operating-system settings are migrated. You can't modify these files. If you want to exclude certain operating-system settings, you must create and modify a `Config.xml` file.
3. LoadState determines which user profiles should be migrated. By default, all user profiles present on the source computer are migrated. However, you can include and exclude users using the User Options. The system profile, the "All users" profile in a source computer running Windows XP, or the Public profile in a source computer running Windows Vista, Windows 7, and Windows 8, is always migrated and you cannot exclude these profiles from the migration.
3. **LoadState** determines which user profiles should be migrated. By default, all user profiles present on the source computer are migrated. However, you can include and exclude users using the **User Options**. The system profile, the Public profile in a source computer running Windows 7, Windows 8, and Windows 10 is always migrated and you can't exclude these profiles from the migration.
- If you are migrating local user accounts and if the accounts do not already exist on the destination computer, you must use the<strong>/lac</strong> command-line option. If you do not specify the **/lac** option, any local user accounts that are not already present on the destination computer, are not migrated.
- If you're migrating local user accounts and if the accounts don't already exist on the destination computer, you must use the `/lac` command-line option. If you don't specify the `/lac` option, any local user accounts that aren't already present on the destination computer, aren't migrated.
- The **/md** and **/mu** options are processed to rename the user profile on the destination computer, if they have been included when the LoadState command was specified.
- The `/md` and `/mu` options are processed to rename the user profile on the destination computer, if they've been included when the `LoadState.exe` command was specified.
- For each user profile selected from the store, LoadState creates a corresponding user profile on the destination computer. The destination computer does not need to be connected to the domain for domain user profiles to be created. If USMT cannot determine a domain, it attempts to apply the settings to a local account. For more information, see [Identify Users](usmt-identify-users.md).
- For each user profile selected from the store, **LoadState** creates a corresponding user profile on the destination computer. The destination computer doesn't need to be connected to the domain for domain user profiles to be created. If USMT can't determine a domain, it attempts to apply the settings to a local account. For more information, see [Identify Users](usmt-identify-users.md).
4. In the "Scanning" phase, LoadState does the following for each user profile:
4. In the **Scanning** phase, **LoadState** does the following for each user profile:
1. For each component, LoadState checks the type of the component. If the current user profile is the system profile and the component type is “System” or “UserAndSystem”, the component is selected for this user. Otherwise, the component is ignored. Alternatively, if the current user profile is not the system profile and the component type is “User” or “UserAndSystem”, the component is selected for this user. Otherwise, this component is ignored.
1. For each component, **LoadState** checks the type of the component. If the current user profile is the system profile and the component type is **System** or **UserAndSystem**, the component is selected for this user. Otherwise, the component is ignored. Alternatively, if the current user profile isn't the system profile and the component type is **User** or **UserAndSystem**, the component is selected for this user. Otherwise, this component is ignored.
**Note**
From this point on, LoadState does not distinguish between components that migrate operating-system settings, those that migrate application settings, and those that migrate users’ files. LoadState evaluates all components in the same way.
> [!NOTE]
> From this point on, **LoadState** does not distinguish between components that migrate operating-system settings, those that migrate application settings, and those that migrate users' files. **LoadState** evaluates all components in the same way.
2. Each component that is selected is processed further. Any profile-specific variables (such as **CSIDL_PERSONAL**) are evaluated in the context of the current profile. For example, if the profile being processed belongs to **User1**, then **CSIDL_PERSONAL** would expand to `C:\Users\User1\Documents` (assuming that the user profiles are stored in the `C:\Users` directory).
> [!NOTE]
> **LoadState** ignores the **&lt;detects&gt;** section specified in a component. At this point, all specified components are considered to be detected and are selected for migration.
2. Each component that is selected is processed further. Any profile-specific variables (such as CSIDL\_PERSONAL) are evaluated in the context of the current profile. For example, if the profile being processed belongs to “User1”, then CSIDL\_PERSONAL would expand to C:\\Users\\User1\\Documents (assuming that the user profiles are stored in the C:\\Users directory).
**Note**
LoadState ignores the &lt;detects&gt; section specified in a component. At this point, all specified components are considered to be detected and are selected for migration.
3. For each selected component, LoadState evaluates the &lt;rules&gt; sections. For each &lt;rules&gt; section, if the current user profile is the system profile and the context of the &lt;rules&gt; section is “System” or “UserAndSystem”, the rule is processed further. Otherwise, this rule is ignored. Alternatively, if the current user profile is not the system profile and the context of the &lt;rules&gt; section is “User” or “UserAndSystem”, the rule is processed further. Otherwise, this rule is ignored.
4. LoadState creates a master list of migration units by processing the various subsections under the &lt;rules&gt; section. Each migration unit that is in an &lt;include&gt; subsection is migrated as long, as there is not a more specific rule for it in an &lt;exclude&gt; subsection in the same &lt;rules&gt; section. For more information about precedence, see [Conflicts and Precedence](usmt-conflicts-and-precedence.md).
5. LoadState evaluates the destination computer-specific subsections; for example, the &lt;destinationCleanup&gt; and &lt;locationModify&gt; subsections.
6. If the destination computer is running Windows 7 or Windows 8 then the migunits that were collected by ScanState using downlevel manifest files are processed by LoadState using the corresponding Component Manifest for Windows 7. The downlevel manifest files are not used during LoadState.
**Important**
It is important to specify the .xml files with the LoadState command if you want LoadState to use them. Otherwise, any destination-specific rules, such as &lt;locationModify&gt;, in these .xml files are ignored, even if the same .xml files were provided when the ScanState command ran.
5. In the "Apply" phase, LoadState writes the migration units that were collected to the various locations on the destination computer. If there are conflicts and there is not a &lt;merge&gt; rule for the object, 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. Some settings, such as fonts, wallpaper, and screen-saver settings, do not take effect until the next time the user logs on. For this reason, you should log off when the LoadState command actions have completed.
## Related topics
[User State Migration Tool (USMT) Command-line Syntax](usmt-command-line-syntax.md)
3. For each selected component, **LoadState** evaluates the **&lt;rules&gt;** sections. For each **&lt;rules&gt;** section, if the current user profile is the system profile and the context of the **&lt;rules&gt;** section is **System** or **UserAndSystem**, the rule is processed further. Otherwise, this rule is ignored. Alternatively, if the current user profile isn't the system profile and the context of the **&lt;rules&gt;** section is **User** or **UserAndSystem**, the rule is processed further. Otherwise, this rule is ignored.
4. **LoadState** creates a master list of migration units by processing the various subsections under the **&lt;rules&gt;** section. Each migration unit that is in an **&lt;include&gt;** subsection is migrated as long, as there isn't a more specific rule for it in an **&lt;exclude&gt;** subsection in the same **&lt;rules&gt;** section. For more information about precedence, see [Conflicts and precedence](usmt-conflicts-and-precedence.md).
5. **LoadState** evaluates the destination computer-specific subsections; for example, the **&lt;destinationCleanup&gt;** and **&lt;locationModify&gt;** subsections.
6. If the destination computer is running Windows 7, Windows 8, or Windows 10, then the migunits that were collected by **ScanState** using downlevel manifest files are processed by **LoadState** using the corresponding Component Manifest for Windows 7. The downlevel manifest files aren't used during **LoadState**.
> [!IMPORTANT]
> It is important to specify the .xml files with the `LoadState.exe` command if you want **LoadState** to use them. Otherwise, any destination-specific rules, such as **&lt;locationModify&gt;**, in these .xml files are ignored, even if the same .xml files were provided when the `ScanState.exe` command ran.
5. In the **Apply** phase, **LoadState** writes the migration units that were collected to the various locations on the destination computer. If there are conflicts and there isn't a **&lt;merge&gt;** rule for the object, 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. Some settings, such as fonts, wallpaper, and screen-saver settings, don't take effect until the next time the user logs on. For this reason, you should sign out when the `LoadState.exe` command actions have completed.
## Related articles
[User State Migration Tool (USMT) command-line syntax](usmt-command-line-syntax.md)

38
windows/deployment/usmt/usmt-how-to.md
View File

@ -1,6 +1,6 @@
---
title: User State Migration Tool (USMT) How-to topics (Windows 10)
description: Reference the topics in this article to learn how to use User State Migration Tool (USMT) 10.0 to perform specific tasks.
title: User State Migration Tool (USMT) How-to articles (Windows 10)
description: Reference the articles in this article to learn how to use User State Migration Tool (USMT) 10.0 to perform specific tasks.
ms.reviewer:
manager: aaroncz
ms.author: frankroj
@ -11,23 +11,25 @@ ms.topic: article
ms.technology: itpro-deploy
---
# User State Migration Tool (USMT) How-to topics
The following table lists topics that describe how to use User State Migration Tool (USMT) 10.0 to perform specific tasks.
# User State Migration Tool (USMT) how-to articles
## In This Section
The following table lists articles that describe how to use User State Migration Tool (USMT) 10.0 to perform specific tasks.
|Topic |Description|
## In this section
|Article |Description|
|------|-----------|
|[Exclude Files and Settings](usmt-exclude-files-and-settings.md)|Create a custom .xml file to exclude files, file types, folders, or registry settings from your migration.|
|[Extract Files from a Compressed USMT Migration Store](usmt-extract-files-from-a-compressed-migration-store.md)|Recover files from a compressed migration store after installing the operating system.|
|[Include Files and Settings](usmt-include-files-and-settings.md)|Create a custom .xml file to include files, file types, folders, or registry settings in your migration.|
|[Migrate Application Settings](migrate-application-settings.md)|Migrate the settings of an application that the MigApp.xml file does not include by default.|
|[Migrate EFS Files and Certificates](usmt-migrate-efs-files-and-certificates.md)|Migrate Encrypting File System (EFS) certificates by using USMT.|
|[Migrate User Accounts](usmt-migrate-user-accounts.md)|Specify the users to include and exclude in your migration.|
|[Reroute Files and Settings](usmt-reroute-files-and-settings.md)|Create a custom .xml file to reroute files and settings during a migration.|
|[Verify the Condition of a Compressed Migration Store](verify-the-condition-of-a-compressed-migration-store.md)|Determine whether a compressed migration store is intact, or whether it contains corrupt files or a corrupt catalog.|
|[Exclude files and settings](usmt-exclude-files-and-settings.md)|Create a custom .xml file to exclude files, file types, folders, or registry settings from your migration.|
|[Extract files from a compressed USMT migration store](usmt-extract-files-from-a-compressed-migration-store.md)|Recover files from a compressed migration store after installing the operating system.|
|[Include files and settings](usmt-include-files-and-settings.md)|Create a custom .xml file to include files, file types, folders, or registry settings in your migration.|
|[Migrate application settings](migrate-application-settings.md)|Migrate the settings of an application that the MigApp.xml file doesn't include by default.|
|[Migrate EFS files and certificates](usmt-migrate-efs-files-and-certificates.md)|Migrate Encrypting File System (EFS) certificates by using USMT.|
|[Migrate user accounts](usmt-migrate-user-accounts.md)|Specify the users to include and exclude in your migration.|
|[Reroute files and settings](usmt-reroute-files-and-settings.md)|Create a custom .xml file to reroute files and settings during a migration.|
|[Verify the condition of a compressed migration store](verify-the-condition-of-a-compressed-migration-store.md)|Determine whether a compressed migration store is intact, or whether it contains corrupt files or a corrupt catalog.|
## Related topics
- [User State Migration Tool (USMT) Overview Topics](usmt-topics.md)
- [User State Migration Tool (USMT) Troubleshooting](usmt-troubleshooting.md)
- [User State Migration Toolkit (USMT) Reference](usmt-reference.md)
## Related articles
- [User State Migration Tool (USMT) overview topics](usmt-topics.md)
- [User State Migration Tool (USMT) troubleshooting](usmt-troubleshooting.md)
- [User State Migration Toolkit (USMT) reference](usmt-reference.md)

4
windows/deployment/usmt/usmt-scanstate-syntax.md
View File

@ -29,7 +29,7 @@ The ScanState command is used with the User State Migration Tool (USMT) 10.0 to
[User Options](#bkmk-useroptions)
[Encrypted File Options](#bkmk-efs)
[Encrypted file options](#encrypted-file-options)
[Incompatible Command-Line Options](#bkmk-iclo)
@ -184,7 +184,7 @@ The /**uel** option takes precedence over the /**ue** option. If a user has logg
|Include only the domain users from Contoso, except Contoso\User1.|This behavior cannot be completed using a single command. Instead, to migrate this set of users, you will need to specify the following commands: <ul><li>On the **ScanState** command line, type: `/ue:*\* /ui:contoso\*`</li><li>On the **LoadState** command line, type: `/ue:contoso\user1`</li></ul>|
|Include only local (non-domain) users.|`/ue:*\* /ui:%computername%\*`|
## <a href="" id="bkmk-efs"></a>Encrypted File Options
## Encrypted file options
You can use the following options to migrate encrypted files. In all cases, by default, USMT fails if an encrypted file is found unless you specify an /**efs** option. To migrate encrypted files, you must change the default behavior.