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

fix warning

Browse Source
This commit is contained in:
Greg Lindsay 2020-08-24 15:45:25 -07:00
parent 65e124f0b1
commit 45e0a5cbf6
1 changed files with 4 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -1,6 +1,6 @@
--- ---
title: How USMT Works (Windows 10) title: How USMT Works (Windows 10)
description: Learn how USMT works and how it includes two tools that migrate settings and data: ScanState and LoadState. description: Learn how USMT works and how it includes two tools that migrate settings and data - ScanState and LoadState.
ms.assetid: 5c8bd669-9e1e-473d-81e6-652f40b24171 ms.assetid: 5c8bd669-9e1e-473d-81e6-652f40b24171
ms.reviewer: ms.reviewer:
manager: laurawi manager: laurawi
@ -10,7 +10,6 @@ ms.mktglfcycl: deploy
ms.sitesec: library ms.sitesec: library
audience: itpro audience: itpro
author: greg-lindsay author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article ms.topic: article
--- ---
@ -20,16 +19,12 @@ ms.topic: article
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.
- [ScanState Process](#bkmk-ssprocess) - [ScanState Process](#bkmk-ssprocess)
- [LoadState Process](#bkmk-lsprocess) - [LoadState Process](#bkmk-lsprocess)
**Note**   **Note**  
For more information about how USMT processes the rules and the XML files, see [Conflicts and Precedence](usmt-conflicts-and-precedence.md). For more information about how USMT processes the rules and the XML files, see [Conflicts and Precedence](usmt-conflicts-and-precedence.md).
## <a href="" id="bkmk-ssprocess"></a>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:
@ -40,9 +35,7 @@ When you run the ScanState tool on the source computer, it goes through the foll
There are three types of components: There are three types of components:
- Components that migrate the operating system settings - Components that migrate the operating system settings
- Components that migrate application settings - Components that migrate application settings
- Components that migrate users’ files - 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. The ScanState tool collects information about the application settings and user data components from the .xml files that are specified on the command line.
@ -58,8 +51,6 @@ When you run the ScanState tool on the source computer, it goes through the foll
**Note**   **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. 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.
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. 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.
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. 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.
@ -73,8 +64,6 @@ When you run the ScanState tool on the source computer, it goes through the foll
**Note**   **Note**  
ScanState ignores some subsections such as &lt;destinationCleanup&gt; and &lt;locationModify&gt;. These sections are evaluated only on the destination computer. ScanState ignores some subsections such as &lt;destinationCleanup&gt; and &lt;locationModify&gt;. These sections are evaluated only on the destination computer.
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. 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.
6. In the "Saving" phase, ScanState writes the migration units that were collected to the store location. 6. In the "Saving" phase, ScanState writes the migration units that were collected to the store location.
@ -82,9 +71,7 @@ When you run the ScanState tool on the source computer, it goes through the foll
**Note**   **Note**  
ScanState does not modify the source computer in any way. ScanState does not modify the source computer in any way.
## The LoadState Process
## <a href="" id="bkmk-lsprocess"></a>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 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.
@ -132,13 +119,10 @@ The LoadState process is very similar to the ScanState process. The ScanState to
**Important** **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. 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. 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 ## Related topics
[User State Migration Tool (USMT) Command-line Syntax](usmt-command-line-syntax.md) [User State Migration Tool (USMT) Command-line Syntax](usmt-command-line-syntax.md)