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

USMT Refresh

Browse Source
This commit is contained in:
Frank Rojas 2023-12-21 15:00:21 -05:00
parent 20a1a31224
commit 3b24f6731b
4 changed files with 96 additions and 63 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -1,5 +1,5 @@
---
title: How USMT Works (Windows 10)
title: How USMT Works
description: Learn how USMT works and how it includes two tools that migrate settings and data - ScanState and LoadState.
manager: aaroncz
ms.author: frankroj
@ -7,20 +7,16 @@ ms.prod: windows-client
author: frankroj
ms.topic: article
ms.technology: itpro-deploy
ms.date: 11/01/2022
ms.date: 12/21/2023
---
# 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.
- [How USMT works](#how-usmt-works)
- [The ScanState process](#the-scanstate-process)
- [The LoadState process](#the-loadstate-process)
- [Related articles](#related-articles)
> [!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
@ -28,48 +24,51 @@ When you run the **ScanState** tool on the source computer, it goes through the
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.
1. 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 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.
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.
In currently supported versions of Windows, 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. **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. **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 currently supported versions of Windows is always migrated, and you can't exclude these profiles from the migration.
4. In the **Scanning** phase, **ScanState** does the following for each user profile selected for migration:
1. In the **Scanning** phase, **ScanState** does the following for each user profile selected for 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 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, **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** doesn't distinguish between components that migrate operating-system settings, components that migrate application settings, and components 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.
1. 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 **<detects>** section. If the condition in the **<detects>** section evaluates to false, the component isn't processed any further. Otherwise, the processing of this component continues.
1. For each selected component, **ScanState** evaluates the **<detects>** section. If the condition in the **<detects>** section evaluates to false, the component isn't processed any further. Otherwise, the processing of this component continues.
4. For each selected component, **ScanState** evaluates the **<rules>** sections. For each **<rules>** section, if the current user profile is the system profile and the context of the **<rules>** 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 **<rules>** section is **User** or **UserAndSystem**, the rule is processed further. Otherwise, this rule is ignored.
1. For each selected component, **ScanState** evaluates the **<rules>** sections. For each **<rules>** section, if the current user profile is the system profile and the context of the **<rules>** 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 **<rules>** section is **User** or **UserAndSystem**, the rule is processed further. Otherwise, this rule is ignored.
5. **ScanState** creates a list of migration units that need to be migrated by processing the various subsections under this **<rules>** section. Each unit is collected if it's mentioned in an **<include>** subsection, as long as there isn't a more specific rule for it in an **<exclude>** subsection in the same **<rules>** section. For more information about precedence in the .xml files, see [Conflicts and precedence](usmt-conflicts-and-precedence.md).
1. **ScanState** creates a list of migration units that need to be migrated by processing the various subsections under this **<rules>** section. Each unit is collected if the unit is mentioned in an **<include>** subsection, as long as there isn't a more specific rule for it in an **<exclude>** subsection in the same **<rules>** section. For more information about precedence in the **.xml** files, see [Conflicts and precedence](usmt-conflicts-and-precedence.md).
In addition, any migration unit (such as a file, registry key, or set of registry values) that is in an <UnconditionalExclude> section isn't migrated.
> [!NOTE]
>
> **ScanState** ignores some subsections such as <destinationCleanup> and <locationModify>. 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.
1. In the **Collecting** phase, **ScanState** creates a central 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.
1. In the **Saving** phase, **ScanState** writes the migration units that were collected to the store location.
> [!NOTE]
> **ScanState** does not modify the source computer in any way.
>
> **ScanState** doesn't modify the source computer in any way.
## The LoadState process
@ -77,45 +76,48 @@ The **LoadState** process is similar to the **ScanState** process. The **ScanSta
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.
1. **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.exe` 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, 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.
In currently supported versions of Windows, 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 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. **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 currently supported versions of Windows is always migrated and you can't exclude these profiles from the migration.
- 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've been included when the `LoadState.exe` command was specified.
- When specified with the `LoadState.exe` command, the `/md` and `/mu` options are processed to rename the user profile on the destination computer.
- 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:
1. 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 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.
>
> From this point on, **LoadState** doesn't distinguish between components that migrate operating-system settings, components that migrate application settings, and components 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).
1. 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 **<detects>** 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 **<rules>** sections. For each **<rules>** section, if the current user profile is the system profile and the context of the **<rules>** 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 **<rules>** section is **User** or **UserAndSystem**, the rule is processed further. Otherwise, this rule is ignored.
1. For each selected component, **LoadState** evaluates the **<rules>** sections. For each **<rules>** section, if the current user profile is the system profile and the context of the **<rules>** 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 **<rules>** 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 **<rules>** section. Each migration unit that is in an **<include>** subsection is migrated as long, as there isn't a more specific rule for it in an **<exclude>** subsection in the same **<rules>** section. For more information about precedence, see [Conflicts and precedence](usmt-conflicts-and-precedence.md).
1. **LoadState** creates a central list of migration units by processing the various subsections under the **<rules>** section. Each migration unit that is in an **<include>** subsection is migrated as long, as there isn't a more specific rule for it in an **<exclude>** subsection in the same **<rules>** 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 **<destinationCleanup>** and **<locationModify>** subsections.
1. **LoadState** evaluates the destination computer-specific subsections, for example, the **<destinationCleanup>** and **<locationModify>** 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**.
1. If the destination computer is running a currently supported version of Windows, then the migunits that were collected by **ScanState** using downlevel manifest files are processed by **LoadState** using the corresponding Component Manifest from the downlevel Windows version. 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 **<locationModify>**, in these .xml files are ignored, even if the same .xml files were provided when the `ScanState.exe` command ran.
>
> It's 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 **<locationModify>**, 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 **<merge>** 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.
1. 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 **<merge>** 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 are finished.
## Related articles
[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).

14
windows/deployment/usmt/usmt-identify-application-settings.md
View File

@ -1,24 +1,24 @@
---
title: Identify Applications Settings (Windows 10)
title: Identify Applications Settings
description: Identify which applications and settings you want to migrate before using the User State Migration Tool (USMT).
manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 11/01/2022
ms.date: 12/21/2023
ms.topic: article
ms.technology: itpro-deploy
---
# Identify applications settings
When planning for your migration, you should identify which applications and settings you want to migrate. For more information about how to create a custom .xml file to migrate the settings of another application, see [Customize USMT XML files](usmt-customize-xml-files.md).
When planning for your migration, you should identify which applications and settings you want to migrate. For more information about how to create a custom **.xml** file to migrate the settings of another application, see [Customize USMT XML files](usmt-customize-xml-files.md).
## Applications
First, create and prioritize a list of applications that need to be migrated. It may be helpful to review the application lists and decide which applications will be redeployed and which applications will be retired. Often, what applications are migrated are prioritized based on a combination of how widely the application is used and how complex the application is.
First, create and prioritize a list of applications that need to be migrated. It might be helpful to review the application lists and decide which applications need to be redeployed and which applications need to be retired. Often, how the application is used and how complex the application is determines the priority of what applications are migrated.
Next, identify an application owner to be in charge of each application. Application ownership identification is necessary because the developers won't be experts on all of the applications in the organization. The application owner should have the most experience with an application. The application owner provides insight into how the organization installs, configures, and uses the application.
Next, identify an application owner to be in charge of each application. Application ownership identification is necessary because the developers aren't be experts on all of the applications in the organization. The application owner should have the most experience with an application. The application owner provides insight into how the organization installs, configures, and uses the application.
## Application settings
@ -34,7 +34,7 @@ After completing the list of applications to be migrated, review the list, and w
- Can the first-run process force the application to appear as if it had run already? If so, does this work correctly, or does it break the application?
After answering these questions, create a custom .xml file to migrate settings. Work with the application owner to develop test cases and to determine the file types that need to be migrated for the application.
After answering these questions, create a custom **.xml** file to migrate settings. Work with the application owner to develop test cases and to determine the file types that need to be migrated for the application.
## Locating where settings are stored
@ -42,4 +42,4 @@ See [Migrate application settings](migrate-application-settings.md) and follow t
## Related articles
[Determine what to migrate](usmt-determine-what-to-migrate.md)
- [Determine what to migrate](usmt-determine-what-to-migrate.md).

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

@ -1,11 +1,11 @@
---
title: Identify File Types, Files, and Folders (Windows 10)
title: Identify File Types, Files, and Folders
description: Learn how to identify the file types, files, folders, and settings that you want to migrate when you're planning your migration.
manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 11/01/2022
ms.date: 12/21/2023
ms.topic: article
ms.technology: itpro-deploy
---
@ -22,16 +22,30 @@ When planning for your migration, if not using MigDocs.xml, you should identify
Once you've verified which files and file types that the end users work with regularly, you'll need to locate them. Files may 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.
To find the registered file types on a computer running Windows 7, Windows 8, Windows 10, or Windows 11:
To find the registered file types on a computer running a currently supported version of Windows:
1. Right-click the Start Menu and select **Settings**.
1. From the left panel, select **Apps**.
1. Under the **Apps** pane, select **Default apps**.
1. Under the **Apps > Default apps** pane, scroll down past the list of apps until the **Related settings** section is reached.
1. Under **Related settings**, select **Choose defaults by file type**.
1. Under the **Apps > Default apps > Choose defaults by file type**, the registered file types are displayed.
1. Open **Control Panel**
2. Make sure **View by:** is set to **Category** and then select **Programs**.
3. Select **Default Programs**
1. Make sure **View by:** is set to **Category** and then select **Programs**.
4. select **Associate a file type or protocol with a program**.
1. Select **Default Programs**
5. On this screen, the registered file types are displayed.
1. select **Associate a file type or protocol with a program**.
1. On this screen, the registered file types are displayed.
For more information about how to change the file types, files, and folders that are migrated when you specify the MigUser.xml file, see [User State Migration Tool (USMT) how-to topics](usmt-how-to.md).

35
windows/deployment/usmt/usmt-identify-operating-system-settings.md
View File

@ -1,18 +1,18 @@
---
title: Identify Operating System Settings (Windows 10)
title: Identify Operating System Settings
description: Identify which system settings you want to migrate, then use the User State Migration Tool (USMT) to select settings and keep the default values for all others.
manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 11/01/2022
ms.date: 12/21/2023
ms.topic: article
ms.technology: itpro-deploy
---
# Identify operating system settings
When planning for your migration, you should identify which operating system settings you want to migrate and to what extent you want to create a new standard environment on each of the computers. User State Migration Tool (USMT) 10.0 enables you to migrate select settings and keep the default values for all others. The operating system settings include the following parameters:
When planning for your migration, you should identify which operating system settings you want to migrate and to what extent you want to create a new standard environment on each of the computers. User State Migration Tool (USMT) enables you to migrate select settings and keep the default values for all others. The operating system settings include the following parameters:
- **Appearance**
@ -20,25 +20,42 @@ When planning for your migration, you should identify which operating system set
- **Action**
The action factor includes items such as the key-repeat rate, whether double-clicking a folder opens it in a new window or the same window, and whether you need to single-click or double-click an item to open it.
The action factor includes items such as:
- The key-repeat rate.
- Whether double-clicking a folder opens it in a new window or the same window.
- Whether you need to single-click or double-click an item to open it.
- **Internet**
The Internet factor includes the settings that let you connect to the Internet and control how your browser operates. The settings include items such as your home page URL, favorites, bookmarks, cookies, security settings, dial-up connections, and proxy settings.
The Internet factor includes the settings that let you connect to the Internet and control how your browser operates. The settings include items such as your home page URL, favorites, bookmarks, cookies, security settings, and proxy settings.
- **Mail**
The mail factor includes the information that you need to connect to your mail server, your signature file, views, mail rules, local mail, and contacts.
To help you decide which settings to migrate, you should consider any previous migration experiences and the results of any surveys and tests that you've conducted. You should also consider the number of help-desk calls related to operating-system settings that you've had in the past, and are able to handle in the future. Also decide how much of the new operating-system functionality you want to take advantage of.
To help determine which settings to migrate, consider any previous migration experiences and the results of any conducted surveys and tests. Also consider the number of help-desk calls related to operating-system settings from the past, and are able to handle in the future. Also decide how much of the new operating-system functionality needs to be taken advantage of.
You should migrate any settings that users need to get their jobs done, those settings that make the work environment comfortable, and those settings that will reduce help-desk calls after the migration. Although it's easy to dismiss migrating user preferences, you should consider the factor of users spending a significant amount of time restoring items such as wallpaper, screen savers, and other customizable user-interface features. Most users don't remember how these settings were applied. Although these items aren't critical to migration success, migrating these items increases user productivity and overall satisfaction of the migration process.
Settings that should be migrated include:
- Settings that allow users need to get their jobs done.
- Settings that make the work environment comfortable.
- Settings that will reduce help-desk calls after the migration.
Although it's easy to dismiss migrating user preferences, you should consider the factor of users spending time restoring items such as:
- Wallpaper.
- Screen savers.
- Other customizable user-interface features.
Most users don't remember how these settings were applied. Although these items aren't critical to migration success, migrating these items increases user productivity and overall satisfaction of the migration process.
> [!NOTE]
> For more information about how to change the operating-system settings that are migrated, see [User State Migration Tool (USMT) how-to topics](usmt-how-to.md).
>
> For more information about how to change the operating-system settings that are migrated, see [User State Migration Tool (USMT) how-to articles](usmt-how-to.md).
For information about the operating-system settings that USMT migrates, see [What does USMT migrate?](usmt-what-does-usmt-migrate.md)
## Related articles
[Determine What to Migrate](usmt-determine-what-to-migrate.md)
- [Determine What to Migrate](usmt-determine-what-to-migrate.md).