diff --git a/windows/deployment/usmt/getting-started-with-the-user-state-migration-tool.md b/windows/deployment/usmt/getting-started-with-the-user-state-migration-tool.md index 801dd76b13..6877961d15 100644 --- a/windows/deployment/usmt/getting-started-with-the-user-state-migration-tool.md +++ b/windows/deployment/usmt/getting-started-with-the-user-state-migration-tool.md @@ -15,14 +15,6 @@ ms.date: 11/01/2022 This article outlines the general process that you should follow to migrate files and settings. -## In this topic - -- [Step 1: Plan your migration](#step-1-plan-your-migration) - -- [Step 2: Collect files and settings from the source computer](#step-2-collect-files-and-settings-from-the-source-computer) - -- [Step 3: Prepare the destination computer and restore files and settings](#step-3-prepare-the-destination-computer-and-restore-files-and-settings) - ## Step 1: Plan your migration 1. [Plan Your Migration](usmt-plan-your-migration.md). Depending on whether your migration scenario is refreshing or replacing computers, you can choose an online migration or an offline migration using Windows Preinstallation Environment (WinPE) or the files in the Windows.old directory. For more information, see [Common Migration Scenarios](usmt-common-migration-scenarios.md). diff --git a/windows/deployment/usmt/migrate-application-settings.md b/windows/deployment/usmt/migrate-application-settings.md index 27feed854b..02d47cae69 100644 --- a/windows/deployment/usmt/migrate-application-settings.md +++ b/windows/deployment/usmt/migrate-application-settings.md @@ -19,20 +19,6 @@ This article defines how to author a custom migration .xml file that migrates th This article doesn't contain information about how to migrate applications that store settings in an application-specific store, only the applications that store the information in files or in the registry. It also doesn't contain information about how to migrate the data that users create using the application. For example, if the application creates .doc files using a specific template, this article doesn't discuss how to migrate the .doc files and templates themselves. -## In this topic - -- [Before you begin](#before-you-begin) - -- [Step 1: Verify that the application is installed on the source computer, and that it's the same version as the version to be installed on the destination computer](#step-1-verify-that-the-application-is-installed-on-the-source-computer-and-that-its-the-same-version-as-the-version-to-be-installed-on-the-destination-computer). - -- [Step 2: Identify settings to collect and determine where each setting is stored on the computer](#step-2-identify-settings-to-collect-and-determine-where-each-setting-is-stored-on-the-computer). - -- [Step 3: Identify how to apply the gathered settings](#step-3-identify-how-to-apply-the-gathered-settings). - -- [Step 4: Create the migration XML component for the application](#step-4-create-the-migration-xml-component-for-the-application). - -- [Step 5: Test the application settings migration](#step-5-test-the-application-settings-migration). - ## Before you begin You should identify a test computer that contains the operating system of your source computers, and the application whose settings you want to migrate. For example, if you're planning on migrating from Windows 7 to Windows 10, install Windows 7 on your test computer and then install the application. diff --git a/windows/deployment/usmt/migration-store-types-overview.md b/windows/deployment/usmt/migration-store-types-overview.md index cd170fadb4..d2cc3a4ec4 100644 --- a/windows/deployment/usmt/migration-store-types-overview.md +++ b/windows/deployment/usmt/migration-store-types-overview.md @@ -15,14 +15,6 @@ ms.technology: itpro-deploy When planning your migration, you should determine which migration store type best meets your needs. As part of these considerations, determine how much space is required to run the User State Migration Tool (USMT) 10.0 components on your source and destination computers. You should also determine the space needed to create and host the migration store, whether you're using a local share, network share, or storage device. -## In this topic - -[Migration store types](#migration-store-types) - -[Local store vs. remote store](#local-store-vs-remote-store) - -[The /localonly command-line option](#the-localonly-command-line-option) - ## Migration store types This section describes the three migration store types available in USMT. diff --git a/windows/deployment/usmt/offline-migration-reference.md b/windows/deployment/usmt/offline-migration-reference.md index 4a60f02043..b7ab0afb24 100644 --- a/windows/deployment/usmt/offline-migration-reference.md +++ b/windows/deployment/usmt/offline-migration-reference.md @@ -27,20 +27,6 @@ When you use User State Migration Tool (USMT) 10.0 to gather and restore user st - **New recovery scenario.** In scenarios where a machine no longer restarts properly, it might be possible to gather user state with the ScanState tool from within WinPE. -## In this topic - -- [What will migrate offline?](#what-will-migrate-offline) - -- [What offline environments are supported?](#what-offline-environments-are-supported) - -- [User-group membership and profile control](#user-group-membership-and-profile-control) - -- [Command-line options](#command-line-options) - -- [Environment variables](#environment-variables) - -- [Offline.xml elements](#offlinexml-elements) - ## What will migrate offline? The following user data and settings migrate offline, similar to an online migration: diff --git a/windows/deployment/usmt/understanding-migration-xml-files.md b/windows/deployment/usmt/understanding-migration-xml-files.md index 25cebd9242..62d1b5eda8 100644 --- a/windows/deployment/usmt/understanding-migration-xml-files.md +++ b/windows/deployment/usmt/understanding-migration-xml-files.md @@ -17,32 +17,6 @@ You can modify the behavior of a basic User State Migration Tool (USMT) 10.0 mig This article provides an overview of the default and custom migration XML files and includes guidelines for creating and editing a customized version of the `MigDocs.xml` file. The `MigDocs.xml` file uses the new `GenerateDocPatterns` function available in USMT to automatically find user documents on a source computer. -## In this topic - -[Overview of the Config.xml file](#overview-of-the-configxml-file) - -[Overview of the MigApp.xml file](#overview-of-the-migappxml-file) - -[Overview of the MigDocs.xml file](#overview-of-the-migdocsxml-file) - -[Overview of the MigUser.xml file](#overview-of-the-miguserxml-file) - -[Using multiple XML files](#using-multiple-xml-files) - -[XML rules for migrating user files](#xml-rules-for-migrating-user-files) - -[The GenerateDocPatterns function](#the-generatedocpatterns-function) - -[Understanding the system and user context](#understanding-the-system-and-user-context) - -[Sample migration rules for customized versions of XML files](#sample-migration-rules-for-customized-versions-of-xml-files) - -[Exclude rules usage examples](#exclude-rules-usage-examples) - -[Include rules usage examples](#include-rules-usage-examples) - -[Next Steps](#next-steps) - ## Overview of the Config.xml file The `Config.xml` file is the configuration file created by the `/genconfig` option of the ScanState tool; it can be used to modify which operating-system components are migrated by USMT. The `Config.xml` file can be used with other XML files, such as in the following example: diff --git a/windows/deployment/usmt/usmt-command-line-syntax.md b/windows/deployment/usmt/usmt-command-line-syntax.md index 74c1c3c801..d7332ed880 100644 --- a/windows/deployment/usmt/usmt-command-line-syntax.md +++ b/windows/deployment/usmt/usmt-command-line-syntax.md @@ -15,7 +15,7 @@ ms.technology: itpro-deploy The User State Migration Tool (USMT) 10.0 migrates user files and settings during large deployments of Windows. To improve and simplify the migration process, USMT captures desktop, network, and application settings in addition to a user's files. USMT then migrates these items to a new Windows installation. -## In This Section +## In this Section | Link | Description | |--- |--- | diff --git a/windows/deployment/usmt/usmt-common-issues.md b/windows/deployment/usmt/usmt-common-issues.md index 48dcbd4b35..31de16f3e7 100644 --- a/windows/deployment/usmt/usmt-common-issues.md +++ b/windows/deployment/usmt/usmt-common-issues.md @@ -11,36 +11,20 @@ ms.topic: article ms.technology: itpro-deploy --- -# Common Issues +# Common issues The following sections discuss common issues that you might see when you run the User State Migration Tool (USMT) 10.0 tools. USMT produces log files that describe in further detail any errors that occurred during the migration process. These logs can be used to troubleshoot migration failures. -## In this topic - -[User account problems](#user-account-problems) - -[Command-line problems](#command-line-problems) - -[XML file problems](#xml-file-problems) - -[Migration problems](#migration-problems) - -[Offline migration problems](#offline-migration-problems) - -[Hard link migration problems](#hard-link-migration-problems) - -[USMT doesn't migrate the Start layout](#usmt-doesnt-migrate-the-start-layout) - -## General Guidelines for Identifying Migration Problems +## General guidelines for identifying migration problems When you encounter a problem or error message during migration, you can use the following general guidelines to help determine the source of the problem: -- Examine the ScanState, LoadState, and UsmtUtils logs to obtain the exact USMT error messages and Windows® application programming interface (API) error messages. For more information about USMT return codes and error messages, see [Return Codes](usmt-return-codes.md). For more information about Windows API error messages, type **nethelpmsg** on the command line. +- Examine the **ScanState**, **LoadState**, and UsmtUtils logs to obtain the exact USMT error messages and Windows® application programming interface (API) error messages. For more information about USMT return codes and error messages, see [Return codes](usmt-return-codes.md). For more information about Windows API error messages, type **nethelpmsg** on the command line. - In most cases, the ScanState and LoadState logs indicate why a USMT migration is failing. We recommend that you use the `/v:5` option when testing your migration. This verbosity level can be adjusted in a production migration; however, reducing the verbosity level might make it more difficult to diagnose failures that are encountered during production migrations. You can use a verbosity level higher than 5 if you want the log files output to go to a debugger. + In most cases, the **ScanState** and **LoadState** logs indicate why a USMT migration is failing. We recommend that you use the `/v:5` option when testing your migration. This verbosity level can be adjusted in a production migration; however, reducing the verbosity level might make it more difficult to diagnose failures that are encountered during production migrations. You can use a verbosity level higher than 5 if you want the log files output to go to a debugger. > [!NOTE] - > Running the ScanState and LoadState tools with the `/v:5` option creates a detailed log file. Although this option makes the log file large, the extra detail can help you determine where migration errors occurred. + > Running the **ScanState** and **LoadState** tools with the `/v:5` option creates a detailed log file. Although this option makes the log file large, the extra detail can help you determine where migration errors occurred. - Use the `/Verify` option with the UsmtUtils tool to determine whether any files in a compressed migration store are corrupted. For more information, see [Verify the condition of a compressed migration store](verify-the-condition-of-a-compressed-migration-store.md). @@ -50,9 +34,9 @@ When you encounter a problem or error message during migration, you can use the - For the source and destination computers, obtain operating system information, and versions of applications such as Internet Explorer and any other relevant programs. Then verify the exact steps that are needed to reproduce the problem. This information might help you to understand what is wrong and to reproduce the issue in your testing environment. -- Sign out after you run the LoadState tool. Some settings such as fonts, desktop backgrounds, and screen-saver settings won't take effect until the next time the end user logs on. +- Sign out after you run the **LoadState** tool. Some settings such as fonts, desktop backgrounds, and screen-saver settings won't take effect until the next time the end user logs on. -- Close all applications before running ScanState or LoadState tools. If some applications are running during the ScanState or LoadState process, USMT might not migrate some data. For example, if Microsoft Outlook® is open, USMT might not migrate PST files. +- Close all applications before running **ScanState** or **LoadState** tools. If some applications are running during the **ScanState** or **LoadState** process, USMT might not migrate some data. For example, if Microsoft Outlook® is open, USMT might not migrate PST files. > [!NOTE] > USMT will fail if it can't migrate a file or setting unless you specify the `/c` option. When you specify the `/c` option, USMT ignores errors. However, it logs an error when it encounters a file that is in use that didn't migrate. @@ -69,7 +53,7 @@ The following sections describe common user account problems. Expand the section **Causes/Resolutions** There are two possible causes for this problem: -When running the ScanState and LoadState tools on Windows 7, Windows 8, or Windows 10, you must run them in Administrator mode from an account with administrative credentials to ensure that all specified users are migrated. To run in Administrator mode: +When running the **ScanState** and LoadState tools on Windows 7, Windows 8, or Windows 10, you must run them in Administrator mode from an account with administrative credentials to ensure that all specified users are migrated. To run in Administrator mode: 1. Select **Start** > **All Programs** > **Accessories**. @@ -97,7 +81,7 @@ Any user accounts on the computer that haven't been used won't be migrated. For ### The LoadState tool reports an error as return code 71 and fails to restore a user profile during a migration test -**Cause:** During a migration test, if you run the ScanState tool on your test computer and then delete user profiles in order to test the LoadState tool on the same computer, you may have a conflicting key present in the registry. Using the **net use** command to remove a user profile will delete folders and files associated with that profile, but won't remove the registry key. +**Cause:** During a migration test, if you run the **ScanState** tool on your test computer and then delete user profiles in order to test the **LoadState** tool on the same computer, you may have a conflicting key present in the registry. Using the **net use** command to remove a user profile will delete folders and files associated with that profile, but won't remove the registry key. **Resolution:** To delete a user profile, use the **User Accounts** item in Control Panel. To correct an incomplete deletion of a user profile: @@ -111,17 +95,17 @@ Any user accounts on the computer that haven't been used won't be migrated. For ### Files that weren't encrypted before the migration are now encrypted with the account used to run the LoadState tool -**Cause:** The ScanState tool was run using the `/EFS:copyraw` option to migrate encrypted files and Encrypting File System (EFS) certificates. The encryption attribute was set on a folder that was migrated, but the attribute was removed from file contents of that folder prior to migration. +**Cause:** The **ScanState** tool was run using the `/EFS:copyraw` option to migrate encrypted files and Encrypting File System (EFS) certificates. The encryption attribute was set on a folder that was migrated, but the attribute was removed from file contents of that folder prior to migration. -**Resolution:** Before using the ScanState tool for a migration that includes encrypted files and EFS certificates, you can run the Cipher tool at the command prompt to review and change encryption settings on files and folders. You must remove the encryption attribute from folders that contain unencrypted files or encrypt the contents of all files within an encrypted folder. +**Resolution:** Before using the **ScanState** tool for a migration that includes encrypted files and EFS certificates, you can run the Cipher tool at the command prompt to review and change encryption settings on files and folders. You must remove the encryption attribute from folders that contain unencrypted files or encrypt the contents of all files within an encrypted folder. -To remove encryption from files that have already been migrated incorrectly, you must sign into the computer with the account that you used to run the LoadState tool and then remove the encryption from the affected files. +To remove encryption from files that have already been migrated incorrectly, you must sign into the computer with the account that you used to run the **LoadState** tool and then remove the encryption from the affected files. ### The LoadState tool reports an error as return code 71 and a Windows Error 2202 in the log file **Cause:** The computer name was changed during an offline migration of a local user profile. -**Resolution:** You can use the `/mu` option when you run the LoadState tool to specify a new name for the user. For example, +**Resolution:** You can use the `/mu` option when you run the **LoadState** tool to specify a new name for the user. For example, ``` syntax loadstate.exe /i:migapp.xml /i:migdocs.xml \\server\share\migration\mystore @@ -134,13 +118,13 @@ The following sections describe common command-line problems. Expand the section ### I received the following error message: "Usage Error: You can't specify a file path with any of the command-line options that exceeds 256 characters." -**Cause:** You might receive this error message in some cases even if you don't specify a long store or file path, because the path length is calculated based on the absolute path. For example, if you run the `scanstate.exe /o store` command from `C:\Program Files\USMT40`, then each character in "`C:\Program Files\USMT40`" will be added to the length of "store" to get the length of the path. +**Cause:** You might receive this error message in some cases even if you don't specify a long store or file path, because the path length is calculated based on the absolute path. For example, if you run the ` **ScanState**.exe /o store` command from `C:\Program Files\USMT40`, then each character in "`C:\Program Files\USMT40`" will be added to the length of "store" to get the length of the path. **Resolution:** Ensure that the total path length doesn't exceed 256 characters. The total path length includes the store path plus the current directory. ### I received the following error message: "USMT was unable to create the log file(s). Ensure that you have write access to the log directory." -**Cause:** If you're running the ScanState or LoadState tools from a shared network resource, you'll receive this error message if you don't specify `/l`. +**Cause:** If you're running the **ScanState** or **LoadState** tools from a shared network resource, you'll receive this error message if you don't specify `/l`. **Resolution:** To fix this issue in this scenario, specify the `/l:scan.log` or `/l:load.log` option. @@ -164,7 +148,7 @@ The following sections describe common XML file problems. Expand the section to **Cause:** Typically, this issue is caused by incorrect syntax used in a helper function. You receive a Success return code, but the files you wanted to migrate didn't get collected or applied, or weren't collected or applied in the way you expected. -**Resolution:** You should search the ScanState or LoadState log for either the component name that contains the MigXML helper function, or the MigXML helper function title, so that you can locate the related warning in the log file. +**Resolution:** You should search the **ScanState** or **LoadState** log for either the component name that contains the MigXML helper function, or the MigXML helper function title, so that you can locate the related warning in the log file. ## Migration problems @@ -196,7 +180,7 @@ The following sections describe common migration problems. Expand the section to There are three typical causes for this issue. -**Cause**: Some settings such as fonts, desktop backgrounds, and screen-saver settings aren't applied by LoadState until after the destination computer has been restarted. +**Cause**: Some settings such as fonts, desktop backgrounds, and screen-saver settings aren't applied by **LoadState** until after the destination computer has been restarted. **Resolution:** To fix this issue, sign out, and then log back on to see the migrated desktop background. @@ -205,9 +189,9 @@ There are three typical causes for this issue. **Resolution:** Ensure that the desktop background images that you want to migrate aren't in the \\WINDOWS\\Web\\Wallpaper folder on the source computer. -**Cause \#3:** If ScanState wasn't run on Windows XP from an account with administrative credentials, some operating system settings won't migrate. For example, desktop background settings, screen-saver selections, modem options, media-player settings, and Remote Access Service (RAS) connection phone book (.pbk) files and settings won't migrate. +**Cause \#3:** If **ScanState** wasn't run on Windows XP from an account with administrative credentials, some operating system settings won't migrate. For example, desktop background settings, screen-saver selections, modem options, media-player settings, and Remote Access Service (RAS) connection phone book (.pbk) files and settings won't migrate. -**Resolution:** Run the ScanState and LoadState tools from within an account with administrative credentials. +**Resolution:** Run the **ScanState** and **LoadState** tools from within an account with administrative credentials. ---> ### I included MigApp.xml in the migration, but some PST files aren't migrating @@ -252,15 +236,15 @@ The following sections describe common offline migration problems. Expand the se ### The ScanState tool fails with return code 26 -**Cause:** A common cause of return code 26 is that a temp profile is active on the source computer. This profile maps to c:\\users\\temp. The ScanState log shows a MigStartupOfflineCaught exception that includes the message "User profile duplicate SID error". +**Cause:** A common cause of return code 26 is that a temp profile is active on the source computer. This profile maps to c:\\users\\temp. The **ScanState** log shows a **MigStartupOfflineCaught** exception that includes the message **User profile duplicate SID error**. -**Resolution:** You can reboot the computer to get rid of the temp profile or you can set MIG\_FAIL\_ON\_PROFILE\_ERROR=0 to skip the error and exclude the temp profile. +**Resolution:** You can reboot the computer to get rid of the temp profile or you can set **MIG_FAIL_ON_PROFILE_ERROR=0** to skip the error and exclude the temp profile. ### Include and Exclude rules for migrating user profiles don't work the same offline as they do online **Cause:** When offline, the DNS server can't be queried to resolve the user name and SID mapping. -**Resolution:** Use a Security Identifier (SID) to include a user when running the ScanState tool. For example: +**Resolution:** Use a Security Identifier (SID) to include a user when running the **ScanState** tool. For example: ``` syntax Scanstate.exe /ui:S1-5-21-124525095-708259637-1543119021* @@ -272,9 +256,9 @@ You can also use patterns for SIDs that identify generic users or groups. For ex ### My script to wipe the disk fails after running the ScanState tool on a 64-bit system -**Cause:** The HKLM registry hive isn't unloaded after the ScanState tool has finished running. +**Cause:** The HKLM registry hive isn't unloaded after the **ScanState** tool has finished running. -**Resolution:** Reboot the computer or unload the registry hive at the command prompt after the ScanState tool has finished running. For example, at a command prompt, type: +**Resolution:** Reboot the computer or unload the registry hive at the command prompt after the **ScanState** tool has finished running. For example, at a command prompt, type: ``` syntax reg.exe unload hklm\$dest$software diff --git a/windows/deployment/usmt/usmt-common-migration-scenarios.md b/windows/deployment/usmt/usmt-common-migration-scenarios.md index 5d5b8343a8..f9aedeef22 100644 --- a/windows/deployment/usmt/usmt-common-migration-scenarios.md +++ b/windows/deployment/usmt/usmt-common-migration-scenarios.md @@ -17,26 +17,6 @@ You use the User State Migration Tool (USMT) 10.0 when hardware and/or operating One common scenario is when the operating system is upgraded on existing hardware without the hardware being replaced. This scenario is referred to as *PC-refresh*. A second common scenario is known as *PC replacement*, where one piece of hardware is being replaced, typically by newer hardware and a newer operating system. -**In this article:** - -[PC-refresh](#pc-refresh) - -[Scenario One: PC-refresh offline using Windows PE and a hard-link migration store](#scenario-one-pc-refresh-offline-using-windows-pe-and-a-hard-link-migration-store) - -[Scenario Two: PC-refresh using a compressed migration store](#scenario-two-pc-refresh-using-a-compressed-migration-store) - -[Scenario Three: PC-refresh using a hard-link migration store](#scenario-three-pc-refresh-using-a-hard-link-migration-store) - -[Scenario Four: PC-refresh using Windows.old folder and a hard-link migration store](#scenario-four-pc-refresh-using-windowsold-folder-and-a-hard-link-migration-store) - -[PC-replacement](#pc-replacement) - -[Scenario One: Offline migration using Windows PE and an external migration store](#scenario-one-offline-migration-using-windows-pe-and-an-external-migration-store) - -[Scenario Two: Manual network migration](#scenario-two-manual-network-migration) - -[Scenario Three: Managed network migration](#scenario-three-managed-network-migration) - ## PC-refresh The following diagram shows a PC-refresh migration, also known as a computer refresh migration. First, the administrator migrates the user state from a source computer to an intermediate store. After installing the operating system, the administrator migrates the user state back to the source computer. diff --git a/windows/deployment/usmt/usmt-configxml-file.md b/windows/deployment/usmt/usmt-configxml-file.md index 8c2219cf8e..4d4f72d27c 100644 --- a/windows/deployment/usmt/usmt-configxml-file.md +++ b/windows/deployment/usmt/usmt-configxml-file.md @@ -24,73 +24,17 @@ For more information about using the `Config.xml` file with other migration file > [!NOTE] > To exclude a component from the `Config.xml` file, set the **migrate** value to **no**. Deleting the XML tag for the component from the `Config.xml` file will not exclude the component from your migration. -## In this topic +## Migration Policies In USMT there are new migration policies that can be configured in the `Config.xml` file. For example, you can configure additional **<ErrorControl>**, **<ProfileControl>**, and **<HardLinkStoreControl>** options. The following elements and parameters are for use in the `Config.xml` file only. -[<Policies>](#policies) - -[<ErrorControl>](#errorcontrol) - - - -[<fatal>](#fatal) - -[<fileError>](#fileerror) - -[<nonfatal>](#nonfatal) - -[<registryError>](#registryerror) - -[<HardLinkStoreControl>](#hardlinkstorecontrol) - -[<fileLocked>](#filelocked) - -[<createHardLink>](#createhardlink) - -[<errorHardLink>](#errorhardlink) - -[<ProfileControl>](#profilecontrol) - -[<localGroups>](#localgroups) - -[<mappings>](#mappings) - -[<changeGroup>](#changegroup) - -[<include>](#include) - -[<exclude>](#exclude) - -[Sample Config.xml File](#sample-configxml-file) - -## <Policies> +### <Policies> The **<Policies>** element contains elements that describe the policies that USMT follows while creating a migration store. Valid children of the **<Policies>** element are **<ErrorControl>** and **<HardLinkStoreControl>**. The **<Policies>** element is a child of **<Configuration>**. Syntax: `` `` -## <ErrorControl> +### <ErrorControl> The **<ErrorControl>** element is an optional element you can configure in the `Config.xml` file. The configurable **<ErrorControl>** rules support only the environment variables for the operating system that is running and the currently logged-on user. As a workaround, you can specify a path using the (\*) wildcard character. @@ -139,7 +83,7 @@ Syntax: `` *<pattern>* `` You use the **<fatal>** element to specify that errors matching a specific pattern should cause USMT to halt the migration. -## <fileError> +### <fileError> The **<fileError>** element isn't required. @@ -153,7 +97,7 @@ Syntax: `` `` You use the **<fileError>** element to represent the behavior associated with file errors. -## <nonFatal> +### <nonFatal> The **<nonFatal>** element isn't required. @@ -171,7 +115,7 @@ Syntax: `` *<pattern>* `` You use the **<nonFatal>** element to specify that errors matching a specific pattern shouldn't cause USMT to halt the migration. -## <registryError> +### <registryError> The **<registryError>** element isn't required. @@ -189,7 +133,7 @@ Syntax: `` `` You use the **<registryError>** element to specify that errors matching a specific pattern shouldn't cause USMT to halt the migration. -## <HardLinkStoreControl> +### <HardLinkStoreControl> The **<HardLinkStoreControl>** element contains elements that describe how to handle files during the creation of a hard-link migration store. Its only valid child is **<fileLocked>**. @@ -222,43 +166,43 @@ The **<HardLinkStoreControl>** sample code below specifies that hard links ``` -## <fileLocked> +### <fileLocked> The **<fileLocked>** element contains elements that describe how to handle files that are locked for editing. The rules defined by the **<fileLocked>** element are processed in the order in which they appear in the XML file. Syntax: `` `` -## <createHardLink> +### <createHardLink> The **<createHardLink>** element defines a standard MigXML pattern that describes file paths where hard links should be created, even if the file is locked for editing by another application. Syntax: `` *<pattern>* `` -## <errorHardLink> +### <errorHardLink> The **<errorHardLink>** element defines a standard MigXML pattern that describes file paths where hard links shouldn't be created if the file is locked for editing by another application. USMT will attempt to copy files under these paths into the migration store. However, if that isn't possible, **Error\_Locked** is thrown. This error is a standard Windows application programming interface (API) error that can be captured by the **<ErrorControl>** section to either cause USMT to skip the file or abort the migration. Syntax: `` *<pattern>* `` -## <ProfileControl> +### <ProfileControl> This element is used to contain other elements that establish rules for migrating profiles, users, and policies around local group membership during the migration. **<ProfileMigration>** is a child of **<Configuration>**. Syntax: <`ProfileControl>` `` -## <localGroups> +### <localGroups> This element is used to contain other elements that establish rules for how to migrate local groups. **<localGroups>** is a child of **<ProfileControl>**. Syntax: `` `` -## <mappings> +### <mappings> This element is used to contain other elements that establish mappings between groups. Syntax: `` `` -## <changeGroup> +### <changeGroup> This element describes the source and destination groups for a local group membership change during the migration. It's a child of **<localGroups>**. The following parameters are defined: @@ -272,13 +216,13 @@ The valid and required children of **<changeGroup>** are **<include> Syntax: `` `` -## <include> +### <include> This element specifies that its required child, *<pattern>*, should be included in the migration. Syntax: `` `` -## <exclude> +### <exclude> This element specifies that its required child, *<pattern>*, should be excluded from the migration. diff --git a/windows/deployment/usmt/usmt-conflicts-and-precedence.md b/windows/deployment/usmt/usmt-conflicts-and-precedence.md index 016e76bf24..d6433d0ca6 100644 --- a/windows/deployment/usmt/usmt-conflicts-and-precedence.md +++ b/windows/deployment/usmt/usmt-conflicts-and-precedence.md @@ -27,32 +27,6 @@ When you include, exclude, and reroute files and settings, it's important to kno - **You can use the <unconditionalExclude> element to globally exclude data.** This element excludes objects, regardless of any other **<include>** rules that are in the .xml files. For example, you can use the **<unconditionalExclude>** element to exclude all MP3 files on the computer or to exclude all files from `C:\UserData`. -## In this topic - -[General](#general) - -- [What is the relationship between rules that are located within different components?](#what-is-the-relationship-between-rules-that-are-located-within-different-components) - -- [How does precedence work with the Config.xml file?](#how-does-precedence-work-with-the-configxml-file) - -- [How does USMT process each component in an .xml file with multiple components?](#how-does-usmt-process-each-component-in-an-xml-file-with-multiple-components) - -- [How are rules processed?](#how-are-rules-processed) - -- [How does USMT combine all of the .xml files that I specify on the command line?](#how-does-usmt-combine-all-of-the-xml-files-that-i-specify-on-the-command-line) - -[The <include> and <exclude> rules](#the-include-and-exclude-rules) - -- [What happens when there are conflicting <include> and <exclude> rules?](#what-happens-when-there-are-conflicting-include-and-exclude-rules) - -- [<include> and <exclude> rules precedence examples](#include-and-exclude-rules-precedence-examples) - -[File collisions](#file-collisions) - -- [What is the default behavior when there are file collisions?](#what-is-the-default-behavior-when-there-are-file-collisions) - -- [How does the <merge> rule work when there are file collisions?](#how-does-the-merge-rule-work-when-there-are-file-collisions) - ## General ### What is the relationship between rules that are located within different components? diff --git a/windows/deployment/usmt/usmt-custom-xml-examples.md b/windows/deployment/usmt/usmt-custom-xml-examples.md index 4f063c6db3..40514b888a 100644 --- a/windows/deployment/usmt/usmt-custom-xml-examples.md +++ b/windows/deployment/usmt/usmt-custom-xml-examples.md @@ -20,7 +20,7 @@ The following template is a template for the sections that you need to migrate y **Template**
- Expand to show Example 1 application template: + Expand to show Example 1 application template: ``` xml @@ -109,7 +109,7 @@ The following sample is a custom .xml file named `CustomFile.xml` that migrates **XML file**
- Expand to show Example 2 XML file: + Expand to show Example 2 XML file: ```xml @@ -159,7 +159,7 @@ The sample patterns describe the behavior in the following example .xml file. **XML file**
- Expand to show Example 3 XML file: + Expand to show Example 3 XML file: ``` xml @@ -201,7 +201,7 @@ The behavior for this custom .xml file is described within the `` t **XML file**
- Expand to show Example 4 XML file: + Expand to show Example 4 XML file: ``` xml diff --git a/windows/deployment/usmt/usmt-customize-xml-files.md b/windows/deployment/usmt/usmt-customize-xml-files.md index 22adc255cd..b56b14a8f1 100644 --- a/windows/deployment/usmt/usmt-customize-xml-files.md +++ b/windows/deployment/usmt/usmt-customize-xml-files.md @@ -13,20 +13,6 @@ ms.technology: itpro-deploy # Customize USMT XML files -## In this topic - -[Overview](#overview) - -[Migration .xml files](#migration-xml-files) - -[Custom .xml files](#custom-xml-files) - -[The Config.xml file](#the-configxml-file) - -[Examples](#examples) - -[Additional Information](#additional-information) - ## Overview If you want the ScanState and LoadState tools to use any of the migration .xml files, specify these files at the command line using the `/i` option. Because the ScanState and LoadState tools need the .xml files to control the migration, specify the same set of .xml files for both the `ScanState.exe` and `LoadState.exe` commands. However, you don't have to specify the `Config.xml` file with the `/config` option, unless you want to exclude some of the files and settings that you migrated to the store. For example, you might want to migrate the My Documents folder to the store but not to the destination computer. To achieve this scenario, modify the `Config.xml` file and specify the updated file with the `LoadState.exe` command. Then the `LoadState.exe` command will migrate only the files and settings that you want to migrate. diff --git a/windows/deployment/usmt/usmt-estimate-migration-store-size.md b/windows/deployment/usmt/usmt-estimate-migration-store-size.md index 6c72dd6cb8..5232dbb7bc 100644 --- a/windows/deployment/usmt/usmt-estimate-migration-store-size.md +++ b/windows/deployment/usmt/usmt-estimate-migration-store-size.md @@ -15,14 +15,6 @@ ms.technology: itpro-deploy The disk space requirements for a migration are dependent on the size of the migration store and the type of migration. You can estimate the amount of disk space needed for computers in your organization based on information about your organization's infrastructure. You can also calculate the disk space requirements using the ScanState tool. -## 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. - -- [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. - ## Hard disk space requirements - **Store**: For non-hard-link migrations, you should ensure that there's enough available disk space at the location where you'll save your store to contain the data being migrated. You can save your store to another partition, an external storage device such as a USB flash drive or a server. For more information, see [Choose a Migration Store Type](usmt-choose-migration-store-type.md). diff --git a/windows/deployment/usmt/usmt-extract-files-from-a-compressed-migration-store.md b/windows/deployment/usmt/usmt-extract-files-from-a-compressed-migration-store.md index 47f0de9169..8d4a62d699 100644 --- a/windows/deployment/usmt/usmt-extract-files-from-a-compressed-migration-store.md +++ b/windows/deployment/usmt/usmt-extract-files-from-a-compressed-migration-store.md @@ -23,19 +23,7 @@ Options used with the `/extract` option can specify: - Include and exclude patterns for selective data extraction. -In addition, you can specify the file patterns that you want to extract by using the `/i` option to include file patterns or the `/e` option to exclude file patterns. When both the `/i` option and the `/e` option are used in the same command, include patterns take precedence over exclude patterns. Note that this is different from the include and exclude rules used in the ScanState and LoadState tools. - -## In this topic - -- [To run the USMTUtils tool with the /extract option](#to-run-the-usmtutils-tool-with-the-extract-option) - -- [To extract all files from a compressed migration store](#to-extract-all-files-from-a-compressed-migration-store) - -- [To extract specific file types from an encrypted compressed migration store](#to-extract-specific-file-types-from-an-encrypted-compressed-migration-store) - -- [To extract all but one, or more, file types from an encrypted compressed migration store](#to-extract-all-but-one-or-more-file-types-from-an-encrypted-compressed-migration-store) - -- [To extract file types using the include pattern and the exclude pattern](#to-extract-file-types-using-the-include-pattern-and-the-exclude-pattern) +In addition, you can specify the file patterns that you want to extract by using the `/i` option to include file patterns or the `/e` option to exclude file patterns. When both the `/i` option and the `/e` option are used in the same command, include patterns take precedence over exclude patterns. Note that this is different from the include and exclude rules used in the **ScanState** and **LoadState** tools. ### To run the USMTUtils tool with the /extract option diff --git a/windows/deployment/usmt/usmt-general-conventions.md b/windows/deployment/usmt/usmt-general-conventions.md index 15d1d625c2..ffa159f0c3 100644 --- a/windows/deployment/usmt/usmt-general-conventions.md +++ b/windows/deployment/usmt/usmt-general-conventions.md @@ -15,12 +15,6 @@ ms.technology: itpro-deploy This topic describes the XML helper functions. -## In this topic - -[General XML guidelines](#general-xml-guidelines) - -[Helper functions](#helper-functions) - ## General XML guidelines Before you modify the .xml files, become familiar with the following guidelines: diff --git a/windows/deployment/usmt/usmt-hard-link-migration-store.md b/windows/deployment/usmt/usmt-hard-link-migration-store.md index 3992607617..a43972cb9b 100644 --- a/windows/deployment/usmt/usmt-hard-link-migration-store.md +++ b/windows/deployment/usmt/usmt-hard-link-migration-store.md @@ -15,28 +15,6 @@ ms.technology: itpro-deploy 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](#when-to-use-a-hard-link-migration) - -[Understanding a hard-link migration](#understanding-a-hard-link-migration) - -[Hard-Link migration store details](#hard-link-migration-store-details) - -[Hard disk space](#hard-disk-space) - -[Hard-Link store size estimation](#hard-link-store-size-estimation) - -[Migration store path on multiple volumes](#migration-store-path-on-multiple-volumes) - -[Location modifications](#location-modifications) - -[Migrating Encrypting File System (EFS) certificates and files](#migrating-encrypting-file-system-efs-certificates-and-files) - -[Migrating locked files with the hard-link migration store](#migrating-locked-files-with-the-hard-link-migration-store) - -[XML elements in the Config.xml file](#xml-elements-in-the-configxml-file) - ## 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: diff --git a/windows/deployment/usmt/usmt-identify-users.md b/windows/deployment/usmt/usmt-identify-users.md index 772cef9f85..270b1902c3 100644 --- a/windows/deployment/usmt/usmt-identify-users.md +++ b/windows/deployment/usmt/usmt-identify-users.md @@ -16,15 +16,6 @@ ms.date: 11/01/2022 It's important to carefully consider how you plan to migrate users. By default, all users are migrated by User State Migration Tool (USMT) 5.0. You must specify which users to include by using the command line. You can't specify users in the .xml files. For instructions on how to migrate users, see [Migrate user accounts](usmt-migrate-user-accounts.md). -## In this topic - -- [Identify users](#identify-users) - - [In this topic](#in-this-topic) - - [Migrating local accounts](#migrating-local-accounts) - - [Migrating domain accounts](#migrating-domain-accounts) - - [Command-line options](#command-line-options) - - [Related articles](#related-articles) - ## Migrating local accounts Before migrating local accounts, be aware of the following items: diff --git a/windows/deployment/usmt/usmt-include-files-and-settings.md b/windows/deployment/usmt/usmt-include-files-and-settings.md index 371d380e66..52126c877e 100644 --- a/windows/deployment/usmt/usmt-include-files-and-settings.md +++ b/windows/deployment/usmt/usmt-include-files-and-settings.md @@ -1,6 +1,6 @@ --- title: Include Files and Settings (Windows 10) -description: Specify the migration .xml files you want, then use the User State Migration Tool (USMT) 10.0 to migrate the settings and components specified. +description: Specify the migration .xml files you want, then use the User State Migration Tool (USMT) 10.0 to migrate the settings and components specified. ms.reviewer: manager: aaroncz ms.author: frankroj @@ -13,25 +13,9 @@ ms.technology: itpro-deploy # Include Files and Settings +When you specify the migration .xml files, User State Migration Tool (USMT) 10.0 migrates the settings and components specified in [What does USMT migrate?](usmt-what-does-usmt-migrate.md). To include additional files and settings, we recommend that you create a custom .xml file, and then include this file when using both the `ScanState.exe` and `LoadState.exe` commands. By creating a custom .xml file, you can keep your changes separate from the default .xml files, which makes it easier to track your modifications. -When you specify the migration .xml files, User State Migration Tool (USMT) 10.0 migrates the settings and components specified in [What Does USMT Migrate?](usmt-what-does-usmt-migrate.md) To include additional files and settings, we recommend that you create a custom .xml file and then include this file when using both the ScanState and LoadState commands. By creating a custom .xml file, you can keep your changes separate from the default .xml files, which makes it easier to track your modifications. - -In this topic: - -[Migrate a Single Registry Key](#bkmk-migsingleregkey) - -[Migrate a Specific Folder](#bkmk-migspecificfolder) - -[Migrate a Folder from a Specific Drive](#bkmk-migfoldspecdrive) - -[Migrate a Folder from Any Location](#bkmk-migfolderanyloc) - -[Migrate a File Type Into a Specific Folder](#bkmk-migfiletypetospecificfolder) - -[Migrate a Specific File](#bkmk-migspecificfile) - -## Migrate a Single Registry Key - +## Migrate a single registry key The following .xml file migrates a single registry key. @@ -52,54 +36,53 @@ The following .xml file migrates a single registry key. ``` -## Migrate a Specific Folder - +## Migrate a specific folder The following examples show how to migrate a folder from a specific drive, and from any location on the computer. -### Migrate a Folder from a Specific Drive +### Migrate a folder from a specific drive -- **Including subfolders.** The following .xml file migrates all files and subfolders from C:\\EngineeringDrafts to the destination computer. +- **Including subfolders.** The following .xml file migrates all files and subfolders from `C:\EngineeringDrafts` to the destination computer. ``` xml Component to migrate all Engineering Drafts Documents including subfolders -    -       + + C:\EngineeringDrafts\* [*] -     -    + + ``` -- **Excluding subfolders.** The following .xml file migrates all files from C:\\EngineeringDrafts, but it does not migrate any subfolders within C:\\EngineeringDrafts. +- **Excluding subfolders.** The following .xml file migrates all files from `C:\EngineeringDrafts`, but it doesn't migrate any subfolders within `C:\EngineeringDrafts`. ``` xml Component to migrate all Engineering Drafts Documents without subfolders -    -       + + C:\EngineeringDrafts\ [*] -     -    + + ``` -### Migrate a Folder from Any Location +### Migrate a folder from any location -The following .xml file migrates all files and subfolders of the EngineeringDrafts folder from any drive on the computer. If multiple folders exist with the same name, then all files with this name are migrated. +The following .xml file migrates all files and subfolders of the `EngineeringDrafts` folder from any drive on the computer. If multiple folders exist with the same name, then all files with this name are migrated. ``` xml @@ -119,7 +102,7 @@ The following .xml file migrates all files and subfolders of the EngineeringDraf ``` -The following .xml file migrates all files and subfolders of the EngineeringDrafts folder from any location on the C:\\ drive. If multiple folders exist with the same name, they are all migrated. +The following .xml file migrates all files and subfolders of the `EngineeringDrafts` folder from any location on the `C:\` drive. If multiple folders exist with the same name, they're all migrated. ``` xml @@ -139,10 +122,9 @@ The following .xml file migrates all files and subfolders of the EngineeringDraf ``` -## Migrate a File Type Into a Specific Folder +## Migrate a file type into a specific folder - -The following .xml file migrates .mp3 files located in the specified drives on the source computer into the C:\\Music folder on the destination computer. +The following .xml file migrates `.mp3` files located in the specified drives on the source computer into the `C:\Music` folder on the destination computer. ``` xml @@ -167,31 +149,30 @@ The following .xml file migrates .mp3 files located in the specified drives on t ``` -## Migrate a Specific File - +## Migrate a specific file The following examples show how to migrate a file from a specific folder, and how to migrate a file from any location. -- **To migrate a file from a folder.** The following .xml file migrates only the Sample.doc file from C:\\EngineeringDrafts on the source computer to the destination computer. +- **To migrate a file from a folder.** The following .xml file migrates only the `Sample.doc` file from `C:\EngineeringDrafts` on the source computer to the destination computer. ``` xml Component to migrate all Engineering Drafts Documents -    -       + + C:\EngineeringDrafts\ [Sample.doc] -     -    + + ``` -- **To migrate a file from any location.** To migrate the Sample.doc file from any location on the C:\\ drive, use the <pattern> element, as the following example shows. If multiple files exist with the same name on the C:\\ drive, all of files with this name are migrated. +- **To migrate a file from any location.** To migrate the `Sample.doc` file from any location on the `C:\` drive, use the **<pattern>** element, as the following example shows. If multiple files exist with the same name on the `C:\` drive, all of files with this name are migrated. ``` xml C:\* [Sample.doc] @@ -203,22 +184,12 @@ The following examples show how to migrate a file from a specific folder, and ho ``` -## Related topics - - -[Customize USMT XML Files](usmt-customize-xml-files.md) - -[Custom XML Examples](usmt-custom-xml-examples.md) - -[Conflicts and Precedence](usmt-conflicts-and-precedence.md) - -[USMT XML Reference](usmt-xml-reference.md) - -  - -  - +## Related articles +[Customize USMT XML files](usmt-customize-xml-files.md) +[Custom XML examples](usmt-custom-xml-examples.md) +[Conflicts and precedence](usmt-conflicts-and-precedence.md) +[USMT XML reference](usmt-xml-reference.md) diff --git a/windows/deployment/usmt/usmt-loadstate-syntax.md b/windows/deployment/usmt/usmt-loadstate-syntax.md index 829942814a..64d838d96e 100644 --- a/windows/deployment/usmt/usmt-loadstate-syntax.md +++ b/windows/deployment/usmt/usmt-loadstate-syntax.md @@ -1,4 +1,4 @@ ---- +---This title: LoadState Syntax (Windows 10) description: Learn about the syntax and usage of the command-line options available when you use the LoadState command. ms.reviewer: @@ -11,90 +11,88 @@ ms.topic: article ms.technology: itpro-deploy --- -# LoadState Syntax +# LoadState syntax -This topic discusses the **LoadState** command syntax and options available with it. +This article discusses the `LoadState.exe` command syntax and options available with it. -## Before You Begin +## Before you begin -Before you run the **LoadState** command, note the following: +Before you run the `LoadState.exe` command, note the following items: -- To ensure that all operating system settings migrate, we recommend that you run the **LoadState** commands in administrator mode from an account with administrative credentials. +- To ensure that all operating system settings migrate, we recommend that you run the `LoadState.exe` commands in administrator mode from an account with administrative credentials. -- For information about software requirements for running the **LoadState** command, see [USMT Requirements](usmt-requirements.md). +- For information about software requirements for running the `LoadState.exe` command, see [USMT requirements](usmt-requirements.md). -- You should log off after you run the **LoadState** command. Some settings (for example, fonts, wallpaper, and screensaver settings) will not take effect until the next time the user logs in. +- You should sign out after you run the `LoadState.exe` command. Some settings (for example, fonts, wallpaper, and screensaver settings) won't take effect until the next time the user logs in. -- Unless otherwise specified, you can use each option only once when running a tool on the command line. +- Unless otherwise specified, you can use each option only once when running a tool on the command line. -- **LoadState** does not require domain controller access to apply domain profiles. This functionality is available without any additional configuration. It is not necessary for the source computer to have had domain controller access when the user profile was gathered using **ScanState**. However, domain profiles are inaccessible until the destination computer is joined to the domain. +- **LoadState** doesn't require domain controller access to apply domain profiles. This functionality is available without any additional configuration. It isn't necessary for the source computer to have had domain controller access when the user profile was gathered using **ScanState**. However, domain profiles are inaccessible until the destination computer is joined to the domain. -- The [Incompatible Command-Line Options](#bkmk-cloi) table lists which options you can use together and which command-line options are incompatible. +- The [Incompatible command-line options](#incompatible-command-line-options) table lists which options you can use together and which command-line options are incompatible. -## Syntax +## Syntax -This section explains the syntax and usage of the command-line options available when you use the **LoadState** command. The options can be specified in any order. If the option contains a parameter, you can specify either a colon or space separator. +This section explains the syntax and usage of the command-line options available when you use the `LoadState.exe` command. The options can be specified in any order. If the option contains a parameter, you can specify either a colon or space separator. -The **LoadState** command's syntax is: +The `LoadState.exe` command's syntax is: -loadstate *StorePath* \[/i:\[*Path*\\\]*FileName*\] \[/v:*VerbosityLevel*\] \[/nocompress\] \[/decrypt /key:*KeyString*|/keyfile:\[Path\\\]*FileName*\] \[/l:\[*Path*\\\]*FileName*\] \[/progress:\[*Path*\\\]*FileName*\] \[/r:*TimesToRetry*\] \[/w:*SecondsToWait*\] \[/c\] \[/all\] \[/ui:\[*DomainName*|*ComputerName*\\\]*UserName*\] \[/ue:\[\[*DomainName*|*ComputerName*\\\]*UserName*\] \[/uel:*NumberOfDays*|*YYYY/MM/DD*|0\] \[/md:*OldDomain*:*NewDomain*\] \[/mu:*OldDomain*\\*OldUserName*:\[*NewDomain*\\\]*NewUserName*\] \[/lac:\[*Password*\]\] \[/lae\] \[/config:\[*Path*\\\]*FileName*\] \[/?|help\] +`loadstate.exe` *StorePath* \[/i:\[*Path*\\\]*FileName*\] \[/v:*VerbosityLevel*\] \[/nocompress\] \[/decrypt /key:*KeyString*|/keyfile:\[Path\\\]*FileName*\] \[/l:\[*Path*\\\]*FileName*\] \[/progress:\[*Path*\\\]*FileName*\] \[/r:*TimesToRetry*\] \[/w:*SecondsToWait*\] \[/c\] \[/all\] \[/ui:\[*DomainName*|*ComputerName*\\\]*UserName*\] \[/ue:\[\[*DomainName*|*ComputerName*\\\]*UserName*\] \[/uel:*NumberOfDays*|*YYYY/MM/DD*|0\] \[/md:*OldDomain*:*NewDomain*\] \[/mu:*OldDomain*\\*OldUserName*:\[*NewDomain*\\\]*NewUserName*\] \[/lac:\[*Password*\]\] \[/lae\] \[/config:\[*Path*\\\]*FileName*\] \[/?|help\] -For example, to decrypt the store and migrate the files and settings to a computer running Windows 7 type the following on the command line: +For example, to decrypt the store and migrate the files and settings to a computer, type the following command: -`loadstate \\server\share\migration\mystore /i:migapp.xml /i:migdocs.xml /v:13 /decrypt /key:"mykey"` - -## Storage Options +`loadstate.exe \\server\share\migration\mystore /i:migapp.xml /i:migdocs.xml /v:13 /decrypt /key:"mykey"` +## Storage options USMT provides the following options that you can use to specify how and where the migrated data is stored. | Command-Line Option | Description | |--- |--- | -| `StorePath` | Indicates the folder where the files and settings data are stored. You must specify *StorePath* when using the **LoadState** command. You cannot specify more than one *StorePath*. | -| `/decrypt /key`:*KeyString*
or
`/decrypt /key`:"*Key String*"
or
`/decrypt /keyfile`:[*Path*]*FileName* | Decrypts the store with the specified key. With this option, you will need to specify the encryption key in one of the following ways:
  • `/key:`*KeyString* specifies the encryption key. If there is a space in *KeyString*, you must surround the argument with quotation marks.
  • `/keyfile:`*FilePathAndName* specifies a text (.txt) file that contains the encryption key

*KeyString* cannot exceed 256 characters.
The `/key` and `/keyfile` options cannot be used on the same command line.
The `/decrypt` and `/nocompress` options cannot be used on the same command line.
**Important**
Use caution with this option, because anyone who has access to the **LoadState** command-line script will also have access to the encryption key.

For example:
`loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /decrypt /key:mykey` | -| `/decrypt:`*"encryption strength"* | The `/decrypt` option accepts a command-line parameter to define the encryption strength specified for the migration store encryption. For more information about supported encryption algorithms, see [Migration Store Encryption](usmt-migration-store-encryption.md). | -| `/hardlink` | Enables user-state data to be restored from a hard-link migration store. The `/nocompress` parameter must be specified with `/hardlink` option. | -| `/nocompress` | Specifies that the store is not compressed. You should only use this option in testing environments. We recommend that you use a compressed store during your actual migration. This option cannot be used with the `/decrypt` option.
For example:
`loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /nocompress` | +| **StorePath** | Indicates the folder where the files and settings data are stored. You must specify *StorePath* when using the `LoadState.exe` command. You can't specify more than one *StorePath*. | +| **/decrypt /key**:*KeyString*
or
**/decrypt /key**:"*Key String*"
or
**/decrypt /keyfile**:[*Path*]*FileName* | Decrypts the store with the specified key. With this option, you'll need to specify the encryption key in one of the following ways:
  • `/key:`*KeyString* specifies the encryption key. If there's a space in *KeyString*, you must surround the argument with quotation marks.
  • `/keyfile:`*FilePathAndName* specifies a text (.txt) file that contains the encryption key

*KeyString* can't exceed 256 characters.
The `/key` and `/keyfile` options can't be used on the same command line.
The `/decrypt` and `/nocompress` options can't be used on the same command line.
**Important**
Use caution when using the `/key` or `keyfile` options. For example, anyone who has access to scripts that run the `LoadState.exe` command with these options will also have access to the encryption key.

For example:
`loadstate.exe /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /decrypt /key:mykey` | +| **/decrypt**:*"encryption strength"* | The `/decrypt` option accepts a command-line parameter to define the encryption strength specified for the migration store encryption. For more information about supported encryption algorithms, see [Migration Store Encryption](usmt-migration-store-encryption.md). | +| **/hardlink** | Enables user-state data to be restored from a hard-link migration store. The `/nocompress` parameter must be specified with `/hardlink` option. | +| **/nocompress** | Specifies that the store isn't compressed. You should only use this option in testing environments. We recommend that you use a compressed store during your actual migration. This option can't be used with the `/decrypt` option.
For example:
`loadstate.exe /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /nocompress` | -## Migration Rule Options +## Migration rule options USMT provides the following options to specify what files you want to migrate. | Command-Line Option | Description | |--- |--- | -| `/i`:[*Path*]*FileName* | **(include)**
Specifies an .xml file that contains rules that define what state to migrate. You can specify this option multiple times to include all of your .xml files (MigApp.xml, MigSys.xml, MigDocs.xml and any custom .xml files that you create). *Path* can be either a relative or full path. If you do not specify the *Path* variable, then *FileName* must be located in the current directory.

For more information about which files to specify, see the "XML files" section of the [Frequently Asked Questions](usmt-faq.yml) topic. | -| `/config:`[*Path*]*FileName* | Specifies the Config.xml file that the **LoadState** command should use. You cannot specify this option more than once on the command line. *Path* can be either a relative or full path. If you do not specify the *Path* variable, then the *FileName* must be located in the current directory.

This example migrates the files and settings based on the rules in the Config.xml, MigDocs.xml, and MigApp.xml files:

`loadstate \server\share\migration\mystore /config:config.xml /i:migdocs.xml /i:migapp.xml /v:5 /l:loadstate.log` | -| `/auto:`*"path to script files"* | This option enables you to specify the location of the default .xml files and then launch your migration. If no path is specified, USMT will use the directory where the USMT binaries are located. The `/auto` option has the same effect as using the following options: `/i:MigDocs.xml` `/i:MigApp.xml /v:5`. | +| **/i**:[*Path*]*FileName* | **(include)**
Specifies an .xml file that contains rules that define what state to migrate. You can specify this option multiple times to include all of your .xml files (MigApp.xml, MigSys.xml, MigDocs.xml and any custom .xml files that you create). *Path* can be either a relative or full path. If you don't specify the *Path* variable, then *FileName* must be located in the current directory.

For more information about which files to specify, see the "XML files" section of the [Frequently Asked Questions](usmt-faq.yml) article. | +| **/config**:[*Path*]*FileName* | Specifies the `Config.xml` file that the `LoadState.exe` command should use. You can't specify this option more than once on the command line. *Path* can be either a relative or full path. If you don't specify the *Path* variable, then the *FileName* must be located in the current directory.

This example migrates the files and settings based on the rules in the Config.xml, MigDocs.xml, and MigApp.xml files:

`loadstate.exe \server\share\migration\mystore /config:config.xml /i:migdocs.xml /i:migapp.xml /v:5 /l:loadstate.log` | +| **/auto**:*"path to script files"* | This option enables you to specify the location of the default .xml files and then launch your migration. If no path is specified, USMT will use the directory where the USMT binaries are located. The `/auto` option has the same effect as using the following options: `/i:MigDocs.xml` `/i:MigApp.xml /v:5`. | -## Monitoring Options +## Monitoring options USMT provides several command-line options that you can use to analyze problems that occur during migration. | Command-Line Option | Description | |--- |--- | -| `/l:`[*Path*]*FileName* | Specifies the location and name of the **LoadState** log. You cannot store any of the log files in *StorePath*. *Path* can be either a relative or full path. If you do not specify the *Path* variable, then the log will be created in the current directory. You can specify the **/v** option to adjust the amount of output.

If you run the **LoadState** command from a shared network resource, you must specify this option or USMT will fail with the error: "USMT was unable to create the log file(s)". To fix this issue, use the **/l:load.log** option. | -| `/v:`*``* | **(Verbosity)**

Enables verbose output in the LoadState log file. The default value is 0.
You can set the *VerbosityLevel* to one of the following levels:
  • **0** - Only the default errors and warnings are enabled.
  • **1** - Enables verbose output.
  • **4** - Enables error and status output.
  • **5** - Enables verbose and status output.
  • **8** - Enables error output to a debugger.
  • **9** - Enables verbose output to a debugger.
  • **12** - Enables error and status output to a debugger.
  • **13** - Enables verbose, status, and debugger output.

For example:
`loadstate \server\share\migration\mystore /v:5 /i:migdocs.xml /i:migapp.xml` | -| `/progress:`[*Path*]*FileName* | Creates the optional progress log. You cannot store any of the log files in *StorePath*. *Path* can be either a relative or full path. If you do not specify the *Path* variable, then *FileName* will be created in the current directory.

For example:
`loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /progress:prog.log /l:loadlog.log` | -| `/c` | When this option is specified, the **LoadState** command will continue to run, even if non-fatal errors occur. Any files or settings that cause an error are logged in the progress log. For example, if there is a large file that will not fit on the computer, the **LoadState** command will log an error and continue with the migration. Without the **/c** option, the **LoadState** command will exit on the first error. You can use the new <**ErrorControl**> section in the Config.xml file to specify which file or registry read/write errors can be safely ignored and which might cause the migration to fail. This enables the **/c** command-line option to safely skip all input/output (I/O) errors in your environment. In addition, the **/genconfig** option now generates a sample <**ErrorControl**> section that is enabled by specifying error messages and desired behaviors in the Config.xml file. | -| `/r:`*``* | **(Retry)**

Specifies the number of times to retry when an error occurs while migrating the user state from a server. The default is three times. This option is useful in environments where network connectivity is not reliable.

While restoring the user state, the **/r** option will not recover data that is lost due to a network-hardware failure, such as a faulty or disconnected network cable, or when a virtual private network (VPN) connection fails. The retry option is intended for large, busy networks where connectivity is satisfactory, but communication latency is a problem. | -| `/w:`*``* | **(Wait)**

Specifies the time to wait, in seconds, before retrying a network file operation. The default is 1 second. | -| `/?` or `/help` | Displays Help on the command line. | +| **/l**:[*Path*]*FileName* | Specifies the location and name of the **LoadState** log. You can't store any of the log files in *StorePath*. *Path* can be either a relative or full path. If you don't specify the *Path* variable, then the log will be created in the current directory. You can specify the `/v` option to adjust the verbosity of the log.

If you run the `LoadState.exe` command from a shared network resource, you must specify this option, or USMT will fail with the error:

***USMT was unable to create the log file(s)***

To fix this issue, make sure to specify the `/l` option when running `LoadState.exe` from a shared network resource. | +| **/v**:*``* | **(Verbosity)**

Enables verbose output in the **LoadState** log file. The default value is 0.
You can set the *VerbosityLevel* to one of the following levels:
  • **0** - Only the default errors and warnings are enabled.
  • **1** - Enables verbose output.
  • **4** - Enables error and status output.
  • **5** - Enables verbose and status output.
  • **8** - Enables error output to a debugger.
  • **9** - Enables verbose output to a debugger.
  • **12** - Enables error and status output to a debugger.
  • **13** - Enables verbose, status, and debugger output.

For example:
`loadstate.exe \server\share\migration\mystore /v:5 /i:migdocs.xml /i:migapp.xml` | +| **/progress**:[*Path*]*FileName* | Creates the optional progress log. You can't store any of the log files in *StorePath*. *Path* can be either a relative or full path. If you don't specify the *Path* variable, then *FileName* will be created in the current directory.

For example:
`loadstate.exe /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /progress:prog.log /l:loadlog.log` | +| **/c** | When this option is specified, the `LoadState.exe` command will continue to run, even if non-fatal errors occur. Any files or settings that cause an error are logged in the progress log. For example, if there's a large file that won't fit on the computer, the `LoadState.exe` command will log an error and continue with the migration. Without the **/c** option, the `LoadState.exe` command will exit on the first error. You can use the new <**ErrorControl**> section in the `Config.xml` file to specify which file or registry read/write errors can be safely ignored and which might cause the migration to fail. This error control enables the **/c** command-line option to safely skip all input/output (I/O) errors in your environment. In addition, the **/genconfig** option now generates a sample <**ErrorControl**> section that is enabled by specifying error messages and desired behaviors in the Config.xml file. | +| **/r**:*``* | **(Retry)**

Specifies the number of times to retry when an error occurs while migrating the user state from a server. The default is three times. This option is useful in environments where network connectivity isn't reliable.

While restoring the user state, the `/r` option won't recover data that is lost due to a network-hardware failure, such as a faulty or disconnected network cable, or when a virtual private network (VPN) connection fails. The retry option is intended for large, busy networks where connectivity is satisfactory, but communication latency is a problem. | +| **/w**:*``* | **(Wait)**

Specifies the time to wait, in seconds, before retrying a network file operation. The default is 1 second. | +| **/?** or **/help** | Displays Help on the command line. | -## User Options +## User options -By default, all users are migrated. The only way to specify which users to include and exclude is by using the following options. You cannot exclude users in the migration .xml files or by using the Config.xml file. For more information, see [Identify Users](usmt-identify-users.md). +By default, all users are migrated. The only way to specify which users to include and exclude is by using the following options. You can't exclude users in the migration .xml files or by using the Config.xml file. For more information, see [Identify Users](usmt-identify-users.md). | Command-Line Option | Description | |--- |--- | -| `/all` | Migrates all of the users on the computer.

USMT migrates all user accounts on the computer, unless you specifically exclude an account with the **/ue** or **/uel** options. For this reason, you do not need to specify this option on the command line. However, if you choose to use the **/all** option, you cannot also use the **/ui**, **/ue** or **/uel** options. | -| `/ui:`*DomainName UserName*
or
`/ui:`*"DomainName User Name"*
or
`/ui:`*ComputerName LocalUserName* | **(User include)**

Migrates the specified user. By default, all users are included in the migration. Therefore, this option is helpful only when used with the **/ue** option. You can specify multiple **/ui** options, but you cannot use the **/ui** option with the **/all** option. *DomainName* and *UserName* can contain the asterisk () wildcard character. When you specify a user name that contains spaces, you will need to surround it with quotations marks.
For example:
  • To include only User2 from the Corporate domain, type:
    `/ue:* /ui:corporate\user2`
**Note**
If a user is specified for inclusion with the **/ui** option, and also is specified to be excluded with either the **/ue** or **/uel** options, the user will be included in the migration.

For more examples, see the descriptions of the **/uel**, **/ue**, and **/ui** options in this table. | -| `/uel:`*``*
or
`/uel:`*``*
or
`/uel:0` | **(User exclude based on last logon)**

Migrates only the users that logged onto the source computer within the specified time period, based on the **Last Modified** date of the Ntuser.dat file on the source computer. The **/uel** option acts as an include rule. For example, the **/uel:30** option migrates users who logged on, or whose user account was modified, within the last 30 days from the date when the ScanState command is run. You can specify a number of days or you can specify a date. You cannot use this option with the **/all** option. USMT retrieves the last logon information from the local computer, so the computer does not need to be connected to the network when you run this option. In addition, if a domain user has logged onto another computer, that logon instance is not considered by USMT.
**Note**
The **/uel** option is not valid in offline migrations.

Examples:
  • `/uel:0` migrates accounts that were logged on to the source computer when the **ScanState** command was run.
  • `/uel:90` migrates users who have logged on, or whose accounts have been otherwise modified, within the last 90 days.
  • `/uel:1` migrates users whose accounts have been modified within the last 24 hours.
  • `/uel:2002/1/15` migrates users who have logged on or whose accounts have been modified since January 15, 2002.

For example:
`loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /uel:0` | -| `/ue`:*DomainName UserName*
or
`/ue`*"DomainName User Name"*
or
`/ue`:*ComputerName LocalUserName* | **(User exclude)**

Excludes the specified users from the migration. You can specify multiple **/ue** options but you cannot use the **/ue** option with the **/all** option. *DomainName* and *UserName* can contain the asterisk () wildcard character. When you specify a user name that contains spaces, you will need to surround it with quotation marks.

For example:
`loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /ue:contoso\user1`
For more examples, see the descriptions of the **/uel**, **/ue**, and **/ui** options in this table. | -| `/md:`*OldDomain*:*NewDomain*
or
`/md:`*LocalComputerName:NewDomain* | **(move domain)**
Specifies a new domain for the user. Use this option to change the domain for users on a computer or to migrate a local user to a domain account. *OldDomain* may contain the asterisk () wildcard character.

You can specify this option more than once. You may want to specify multiple **/md** options if you are consolidating users across multiple domains to a single domain. For example, you could specify the following to consolidate the users from the Corporate and FarNorth domains into the Fabrikam domain: `/md:corporate:fabrikam` and `/md:farnorth:fabrikam`.

If there are conflicts between two **/md** commands, the first rule that you specify is applied. For example, if you specify the `/md:corporate:fabrikam` and `/md:corporate:farnorth` commands, then Corporate users would be mapped to the Fabrikam domain.
**Note**
If you specify an *OldDomain* that did not exist on the source computer, the **LoadState** command will appear to complete successfully, without an error or warning. However, in this case, users will not be moved to *NewDomain* but will remain in their original domain. For example, if you misspell "contoso" and you specify "/md:contso:fabrikam", the users will remain in contoso on the destination computer.

For example:
`loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore`
` /progress:prog.log /l:load.log /md:contoso:fabrikam` | -| `/mu:`*OldDomain OldUserName*:[*NewDomain*]*NewUserName*
or
`/mu:`*OldLocalUserName*:*NewDomain NewUserName* | Specifies a new user name for the specified user. If the store contains more than one user, you can specify multiple **/mu** options. You cannot use wildcard characters with this option.

For example:
`loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore`
`/progress:prog.log /l:load.log /mu:contoso\user1:fabrikam\user1` | -| `/lac:`[*Password*] | **(local account create)**

Specifies that if a user account is a local (non-domain) account, and it does not exist on the destination computer, USMT will create the account on the destination computer but it will be disabled. To enable the account, you must also use the **/lae** option.

If the **/lac** option is not specified, any local user accounts that do not already exist on the destination computer will not be migrated.

*Password* is the password for the newly created account. An empty password is used by default.
**Caution**
Use the *Password* variable with caution because it is provided in plain text and can be obtained by anyone with access to the computer that is running the **LoadState** command.
Also, if the computer has multiple users, all migrated users will have the same password.

For example:
`loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore`
For instructions, see [Migrate User Accounts](usmt-migrate-user-accounts.md). | -| `/lae` | **(local account enable)**

Enables the account that was created with the **/lac** option. You must specify the **/lac** option with this option.

For example:
`loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore`
`/progress:prog.log /l:load.log /lac:password /lae`

For instructions, see [Migrate User Accounts](usmt-migrate-user-accounts.md). | - +| **/all** | Migrates all of the users on the computer.

USMT migrates all user accounts on the computer, unless you specifically exclude an account with the `/ue` or `/uel` options. For this reason, you don't need to specify this option on the command line. However, if you choose to use the `/all` option, you can't also use the `/ui`, `/ue` or `/uel` options. | +| **/ui**:*DomainName UserName*
or
**/ui**:*"DomainName User Name"*
or
**/ui**:*ComputerName LocalUserName* | **(User include)**

Migrates the specified user. By default, all users are included in the migration. Therefore, this option is helpful only when used with the `/ue` option. You can specify multiple `/ui` options, but you can't use the `/ui` option with the `/all` option. *DomainName* and *UserName* can contain the asterisk () wildcard character. When you specify a user name that contains spaces, you'll need to surround it with quotations marks.
For example:
  • To include only User2 from the Corporate domain, type:
    `/ue:* /ui:corporate\user2`
**Note**
If a user is specified for inclusion with the `/ui` option and also specified to be excluded with either the `/ue` or `/uel` options, the user will be included in the migration.

For more examples, see the descriptions of the `/uel`, `/ue`, and `/ui` options in this table. | +| **/uel**:*``*
or
**/uel**:*``*
or
**/uel**:0 | **(User exclude based on last logon)**

Migrates only the users that logged onto the source computer within the specified time period, based on the **Last Modified** date of the Ntuser.dat file on the source computer. The `/uel` option acts as an include rule. For example, the `/uel:30` option migrates users who logged on, or whose user account was modified, within the last 30 days from the date when the `ScanState.exe` command is run. You can specify the number of days or you can specify a date. You can't use this option with the `/all` option. USMT retrieves the last sign-in information from the local computer, so the computer doesn't need to be connected to the network when you run this option. In addition, if a domain user has signed into another computer, that sign-in instance isn't considered by USMT.
**Note**
The `/uel` option isn't valid in offline migrations.

Examples:
  • `/uel:0` migrates accounts that were logged on to the source computer when the `ScanState.exe` command was run.
  • `/uel:90` migrates users who have logged on, or whose accounts have been otherwise modified, within the last 90 days.
  • `/uel:1` migrates users whose accounts have been modified within the last 24 hours.
  • `/uel:2002/1/15` migrates users who have logged on or whose accounts have been modified since January 15, 2002.

For example:
`loadstate.exe/i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /uel:0` | +| **/ue**:*DomainName\UserName*
or
**/ue** *"DomainName\User Name"*
or
**/ue**:*ComputerName\LocalUserName* | **(User exclude)**

Excludes the specified users from the migration. You can specify multiple `/ue` options but you can't use the `/ue` option with the `/all` option. *DomainName* and *UserName* can contain the asterisk () wildcard character. When you specify a user name that contains spaces, you'll need to surround it with quotation marks.

For example:
`loadstate.exe/i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /ue:contoso\user1`
For more examples, see the descriptions of the `/uel`, `/ue`, and `/ui` options in this table. | +| **/md**:*OldDomain*:*NewDomain*
or
**/md**:*LocalComputerName:NewDomain* | **(Move domain)**

Specifies a new domain for the user. Use this option to change the domain for users on a computer or to migrate a local user to a domain account. *OldDomain* may contain the asterisk () wildcard character.

You can specify this option more than once. You may want to specify multiple `/md` options if you're consolidating users across multiple domains to a single domain. For example, you could specify the following to consolidate the users from the Corporate and FarNorth domains into the Fabrikam domain: `/md:corporate:fabrikam` and `/md:farnorth:fabrikam`.

If there are conflicts between two `/md` commands, the first rule that you specify is applied. For example, if you specify the `/md:corporate:fabrikam` and `/md:corporate:farnorth` commands, then Corporate users would be mapped to the Fabrikam domain.
**Note**
If you specify an *OldDomain* that didn't exist on the source computer, the `LoadState.exe` command will appear to complete successfully, without an error or warning. However, in this case, users won't be moved to *NewDomain* but will remain in their original domain. For example, if you misspell **contoso** and you instead specify **/md:contso:fabrikam**, the users will remain in **contoso** on the destination computer.

For example:
`loadstate.exe /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore`
` /progress:prog.log /l:load.log /md:contoso:fabrikam` | +| **/mu**:*OldDomain OldUserName*:[*NewDomain*]*NewUserName*
or
**/mu**:*OldLocalUserName*:*NewDomain NewUserName* | **(Move user)**

Specifies a new user name for the specified user. If the store contains more than one user, you can specify multiple `/mu` options. You can't use wildcard characters with this option.

For example:
`loadstate.exe /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore`
`/progress:prog.log /l:load.log /mu:contoso\user1:fabrikam\user1` | +| **/lac**:[*Password*] | **(Local account create)**

Specifies that if a user account is a local (non-domain) account, and it doesn't exist on the destination computer, USMT will create the account on the destination computer but it will be disabled. To enable the account, you must also use the `/lae` option.

If the `/lac` option isn't specified, any local user accounts that don't already exist on the destination computer won't be migrated.

*Password* is the password for the newly created account. An empty password is used by default.
**Caution**
Use the *Password* variable with caution because it's provided in plain text and can be obtained by anyone with access to the computer that is running the `LoadState.exe` command.
Also, if the computer has multiple users, all migrated users will have the same password.

For example:
`loadstate.exe /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore`

For instructions, see [Migrate user accounts](usmt-migrate-user-accounts.md). | +| `/lae` | **(Local account enable)**

Enables the account that was created with the `/lac` option. You must specify the `/lac` option with this option.

For example:
`loadstate.exe /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore`
`/progress:prog.log /l:load.log /lac:password /lae`

For instructions, see [Migrate user accounts](usmt-migrate-user-accounts.md). | ### Examples for the /ui and /ue options @@ -109,24 +107,24 @@ The following examples apply to both the **/ui** and **/ue** options. You can re | Exclude all local users. | `/ue:%computername%` | | Exclude users in all domains named User1, User2, and so on. | `/ue:\user` | -### Using the Options Together +### Using the options together -You can use the **/uel**, **/ue** and **/ui** options together to migrate only the users that you want migrated. +You can use the `/uel`, `/ue` and `/ui` options together to migrate only the users that you want migrated. -**The /ui option has precedence over the /ue and /uel options.** If a user is specified to be included using the **/ui** option, and also specified to be excluded using either the **/ue** or **/uel** options, the user will be included in the migration. For example, if you specify `/ui:contoso\* /ue:contoso\user1`, then User1 will be migrated, because the **/ui** option takes precedence over the **/ue** option. +**The /ui option has precedence over the /ue and /uel options.** If a user is included using the `/ui` option and also excluded using either the `/ue` or `/uel` options, the user will be included in the migration. For example, if you specify `/ui:contoso\* /ue:contoso\user1`, then User1 will be migrated, because the `/ui` option takes precedence over the `/ue` option. -**The /uel option takes precedence over the /ue option.** If a user has logged on within the specified time period set by the **/uel** option, that user's profile will be migrated even if they are excluded by using the **/ue** option. For example, if you specify `/ue:contoso\user1 /uel:14`, the User1 will be migrated if they have logged on to the computer within the last 14 days. +**The /uel option takes precedence over the /ue option.** If a user has logged on within the specified time period set by the `/uel` option, that user's profile will be migrated even if they're excluded by using the `/ue` option. For example, if you specify `/ue:contoso\user1 /uel:14`, the User1 will be migrated if they've logged on to the computer within the last 14 days. | Behavior | Command | |--- |--- | | Include only User2 from the Fabrikam domain and exclude all other users. | `/ue:* /ui:fabrikam\user2` | | Include only the local user named User1 and exclude all other users. | `/ue:* /ui:user1` | -| 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:
  • Using the **ScanState** command-line tool, type: `/ue:* /ui:contoso`
  • Using the **LoadState** command-line tool, type: `/ue:contoso\user1`
| +| Include only the domain users from Contoso, except Contoso\User1. | This behavior can't be completed using a single command. Instead, to migrate this set of users, you'll need to specify the following options:
  • Using the **ScanState** command-line tool, type: `/ue:* /ui:contoso`
  • Using the **LoadState** command-line tool, type: `/ue:contoso\user1`
| | Include only local (non-domain) users. | `/ue: /ui:%computername%*` | -## Incompatible Command-Line Options +## Incompatible command-line options -The following table indicates which command-line options are not compatible with the **LoadState** command. If the table entry for a particular combination is blank, the options are compatible and you can use them together. The X symbol means that the options are not compatible. For example, you cannot use the **/nocompress** option with the **/encrypt** option. +The following table indicates which command-line options aren't compatible with the `LoadState.exe` command. If the table entry for a particular combination is blank, the options are compatible, and you can use them together. The X symbol means that the options aren't compatible. For example, you can't use the `/nocompress` option with the `/encrypt` option. | Command-Line Option | /keyfile | /nocompress | /genconfig | /all | |--- |--- |--- |--- |--- | @@ -155,8 +153,8 @@ The following table indicates which command-line options are not compatible with | **/lac** | | | | | > [!NOTE] -> You must specify either the **/key** or **/keyfile** option with the **/encrypt** option. +> You must specify either the `/key` or `/keyfile` option with the `/encrypt` option. -## Related topics +## Related articles -[XML Elements Library](usmt-xml-elements-library.md) +[XML elements library](usmt-xml-elements-library.md) diff --git a/windows/deployment/usmt/usmt-log-files.md b/windows/deployment/usmt/usmt-log-files.md index 57563d3932..80d06d0350 100644 --- a/windows/deployment/usmt/usmt-log-files.md +++ b/windows/deployment/usmt/usmt-log-files.md @@ -1,6 +1,6 @@ --- title: Log Files (Windows 10) -description: Learn how to use User State Migration Tool (USMT) 10.0 logs to monitor your migration and to troubleshoot errors and failed migrations. +description: Learn how to use User State Migration Tool (USMT) 10.0 logs to monitor your migration and to troubleshoot errors and failed migrations. ms.reviewer: manager: aaroncz ms.author: frankroj @@ -11,98 +11,98 @@ ms.topic: article ms.technology: itpro-deploy --- -# Log Files +# Log files -You can use User State Migration Tool (USMT) 10.0 logs to monitor your migration and to troubleshoot errors and failed migrations. This topic describes the available command-line options to enable USMT logs, and new XML elements that configure which types of errors are fatal and should halt the migration, which types are non-fatal and should be skipped so that the migration can continue. +You can use User State Migration Tool (USMT) 10.0 logs to monitor your migration and to troubleshoot errors and failed migrations. This article describes the available command-line options to enable USMT logs, and new XML elements that configure which types of errors are fatal and should halt the migration, which types are non-fatal and should be skipped so that the migration can continue. -[Log Command-Line Options](#bkmk-commandlineoptions) +[Log command-line options](#log-command-line-options) -[ScanState and LoadState Logs](#bkmk-scanloadstatelogs) +[ScanState and LoadState logs](#scanstate-and-loadstate-logs) -[Progress Log](#bkmk-progresslog) +[Progress log](#progress-log) -[List Files Log](#bkmk-listfileslog) +[List files log](#list-files-log) -[Diagnostic Log](#bkmk-diagnosticlog) +[Diagnostic log](#diagnostic-log) -## Log Command-Line Options +## Log command-line options The following table describes each command-line option related to logs, and it provides the log name and a description of what type of information each log contains. |Command line Option|File Name|Description| |--- |--- |--- | -|**/l** *[Path]FileName*|Scanstate.log or LoadState.log|Specifies the path and file name of the ScanState.log or LoadState log.| -|**/progress** *[Path]FileName*|Specifies the path and file name of the Progress log.|Provides information about the status of the migration, by percentage complete.| -|**/v** *[VerbosityLevel]*|Not applicable|See the "Monitoring Options" section in [ScanState Syntax](usmt-scanstate-syntax.md).| -|**/listfiles** *[Path]FileName*|Specifies the path and file name of the Listfiles log.|Provides a list of the files that were migrated.| -|Set the environment variable MIG_ENABLE_DIAG to a path to an XML file.|USMTDiag.xml|The diagnostic log contains detailed system environment information, user environment information, and information about the migration units (migunits) being gathered and their contents.| +|**/l**"*[Path]FileName*|`Scanstate.log` or `LoadState.log`|Specifies the path and file name of the **ScanState** log or **LoadState** log.| +|**/progress**:*[Path]FileName*|Specifies the path and file name of the Progress log.|Provides information about the status of the migration, by percentage complete.| +|**/v**:*[VerbosityLevel]*|Not applicable|See [Monitoring options](usmt-scanstate-syntax.md#monitoring-options) in [ScanState syntax](usmt-scanstate-syntax.md).| +|**/listfiles**:*[Path]FileName*|Specifies the path and file name of the Listfiles log.|Provides a list of the files that were migrated.| +|Set the environment variable **MIG_ENABLE_DIAG** to a path to an XML file.|`USMTDiag.xml`|The diagnostic log contains detailed system environment information, user environment information, and information about the migration units (migunits) being gathered and their contents.| > [!NOTE] > You cannot store any of the log files in *StorePath*. If you do, the log will be overwritten when USMT is run. -## ScanState and LoadState Logs +## ScanState and LoadState logs -ScanState and LoadState logs are text files that are create when you run the ScanState and LoadState tools. You can use these logs to help monitor your migration. The content of the log depends on the command-line options that you use and the verbosity level that you specify. For more information about verbosity levels, see Monitoring Options in [ScanState Syntax](usmt-scanstate-syntax.md). + **ScanState** and **LoadState** logs are text files that are create when you run the **ScanState** and **LoadState** tools. You can use these logs to help monitor your migration. The content of the log depends on the command-line options that you use and the verbosity level that you specify. For more information about verbosity levels, see [Monitoring options](usmt-scanstate-syntax.md#monitoring-options) in [ScanState syntax](usmt-scanstate-syntax.md). -## Progress Log +## Progress log -You can create a progress log using the **/progress** option. External tools, such as Microsoft System Center Operations Manager 2007, can parse the progress log to update your monitoring systems. The first three fields in each line are fixed as follows: +You can create a progress log using the `/progress` option. External tools, such as Microsoft System Center Operations Manager, can parse the progress log to update your monitoring systems. The first three fields in each line are fixed as follows: -- **Date:** Date, in the format of *day* *shortNameOfTheMonth* *year*. For example: 08 Jun 2006. +- **Date:** Date, in the format of *day* *shortNameOfTheMonth* *year*. For example: 08 Jun 2006. -- **Local time:** Time, in the format of *hrs*:*minutes*:*seconds* (using a 24-hour clock). For example: 13:49:13. +- **Local time:** Time, in the format of *hrs*:*minutes*:*seconds* (using a 24-hour clock). For example: 13:49:13. -- **Migration time:** Duration of time that USMT was run, in the format of *hrs:minutes:seconds*. For example: 00:00:10. +- **Migration time:** Duration of time that USMT was run, in the format of *hrs:minutes:seconds*. For example: 00:00:10. The remaining fields are key/value pairs as indicated in the following table. | Key | Value | |-----|-------| -| program | ScanState.exe or LoadState.exe. | -| productVersion | The full product version number of USMT. | -| computerName | The name of the source or destination computer on which USMT was run. | -| commandLine | The full command used to run USMT. | -| PHASE | Reports that a new phase in the migration is starting. This can be one of the following:
  • Initializing
  • Scanning
  • Collecting
  • Saving
  • Estimating
  • Applying
| -| detectedUser |
  • For the ScanState tool, these are the users USMT detected on the source computer that can be migrated.
  • For the LoadState tool, these are the users USMT detected in the store that can be migrated.
| -| includedInMigration | Defines whether the user profile/component is included for migration. Valid values are Yes or No. | -| forUser | Specifies either of the following:
  • The user state being migrated.
  • *This Computer*, meaning files and settings that are not associated with a user.
| -| detectedComponent | Specifies a component detected by USMT.
  • For ScanState, this is a component or application that is installed on the source computer.
  • For LoadState, this is a component or application that was detected in the store.
| -| totalSizeInMBToTransfer | Total size of the files and settings to migrate in megabytes (MB). | -| totalPercentageCompleted | Total percentage of the migration that has been completed by either ScanState or LoadState. | -| collectingUser | Specifies which user ScanState is collecting files and settings for. | -| totalMinutesRemaining | Time estimate, in minutes, for the migration to complete. | -| error | Type of non-fatal error that occurred. This can be one of the following:
  • **UnableToCopy**: Unable to copy to store because the disk on which the store is located is full.
  • **UnableToOpen**: Unable to open the file for migration because the file is opened in non-shared mode by another application or service.
  • **UnableToCopyCatalog**: Unable to copy because the store is corrupted.
  • **UnableToAccessDevice**: Unable to access the device.
  • **UnableToApply**: Unable to apply the setting to the destination computer.
| -| objectName | The name of the file or setting that caused the non-fatal error. | -| action | Action taken by USMT for the non-fatal error. The values are:
  • **Ignore**: Non-fatal error ignored and the migration continued because the **/c** option was specified on the command line.
  • **Abort**: Stopped the migration because the **/c** option was not specified.
| -| errorCode | The errorCode or return value. | -| numberOfIgnoredErrors | The total number of non-fatal errors that USMT ignored. | -| message | The message corresponding to the errorCode. | +| **program** | `ScanState.exe` or `LoadState.exe`. | +| **productVersion** | The full product version number of USMT. | +| **computerName** | The name of the source or destination computer on which USMT was run. | +| **commandLine** | The full command used to run USMT. | +| **PHASE** | Reports that a new phase in the migration is starting. This key can be one of the following values:
  • Initializing
  • Scanning
  • Collecting
  • Saving
  • Estimating
  • Applying
| +| **detectedUser** |
  • For the **ScanState** tool, this key are the users USMT detected on the source computer that can be migrated.
  • For the **LoadState** tool, this key are the users USMT detected in the store that can be migrated.
| +| **includedInMigration** | Defines whether the user profile/component is included for migration. Valid values are **Yes** or **No**. | +| **forUser** | Specifies either of the following values:
  • The user state being migrated.
  • *This Computer*, meaning files and settings that aren't associated with a user.
| +| **detectedComponent** | Specifies a component detected by USMT.
  • For **ScanState**, this key is a component or application that is installed on the source computer.
  • For **LoadState**, this key is a component or application that was detected in the store.
| +| **totalSizeInMBToTransfer** | Total size of the files and settings to migrate in megabytes (MB). | +| **totalPercentageCompleted** | Total percentage of the migration that has been completed by either **ScanState** or **LoadState**. | +| **collectingUser** | Specifies which user **ScanState** is collecting files and settings for. | +| **totalMinutesRemaining** | Time estimate, in minutes, for the migration to complete. | +| **error** | Type of non-fatal error that occurred. This key can be one of the following values:
  • **UnableToCopy**: Unable to copy to store because the disk on which the store is located is full.
  • **UnableToOpen**: Unable to open the file for migration because the file is opened in non-shared mode by another application or service.
  • **UnableToCopyCatalog**: Unable to copy because the store is corrupted.
  • **UnableToAccessDevice**: Unable to access the device.
  • **UnableToApply**: Unable to apply the setting to the destination computer.
| +| **objectName** | The name of the file or setting that caused the non-fatal error. | +| **action** | Action taken by USMT for the non-fatal error. The values are:
  • **Ignore**: Non-fatal error ignored and the migration continued because the **/c** option was specified on the command line.
  • **Abort**: Stopped the migration because the **/c** option wasn't specified.
| +| **errorCode** | The errorCode or return value. | +| **numberOfIgnoredErrors** | The total number of non-fatal errors that USMT ignored. | +| **message** | The message corresponding to the errorCode. | -## List Files Log +## List files log -The List files log (Listfiles.txt) provides a list of the files that were migrated. This list can be used to troubleshoot XML issues or can be retained as a record of the files that were gathered into the migration store. The List Files log is only available for ScanState.exe. +The List files log (`Listfiles.txt`) provides a list of the files that were migrated. This list can be used to troubleshoot XML issues or can be retained as a record of the files that were gathered into the migration store. The List Files log is only available for `ScanState.exe`. -## Diagnostic Log +## Diagnostic log -You can obtain the diagnostic log by setting the environment variable MIG\_ENABLE\_DIAG to a path to an XML file. +You can obtain the diagnostic log by setting the environment variable **MIG_ENABLE_DIAG** to a path to an XML file. The diagnostic log contains: -- Detailed system environment information +- Detailed system environment information -- Detailed user environment information +- Detailed user environment information -- Information about the migration units (migunits) being gathered and their contents +- Information about the migration units (migunits) being gathered and their contents ## Using the Diagnostic Log -The diagnostic log is essentially a report of all the migration units (migunits) included in the migration. A migunit is a collection of data that is identified by the component it is associated with in the XML files. The migration store is made up of all the migunits in the migration. The diagnostic log can be used to verify which migunits were included in the migration and can be used for troubleshooting while authoring migration XML files. +The diagnostic log is essentially a report of all the migration units (migunits) included in the migration. A migunit is a collection of data that is identified by the component it's associated with in the XML files. The migration store is made up of all the migunits in the migration. The diagnostic log can be used to verify which migunits were included in the migration and can be used for troubleshooting while authoring migration XML files. The following examples describe common scenarios in which you can use the diagnostic log. **Why is this file not migrating when I authored an "include" rule for it?** -Let's imagine that we have the following directory structure and that we want the "data" directory to be included in the migration along with the "New Text Document.txt" file in the "New Folder." The directory of **C:\\data** contains: +Let's imagine that we have the following directory structure and that we want the **data** directory to be included in the migration along with the **New Text Document.txt** file in the **New Folder**. The directory of `C:\data` contains: ```console 01/21/2009 10:08 PM . @@ -113,7 +113,7 @@ Let's imagine that we have the following directory structure and that we want th 2 File(s) 26 bytes ``` -The directory of **C:\\data\\New Folder** contains: +The directory of `C:\data\New Folder` contains: ```console 01/21/2009 10:08 PM . @@ -144,59 +144,59 @@ To migrate these files you author the following migration XML: ``` -However, upon testing the migration you notice that the "New Text Document.txt" file isn't included in the migration. To troubleshoot this failure, the migration can be repeated with the environment variable MIG\_ENABLE\_DIAG set such that the diagnostic log is generated. Upon searching the diagnostic log for the component "DATA1", the following XML section is discovered: +However, upon testing the migration you notice that the **New Text Document.txt** file isn't included in the migration. To troubleshoot this failure, the migration can be repeated with the environment variable **MIG_ENABLE_DIAG** set such that the diagnostic log is generated. Upon searching the diagnostic log for the component **DATA1**, the following XML section is discovered: ```xml - - - - - + + + + + - - - - - + + + + + ``` -Analysis of this XML section reveals the migunit that was created when the migration rule was processed. The <Perform> section details the actual files that were scheduled for gathering and the result of the gathering operation. The "New Text Document.txt" file doesn't appear in this section, which confirms that the migration rule was not correctly authored. +Analysis of this XML section reveals the migunit that was created when the migration rule was processed. The **<Perform>** section details the actual files that were scheduled for gathering and the result of the gathering operation. The **New Text Document.txt** file doesn't appear in this section, which confirms that the migration rule wasn't correctly authored. -An analysis of the XML elements reference topic reveals that the <pattern> tag needs to be modified as follows: +An analysis of the [XML elements library](usmt-xml-elements-library.md) reference article reveals that the [**<pattern>**](usmt-xml-elements-library.md#pattern) tag needs to be modified as follows: ```xml c:\data\* [*] ``` -When the migration is preformed again with the modified tag, the diagnostic log reveals the following: +When the migration is performed again with the modified tag, the diagnostic log reveals the following information: ```xml - - - - - + + + + + - - - - - - - + + + + + + + ``` -This diagnostic log confirms that the modified <pattern> value enables the migration of the file. +This diagnostic log confirms that the modified **<pattern>** value enables the migration of the file. **Why is this file migrating when I authored an exclude rule excluding it?** -In this scenario, you have the following directory structure and you want all files in the "data" directory to migrate, except for text files. The **C:\\Data** folder contains: +In this scenario, you have the following directory structure and you want all files in the **Data** directory to migrate, except for text files. The `C:\Data` folder contains: ```console Directory of C:\Data @@ -209,7 +209,7 @@ Directory of C:\Data 2 File(s) 26 bytes ``` -The **C:\\Data\\New Folder\\** contains: +The `C:\Data\New Folder\` contains: ```console 01/21/2009 10:08 PM . @@ -246,33 +246,33 @@ You author the following migration XML: ``` -However, upon testing the migration you notice that all the text files are still included in the migration. In order to troubleshoot this issue, the migration can be performed with the environment variable MIG\_ENABLE\_DIAG set so that the diagnostic log is generated. Upon searching the diagnostic log for the component "DATA1", the following XML section is discovered: +However, upon testing the migration you notice that all the text files are still included in the migration. In order to troubleshoot this issue, the migration can be performed with the environment variable **MIG_ENABLE_DIAG** set so that the diagnostic log is generated. Upon searching the diagnostic log for the component **DATA1**, the following XML section is discovered: ```xml - - - - - - - - + + + + + + + + - - - - - - - - - + + + + + + + + + ``` -Upon reviewing the diagnostic log, you confirm that the files are still migrating, and that it is a problem with the authored migration XML rule. You author an update to the migration XML script as follows: +Upon reviewing the diagnostic log, you confirm that the files are still migrating, and that it's a problem with the authored migration XML rule. You author an update to the migration XML script as follows: ```xml @@ -307,31 +307,30 @@ Your revised migration XML script excludes the files from migrating, as confirme ```xml - - - - - - - - + + + + + + + + - - - - - - + + + + + + ``` -## Related topics +## Related articles +[XML elements library](usmt-xml-elements-library.md) -[XML Elements Library](usmt-xml-elements-library.md) +[ScanState syntax](usmt-scanstate-syntax.md) -[ScanState Syntax](usmt-scanstate-syntax.md) - -[LoadState Syntax](usmt-loadstate-syntax.md) +[LoadState syntax](usmt-loadstate-syntax.md) diff --git a/windows/deployment/usmt/usmt-migrate-efs-files-and-certificates.md b/windows/deployment/usmt/usmt-migrate-efs-files-and-certificates.md index d69ef98d2d..bad81e8a92 100644 --- a/windows/deployment/usmt/usmt-migrate-efs-files-and-certificates.md +++ b/windows/deployment/usmt/usmt-migrate-efs-files-and-certificates.md @@ -11,43 +11,37 @@ ms.topic: article ms.technology: itpro-deploy --- -# Migrate EFS Files and Certificates +# Migrate EFS files and certificates +This article describes how to migrate Encrypting File System (EFS) certificates. For more information about the `/efs` option, see [Encrypted file options](#encrypted-file-options) in [ScanState syntax](usmt-scanstate-syntax.md). -This topic describes how to migrate Encrypting File System (EFS) certificates. For more information about the **/efs** For options, see [ScanState Syntax](usmt-scanstate-syntax.md). +## To migrate EFS files and certificates -## To Migrate EFS Files and Certificates +Encrypting File System (EFS) certificates will be migrated automatically. However, by default, the User State Migration Tool (USMT) 10.0 fails if an encrypted file is found unless you specify an `/efs` option. Therefore when a device has EFS encrypted files, you must specify the `/efs` option with any one of the following parameters: +- `abort` +- `skip` +- `decryptcopy` +- `copyraw` +- `hardlink` -Encrypting File System (EFS) certificates will be migrated automatically. However, by default, the User State Migration Tool (USMT) 10.0 fails if an encrypted file is found (unless you specify an **/efs** option). Therefore, you must specify **/efs:abort | skip | decryptcopy | copyraw | hardlink** with the ScanState command to migrate the encrypted files. Then, when you run the LoadState command on the destination computer, the encrypted file and the EFS certificate will be automatically migrated. +when running the `ScanState.exe` command to migrate the encrypted files. Then, when you run the `LoadState.exe` command on the destination computer, the encrypted file and the EFS certificate will be automatically migrated. -**Note**   -The **/efs** options are not used with the LoadState command. +> [!NOTE] +> The `/efs` options are not used with the `LoadState.exe` command. - +Before using the **ScanState** tool for a migration that includes encrypted files and EFS certificates, you must ensure that all files in an encrypted folder are encrypted as well or remove the encryption attribute from folders that contain unencrypted files. If the encryption attribute has been removed from a file but not from the parent folder, the file will be encrypted during the migration using the credentials of the account used to run the **LoadState** tool. -Before using the ScanState tool for a migration that includes encrypted files and EFS certificates, you must ensure that all files in an encrypted folder are encrypted as well or remove the encryption attribute from folders that contain unencrypted files. If the encryption attribute has been removed from a file but not from the parent folder, the file will be encrypted during the migration using the credentials of the account used to run the LoadState tool. - -You can run the Cipher tool at a Windows command prompt to review and change encryption settings on files and folders. For example, to remove encryption from a folder, at a command prompt type: +You can run the [Cipher.exe](/windows-server/administration/windows-commands/cipher) tool at a Windows command prompt to review and change encryption settings on files and folders. For example, to remove encryption from a folder, at a command prompt type: ``` syntax -Cipher /D /S: +Cipher.exe /D /S: ``` -Where *<Path>* is the full path of the topmost parent directory where the encryption attribute is set. - -## Related topics - - -[What Does USMT Migrate?](usmt-what-does-usmt-migrate.md) - -[Identify File Types, Files, and Folders](usmt-identify-file-types-files-and-folders.md) - - - - - - +where *<Path>* is the full path of the topmost parent directory where the encryption attribute is set. +## Related articles +[What does USMT migrate?](usmt-what-does-usmt-migrate.md) +[Identify file types, files, and folders](usmt-identify-file-types-files-and-folders.md) diff --git a/windows/deployment/usmt/usmt-migrate-user-accounts.md b/windows/deployment/usmt/usmt-migrate-user-accounts.md index ad49e90fc3..ebb8f677d1 100644 --- a/windows/deployment/usmt/usmt-migrate-user-accounts.md +++ b/windows/deployment/usmt/usmt-migrate-user-accounts.md @@ -13,82 +13,69 @@ ms.technology: itpro-deploy # Migrate User Accounts +By default, all users are migrated. The only way to specify which users to include and exclude is on the command line by using the User options. You can't specify users in the migration XML files or by using the Config.xml file. -By default, all users are migrated. The only way to specify which users to include and exclude is on the command line by using the User options. You cannot specify users in the migration XML files or by using the Config.xml file. +## To migrate all user accounts and user settings -## In this Topic +Links to detailed explanations of commands are available in the [Related articles](#related-articles) section. +1. Sign into the source computer as an administrator. -- [To migrate all user accounts and user settings](#bkmk-migrateall) +2. Enter the following `scanstate.exe` command line in a command prompt window: -- [To migrate two domain accounts (User1 and User2)](#bkmk-migratetwo) + `scanstate.exe \\server\share\migration\mystore /i:migdocs.xml /i:migapp.xml /o` -- [To migrate two domain accounts (User1 and User2) and move User1 from the Contoso domain to the Fabrikam domain](#bkmk-migratemoveuserone) +3. Sign into the destination computer as an administrator. -## To migrate all user accounts and user settings -Links to detailed explanations of commands are available in the Related Topics section. +4. Enter one of the following `loadstate.exe` command lines in a command prompt window: -1. Log on to the source computer as an administrator, and specify the following in a **Command-Prompt** window: + - If you're migrating domain accounts, Enter: - `scanstate \\server\share\migration\mystore /i:migdocs.xml /i:migapp.xml /o` + `loadstate.exe \\server\share\migration\mystore /i:migdocs.xml /i:migapp.xml` -2. Log on to the destination computer as an administrator. + - If you're migrating local accounts along with domain accounts, Enter: -3. Do one of the following: + `loadstate.exe \\server\share\migration\mystore /i:migdocs.xml /i:migapp.xml /lac /lae` - - If you are migrating domain accounts, specify: + > [!NOTE] + > You do not have to specify the `/lae` option, which enables the account that was created with the `/lac` option. Instead, you can create a disabled local account by specifying only the `/lac` option, and then a local administrator needs to enable the account on the destination computer. - `loadstate \\server\share\migration\mystore /i:migdocs.xml /i:migapp.xml` +## To migrate two domain accounts (User1 and User2) - - If you are migrating local accounts along with domain accounts, specify: +Links to detailed explanations of commands are available in the [Related articles](#related-articles) section. - `loadstate \\server\share\migration\mystore /i:migdocs.xml /i:migapp.xml /lac /lae` +1. Sign into the source computer as an administrator. - **Note**   - You do not have to specify the **/lae** option, which enables the account that was created with the **/lac** option. Instead, you can create a disabled local account by specifying only the **/lac** option, and then a local administrator needs to enable the account on the destination computer. +2. Enter the following `scanstate.exe` command line in a command prompt window: - + `scanstate.exe \\server\share\migration\mystore /ue:*\* /ui:contoso\user1 /ui:fabrikam\user2 /i:migdocs.xml /i:migapp.xml /o` -## To migrate two domain accounts (User1 and User2) -Links to detailed explanations of commands are available in the Related Topics section. +3. Sign into the destination computer as an administrator. -1. Log on to the source computer as an administrator, and specify: +4. Enter the following `loadstate.exe` command line in a command prompt window: - `scanstate \\server\share\migration\mystore /ue:*\* /ui:contoso\user1 /ui:fabrikam\user2 /i:migdocs.xml /i:migapp.xml /o` + `loadstate.exe \\server\share\migration\mystore /i:migdocs.xml /i:migapp.xml` -2. Log on to the destination computer as an administrator. +## To migrate two domain accounts (User1 and User2) and move User1 from the Contoso domain to the Fabrikam domain -3. Specify the following: +Links to detailed explanations of commands are available in the [Related articles](#related-articles) section. - `loadstate \\server\share\migration\mystore /i:migdocs.xml /i:migapp.xml` +1. Sign into the source computer as an administrator. -## To migrate two domain accounts (User1 and User2) and move User1 from the Contoso domain to the Fabrikam domain -Links to detailed explanations of commands are available in the Related Topics section. +2. Enter the following `scanstate.exe` command line in a command prompt window: -1. Log on to the source computer as an administrator, and type the following at the command-line prompt: + `scanstate.exe \\server\share\migration\mystore /ue:*\* /ui:contoso\user1 /ui:contoso\user2 /i:migdocs.xml /i:migapp.xml /o` - `scanstate \\server\share\migration\mystore /ue:*\* /ui:contoso\user1 /ui:contoso\user2 /i:migdocs.xml /i:migapp.xml /o` +3. Sign into the destination computer as an administrator. -2. Log on to the destination computer as an administrator. - -3. Specify the following: - - `loadstate \\server\share\migration\mystore /mu:contoso\user1:fabrikam\user2 /i:migdocs.xml /i:migapp.xml` - -## Related topics - - -[Identify Users](usmt-identify-users.md) - -[ScanState Syntax](usmt-scanstate-syntax.md) - -[LoadState Syntax](usmt-loadstate-syntax.md) - - - - +4. Enter the following `loadstate.exe` command line in a command prompt window: + `loadstate.exe \\server\share\migration\mystore /mu:contoso\user1:fabrikam\user2 /i:migdocs.xml /i:migapp.xml` +## Related articles +[Identify users](usmt-identify-users.md) +[ScanState syntax](usmt-scanstate-syntax.md) +[LoadState syntax](usmt-loadstate-syntax.md) diff --git a/windows/deployment/usmt/usmt-migration-store-encryption.md b/windows/deployment/usmt/usmt-migration-store-encryption.md index c0a58da681..bdbed437a0 100644 --- a/windows/deployment/usmt/usmt-migration-store-encryption.md +++ b/windows/deployment/usmt/usmt-migration-store-encryption.md @@ -1,6 +1,6 @@ --- title: Migration Store Encryption (Windows 10) -description: Learn how the User State Migration Tool (USMT) enables support for stronger encryption algorithms, called Advanced Encryption Standard (AES). +description: Learn how the User State Migration Tool (USMT) enables support for stronger encryption algorithms, called Advanced Encryption Standard (AES). ms.reviewer: manager: aaroncz ms.author: frankroj @@ -11,26 +11,26 @@ ms.topic: article ms.technology: itpro-deploy --- -# Migration Store Encryption +# Migration store encryption -This topic discusses User State Migration Tool (USMT) 10.0 options for migration store encryption to protect the integrity of user data during a migration. +This article discusses User State Migration Tool (USMT) 10.0 options for migration store encryption to protect the integrity of user data during a migration. -## USMT Encryption Options +## USMT encryption options USMT enables support for stronger encryption algorithms, called Advanced Encryption Standard (AES), in several bit-level options. AES is a National Institute of Standards and Technology (NIST) specification for the encryption of electronic data. -The encryption algorithm you choose must be specified for both the **ScanState** and the **LoadState** commands, so that these commands can create or read the store during encryption and decryption. The new encryption algorithms can be specified on the **ScanState** and the **LoadState** command lines by using the **/encrypt**:*"encryptionstrength"* and the **/decrypt**:*"encryptionstrength"* command-line options. All of the encryption application programming interfaces (APIs) used by USMT are available in Windows 7, Windows 8, and Windows 10 operating systems. However, export restrictions might limit the set of algorithms that are available to computers in certain locales. You can use the Usmtutils.exe file to determine which encryption algorithms are available to the computers' locales before you begin the migration. +The encryption algorithm you choose must be specified for both the `ScanState.exe` and the `LoadState.exe` commands, so that these commands can create or read the store during encryption and decryption. The new encryption algorithms can be specified on the `ScanState.exe` and the `LoadState.exe` command lines by using the `/encrypt`:*encryptionstrength* and the `/decrypt`:*encryptionstrength* command-line options. All of the encryption application programming interfaces (APIs) used by USMT are available in Windows 7, Windows 8, and Windows 10 operating systems. However, export restrictions might limit the set of algorithms that are available to computers in certain locales. You can use the `Usmtutils.exe` file to determine which encryption algorithms are available to the computers' locales before you begin the migration. The following table describes the command-line encryption options in USMT. |Component|Option|Description| |--- |--- |--- | -|**ScanState**|**/encrypt**<*AES, AES_128, AES_192, AES_256, 3DES, 3DES_112*>|This option and argument specify that the migration store is encrypted and which algorithm to use. When the algorithm argument is not provided, the **ScanState** tool employs the 3DES algorithm.| -|**LoadState**|**/decrypt**<*AES, AES_128, AES_192, AES_256, 3DES, 3DES_112*>|This option and argument specify that the store must be decrypted and which algorithm to use. When the algorithm argument is not provided, the **LoadState** tool employs the 3DES algorithm.| +|**ScanState**|**/encrypt**<*AES, AES_128, AES_192, AES_256, 3DES, 3DES_112*>|This option and argument specify that the migration store is encrypted and which algorithm to use. When the algorithm argument isn't provided, the **ScanState** tool employs the **3DES** algorithm.| +|**LoadState**|**/decrypt**<*AES, AES_128, AES_192, AES_256, 3DES, 3DES_112*>|This option and argument specify that the store must be decrypted and which algorithm to use. When the algorithm argument isn't provided, the **LoadState** tool employs the **3DES** algorithm.| -**Important**   -Some encryption algorithms may not be available on your systems. You can verify which algorithms are available by running the UsmtUtils command with the **/ec** option. For more information see [UsmtUtils Syntax](usmt-utilities.md) +> [!IMPORTANT] +> Some encryption algorithms may not be available on your systems. You can verify which algorithms are available by running the `UsmtUtils.exe` command with the `/ec` option. For more information, see [UsmtUtils syntax](usmt-utilities.md). -## Related topics +## Related articles -[Plan Your Migration](usmt-plan-your-migration.md) +[Plan your migration](usmt-plan-your-migration.md) diff --git a/windows/deployment/usmt/usmt-overview.md b/windows/deployment/usmt/usmt-overview.md index 3bb7d204bb..7609e4e147 100644 --- a/windows/deployment/usmt/usmt-overview.md +++ b/windows/deployment/usmt/usmt-overview.md @@ -11,36 +11,36 @@ ms.collection: highpri ms.technology: itpro-deploy --- -# User State Migration Tool (USMT) Overview +# User State Migration Tool (USMT) overview -You can use User State Migration Tool (USMT) 10.0 to streamline and simplify user state migration during large deployments of Windows operating systems. USMT captures user accounts, user files, operating system settings, and application settings, and then migrates them to a new Windows installation. You can use USMT for both PC replacement and PC refresh migrations. For more information, see [Common Migration Scenarios](usmt-common-migration-scenarios.md). +You can use User State Migration Tool (USMT) 10.0 to streamline and simplify user state migration during large deployments of Windows operating systems. USMT captures user accounts, user files, operating system settings, and application settings, and then migrates them to a new Windows installation. You can use USMT for both PC replacement and PC refresh migrations. For more information, see [Common migration scenarios](usmt-common-migration-scenarios.md). -USMT enables you to do the following: +USMT enables you to do the following actions: -- Configure your migration according to your business needs by using the migration rule (.xml) files to control exactly which files and settings are migrated and how they are migrated. For more information about how to modify these files, see [USMT XML Reference](usmt-xml-reference.md). -- Fit your customized migration into your automated deployment process by using the ScanState and LoadState tools, which control collecting and restoring the user files and settings. For more information, see [User State Migration Tool (USMT) Command-line Syntax](usmt-command-line-syntax.md). -- Perform offline migrations. You can run migrations offline by using the ScanState command in Windows Preinstallation Environment (WinPE) or you can perform migrations from previous installations of Windows contained in Windows.old directories. For more information about migration types, see [Choose a Migration Store Type](usmt-choose-migration-store-type.md) and [Offline Migration Reference](offline-migration-reference.md). +- Configure your migration according to your business needs by using the migration rule (.xml) files to control exactly which files and settings are migrated and how they're migrated. For more information about how to modify these files, see [USMT XML reference](usmt-xml-reference.md). +- Fit your customized migration into your automated deployment process by using the **ScanState** and **LoadState** tools, which control collecting and restoring the user files and settings. For more information, see [User State Migration Tool (USMT) command-line syntax](usmt-command-line-syntax.md). +- Perform offline migrations. You can run migrations offline by using the ScanState command in Windows Preinstallation Environment (WinPE) or you can perform migrations from previous installations of Windows contained in Windows.old directories. For more information about migration types, see [Choose a migration store Type](usmt-choose-migration-store-type.md) and [Offline migration reference](offline-migration-reference.md). ## Benefits USMT provides the following benefits to businesses that are deploying Windows operating systems: -- Safely migrates user accounts, operating system and application settings. -- Lowers the cost of deploying Windows by preserving user state. -- Reduces end-user downtime required to customize desktops and find missing files. -- Reduces help-desk calls. -- Reduces the time needed for the user to become familiar with the new operating system. -- Increases employee satisfaction with the migration experience. +- Safely migrates user accounts, operating system and application settings. +- Lowers the cost of deploying Windows by preserving user state. +- Reduces end-user downtime required to customize desktops and find missing files. +- Reduces help-desk calls. +- Reduces the time needed for the user to become familiar with the new operating system. +- Increases employee satisfaction with the migration experience. ## Limitations -USMT is intended for administrators who are performing large-scale automated deployments. If you are only migrating the user states of a few computers, you can use [PCmover Express](https://go.microsoft.com/fwlink/?linkid=620915). PCmover is not a free utility. PCmover Express is a tool created by Microsoft's partner, Laplink. +USMT is intended for administrators who are performing large-scale automated deployments. If you're only migrating the user states of a few computers, you can use [PCmover Express](https://go.microsoft.com/fwlink/?linkid=620915). PCmover isn't a free utility. PCmover Express is a tool created by Microsoft's partner, Laplink. -There are some scenarios in which the use of USMT is not recommended. These include: +There are some scenarios in which the use of USMT isn't recommended. These scenarios include: -- Migrations that require end-user interaction. -- Migrations that require customization on a machine-by-machine basis. +- Migrations that require end-user interaction. +- Migrations that require customization on a machine-by-machine basis. -## Related topics +## Related articles -- [User State Migration Tool (USMT) Technical Reference](usmt-technical-reference.md) +- [User State Migration Tool (USMT) technical reference](usmt-technical-reference.md) diff --git a/windows/deployment/usmt/usmt-plan-your-migration.md b/windows/deployment/usmt/usmt-plan-your-migration.md index 0a19f947c6..6559990881 100644 --- a/windows/deployment/usmt/usmt-plan-your-migration.md +++ b/windows/deployment/usmt/usmt-plan-your-migration.md @@ -11,24 +11,24 @@ ms.topic: article ms.technology: itpro-deploy --- -# Plan Your Migration +# Plan your migration -Before you use the User State Migration Tool (USMT) 10.0 to perform your migration, we recommend that you plan your migration carefully. Planning can help your migration proceed smoothly and can reduce the risk of migration failure. +Before you use the User State Migration Tool (USMT) 10.0 to perform your migration, we recommend that you plan your migration carefully. Planning can help your migration proceed smoothly and can reduce the risk of migration failure. In migration planning, both organizations and individuals must first identify what to migrate, including user settings, applications and application settings, and personal data files and folders. Identifying the applications to migrate is especially important so that you can avoid capturing data about applications that may be phased out. -One of the most important requirements for migrating settings and data is restoring only the information that the destination computer requires. Although the data that you capture on the source computer may be more comprehensive than the restoration data for backup purposes, restoring data or settings for applications that you will not install on the destination system is redundant. This can also introduce instability in a newly deployed computer. +One of the most important requirements for migrating settings and data is restoring only the information that the destination computer requires. Although the data that you capture on the source computer may be more comprehensive than the restoration data for backup purposes, restoring data or settings for applications that you won't install on the destination system is redundant. Restoring data or settings for applications that aren't installed can also introduce instability in a newly deployed computer. -## In This Section +## In this section | Link | Description | |--- |--- | -|[Common Migration Scenarios](usmt-common-migration-scenarios.md)|Determine whether you will perform a refresh migration or a replace migration.| -|[What Does USMT Migrate?](usmt-what-does-usmt-migrate.md)|Learn which applications, user data, and operating system components USMT migrates.| -|[Choose a Migration Store Type](usmt-choose-migration-store-type.md)|Choose an uncompressed, compressed, or hard-link migration store.| -|[Determine What to Migrate](usmt-determine-what-to-migrate.md)|Identify user accounts, application settings, operating system settings, and files that you want to migrate inside your organization.| -|[Test Your Migration](usmt-test-your-migration.md)|Test your migration before you deploy Windows to all users.| +|[Common migration scenarios](usmt-common-migration-scenarios.md)|Determine whether you'll perform a refresh migration or a replace migration.| +|[What does USMT migrate?](usmt-what-does-usmt-migrate.md)|Learn which applications, user data, and operating system components USMT migrates.| +|[Choose a migration store type](usmt-choose-migration-store-type.md)|Choose an uncompressed, compressed, or hard-link migration store.| +|[Determine what to migrate](usmt-determine-what-to-migrate.md)|Identify user accounts, application settings, operating system settings, and files that you want to migrate inside your organization.| +|[Test your migration](usmt-test-your-migration.md)|Test your migration before you deploy Windows to all users.| -## Related topics +## Related articles -[USMT XML Reference](usmt-xml-reference.md) +[USMT XML reference](usmt-xml-reference.md) diff --git a/windows/deployment/usmt/usmt-recognized-environment-variables.md b/windows/deployment/usmt/usmt-recognized-environment-variables.md index 9f2b03a289..000f67af87 100644 --- a/windows/deployment/usmt/usmt-recognized-environment-variables.md +++ b/windows/deployment/usmt/usmt-recognized-environment-variables.md @@ -11,84 +11,75 @@ ms.collection: highpri ms.technology: itpro-deploy --- -# Recognized Environment Variables +# Recognized environment variables +When using the XML files `MigDocs.xml`, `MigApp.xml`, and `MigUser.xml`, you can use environment variables to identify folders that may be different on different computers. Constant special item ID list (CSIDL) values provide a way to identify folders that applications use frequently but may not have the same name or location on any given computer. For example, the **Documents** folder may be `C:\Users\\My Documents` on one computer and `C:\Documents and Settings\\My Documents` on another. You can use the asterisk (\*) wildcard character in `MigUser.xml`, `MigApp.xml` and `MigDoc.xml` files. However, you can't use the asterisk (\*) wildcard characters in the `Config.xml` file. -When using the XML files MigDocs.xml, MigApp.xml, and MigUser.xml, you can use environment variables to identify folders that may be different on different computers. Constant special item ID list (CSIDL) values provide a way to identify folders that applications use frequently but may not have the same name or location on any given computer. For example, the documents folder may be C:\\Users\\<Username>\\My Documents on one computer and C:\\Documents and Settings on another. You can use the asterisk (\*) wildcard character in MigUser.xml, MigApp.xml and MigDoc.xml files. However, you cannot use the asterisk (\*) wildcard characters in the Config.xml file. - -## In This Topic - - -- [Variables that are processed for the operating system and in the context of each user](#bkmk-1) - -- [Variables that are recognized only in the user context](#bkmk-2) - -## Variables that are processed for the operating system and in the context of each user - +## Variables that are processed for the operating system and in the context of each user You can use these variables within sections in the .xml files with `context=UserAndSystem`, `context=User`, and `context=System`. |Variable|Explanation| |--- |--- | |**ALLUSERSAPPDATA**|Same as **CSIDL_COMMON_APPDATA**.| -|**ALLUSERSPROFILE**|Refers to %**PROFILESFOLDER**%\Public or %**PROFILESFOLDER**%\all users.| +|**ALLUSERSPROFILE**|Refers to `%PROFILESFOLDER%\Public` or `%PROFILESFOLDER%\all users`.| |**COMMONPROGRAMFILES**|Same as **CSIDL_PROGRAM_FILES_COMMON**.| -|**COMMONPROGRAMFILES**(X86)|Refers to the C:\Program Files (x86)\Common Files folder on 64-bit systems.| -|**CSIDL_COMMON_ADMINTOOLS**|Version 10.0. The file-system directory that contains administrative tools for all users of the computer.| +|**COMMONPROGRAMFILES**(X86)|Refers to the `C:\Program Files (x86)\Common Files` folder on 64-bit systems.| +|**CSIDL_COMMON_ADMINTOOLS**|Version 10.0. The file-system directory that contains administrative tools for all users of the computer.| |**CSIDL_COMMON_ALTSTARTUP**|The file-system directory that corresponds to the non-localized Startup program group for all users.| -|**CSIDL_COMMON_APPDATA**|The file-system directory that contains application data for all users. A typical path Windows is C:\ProgramData.| -|**CSIDL_COMMON_DESKTOPDIRECTORY**|The file-system directory that contains files and folders that appear on the desktop for all users. A typical Windows® XP path is C:\Documents and Settings\All Users\Desktop. A typical path is C:\Users\Public\Desktop.| -|**CSIDL_COMMON_DOCUMENTS**|The file-system directory that contains documents that are common to all users. A typical path in Windows XP is C:\Documents and Settings\All Users\Documents. A typical path is C:\Users\Public\Documents.| -|**CSIDL_COMMON_FAVORITES**|The file-system directory that serves as a common repository for favorites common to all users. A typical path is C:\Users\Public\Favorites.| -|**CSIDL_COMMON_MUSIC**|The file-system directory that serves as a repository for music files common to all users. A typical path is C:\Users\Public\Music.| -|**CSIDL_COMMON_PICTURES**|The file-system directory that serves as a repository for image files common to all users. A typical path is C:\Users\Public\Pictures.| -|**CSIDL_COMMON_PROGRAMS**|The file-system directory that contains the directories for the common program groups that appear on the **Start** menu for all users. A typical path is C:\ProgramData\Microsoft\Windows\Start Menu\Programs.| -|**CSIDL_COMMON_STARTMENU**|The file-system directory that contains the programs and folders which appear on the **Start** menu for all users. A typical path in Windows is C:\ProgramData\Microsoft\Windows\Start Menu.| -|**CSIDL_COMMON_STARTUP**|The file-system directory that contains the programs that appear in the Startup folder for all users. A typical path in Windows XP is C:\Documents and Settings\All Users\Start Menu\Programs\Startup. A typical path is C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup.| -|**CSIDL_COMMON_TEMPLATES**|The file-system directory that contains the templates that are available to all users. A typical path is C:\ProgramData\Microsoft\Windows\Templates.| -|**CSIDL_COMMON_VIDEO**|The file-system directory that serves as a repository for video files common to all users. A typical path is C:\Users\Public\Videos.| -|**CSIDL_DEFAULT_APPDATA**|Refers to the Appdata folder inside %**DEFAULTUSERPROFILE**%.| -|C**SIDL_DEFAULT_LOCAL_APPDATA**|Refers to the local Appdata folder inside %**DEFAULTUSERPROFILE**%.| -|**CSIDL_DEFAULT_COOKIES**|Refers to the Cookies folder inside %**DEFAULTUSERPROFILE**%.| -|**CSIDL_DEFAULT_CONTACTS**|Refers to the Contacts folder inside %**DEFAULTUSERPROFILE**%.| -|**CSIDL_DEFAULT_DESKTOP**|Refers to the Desktop folder inside %**DEFAULTUSERPROFILE**%.| -|**CSIDL_DEFAULT_DOWNLOADS**|Refers to the Downloads folder inside %**DEFAULTUSERPROFILE**%.| -|**CSIDL_DEFAULT_FAVORITES**|Refers to the Favorites folder inside %**DEFAULTUSERPROFILE**%.| -|**CSIDL_DEFAULT_HISTORY**|Refers to the History folder inside %**DEFAULTUSERPROFILE**%.| -|**CSIDL_DEFAULT_INTERNET_CACHE**|Refers to the Internet Cache folder inside %**DEFAULTUSERPROFILE**%.| -|**CSIDL_DEFAULT_PERSONAL**|Refers to the Personal folder inside %**DEFAULTUSERPROFILE**%.| -|**CSIDL_DEFAULT_MYDOCUMENTS**|Refers to the My Documents folder inside %**DEFAULTUSERPROFILE**%.| -|**CSIDL_DEFAULT_MYPICTURES**|Refers to the My Pictures folder inside %**DEFAULTUSERPROFILE**%.| -|**CSIDL_DEFAULT_MYMUSIC**|Refers to the My Music folder inside %**DEFAULTUSERPROFILE**%.| -|**CSIDL_DEFAULT_MYVIDEO**|Refers to the My Videos folder inside %**DEFAULTUSERPROFILE**%.| -|**CSIDL_DEFAULT_RECENT**|Refers to the Recent folder inside %**DEFAULTUSERPROFILE**%.| -|**CSIDL_DEFAULT_SENDTO**|Refers to the Send To folder inside %**DEFAULTUSERPROFILE**%.| -|**CSIDL_DEFAULT_STARTMENU**|Refers to the Start Menu folder inside %**DEFAULTUSERPROFILE**%.| -|**CSIDL_DEFAULT_PROGRAMS**|Refers to the Programs folder inside %**DEFAULTUSERPROFILE**%.| -|**CSIDL_DEFAULT_STARTUP**|Refers to the Startup folder inside %**DEFAULTUSERPROFILE**%.| -|**CSIDL_DEFAULT_TEMPLATES**|Refers to the Templates folder inside %**DEFAULTUSERPROFILE**%.| -|**CSIDL_DEFAULT_QUICKLAUNCH**|Refers to the Quick Launch folder inside %**DEFAULTUSERPROFILE**%.| -|**CSIDL_FONTS**|A virtual folder containing fonts. A typical path is C:\Windows\Fonts.| -|**CSIDL_PROGRAM_FILESX86**|The Program Files folder on 64-bit systems. A typical path is C:\Program Files(86).| -|**CSIDL_PROGRAM_FILES_COMMONX86**|A folder for components that are shared across applications on 64-bit systems. A typical path is C:\Program Files(86)\Common.| -|**CSIDL_PROGRAM_FILES**|The Program Files folder. A typical path is C:\Program Files.| -|**CSIDL_PROGRAM_FILES_COMMON**|A folder for components that are shared across applications. A typical path is C:\Program Files\Common.| -|**CSIDL_RESOURCES**|The file-system directory that contains resource data. A typical path is C:\Windows\Resources.| -|**CSIDL_SYSTEM**|The Windows System folder. A typical path is C:\Windows\System32.| -|**CSIDL_WINDOWS**|The Windows directory or system root. This corresponds to the %**WINDIR**% or %**SYSTEMROOT**% environment variables. A typical path is C:\Windows.| -|**DEFAULTUSERPROFILE**|Refers to the value in **HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList [DefaultUserProfile]**.| -|**PROFILESFOLDER**|Refers to the value in **HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList [ProfilesDirectory]**.| +|**CSIDL_COMMON_APPDATA**|The file-system directory that contains application data for all users. A typical path Windows is `C:\ProgramData`.| +|**CSIDL_COMMON_DESKTOPDIRECTORY**|The file-system directory that contains files and folders that appear on the desktop for all users. A typical path is `C:\Users\Public\Desktop`.| +|**CSIDL_COMMON_DOCUMENTS**|The file-system directory that contains documents that are common to all users. A typical path is `C:\Users\Public\Documents`.| +|**CSIDL_COMMON_FAVORITES**|The file-system directory that serves as a common repository for favorites common to all users. A typical path is C:\Users\Public\Favorites.| +|**CSIDL_COMMON_MUSIC**|The file-system directory that serves as a repository for music files common to all users. A typical path is `C:\Users\Public\Music`.| +|**CSIDL_COMMON_PICTURES**|The file-system directory that serves as a repository for image files common to all users. A typical path is `C:\Users\Public\Pictures`.| +|**CSIDL_COMMON_PROGRAMS**|The file-system directory that contains the directories for the common program groups that appear on the **Start** menu for all users. A typical path is `C:\ProgramData\Microsoft\Windows\Start Menu\Programs`.| +|**CSIDL_COMMON_STARTMENU**|The file-system directory that contains the programs and folders that appear on the **Start** menu for all users. A typical path in Windows is `C:\ProgramData\Microsoft\Windows\Start Menu`.| +|**CSIDL_COMMON_STARTUP**|The file-system directory that contains the programs that appear in the Startup folder for all users. A typical path is `C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup`.| +|**CSIDL_COMMON_TEMPLATES**|The file-system directory that contains the templates that are available to all users. A typical path is `C:\ProgramData\Microsoft\Windows\Templates`.| +|**CSIDL_COMMON_VIDEO**|The file-system directory that serves as a repository for video files common to all users. A typical path is `C:\Users\Public\Videos`.| +|**CSIDL_DEFAULT_APPDATA**|Refers to the Appdata folder inside `%DEFAULTUSERPROFILE%`.| +|C**SIDL_DEFAULT_LOCAL_APPDATA**|Refers to the local Appdata folder inside `%DEFAULTUSERPROFILE%`.| +|**CSIDL_DEFAULT_COOKIES**|Refers to the Cookies folder inside `%DEFAULTUSERPROFILE%`.| +|**CSIDL_DEFAULT_CONTACTS**|Refers to the Contacts folder inside `%DEFAULTUSERPROFILE%`.| +|**CSIDL_DEFAULT_DESKTOP**|Refers to the Desktop folder inside `%DEFAULTUSERPROFILE%`.| +|**CSIDL_DEFAULT_DOWNLOADS**|Refers to the Downloads folder inside `%DEFAULTUSERPROFILE%`.| +|**CSIDL_DEFAULT_FAVORITES**|Refers to the Favorites folder inside `%DEFAULTUSERPROFILE%`.| +|**CSIDL_DEFAULT_HISTORY**|Refers to the History folder inside `%DEFAULTUSERPROFILE%`.| +|**CSIDL_DEFAULT_INTERNET_CACHE**|Refers to the Internet Cache folder inside `%DEFAULTUSERPROFILE%`.| +|**CSIDL_DEFAULT_PERSONAL**|Refers to the Personal folder inside `%DEFAULTUSERPROFILE%`.| +|**CSIDL_DEFAULT_MYDOCUMENTS**|Refers to the My Documents folder inside `%DEFAULTUSERPROFILE%`.| +|**CSIDL_DEFAULT_MYPICTURES**|Refers to the My Pictures folder inside `%DEFAULTUSERPROFILE%`.| +|**CSIDL_DEFAULT_MYMUSIC**|Refers to the My Music folder inside `%DEFAULTUSERPROFILE%`.| +|**CSIDL_DEFAULT_MYVIDEO**|Refers to the My Videos folder inside `%DEFAULTUSERPROFILE%`.| +|**CSIDL_DEFAULT_RECENT**|Refers to the Recent folder inside `%DEFAULTUSERPROFILE%`.| +|**CSIDL_DEFAULT_SENDTO**|Refers to the Send To folder inside `%DEFAULTUSERPROFILE%`.| +|**CSIDL_DEFAULT_STARTMENU**|Refers to the Start Menu folder inside `%DEFAULTUSERPROFILE%`.| +|**CSIDL_DEFAULT_PROGRAMS**|Refers to the Programs folder inside `%DEFAULTUSERPROFILE%`.| +|**CSIDL_DEFAULT_STARTUP**|Refers to the Startup folder inside `%DEFAULTUSERPROFILE%`.| +|**CSIDL_DEFAULT_TEMPLATES**|Refers to the Templates folder inside `%DEFAULTUSERPROFILE%`.| +|**CSIDL_DEFAULT_QUICKLAUNCH**|Refers to the Quick Launch folder inside `%DEFAULTUSERPROFILE%`.| +|**CSIDL_FONTS**|A virtual folder containing fonts. A typical path is `C:\Windows\Fonts`.| +|**CSIDL_PROGRAM_FILESX86**|The Program Files folder on 64-bit systems. A typical path is `C:\Program Files(86)`.| +|**CSIDL_PROGRAM_FILES_COMMONX86**|A folder for components that are shared across applications on 64-bit systems. A typical path is `C:\Program Files(86)\Common`.| +|**CSIDL_PROGRAM_FILES**|The Program Files folder. A typical path is `C:\Program Files`.| +|**CSIDL_PROGRAM_FILES_COMMON**|A folder for components that are shared across applications. A typical path is `C:\Program Files\Common`.| +|**CSIDL_RESOURCES**|The file-system directory that contains resource data. A typical path is `C:\Windows\Resources`.| +|**CSIDL_SYSTEM**|The Windows System folder. A typical path is `C:\Windows\System32`.| +|**CSIDL_WINDOWS**|The Windows directory or system root path. This value corresponds to the `%WINDIR%` or `%SYSTEMROOT%` environment variables. A typical path is `C:\Windows`.| +|**DEFAULTUSERPROFILE**|Refers to the value in `HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList [DefaultUserProfile]`.| +|**PROFILESFOLDER**|Refers to the value in `HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList [ProfilesDirectory]`.| |**PROGRAMFILES**|Same as **CSIDL_PROGRAM_FILES**.| -|**PROGRAMFILES(X86)**|Refers to the C:\Program Files (x86) folder on 64-bit systems.| -|**SYSTEM**|Refers to %**WINDIR**%\system32.| -|**SYSTEM16**|Refers to %**WINDIR**%\system.| -|**SYSTEM32**|Refers to %**WINDIR**%\system32.| -|**SYSTEMDRIVE**|The drive that holds the Windows folder. Note that this is a drive name and not a folder name (`C:` not `C:\`).| -|**SYSTEMPROFILE**|Refers to the value in **HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-18 [ProfileImagePath]**.| +|**PROGRAMFILES(X86)**|Refers to the `C:\Program Files (x86)` folder on 64-bit systems.| +|**SYSTEM**|Refers to `%WINDIR%\system32`.| +|**SYSTEM16**|Refers to `%WINDIR%\system`.| +|**SYSTEM32**|Refers to `%WINDIR%\system32`.| +|**SYSTEMDRIVE**|The drive that holds the Windows folder. This value is a drive name and not a folder name (`C:` not `C:\`).| +|**SYSTEMPROFILE**|Refers to the value in `HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-18 [ProfileImagePath]`.| |**SYSTEMROOT**|Same as **WINDIR**.| |**WINDIR**|Refers to the Windows folder located on the system drive.| -## Variables that are recognized only in the user context +## Variables that are recognized only in the user context You can use these variables in the .xml files within sections with `context=User` and `context=UserAndSystem`. @@ -97,44 +88,44 @@ You can use these variables in the .xml files within sections with `context=User |**APPDATA**|Same as **CSIDL_APPDATA**.| |**CSIDL_ADMINTOOLS**|The file-system directory that is used to store administrative tools for an individual user. The Microsoft® Management Console (MMC) saves customized consoles to this directory, which roams with the user profile.| |**CSIDL_ALTSTARTUP**|The file-system directory that corresponds to the user's non-localized Startup program group.| -|**CSIDL_APPDATA**|The file-system directory that serves as a common repository for application-specific data. A typical path is C:\Documents and Settings\username\Application Data or C:\Users\username\AppData\Roaming.| +|**CSIDL_APPDATA**|The file-system directory that serves as a common repository for application-specific data. A typical path is `C:\Users\\AppData\Roaming`.| |**CSIDL_BITBUCKET**|The virtual folder that contains the objects in the user's Recycle Bin.| -|**CSIDL_CDBURN_AREA**|The file-system directory acting as a staging area for files waiting to be written to CD. A typical path is C:\Users\username\AppData\Local\Microsoft\Windows\MasteredBurning\Disc Burning.| +|**CSIDL_CDBURN_AREA**|The file-system directory acting as a staging area for files waiting to be written to CD. A typical path is `C:\Users\\AppData\Local\Microsoft\Windows\MasteredBurning\Disc Burning`.| |**CSIDL_CONNECTIONS**|The virtual folder representing Network Connections that contains network and dial-up connections.| -|**CSIDL_CONTACTS**|This refers to the Contacts folder in %**CSIDL_PROFILE**%.| +|**CSIDL_CONTACTS**|This value refers to the Contacts folder in %**CSIDL_PROFILE**%.| |**CSIDL_CONTROLS**|The virtual folder that contains icons for the Control Panel items.| -|**CSIDL_COOKIES**|The file-system directory that serves as a common repository for Internet cookies. A typical path is C:\Users\username\AppData\Roaming\Microsoft\Windows\Cookies.| +|**CSIDL_COOKIES**|The file-system directory that serves as a common repository for Internet cookies. A typical path is `C:\Users\\AppData\Roaming\Microsoft\Windows\Cookies`.| |**CSIDL_DESKTOP**|The virtual folder representing the Windows desktop.| -|**CSIDL_DESKTOPDIRECTORY**|The file-system directory used to physically store file objects on the desktop, which should not be confused with the desktop folder itself. A typical path is C:\Users\username\Desktop.| +|**CSIDL_DESKTOPDIRECTORY**|The file-system directory used to physically store file objects on the desktop, which shouldn't be confused with the desktop folder itself. A typical path is `C:\Users\\Desktop`.| |**CSIDL_DRIVES**|The virtual folder representing My Computer that contains everything on the local computer: storage devices, printers, and Control Panel. The folder may also contain mapped network drives.| -|**CSIDL_FAVORITES**|The file-system directory that serves as a common repository for the user's favorites. A typical path is C:\Users\Username\Favorites.| +|**CSIDL_FAVORITES**|The file-system directory that serves as a common repository for the user's favorites. A typical path is `C:\Users\\Favorites`.| |**CSIDL_HISTORY**|The file-system directory that serves as a common repository for Internet history items.| |**CSIDL_INTERNET**|A virtual folder for Internet Explorer.| -|**CSIDL_INTERNET_CACHE**|The file-system directory that serves as a common repository for temporary Internet files. A typical path is C:\Users\username\AppData\Local\Microsoft\Windows\Temporary Internet Files| -|**CSIDL_LOCAL_APPDATA**|The file-system directory that serves as a data repository for local, non-roaming applications. A typical path is C:\Users\username\AppData\Local.| -|**CSIDL_MYDOCUMENTS**|The virtual folder representing My Documents.A typical path is C:\Users\Username\Documents.| -|**CSIDL_MYMUSIC**|The file-system directory that serves as a common repository for music files. A typical path is C:\Users\Username\Music.| -|**CSIDL_MYPICTURES**|The file-system directory that serves as a common repository for image files. A typical path is C:\Users\Username\Pictures.| -|**CSIDL_MYVIDEO**|The file-system directory that serves as a common repository for video files. A typical path is C:\Users\Username\Videos.| -|**CSIDL_NETHOOD**|A file-system directory that contains the link objects that may exist in the My Network Places virtual folder. It is not the same as CSIDL_NETWORK, which represents the network namespace root. A typical path is C:\Users\Username\AppData\Roaming\Microsoft\Windows\Network Shortcuts.| +|**CSIDL_INTERNET_CACHE**|The file-system directory that serves as a common repository for temporary Internet files. A typical path is `C:\Users\\AppData\Local\Microsoft\Windows\Temporary Internet Files`| +|**CSIDL_LOCAL_APPDATA**|The file-system directory that serves as a data repository for local, non-roaming applications. A typical path is `C:\Users\\AppData\Local`.| +|**CSIDL_MYDOCUMENTS**|The virtual folder representing My Documents.A typical path is `C:\Users\\Documents`.| +|**CSIDL_MYMUSIC**|The file-system directory that serves as a common repository for music files. A typical path is `C:\Users\\Music`.| +|**CSIDL_MYPICTURES**|The file-system directory that serves as a common repository for image files. A typical path is `C:\Users\\Pictures`.| +|**CSIDL_MYVIDEO**|The file-system directory that serves as a common repository for video files. A typical path is `C:\Users\\Videos`.| +|**CSIDL_NETHOOD**|A file-system directory that contains the link objects that may exist in the My Network Places virtual folder. It isn't the same as **CSIDL_NETWORK**, which represents the network namespace root. A typical path is `C:\Users\\AppData\Roaming\Microsoft\Windows\Network Shortcuts`.| |**CSIDL_NETWORK**|A virtual folder representing My Network Places, the root of the network namespace hierarchy.| -|**CSIDL_PERSONAL**|The virtual folder representing the My Documents desktop item. This is equivalent to **CSIDL_MYDOCUMENTS**.
A typical path is C:\Documents and Settings\username\My Documents.| -|**CSIDL_PLAYLISTS**|The virtual folder used to store play albums, typically C:\Users\username\My Music\Playlists.| +|**CSIDL_PERSONAL**|The virtual folder representing the My Documents desktop item. This value is equivalent to **CSIDL_MYDOCUMENTS**. A typical path is `C:\Documents and Settings\\My Documents`.| +|**CSIDL_PLAYLISTS**|The virtual folder used to store play albums, typically `C:\Users\\My Music\Playlists`.| |**CSIDL_PRINTERS**|The virtual folder that contains installed printers.| -|**CSIDL_PRINTHOOD**|The file-system directory that contains the link objects that can exist in the Printers virtual folder. A typical path is C:\Users\username\AppData\Roaming\Microsoft\Windows\Printer Shortcuts.| -|**CSIDL_PROFILE**|The user's profile folder. A typical path is C:\Users\Username.| -|**CSIDL_PROGRAMS**|The file-system directory that contains the user's program groups, which are themselves file-system directories. A typical path is C:\Users\Username\AppData\Roaming\Microsoft\Windows\Start Menu\Programs.| -|**CSIDL_RECENT**|The file-system directory that contains shortcuts to the user's most recently used documents. A typical path is C:\Users\Username\AppData\Roaming\Microsoft\Windows\Recent.| -|**CSIDL_SENDTO**|The file-system directory that contains **Send To** menu items. A typical path is C:\Users\username\AppData\Roaming\Microsoft\Windows\SendTo.| -|**CSIDL_STARTMENU**|The file-system directory that contains **Start** menu items. A typical path in Windows XP is C:\Documents and Settings\username\Start Menu. A typical path in Windows Vista, Windows 7, or Windows 8 is C:\Users\Username\AppData\Roaming\Microsoft\Windows\Start Menu.| -|**CSIDL_STARTUP**|The file-system directory that corresponds to the user's Startup program group. A typical path is C:\Users\Username\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup.| -|**CSIDL_TEMPLATES**|The file-system directory that serves as a common repository for document templates. A typical path is C:\Users\username\AppData\Roaming\Microsoft\Windows\Templates.| +|**CSIDL_PRINTHOOD**|The file-system directory that contains the link objects that can exist in the Printers virtual folder. A typical path is `C:\Users\\AppData\Roaming\Microsoft\Windows\Printer Shortcuts`.| +|**CSIDL_PROFILE**|The user's profile folder. A typical path is `C:\Users\`.| +|**CSIDL_PROGRAMS**|The file-system directory that contains the user's program groups, which are themselves file-system directories. A typical path is `C:\Users\\AppData\Roaming\Microsoft\Windows\Start Menu\Programs`.| +|**CSIDL_RECENT**|The file-system directory that contains shortcuts to the user's most recently used documents. A typical path is `C:\Users\\AppData\Roaming\Microsoft\Windows\Recent`.| +|**CSIDL_SENDTO**|The file-system directory that contains **Send To** menu items. A typical path is `C:\Users\\AppData\Roaming\Microsoft\Windows\SendTo`.| +|**CSIDL_STARTMENU**|The file-system directory that contains **Start** menu items. A typical path is `C:\Users\\AppData\Roaming\Microsoft\Windows\Start Menu`.| +|**CSIDL_STARTUP**|The file-system directory that corresponds to the user's Startup program group. A typical path is `C:\Users\\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup`.| +|**CSIDL_TEMPLATES**|The file-system directory that serves as a common repository for document templates. A typical path is `C:\Users\\AppData\Roaming\Microsoft\Windows\Templates`.| |**HOMEPATH**|Same as the standard environment variable.| -|**TEMP**|The temporary folder on the computer. A typical path is %**USERPROFILE**%\AppData\Local\Temp.| -|**TMP**|The temporary folder on the computer. A typical path is %**USERPROFILE**%\AppData\Local\Temp.| +|**TEMP**|The temporary folder on the computer. A typical path is `%USERPROFILE%\AppData\Local\Temp`.| +|**TMP**|The temporary folder on the computer. A typical path is `%**USERPROFILE**%\AppData\Local\Temp`.| |**USERPROFILE**|Same as **CSIDL_PROFILE**.| -|**USERSID**|Represents the current user-account security identifier (SID). For example,
S-1-5-21-1714567821-1326601894-715345443-1026.| +|**USERSID**|Represents the current user-account security identifier (SID). For example, `S-1-5-21-1714567821-1326601894-715345443-1026`.| -## Related topics +## Related articles -[USMT XML Reference](usmt-xml-reference.md) +[USMT XML reference](usmt-xml-reference.md) diff --git a/windows/deployment/usmt/usmt-reference.md b/windows/deployment/usmt/usmt-reference.md index 06c1fbebbb..9c2604adf1 100644 --- a/windows/deployment/usmt/usmt-reference.md +++ b/windows/deployment/usmt/usmt-reference.md @@ -11,24 +11,24 @@ ms.topic: article ms.technology: itpro-deploy --- -# User State Migration Toolkit (USMT) Reference +# User State Migration Toolkit (USMT) reference -## In This Section +## In this section | Link | Description | |--- |--- | -|[USMT Requirements](usmt-requirements.md)|Describes operating system, hardware, and software requirements, and user prerequisites.| -|[USMT Best Practices](usmt-best-practices.md)|Discusses general and security-related best practices when using USMT.| -|[How USMT Works](usmt-how-it-works.md)|Learn about the processes behind the ScanState and LoadState tools.| -|[Plan Your Migration](usmt-plan-your-migration.md)|Choose what to migrate and the best migration scenario for your enterprise.| -|[User State Migration Tool (USMT) Command-line Syntax](usmt-command-line-syntax.md)|Explore command-line options for the ScanState, LoadState, and UsmtUtils tools.| -|[USMT XML Reference](usmt-xml-reference.md)|Learn about customizing a migration with XML files.| -|[Offline Migration Reference](offline-migration-reference.md)|Find requirements, best practices, and other considerations for performing a migration offline.| +|[USMT requirements](usmt-requirements.md)|Describes operating system, hardware, and software requirements, and user prerequisites.| +|[USMT best practices](usmt-best-practices.md)|Discusses general and security-related best practices when using USMT.| +|[How USMT works](usmt-how-it-works.md)|Learn about the processes behind the ScanState and LoadState tools.| +|[Plan your migration](usmt-plan-your-migration.md)|Choose what to migrate and the best migration scenario for your enterprise.| +|[User State Migration Tool (USMT) command-line syntax](usmt-command-line-syntax.md)|Explore command-line options for the ScanState, LoadState, and UsmtUtils tools.| +|[USMT XML reference](usmt-xml-reference.md)|Learn about customizing a migration with XML files.| +|[Offline Migration reference](offline-migration-reference.md)|Find requirements, best practices, and other considerations for performing a migration offline.| -## Related topics +## Related articles -[User State Migration Tool (USMT) Overview Topics](usmt-topics.md) +[User State Migration Tool (USMT) overview topics](usmt-topics.md) -[User State Migration Tool (USMT) How-to topics](usmt-how-to.md) +[User State Migration Tool (USMT) how-to topics](usmt-how-to.md) -[User State Migration Tool (USMT) Troubleshooting](usmt-troubleshooting.md) +[User State Migration Tool (USMT) troubleshooting](usmt-troubleshooting.md) diff --git a/windows/deployment/usmt/usmt-requirements.md b/windows/deployment/usmt/usmt-requirements.md index 622a516b54..b3af869f87 100644 --- a/windows/deployment/usmt/usmt-requirements.md +++ b/windows/deployment/usmt/usmt-requirements.md @@ -11,92 +11,83 @@ ms.topic: article ms.technology: itpro-deploy --- -# USMT Requirements +# USMT requirements -## In This Topic +## Supported operating systems -- [Supported Operating Systems](#bkmk-1) -- [Windows PE](#windows-pe) -- [Credentials](#credentials) -- [Config.xml](#configxml) -- [LoadState](#loadstate) -- [Hard Disk Requirements](#bkmk-3) -- [User Prerequisites](#bkmk-userprereqs) - -## Supported Operating Systems - -The User State Migration Tool (USMT) 10.0 does not have any explicit RAM or CPU speed requirements for either the source or destination computers. If your computer complies with the system requirements of the operating system, it also complies with the requirements for USMT. You need an intermediate store location large enough to hold all of the migrated data and settings, and the same amount of hard disk space on the destination computer for the migrated files and settings. +The User State Migration Tool (USMT) 10.0 doesn't have any explicit RAM or CPU speed requirements for either the source or destination computers. If your computer complies with the system requirements of the operating system, it also complies with the requirements for USMT. You need an intermediate store location large enough to hold all of the migrated data and settings, and the same amount of hard disk space on the destination computer for the migrated files and settings. The following table lists the operating systems supported in USMT. -|Operating Systems|ScanState (source computer)|LoadState (destination computer)| +|Operating Systems|ScanState (source computer)|LoadState (destination computer)| |--- |--- |--- | -|32-bit versions of Windows 7|✔️|✔️| -|64-bit versions of Windows 7|✔️|✔️| -|32-bit versions of Windows 8|✔️|✔️| -|64-bit versions of Windows 8|✔️|✔️| -|32-bit versions of Windows 10|✔️|✔️| -|64-bit versions of Windows 10|✔️|✔️| +|32-bit versions of Windows 7|✔️|✔️| +|64-bit versions of Windows 7|✔️|✔️| +|32-bit versions of Windows 8|✔️|✔️| +|64-bit versions of Windows 8|✔️|✔️| +|32-bit versions of Windows 10|✔️|✔️| +|64-bit versions of Windows 10|✔️|✔️| > [!NOTE] > You can migrate a 32-bit operating system to a 64-bit operating system. However, you cannot migrate a 64-bit operating system to a 32-bit operating system. -USMT does not support any of the Windows Server® operating systems, Windows 2000, Windows XP, or any of the starter editions for Windows Vista or Windows 7. +## Unsupported scenarios -USMT for Windows 10 should not be used for migrating from Windows 7 to Windows 8.1. It is meant to migrate to Windows 10. -For more information about previous releases of the USMT tools, see [User State Migration Tool (USMT) 4.0 User’s Guide](/previous-versions/windows/server/dd560801(v=ws.10)). +- USMT doesn't support any of the Windows Server® operating systems. +- USMT for Windows 10 shouldn't be used for migrating between previous versions of Windows. USMT for Windows 10 is only meant to migrate to Windows 10 or between Windows 10 versions. For more information about previous releases of the USMT tools, see [User State Migration Tool (USMT) 4.0 User’s Guide](/previous-versions/windows/server/dd560801(v=ws.10)). ## Windows PE -- **Must use latest version of Windows PE.** For example, to migrate to Windows 10, you'll need Windows PE 5.1. For more info, see [What's New in Windows PE](/windows-hardware/manufacture/desktop/whats-new-in-windows-pe-s14). +- **Must use latest version of Windows PE.** For example, to migrate to Windows 10, you'll need Windows PE 5.1. For more info, see [What's New in Windows PE](/windows-hardware/manufacture/desktop/whats-new-in-windows-pe-s14). ## Credentials - **Run as administrator** - When manually running the **ScanState** and **LoadState** tools on Windows 7, Windows 8, or Windows 10 you must run them from an elevated command prompt to ensure that all specified users are migrated. If you do not run USMT from an elevated prompt, only the user profile that is logged on will be included in the migration. + When manually running the **ScanState** and **LoadState** tools on Windows 7, Windows 8, or Windows 10 you must run them from an elevated command prompt to ensure that all specified users are migrated. If you don't run USMT from an elevated prompt, only the user profile that is logged on will be included in the migration. To open an elevated command prompt: -1. Click **Start**. +1. Select **Start**. 2. Enter **cmd** in the search function. -3. Depending on the OS you are using, **cmd** or **Command Prompt** is displayed. -3. Right-click **cmd** or **Command Prompt**, and then click **Run as administrator**. -4. If the current user is not already an administrator, you will be prompted to enter administrator credentials. +3. Depending on the OS you're using, **cmd** or **Command Prompt** is displayed. +4. Right-click **cmd** or **Command Prompt**, and then select **Run as administrator**. +5. If the current user isn't already an administrator, you'll be prompted to enter administrator credentials. > [!IMPORTANT] > You must run USMT using an account with full administrative permissions, including the following privileges: - -- SeBackupPrivilege (Back up files and directories) -- SeDebugPrivilege (Debug programs) -- SeRestorePrivilege (Restore files and directories) -- SeSecurityPrivilege (Manage auditing and security log) -- SeTakeOwnership Privilege (Take ownership of files or other objects) +> - SeBackupPrivilege (Back up files and directories) +> - SeDebugPrivilege (Debug programs) +> - SeRestorePrivilege (Restore files and directories) +>- SeSecurityPrivilege (Manage auditing and security log) +> - SeTakeOwnership Privilege (Take ownership of files or other objects) ## Config.xml -- **Specify the /c option and <ErrorControl> settings in the Config.xml file.**
- USMT will fail if it cannot migrate a file or setting, unless you specify the **/c** option. When you specify the **/c** option, USMT logs an error each time it encounters a file that is in use that did not migrate, but the migration will not be interrupted. In USMT, you can specify in the Config.xml file, which types of errors should allow the migration to continue, and which should cause the migration to fail. For more information about error reporting, and the **<ErrorControl>** element, see [Config.xml File](usmt-configxml-file.md), [Log Files](usmt-log-files.md), and [XML Elements Library](usmt-xml-elements-library.md). +### Specify the /c option and <ErrorControl> settings in the Config.xml file + +USMT will fail if it can't migrate a file or setting, unless you specify the `/c` option. When you specify the `/c` option, USMT logs an error each time it encounters a file that is in use that didn't migrate, but the migration won't be interrupted. In USMT, you can specify in the `Config.xml` file, which types of errors should allow the migration to continue, and which should cause the migration to fail. For more information about error reporting, and the **<ErrorControl>** element, see [Config.xml file](usmt-configxml-file.md#errorcontrol), [Log files](usmt-log-files.md), and [XML elements library](usmt-xml-elements-library.md). ## LoadState -- **Install applications before running the LoadState command.**
- Install all applications on the destination computer before restoring the user state. This ensures that migrated settings are preserved. +### Install applications before running the LoadState command. -## Hard-Disk Requirements +Install all applications on the destination computer before restoring the user state. Installing applications before running the `LoadState.exe` command ensures that migrated settings are preserved. -Ensure that there is enough available space in the migration-store location and on the source and destination computers. For more information, see [Estimate Migration Store Size](usmt-estimate-migration-store-size.md). +## Hard-Disk requirements -## User Prerequisites +Ensure that there's enough available space in the migration-store location and on the source and destination computers. For more information, see [Estimate Migration Store Size](usmt-estimate-migration-store-size.md). -This documentation assumes that IT professionals using USMT understand command-line tools. The documentation also assumes that IT professionals using USMT to author MigXML rules understand the following: +## User prerequisites -- The navigation and hierarchy of the Windows registry. -- The files and file types that applications use. -- The methods to extract application and setting information manually from applications created by internal software-development groups and non-Microsoft software vendors. -- XML-authoring basics. +This documentation assumes that IT professionals using USMT understand command-line tools. The documentation also assumes that IT professionals using USMT to author MigXML rules understand the following concepts: -## Related topics +- The navigation and hierarchy of the Windows registry. +- The files and file types that applications use. +- The methods to extract application and setting information manually from applications created by internal software-development groups and non-Microsoft software publishers. +- XML-authoring basics. -[Plan Your Migration](usmt-plan-your-migration.md)
-[Estimate Migration Store Size](usmt-estimate-migration-store-size.md)
-[User State Migration Tool (USMT) Overview Topics](usmt-topics.md)
+## Related articles + +- [Plan your migration](usmt-plan-your-migration.md) +- [Estimate migration store size](usmt-estimate-migration-store-size.md) +- [User State Migration Tool (USMT) overview topics](usmt-topics.md) diff --git a/windows/deployment/usmt/usmt-scanstate-syntax.md b/windows/deployment/usmt/usmt-scanstate-syntax.md index 8f8267209c..c3c9933bf0 100644 --- a/windows/deployment/usmt/usmt-scanstate-syntax.md +++ b/windows/deployment/usmt/usmt-scanstate-syntax.md @@ -25,7 +25,7 @@ The ScanState command is used with the User State Migration Tool (USMT) 10.0 to [Migration Rule Options](#bkmk-migrationruleoptions) -[Monitoring Options](#bkmk-monitoringoptions) +[Monitoring Options](#monitoring-options) [User Options](#bkmk-useroptions) @@ -126,7 +126,7 @@ USMT provides the following options to specify what files you want to migrate. | **/targetwindows7** | Optimizes Scanstate.exe when using USMT 10.0 to migrate a user state to Windows 7 instead of Windows 10. You should use this command-line option in the following scenarios:
  • **To create a Config.xml file by using the /genconfig option.** Using the **/targetwindows7** option optimizes the Config.xml file so that it only contains components that relate to Windows 7.
  • **To create a migration store.** Using the **/targetwindows7** option ensures that the ScanState tool gathers the correct set of operating system settings. Without the **/targetwindows7** command-line option, some settings can be lost during the migration.
| | **/localonly** | Migrates only files that are stored on the local computer, regardless of the rules in the .xml files that you specify on the command line. You should use this option when you want to exclude the data from removable drives on the source computer, such as USB flash drives (UFDs), some external hard drives, and so on, and when there are network drives mapped on the source computer. If the **/localonly** option is not specified, then the **ScanState** command will copy files from these removable or network drives into the store.

Anything that is not considered a fixed drive by the OS will be excluded by **/localonly**. In some cases large external hard drives are considered fixed drives. These drives can be explicitly excluded from migration by using a custom.xml file. For more information about how to exclude all files on a specific drive, see [Exclude Files and Settings](usmt-exclude-files-and-settings.md).

The **/localonly** command-line option includes or excludes data in the migration as identified in the following:
  • **Removable drives such as a USB flash drive** - Excluded
  • **Network drives** - Excluded
  • **Fixed drives** - Included
| -## Monitoring Options +## Monitoring options USMT provides several options that you can use to analyze problems that occur during migration. diff --git a/windows/deployment/usmt/usmt-xml-elements-library.md b/windows/deployment/usmt/usmt-xml-elements-library.md index ed1bc0aacd..d9b9911c21 100644 --- a/windows/deployment/usmt/usmt-xml-elements-library.md +++ b/windows/deployment/usmt/usmt-xml-elements-library.md @@ -11,7 +11,7 @@ ms.topic: article ms.technology: itpro-deploy --- -# XML Elements Library +# XML elements library This topic describes the XML elements and helper functions that you can employ to author migration .xml files to use with User State Migration Tool (USMT). It is assumed that you understand the basics of XML. @@ -1753,7 +1753,7 @@ This is an internal USMT element. Do not use this element. This is an internal USMT element. Do not use this element. -## <pattern> +## <pattern> You can use this element to specify multiple objects. You can specify multiple <pattern> elements for each <objectSet> element and they will be combined. If you are specifying files, you may want to use GenerateDrivePatterns with <script> instead. GenerateDrivePatterns is basically the same as a <pattern> rule, without the drive letter specification. For example, the following two lines of code are similar: