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

Merge pull request #6468 from walsehgal/walsehgal-seo-working-branch

Browse Source 
Update short meta descriptions
This commit is contained in:
Dani Halfin 2020-04-11 08:30:52 -07:00 committed by GitHub
commit 4229fb61db
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
61 changed files with 6264 additions and 6166 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
windows/deployment/update/WIP4Biz-intro.md
View File

@ -1,7 +1,8 @@
---
title: Introduction to the Windows Insider Program for Business
description: Introduction to the Windows Insider Program for Business and why IT Pros should join
description: In this article, you'll learn about the Windows Insider Program for Business and why IT Pros should join.
keywords: updates, servicing, current, deployment, semi-annual channel, feature, quality, rings, insider, WiP4Biz, enterprise, rings, flight
ms.custom: seo-marvel-apr2020
ms.prod: w10
ms.mktglfcycl: manage
audience: itpro

3
windows/deployment/update/wufb-autoupdate.md
View File

@ -1,6 +1,7 @@
---
title: Setting up Automatic Update in Windows Update for Business (Windows 10)
description: Learn how to configure Automatic Update group policies in Windows Update for Business.
description: In this article, you'll learn how to configure Automatic Update group policies in Windows Update for Business (Windows 10).
ms.custom: seo-marvel-apr2020
ms.prod: w10
ms.mktglfcycl: manage
audience: itpro

3
windows/deployment/update/wufb-basics.md
View File

@ -1,6 +1,7 @@
---
title: Configure the Basic group policy for Windows Update for Business
description: Learn how to get started using the Basic GPO in Windows Update for Business.
description: In this article, you will learn how to configure the basic group policy for Windows Update for Business.
ms.custom: seo-marvel-apr2020
ms.prod: w10
ms.mktglfcycl: manage
audience: itpro

3
windows/deployment/update/wufb-compliancedeadlines.md
View File

@ -1,6 +1,7 @@
---
title: Enforce compliance deadlines with policies in Windows Update for Business (Windows 10)
description: Learn how to enforce compliance deadlines using Windows Update for Business.
description: This article contains information on how to enforce compliance deadlines using Windows Update for Business.
ms.custom: seo-marvel-apr2020
ms.prod: w10
ms.mktglfcycl: manage
author: jaimeo

3
windows/deployment/update/wufb-onboard.md
View File

@ -1,6 +1,7 @@
---
title: Onboarding to Windows Update for Business (Windows 10)
description: Learn how to get started using Windows Update for Business.
description: Learn how to get started using Windows Update for Business, that helps you manage content you want to receive from Windows Update Service.
ms.custom: seo-marvel-apr2020
ms.prod: w10
ms.mktglfcycl: manage
audience: itpro

3
windows/deployment/upgrade/log-files.md
View File

@ -3,8 +3,9 @@ title: Log files and resolving upgrade errors
ms.reviewer:
manager: laurawi
ms.author: greglin
description: Learn how to interpret the log files generated during the Windows 10 upgrade process.
description: Learn how to interpret and analyze the log files that are generated during the Windows 10 upgrade process.
keywords: deploy, error, troubleshoot, windows, 10, upgrade, code, rollback, ITPro
ms.custom: seo-marvel-apr2020
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library

3
windows/deployment/upgrade/quick-fixes.md
View File

@ -3,8 +3,9 @@ title: Quick fixes - Windows IT Pro
ms.reviewer:
manager: laurawi
ms.author: greglin
description: Learn how to quickly resolve many problems which may come up during a Windows 10 upgrade.
description: This article helps you learn how to quickly resolve many problems which may come up during a Windows 10 upgrade.
keywords: deploy, error, troubleshoot, windows, 10, upgrade, code, rollback, ITPro
ms.custom: seo-marvel-apr2020
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library

130
windows/deployment/upgrade/resolve-windows-10-upgrade-errors.md
View File

@ -1,64 +1,66 @@
---
title: Resolve Windows 10 upgrade errors - Windows IT Pro
ms.reviewer:
manager: laurawi
ms.author: greglin
description: Resolve Windows 10 upgrade errors for ITPros. Technical information for IT professionals to help diagnose Windows setup errors.
keywords: deploy, error, troubleshoot, windows, 10, upgrade, code, rollback, ITPro
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: deploy
audience: itpro author: greg-lindsay
ms.localizationpriority: medium
ms.topic: article
---
# Resolve Windows 10 upgrade errors : Technical information for IT Pros
**Applies to**
- Windows 10
>[!IMPORTANT]
>This article contains technical instructions for IT administrators. If you are not an IT administrator, try some of the [quick fixes](quick-fixes.md) described in this article then contact [Microsoft Support](https://support.microsoft.com/contactus/) starting with the Virtual Agent. To talk to a person about your issue, click **Get started** to interact with the Virtual Agent, then enter "Talk to a person" two times. The Virtual Agent can also help you to resolve many Windows upgrade issues. Also see: [Get help with Windows 10 upgrade and installation errors](https://support.microsoft.com/help/10587/windows-10-get-help-with-upgrade-installation-errors) and [Submit Windows 10 upgrade errors using Feedback Hub](submit-errors.md).
This article contains a brief introduction to Windows 10 installation processes, and provides resolution procedures that IT administrators can use to resolve issues with Windows 10 upgrade.
The article was originally one page, but has been divided into sub-topics of different technical levels. Basic level provides common procedures that can resolve several types of upgrade errors. Advanced level requires some experience with detailed troubleshooting methods.
The following four levels are assigned:
Level 100: Basic <br>
Level 200: Moderate <br>
Level 300: Moderate advanced <br>
Level 400: Advanced <br>
## In this guide
See the following topics in this article:
- [Quick fixes](quick-fixes.md): \Level 100\ Steps you can take to eliminate many Windows upgrade errors.<br>
- [SetupDiag](setupdiag.md): \Level 300\ SetupDiag is a new tool to help you isolate the root cause of an upgrade failure.
- [Troubleshooting upgrade errors](troubleshoot-upgrade-errors.md): \Level 300\ General advice and techniques for troubleshooting Windows 10 upgrade errors, and an explanation of phases used during the upgrade process.<br>
- [Windows Error Reporting](windows-error-reporting.md): \Level 300\ How to use Event Viewer to review details about a Windows 10 upgrade.
- [Upgrade error codes](upgrade-error-codes.md): \Level 400\ The components of an error code are explained.
- [Result codes](upgrade-error-codes.md#result-codes): Information about result codes.
- [Extend codes](upgrade-error-codes.md#extend-codes): Information about extend codes.
- [Log files](log-files.md): \Level 400\ A list and description of log files useful for troubleshooting.
- [Log entry structure](log-files.md#log-entry-structure): The format of a log entry is described.
- [Analyze log files](log-files.md#analyze-log-files): General procedures for log file analysis, and an example.
- [Resolution procedures](resolution-procedures.md): \Level 200\ Causes and mitigation procedures associated with specific error codes.
- [0xC1900101](resolution-procedures.md#0xc1900101): Information about the 0xC1900101 result code.
- [0x800xxxxx](resolution-procedures.md#0x800xxxxx): Information about result codes that start with 0x800.
- [Other result codes](resolution-procedures.md#other-result-codes): Additional causes and mitigation procedures are provided for some result codes.
- [Other error codes](resolution-procedures.md#other-error-codes): Additional causes and mitigation procedures are provided for some error codes.
- [Submit Windows 10 upgrade errors](submit-errors.md): \Level 100\ Submit upgrade errors to Microsoft for analysis.
## Related topics
[Windows 10 FAQ for IT professionals](https://technet.microsoft.com/windows/dn798755.aspx)
<br>[Windows 10 Enterprise system requirements](https://technet.microsoft.com/windows/dn798752.aspx)
<br>[Windows 10 Specifications](https://www.microsoft.com/windows/Windows-10-specifications)
<br>[Windows 10 IT pro forums](https://social.technet.microsoft.com/Forums/en-US/home?category=Windows10ITPro)
<br>[Fix Windows Update errors by using the DISM or System Update Readiness tool](https://support.microsoft.com/kb/947821)
<br>
---
title: Resolve Windows 10 upgrade errors - Windows IT Pro
ms.reviewer:
manager: laurawi
ms.author: greglin
description: This article contains technical instructions for IT administrators on how diagnose and resolve Windows 10 upgrade errors.
keywords: deploy, error, troubleshoot, windows, 10, upgrade, code, rollback, ITPro
ms.custom: seo-marvel-apr2020
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: deploy
audience: itpro
author: greg-lindsay
ms.localizationpriority: medium
ms.topic: article
---
# Resolve Windows 10 upgrade errors : Technical information for IT Pros
**Applies to**
- Windows 10
>[!IMPORTANT]
>This article contains technical instructions for IT administrators. If you are not an IT administrator, try some of the [quick fixes](quick-fixes.md) described in this article then contact [Microsoft Support](https://support.microsoft.com/contactus/) starting with the Virtual Agent. To talk to a person about your issue, click **Get started** to interact with the Virtual Agent, then enter "Talk to a person" two times. The Virtual Agent can also help you to resolve many Windows upgrade issues. Also see: [Get help with Windows 10 upgrade and installation errors](https://support.microsoft.com/help/10587/windows-10-get-help-with-upgrade-installation-errors) and [Submit Windows 10 upgrade errors using Feedback Hub](submit-errors.md).
This article contains a brief introduction to Windows 10 installation processes, and provides resolution procedures that IT administrators can use to resolve issues with Windows 10 upgrade.
The article was originally one page, but has been divided into sub-topics of different technical levels. Basic level provides common procedures that can resolve several types of upgrade errors. Advanced level requires some experience with detailed troubleshooting methods.
The following four levels are assigned:
Level 100: Basic <br>
Level 200: Moderate <br>
Level 300: Moderate advanced <br>
Level 400: Advanced <br>
## In this guide
See the following topics in this article:
- [Quick fixes](quick-fixes.md): \Level 100\ Steps you can take to eliminate many Windows upgrade errors.<br>
- [SetupDiag](setupdiag.md): \Level 300\ SetupDiag is a new tool to help you isolate the root cause of an upgrade failure.
- [Troubleshooting upgrade errors](troubleshoot-upgrade-errors.md): \Level 300\ General advice and techniques for troubleshooting Windows 10 upgrade errors, and an explanation of phases used during the upgrade process.<br>
- [Windows Error Reporting](windows-error-reporting.md): \Level 300\ How to use Event Viewer to review details about a Windows 10 upgrade.
- [Upgrade error codes](upgrade-error-codes.md): \Level 400\ The components of an error code are explained.
- [Result codes](upgrade-error-codes.md#result-codes): Information about result codes.
- [Extend codes](upgrade-error-codes.md#extend-codes): Information about extend codes.
- [Log files](log-files.md): \Level 400\ A list and description of log files useful for troubleshooting.
- [Log entry structure](log-files.md#log-entry-structure): The format of a log entry is described.
- [Analyze log files](log-files.md#analyze-log-files): General procedures for log file analysis, and an example.
- [Resolution procedures](resolution-procedures.md): \Level 200\ Causes and mitigation procedures associated with specific error codes.
- [0xC1900101](resolution-procedures.md#0xc1900101): Information about the 0xC1900101 result code.
- [0x800xxxxx](resolution-procedures.md#0x800xxxxx): Information about result codes that start with 0x800.
- [Other result codes](resolution-procedures.md#other-result-codes): Additional causes and mitigation procedures are provided for some result codes.
- [Other error codes](resolution-procedures.md#other-error-codes): Additional causes and mitigation procedures are provided for some error codes.
- [Submit Windows 10 upgrade errors](submit-errors.md): \Level 100\ Submit upgrade errors to Microsoft for analysis.
## Related topics
[Windows 10 FAQ for IT professionals](https://technet.microsoft.com/windows/dn798755.aspx)
<br>[Windows 10 Enterprise system requirements](https://technet.microsoft.com/windows/dn798752.aspx)
<br>[Windows 10 Specifications](https://www.microsoft.com/windows/Windows-10-specifications)
<br>[Windows 10 IT pro forums](https://social.technet.microsoft.com/Forums/en-US/home?category=Windows10ITPro)
<br>[Fix Windows Update errors by using the DISM or System Update Readiness tool](https://support.microsoft.com/kb/947821)
<br>

3
windows/deployment/upgrade/setupdiag.md
View File

@ -3,8 +3,9 @@ title: SetupDiag
ms.reviewer:
manager: laurawi
ms.author: greglin
description: How to use the SetupDiag tool to diagnose Windows Setup errors
description: In this article, you will learn about how to use the SetupDiag tool to diagnose Windows Setup errors.
keywords: deploy, troubleshoot, windows, 10, upgrade, update, setup, diagnose
ms.custom: seo-marvel-apr2020
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library

154
windows/deployment/upgrade/submit-errors.md
View File

@ -1,76 +1,78 @@
---
title: Submit Windows 10 upgrade errors using Feedback Hub
ms.reviewer:
manager: laurawi
ms.author: greglin
description: Submit Windows 10 upgrade errors for diagnosis using feedback hub
keywords: deploy, error, troubleshoot, windows, 10, upgrade, code, rollback, feedback
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: deploy
audience: itpro author: greg-lindsay
ms.localizationpriority: medium
ms.topic: article
---
# Submit Windows 10 upgrade errors using Feedback Hub
**Applies to**
- Windows 10
>[!NOTE]
>This is a 100 level topic (basic).<br>
>See [Resolve Windows 10 upgrade errors](resolve-windows-10-upgrade-errors.md) for a full list of topics in this article.
## In this topic
This topic describes how to submit problems with a Windows 10 upgrade to Microsoft using the Windows 10 Feedback Hub.
## About the Feedback Hub
The Feedback Hub app lets you tell Microsoft about any problems you run in to while using Windows 10 and send suggestions to help us improve your Windows experience. Previously, you could only use the Feedback Hub if you were in the Windows Insider Program. Now anyone can use this tool. You can download the Feedback Hub app from the Microsoft Store [here](https://www.microsoft.com/store/p/feedback-hub/9nblggh4r32n?SilentAuth=1&wa=wsignin1.0).
The Feedback Hub requires Windows 10 or Windows 10 mobile. If you are having problems upgrading from an older version of Windows to Windows 10, you can use the Feedback Hub to submit this information, but you must collect the log files from the legacy operating system and then attach these files to your feedback using a device that is running Windows 10. If you are upgrading to Windows 10 from a previous verion of Windows 10, the Feedback Hub will collect log files automatically.
## Submit feedback
To submit feedback about a failed Windows 10 upgrade, click the following link: [Feedback Hub](feedback-hub://?referrer=resolveUpgradeErrorsPage&tabid=2&contextid=81&newFeedback=true&feedbackType=2&topic=submit-errors.md) 
The Feedback Hub will open.
- Under **Tell us about it**, and then under **Summarize your issue**, type **Upgrade failing**.
- Under **Give us more detail**, provide additional information about the failed upgrade, such as:
- When did the failure occur?
- Were there any reboots?
- How many times did the system reboot?
- How did the upgrade fail?
- Were any error codes visible?
- Did the computer fail to a blue screen?
- Did the computer automatically roll back or did it hang, requiring you to power cycle it before it rolled back?
- Additional details
- What type of security software is installed?
- Is the computer up to date with latest drivers and firmware?
- Are there any external devices connected?
- If you used the link above, the category and subcategory will be automatically selected. If it is not selected, choose **Install and Update** and **Windows Installation**.
You can attach a screenshot or file if desired. This is optional, but can be extremely helpful when diagnosing your upgrade issue. The location of these files is described here: [Windows Setup log files and event logs](https://docs.microsoft.com/windows-hardware/manufacture/desktop/windows-setup-log-files-and-event-logs).
Click **Submit** to send your feedback.
See the following example:
![feedback example](../images/feedback.png)
After you click Submit, that's all you need to do. Microsoft will receive your feedback and begin analyzing the issue. You can check on your feedback periodically to see what solutions have been provided.
## Link to your feedback
After your feedback is submitted, you can email or post links to it by opening the Feedback Hub, clicking My feedback at the top, clicking the feedback item you submitted, clicking **Share**, then copying the short link that is displayed.
![share](../images/share.jpg)
## Related topics
[Windows 10 release information](https://technet.microsoft.com/windows/release-info.aspx)
---
title: Submit Windows 10 upgrade errors using Feedback Hub
ms.reviewer:
manager: laurawi
ms.author: greglin
description: This article describes, how to submit Windows 10 upgrade errors to Microsoft for diagnosis using the Windows 10 feedback hub.
keywords: deploy, error, troubleshoot, windows, 10, upgrade, code, rollback, feedback
ms.custom: seo-marvel-apr2020
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: deploy
audience: itpro
author: greg-lindsay
ms.localizationpriority: medium
ms.topic: article
---
# Submit Windows 10 upgrade errors using Feedback Hub
**Applies to**
- Windows 10
>[!NOTE]
>This is a 100 level topic (basic).<br>
>See [Resolve Windows 10 upgrade errors](resolve-windows-10-upgrade-errors.md) for a full list of topics in this article.
## In this topic
This topic describes how to submit problems with a Windows 10 upgrade to Microsoft using the Windows 10 Feedback Hub.
## About the Feedback Hub
The Feedback Hub app lets you tell Microsoft about any problems you run in to while using Windows 10 and send suggestions to help us improve your Windows experience. Previously, you could only use the Feedback Hub if you were in the Windows Insider Program. Now anyone can use this tool. You can download the Feedback Hub app from the Microsoft Store [here](https://www.microsoft.com/store/p/feedback-hub/9nblggh4r32n?SilentAuth=1&wa=wsignin1.0).
The Feedback Hub requires Windows 10 or Windows 10 mobile. If you are having problems upgrading from an older version of Windows to Windows 10, you can use the Feedback Hub to submit this information, but you must collect the log files from the legacy operating system and then attach these files to your feedback using a device that is running Windows 10. If you are upgrading to Windows 10 from a previous verion of Windows 10, the Feedback Hub will collect log files automatically.
## Submit feedback
To submit feedback about a failed Windows 10 upgrade, click the following link: [Feedback Hub](feedback-hub://?referrer=resolveUpgradeErrorsPage&tabid=2&contextid=81&newFeedback=true&feedbackType=2&topic=submit-errors.md) 
The Feedback Hub will open.
- Under **Tell us about it**, and then under **Summarize your issue**, type **Upgrade failing**.
- Under **Give us more detail**, provide additional information about the failed upgrade, such as:
- When did the failure occur?
- Were there any reboots?
- How many times did the system reboot?
- How did the upgrade fail?
- Were any error codes visible?
- Did the computer fail to a blue screen?
- Did the computer automatically roll back or did it hang, requiring you to power cycle it before it rolled back?
- Additional details
- What type of security software is installed?
- Is the computer up to date with latest drivers and firmware?
- Are there any external devices connected?
- If you used the link above, the category and subcategory will be automatically selected. If it is not selected, choose **Install and Update** and **Windows Installation**.
You can attach a screenshot or file if desired. This is optional, but can be extremely helpful when diagnosing your upgrade issue. The location of these files is described here: [Windows Setup log files and event logs](https://docs.microsoft.com/windows-hardware/manufacture/desktop/windows-setup-log-files-and-event-logs).
Click **Submit** to send your feedback.
See the following example:
![feedback example](../images/feedback.png)
After you click Submit, that's all you need to do. Microsoft will receive your feedback and begin analyzing the issue. You can check on your feedback periodically to see what solutions have been provided.
## Link to your feedback
After your feedback is submitted, you can email or post links to it by opening the Feedback Hub, clicking My feedback at the top, clicking the feedback item you submitted, clicking **Share**, then copying the short link that is displayed.
![share](../images/share.jpg)
## Related topics
[Windows 10 release information](https://technet.microsoft.com/windows/release-info.aspx)

160
windows/deployment/upgrade/windows-upgrade-and-migration-considerations.md
View File

@ -1,79 +1,81 @@
---
title: Windows Upgrade and Migration Considerations (Windows 10)
description: Windows Upgrade and Migration Considerations
ms.assetid: 7f85095c-5922-45e9-b28e-91b1263c7281
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.topic: article
---
# Windows upgrade and migration considerations
Files and application settings can be migrated to new hardware running the Windows® operating system, or they can be maintained during an operating system upgrade on the same computer. This topic summarizes the Microsoft® tools you can use to move files and settings between installations in addition to special considerations for performing an upgrade or migration.
## Upgrade from a previous version of Windows
You can upgrade from an earlier version of Windows, which means you can install the new version of Windows and retain your applications, files, and settings as they were in your previous version of Windows. If you decide to perform a custom installation of Windows instead of an upgrade, your applications and settings will not be maintained. Your personal files, and all Windows files and directories, will be moved to a Windows.old folder. You can access your data in the Windows.old folder after Windows Setup is complete.
## Migrate files and settings
Migration tools are available to transfer settings from one computer that is running Windows to another. These tools transfer only the program settings, not the programs themselves.
For more information about application compatibility, see the [Application Compatibility Toolkit (ACT)](https://go.microsoft.com/fwlink/p/?LinkId=131349).
The User State Migration Tool (USMT) 10.0 is an application intended for administrators who are performing large-scale automated deployments. For deployment to a small number of computers or for individually customized deployments, you can use Windows Easy Transfer.
### Migrate with Windows Easy Transfer
Windows Easy Transfer is a software wizard for transferring files and settings from one computer that is running Windows to another. It helps you select what to move to your new computer, enables you to set which migration method to use, and then performs the transfer. When the transfer has completed, Windows Easy Transfer Reports shows you what was transferred and provides a list of programs you might want to install on your new computer, in addition to links to other programs you might want to download.
With Windows Easy Transfer, files and settings can be transferred using a network share, a USB flash drive (UFD), or the Easy Transfer cable. However, you cannot use a regular universal serial bus (USB) cable to transfer files and settings with Windows Easy Transfer. An Easy Transfer cable can be purchased on the Web, from your computer manufacturer, or at an electronics store.
> [!NOTE]
> Windows Easy Transfer [is not available in Windows 10](https://support.microsoft.com/help/4026265/windows-windows-easy-transfer-is-not-available-in-windows-10).
### Migrate with the User State Migration Tool
You can use USMT to automate migration during large deployments of the Windows operating system. USMT uses configurable migration rule (.xml) files to control exactly which user accounts, user files, operating system settings, and application settings are migrated and how they are migrated. You can use USMT for both *side-by-side* migrations, where one piece of hardware is being replaced, or *wipe-and-load* (or *refresh*) migrations, when only the operating system is being upgraded.
## Upgrade and migration considerations
Whether you are upgrading or migrating to a new version of Windows, you must be aware of the following issues and considerations:
### Application compatibility
For more information about application compatibility in Windows, see [Use Upgrade Readiness to manage Windows upgrades](https://docs.microsoft.com/windows/deployment/upgrade/use-upgrade-readiness-to-manage-windows-upgrades).
### Multilingual Windows image upgrades
When performing multilingual Windows upgrades, cross-language upgrades are not supported by USMT. If you are upgrading or migrating an operating system with multiple language packs installed, you can upgrade or migrate only to the system default user interface (UI) language. For example, if English is the default but you have a Spanish language pack installed, you can upgrade or migrate only to English.
If you are using a single-language Windows image that matches the system default UI language of your multilingual operating system, the migration will work. However, all of the language packs will be removed, and you will have to reinstall them after the upgrade is completed.
### Errorhandler.cmd
When upgrading from an earlier version of Windows, if you intend to use Errorhandler.cmd, you must copy this file into the %WINDIR%\\Setup\\Scripts directory on the old installation. This makes sure that if there are errors during the down-level phase of Windows Setup, the commands in Errorhandler.cmd will run.
### Data drive ACL migration
During the configuration pass of Windows Setup, the root access control list (ACL) on drives formatted for NTFS that do not appear to have an operating system will be changed to the default Windows XP ACL format. The ACLs on these drives are changed to enable authenticated users to modify access on folders and files.
Changing the ACLs may affect the performance of Windows Setup if the default Windows XP ACLs are applied to a partition with a large amount of data. Because of these performance concerns, you can change the following registry value to disable this feature:
``` syntax
Key: HKLM\System\Setup
Type: REG_DWORD
Value: "DDACLSys_Disabled" = 1
```
This feature is disabled if this registry key value exists and is configured to `1`.
## Related topics
[User State Migration Tool (USMT) Overview Topics](../usmt/usmt-topics.md)<BR>
[Windows 10 upgrade paths](windows-10-upgrade-paths.md)<BR>
[Windows 10 edition upgrade](windows-10-edition-upgrades.md)
 
 
---
title: Windows Upgrade and Migration Considerations (Windows 10)
description: This article will guide you about things to consider before you make a Windows Upgrade or Migration.
ms.custom: seo-marvel-apr2020
ms.assetid: 7f85095c-5922-45e9-b28e-91b1263c7281
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.topic: article
---
# Windows upgrade and migration considerations
Files and application settings can be migrated to new hardware running the Windows® operating system, or they can be maintained during an operating system upgrade on the same computer. This topic summarizes the Microsoft® tools you can use to move files and settings between installations in addition to special considerations for performing an upgrade or migration.
## Upgrade from a previous version of Windows
You can upgrade from an earlier version of Windows, which means you can install the new version of Windows and retain your applications, files, and settings as they were in your previous version of Windows. If you decide to perform a custom installation of Windows instead of an upgrade, your applications and settings will not be maintained. Your personal files, and all Windows files and directories, will be moved to a Windows.old folder. You can access your data in the Windows.old folder after Windows Setup is complete.
## Migrate files and settings
Migration tools are available to transfer settings from one computer that is running Windows to another. These tools transfer only the program settings, not the programs themselves.
For more information about application compatibility, see the [Application Compatibility Toolkit (ACT)](https://go.microsoft.com/fwlink/p/?LinkId=131349).
The User State Migration Tool (USMT) 10.0 is an application intended for administrators who are performing large-scale automated deployments. For deployment to a small number of computers or for individually customized deployments, you can use Windows Easy Transfer.
### Migrate with Windows Easy Transfer
Windows Easy Transfer is a software wizard for transferring files and settings from one computer that is running Windows to another. It helps you select what to move to your new computer, enables you to set which migration method to use, and then performs the transfer. When the transfer has completed, Windows Easy Transfer Reports shows you what was transferred and provides a list of programs you might want to install on your new computer, in addition to links to other programs you might want to download.
With Windows Easy Transfer, files and settings can be transferred using a network share, a USB flash drive (UFD), or the Easy Transfer cable. However, you cannot use a regular universal serial bus (USB) cable to transfer files and settings with Windows Easy Transfer. An Easy Transfer cable can be purchased on the Web, from your computer manufacturer, or at an electronics store.
> [!NOTE]
> Windows Easy Transfer [is not available in Windows 10](https://support.microsoft.com/help/4026265/windows-windows-easy-transfer-is-not-available-in-windows-10).
### Migrate with the User State Migration Tool
You can use USMT to automate migration during large deployments of the Windows operating system. USMT uses configurable migration rule (.xml) files to control exactly which user accounts, user files, operating system settings, and application settings are migrated and how they are migrated. You can use USMT for both *side-by-side* migrations, where one piece of hardware is being replaced, or *wipe-and-load* (or *refresh*) migrations, when only the operating system is being upgraded.
## Upgrade and migration considerations
Whether you are upgrading or migrating to a new version of Windows, you must be aware of the following issues and considerations:
### Application compatibility
For more information about application compatibility in Windows, see [Use Upgrade Readiness to manage Windows upgrades](https://docs.microsoft.com/windows/deployment/upgrade/use-upgrade-readiness-to-manage-windows-upgrades).
### Multilingual Windows image upgrades
When performing multilingual Windows upgrades, cross-language upgrades are not supported by USMT. If you are upgrading or migrating an operating system with multiple language packs installed, you can upgrade or migrate only to the system default user interface (UI) language. For example, if English is the default but you have a Spanish language pack installed, you can upgrade or migrate only to English.
If you are using a single-language Windows image that matches the system default UI language of your multilingual operating system, the migration will work. However, all of the language packs will be removed, and you will have to reinstall them after the upgrade is completed.
### Errorhandler.cmd
When upgrading from an earlier version of Windows, if you intend to use Errorhandler.cmd, you must copy this file into the %WINDIR%\\Setup\\Scripts directory on the old installation. This makes sure that if there are errors during the down-level phase of Windows Setup, the commands in Errorhandler.cmd will run.
### Data drive ACL migration
During the configuration pass of Windows Setup, the root access control list (ACL) on drives formatted for NTFS that do not appear to have an operating system will be changed to the default Windows XP ACL format. The ACLs on these drives are changed to enable authenticated users to modify access on folders and files.
Changing the ACLs may affect the performance of Windows Setup if the default Windows XP ACLs are applied to a partition with a large amount of data. Because of these performance concerns, you can change the following registry value to disable this feature:
``` syntax
Key: HKLM\System\Setup
Type: REG_DWORD
Value: "DDACLSys_Disabled" = 1
```
This feature is disabled if this registry key value exists and is configured to `1`.
## Related topics
[User State Migration Tool (USMT) Overview Topics](../usmt/usmt-topics.md)<BR>
[Windows 10 upgrade paths](windows-10-upgrade-paths.md)<BR>
[Windows 10 edition upgrade](windows-10-edition-upgrades.md)
 
 

3
windows/deployment/usmt/getting-started-with-the-user-state-migration-tool.md
View File

@ -1,6 +1,7 @@
---
title: User State Migration Tool (USMT) - Getting Started (Windows 10)
description: Getting Started with the User State Migration Tool (USMT)
description: This article will guide you through the general process that you should follow to migrate files and settings. in Windows.
ms.custom: seo-marvel-apr2020
ms.assetid: 506ff1d2-94b8-4460-8672-56aad963504b
ms.reviewer:
manager: laurawi

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

@ -1,172 +1,174 @@
---
title: Migrate Application Settings (Windows 10)
description: Migrate Application Settings
ms.assetid: 28f70a83-0a3e-4a6b-968a-2b78ccd3cc07
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# Migrate Application Settings
You can create a custom .xml file to migrate specific line-of-business application settings or to change the default migration behavior of the User State Migration Tool (USMT) 10.0. For ScanState and LoadState to use this file, you must specify the custom .xml file on both command lines.
This topic defines how to author a custom migration .xml file that migrates the settings of an application that is not migrated by default using MigApp.xml. You should migrate the settings after you install the application, but before the user runs the application for the first time.
This topic does not 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 does not 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 topic does not discuss how to migrate the .doc files and templates themselves.
## <a href="" id="createxmlmigappsettings"></a>In this Topic
- [Before You Begin](#bkmk-beforebegin)
- [Step 1: Verify that the application is installed on the source computer, and that it is the same version as the version to be installed on the destination computer](#bkmk-step1).
- [Step 2: Identify settings to collect and determine where each setting is stored on the computer](#bkmk-step2).
- [Step 3: Identify how to apply the gathered settings](#bkmk-step3).
- [Step 4: Create the migration XML component for the application](#bkmk-step4).
- [Step 5: Test the application settings migration](#bkmk-step5).
## <a href="" id="bkmk-beforebegin"></a>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 are planning on migrating from Windows 7 to Windows 10, install Windows 7 on your test computer and then install the application.
## <a href="" id="bkmk-step1"></a>Step 1: Verify that the application is installed on the source computer, and that it is the same version as the version to be installed on the destination computer.
Before USMT migrates the settings, you need it to check whether the application is installed on the source computer, and that it is the correct version. If the application is not installed on the source computer, you probably do not want USMT to spend time searching for the application’s settings. More importantly, if USMT collects settings for an application that is not installed, it may migrate settings that will cause the destination computer to function incorrectly. You should also investigate whether there is more than one version of the application. This is because the new version may not store the settings in the same place, which may lead to unexpected results on the destination computer.
There are many ways to detect if an application is installed. The best practice is to check for an application uninstall key in the registry, and then search the computer for the executable file that installed the application. It is important that you check for both of these items, because sometimes different versions of the same application share the same uninstall key. So even if the key is there, it may not correspond to the version of the application that you want.
### Check the registry for an application uninstall key.
When many applications are installed (especially those installed using the Microsoft® Windows® Installer technology), an application uninstall key is created under **HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall**. For example, when Adobe Acrobat Reader 7 is installed, it creates a key named **HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall \\{AC76BA86-7AD7-1033-7B44-A70000000000}**. Therefore, if a computer contains this key, then Adobe Acrobat Reader 7 is installed on the computer. You can check for the existence of a registry key using the **DoesObjectExist** helper function.
Usually, you can find this key by searching under **HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall** for the name of the application, the name of the application executable file, or for the name of the company that makes the application. You can use the Registry Editor (**Regedit.exe** located in the %**SystemRoot**%) to search the registry.
### Check the file system for the application executable file.
You should also check the application binaries for the executable that installed the application. To do this, you will first need to determine where the application is installed and what the name of the executable is. Most applications store the installation location of the application binaries in the registry. You should search the registry for the name of the application, the name of the application executable, or for the name of the company that makes the application, until you find the registry value that contains the installation path. Once you have determined the path to the application executable, you can use the **DoesFileVersionMatch** helper function to check for the correct version of the application executable. For an example of how to do this, see the Windows Live™ Messenger section of the MigApp.xml file.
## <a href="" id="bkmk-step2"></a>Step 2: Identify settings to collect and determine where each setting is stored on the computer.
Next, you should go through the user interface and make a list of all of the available settings. You can reduce the list if there are settings that you do not want to migrate. To determine where each setting is stored, you will need to change each setting and monitor the activity on the registry and the file system. You do not need to migrate the binary files and registry settings that are made when the application is installed. This is because you will need to reinstall the application onto the destination computer. You only need to migrate those settings that are customizable.
### <a href="" id="bkmkdetermine"></a>
**How To Determine Where Each Setting is Stored**
1. Download a file and registry monitoring tool, such as the Regmon and Filemon tools, from the [Windows Sysinternals Web site](https://go.microsoft.com/fwlink/p/?linkid=36109).
2. Shut down as many applications as possible to limit the registry and file system activity on the computer.
3. Filter the output of the tools so it only displays changes being made by the application.
**Note**  
Most applications store their settings under the user profile. That is, the settings stored in the file system are under the %**UserProfile**% directory, and the settings stored in the registry are under the **HKEY\_CURRENT\_USER** hive. For these applications you can filter the output of the file and registry monitoring tools to show activity only under these locations. This will considerably reduce the amount of output that you will need to examine.
4. Start the monitoring tool(s), change a setting, and look for registry and file system writes that occurred when you changed the setting. Make sure the changes you make actually take effect. For example, if you are changing a setting in Microsoft Word by selecting a check box in the **Options** dialog box, the change typically will not take effect until you close the dialog box by clicking **OK**.
5. When the setting is changed, note the changes to the file system and registry. There may be more than one file or registry values for each setting. You should identify the minimal set of file and registry changes that are required to change this setting. This set of files and registry keys is what you will need to migrate in order to migrate the setting.
**Note**  
Changing an application setting invariably leads to writing to registry keys. If possible, filter the output of the file and registry monitor tool to display only writes to files and registry keys/values.
## <a href="" id="bkmk-step3"></a>Step 3: Identify how to apply the gathered settings.
If the version of the application on the source computer is the same as the one on the destination computer, then you do not have to modify the collected files and registry keys. By default, USMT migrates the files and registry keys from the source location to the corresponding location on the destination computer. For example, if a file was collected from the C:\\Documents and Settings\\User1\\My Documents folder and the profile directory on the destination computer is located at D:\\Users\\User1, then USMT will automatically migrate the file to D:\\Users\\User1\\My Documents. However, you may need to modify the location of some settings in the following three cases:
### Case 1: The version of the application on the destination computer is newer than the one on the source computer.
In this case, the newer version of the application may be able to read the settings from the source computer without modification. That is, the data collected from an older version of the application is sometimes compatible with the newer version of the application. However, you may need to modify the setting location if either of the following is true:
- **The newer version of the application has the ability to import settings from an older version.** This mapping usually happens the first time a user runs the newer version after the settings have been migrated. Some applications do this automatically after settings are migrated; however, other applications will only do this if the application was upgraded from the older version. When the application is upgraded, a set of files and/or registry keys is installed that indicates the older version of the application was previously installed. If you perform a clean installation of the newer version (which is the case in most migrations), the computer does not contain this set of files and registry keys so the mapping does not occur. In order to trick the newer version of the application into initiating this import process, your migration script may need to create these files and/or registry keys on the destination computer.
To identify which files and/or registry keys/values need to be created to cause the import, you should upgrade the older version of the application to the newer one and monitor the changes made to the file system and registry by using the same process described in [How To determine where each setting is stored](#bkmkdetermine). Once you know the set of files that the computer needs, you can use the &lt;`addObjects`&gt; element to add them to the destination computer.
- [The newer version of the application cannot read settings from the source computer and it is also unable to import the settings into the new format.](#bkmkdetermine) In this case, you will need to create a mapping for each setting from the old locations to the new locations. To do this, determine where the newer version stores each setting using the process described in How to determine where each setting is stored. After you have created the mapping, apply the settings to the new location on the destination computer using the &lt;`locationModify`&gt; element, and the **RelativeMove** and **ExactMove** helper functions.
### Case 2: The destination computer already contains settings for the application.
We recommend that you migrate the settings after you install the application, but before the user runs the application for the first time. We recommend this because this ensures that there are no settings on the destination computer when you migrate the settings. If you must install the application before the migration, you should delete any existing settings using the &lt;`destinationCleanup`&gt; element. If for any reason you want to preserve the settings that are on the destination computer, you can use the &lt;`merge`&gt; element and **DestinationPriority** helper function.
### Case 3: The application overwrites settings when it is installed.
We recommend that you migrate the settings after you install the application, but before the user runs the application for the first time. We recommend this because this ensures that there are no settings on the destination computer when you migrate the settings. Also, when some applications are installed, they overwrite any existing settings that are on the computer. In this scenario, if you migrated the data before you installed the application, your customized settings would be overwritten. This is common for applications that store settings in locations that are outside of the user profile (typically these are settings that apply to all users). These universal settings are sometimes overwritten when an application is installed, and they are replaced by default values. To avoid this, you must install these applications before migrating the files and settings to the destination computer. By default with USMT, data from the source computer overwrites data that already exists in the same location on the destination computer.
## <a href="" id="bkmk-step4"></a>Step 4: Create the migration XML component for the application
After you have completed steps 1 through 3, you will need to create a custom migration .xml file that migrates the application based on the information that you now have. You can use the MigApp.xml file as a model because it contains examples of many of the concepts discussed in this topic. You can also see [Custom XML Examples](usmt-custom-xml-examples.md) for another sample .xml file.
**Note**  
We recommend that you create a separate .xml file instead of adding your script to the **MigApp.xml** file. This is because the **MigApp.xml** file is a very large file and it will be difficult to read and edit. In addition, if you reinstall USMT for some reason, the **MigApp.xml** file will be overwritten by the default version of the file and you will lose your customized version.
**Important**  
Some applications store information in the user profile that should not be migrated (for example, application installation paths, the computer name, and so on). You should make sure to exclude these files and registry keys from the migration.
Your script should do the following:
1. Check whether the application and correct version is installed by:
- Searching for the installation uninstall key under **HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall** using the **DoesObjectExist** helper function.
- Checking for the correct version of the application executable file using the **DoesFileVersionMatch** helper function.
2. If the correct version of the application is installed, then ensure that each setting is migrated to the appropriate location on the destination computer.
- If the versions of the applications are the same on both the source and destination computers, migrate each setting using the &lt;`include`&gt; and &lt;`exclude`&gt; elements.
- If the version of the application on the destination computer is newer than the one on the source computer, and the application cannot import the settings, your script should either 1) add the set of files that trigger the import using the &lt;`addObjects`&gt; element or 2) create a mapping that applies the old settings to the correct location on the destination computer using the &lt;`locationModify`&gt; element, and the **RelativeMove** and **ExactMove** helper functions.
- If you must install the application before migrating the settings, delete any settings that are already on the destination computer using the &lt;`destinationCleanup`&gt; element.
For information about the .xml elements and helper functions, see [XML Elements Library](usmt-xml-elements-library.md).
## <a href="" id="bkmk-step5"></a>Step 5: Test the application settings migration
On a test computer, install the operating system that will be installed on the destination computers. For example, if you are planning on migrating from Windows 7 to Windows 10, install Windows 10 and the application. Next, run LoadState on the test computer and verify that all settings migrate. Make corrections if necessary and repeat the process until all the necessary settings are migrated correctly.
To speed up the time it takes to collect and migrate the data, you can migrate only one user at a time, and you can exclude all other components from the migration except the application that you are testing. To specify only User1 in the migration, type: **/ue:\*\\\* /ui:user1**. For more information, see [Exclude Files and Settings](usmt-exclude-files-and-settings.md) and User options in the [ScanState Syntax](usmt-scanstate-syntax.md) topic. To troubleshoot a problem, check the progress log, and the ScanState and LoadState logs, which contain warnings and errors that may point to problems with the migration.
## Related topics
[USMT XML Reference](usmt-xml-reference.md)
[Conflicts and Precedence](usmt-conflicts-and-precedence.md)
[XML Elements Library](usmt-xml-elements-library.md)
[Log Files](usmt-log-files.md)
---
title: Migrate Application Settings (Windows 10)
description: Learn how to author a custom migration .xml file to migrate the settings of an application that is not migrated by default using MigApp.xml.
ms.custom: seo-marvel-apr2020
ms.assetid: 28f70a83-0a3e-4a6b-968a-2b78ccd3cc07
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# Migrate Application Settings
You can create a custom .xml file to migrate specific line-of-business application settings or to change the default migration behavior of the User State Migration Tool (USMT) 10.0. For ScanState and LoadState to use this file, you must specify the custom .xml file on both command lines.
This topic defines how to author a custom migration .xml file that migrates the settings of an application that is not migrated by default using MigApp.xml. You should migrate the settings after you install the application, but before the user runs the application for the first time.
This topic does not 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 does not 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 topic does not discuss how to migrate the .doc files and templates themselves.
## <a href="" id="createxmlmigappsettings"></a>In this Topic
- [Before You Begin](#bkmk-beforebegin)
- [Step 1: Verify that the application is installed on the source computer, and that it is the same version as the version to be installed on the destination computer](#bkmk-step1).
- [Step 2: Identify settings to collect and determine where each setting is stored on the computer](#bkmk-step2).
- [Step 3: Identify how to apply the gathered settings](#bkmk-step3).
- [Step 4: Create the migration XML component for the application](#bkmk-step4).
- [Step 5: Test the application settings migration](#bkmk-step5).
## <a href="" id="bkmk-beforebegin"></a>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 are planning on migrating from Windows 7 to Windows 10, install Windows 7 on your test computer and then install the application.
## <a href="" id="bkmk-step1"></a>Step 1: Verify that the application is installed on the source computer, and that it is the same version as the version to be installed on the destination computer.
Before USMT migrates the settings, you need it to check whether the application is installed on the source computer, and that it is the correct version. If the application is not installed on the source computer, you probably do not want USMT to spend time searching for the application’s settings. More importantly, if USMT collects settings for an application that is not installed, it may migrate settings that will cause the destination computer to function incorrectly. You should also investigate whether there is more than one version of the application. This is because the new version may not store the settings in the same place, which may lead to unexpected results on the destination computer.
There are many ways to detect if an application is installed. The best practice is to check for an application uninstall key in the registry, and then search the computer for the executable file that installed the application. It is important that you check for both of these items, because sometimes different versions of the same application share the same uninstall key. So even if the key is there, it may not correspond to the version of the application that you want.
### Check the registry for an application uninstall key.
When many applications are installed (especially those installed using the Microsoft® Windows® Installer technology), an application uninstall key is created under **HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall**. For example, when Adobe Acrobat Reader 7 is installed, it creates a key named **HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall \\{AC76BA86-7AD7-1033-7B44-A70000000000}**. Therefore, if a computer contains this key, then Adobe Acrobat Reader 7 is installed on the computer. You can check for the existence of a registry key using the **DoesObjectExist** helper function.
Usually, you can find this key by searching under **HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall** for the name of the application, the name of the application executable file, or for the name of the company that makes the application. You can use the Registry Editor (**Regedit.exe** located in the %**SystemRoot**%) to search the registry.
### Check the file system for the application executable file.
You should also check the application binaries for the executable that installed the application. To do this, you will first need to determine where the application is installed and what the name of the executable is. Most applications store the installation location of the application binaries in the registry. You should search the registry for the name of the application, the name of the application executable, or for the name of the company that makes the application, until you find the registry value that contains the installation path. Once you have determined the path to the application executable, you can use the **DoesFileVersionMatch** helper function to check for the correct version of the application executable. For an example of how to do this, see the Windows Live™ Messenger section of the MigApp.xml file.
## <a href="" id="bkmk-step2"></a>Step 2: Identify settings to collect and determine where each setting is stored on the computer.
Next, you should go through the user interface and make a list of all of the available settings. You can reduce the list if there are settings that you do not want to migrate. To determine where each setting is stored, you will need to change each setting and monitor the activity on the registry and the file system. You do not need to migrate the binary files and registry settings that are made when the application is installed. This is because you will need to reinstall the application onto the destination computer. You only need to migrate those settings that are customizable.
### <a href="" id="bkmkdetermine"></a>
**How To Determine Where Each Setting is Stored**
1. Download a file and registry monitoring tool, such as the Regmon and Filemon tools, from the [Windows Sysinternals Web site](https://go.microsoft.com/fwlink/p/?linkid=36109).
2. Shut down as many applications as possible to limit the registry and file system activity on the computer.
3. Filter the output of the tools so it only displays changes being made by the application.
**Note**  
Most applications store their settings under the user profile. That is, the settings stored in the file system are under the %**UserProfile**% directory, and the settings stored in the registry are under the **HKEY\_CURRENT\_USER** hive. For these applications you can filter the output of the file and registry monitoring tools to show activity only under these locations. This will considerably reduce the amount of output that you will need to examine.
4. Start the monitoring tool(s), change a setting, and look for registry and file system writes that occurred when you changed the setting. Make sure the changes you make actually take effect. For example, if you are changing a setting in Microsoft Word by selecting a check box in the **Options** dialog box, the change typically will not take effect until you close the dialog box by clicking **OK**.
5. When the setting is changed, note the changes to the file system and registry. There may be more than one file or registry values for each setting. You should identify the minimal set of file and registry changes that are required to change this setting. This set of files and registry keys is what you will need to migrate in order to migrate the setting.
**Note**  
Changing an application setting invariably leads to writing to registry keys. If possible, filter the output of the file and registry monitor tool to display only writes to files and registry keys/values.
## <a href="" id="bkmk-step3"></a>Step 3: Identify how to apply the gathered settings.
If the version of the application on the source computer is the same as the one on the destination computer, then you do not have to modify the collected files and registry keys. By default, USMT migrates the files and registry keys from the source location to the corresponding location on the destination computer. For example, if a file was collected from the C:\\Documents and Settings\\User1\\My Documents folder and the profile directory on the destination computer is located at D:\\Users\\User1, then USMT will automatically migrate the file to D:\\Users\\User1\\My Documents. However, you may need to modify the location of some settings in the following three cases:
### Case 1: The version of the application on the destination computer is newer than the one on the source computer.
In this case, the newer version of the application may be able to read the settings from the source computer without modification. That is, the data collected from an older version of the application is sometimes compatible with the newer version of the application. However, you may need to modify the setting location if either of the following is true:
- **The newer version of the application has the ability to import settings from an older version.** This mapping usually happens the first time a user runs the newer version after the settings have been migrated. Some applications do this automatically after settings are migrated; however, other applications will only do this if the application was upgraded from the older version. When the application is upgraded, a set of files and/or registry keys is installed that indicates the older version of the application was previously installed. If you perform a clean installation of the newer version (which is the case in most migrations), the computer does not contain this set of files and registry keys so the mapping does not occur. In order to trick the newer version of the application into initiating this import process, your migration script may need to create these files and/or registry keys on the destination computer.
To identify which files and/or registry keys/values need to be created to cause the import, you should upgrade the older version of the application to the newer one and monitor the changes made to the file system and registry by using the same process described in [How To determine where each setting is stored](#bkmkdetermine). Once you know the set of files that the computer needs, you can use the &lt;`addObjects`&gt; element to add them to the destination computer.
- [The newer version of the application cannot read settings from the source computer and it is also unable to import the settings into the new format.](#bkmkdetermine) In this case, you will need to create a mapping for each setting from the old locations to the new locations. To do this, determine where the newer version stores each setting using the process described in How to determine where each setting is stored. After you have created the mapping, apply the settings to the new location on the destination computer using the &lt;`locationModify`&gt; element, and the **RelativeMove** and **ExactMove** helper functions.
### Case 2: The destination computer already contains settings for the application.
We recommend that you migrate the settings after you install the application, but before the user runs the application for the first time. We recommend this because this ensures that there are no settings on the destination computer when you migrate the settings. If you must install the application before the migration, you should delete any existing settings using the &lt;`destinationCleanup`&gt; element. If for any reason you want to preserve the settings that are on the destination computer, you can use the &lt;`merge`&gt; element and **DestinationPriority** helper function.
### Case 3: The application overwrites settings when it is installed.
We recommend that you migrate the settings after you install the application, but before the user runs the application for the first time. We recommend this because this ensures that there are no settings on the destination computer when you migrate the settings. Also, when some applications are installed, they overwrite any existing settings that are on the computer. In this scenario, if you migrated the data before you installed the application, your customized settings would be overwritten. This is common for applications that store settings in locations that are outside of the user profile (typically these are settings that apply to all users). These universal settings are sometimes overwritten when an application is installed, and they are replaced by default values. To avoid this, you must install these applications before migrating the files and settings to the destination computer. By default with USMT, data from the source computer overwrites data that already exists in the same location on the destination computer.
## <a href="" id="bkmk-step4"></a>Step 4: Create the migration XML component for the application
After you have completed steps 1 through 3, you will need to create a custom migration .xml file that migrates the application based on the information that you now have. You can use the MigApp.xml file as a model because it contains examples of many of the concepts discussed in this topic. You can also see [Custom XML Examples](usmt-custom-xml-examples.md) for another sample .xml file.
**Note**  
We recommend that you create a separate .xml file instead of adding your script to the **MigApp.xml** file. This is because the **MigApp.xml** file is a very large file and it will be difficult to read and edit. In addition, if you reinstall USMT for some reason, the **MigApp.xml** file will be overwritten by the default version of the file and you will lose your customized version.
**Important**  
Some applications store information in the user profile that should not be migrated (for example, application installation paths, the computer name, and so on). You should make sure to exclude these files and registry keys from the migration.
Your script should do the following:
1. Check whether the application and correct version is installed by:
- Searching for the installation uninstall key under **HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall** using the **DoesObjectExist** helper function.
- Checking for the correct version of the application executable file using the **DoesFileVersionMatch** helper function.
2. If the correct version of the application is installed, then ensure that each setting is migrated to the appropriate location on the destination computer.
- If the versions of the applications are the same on both the source and destination computers, migrate each setting using the &lt;`include`&gt; and &lt;`exclude`&gt; elements.
- If the version of the application on the destination computer is newer than the one on the source computer, and the application cannot import the settings, your script should either 1) add the set of files that trigger the import using the &lt;`addObjects`&gt; element or 2) create a mapping that applies the old settings to the correct location on the destination computer using the &lt;`locationModify`&gt; element, and the **RelativeMove** and **ExactMove** helper functions.
- If you must install the application before migrating the settings, delete any settings that are already on the destination computer using the &lt;`destinationCleanup`&gt; element.
For information about the .xml elements and helper functions, see [XML Elements Library](usmt-xml-elements-library.md).
## <a href="" id="bkmk-step5"></a>Step 5: Test the application settings migration
On a test computer, install the operating system that will be installed on the destination computers. For example, if you are planning on migrating from Windows 7 to Windows 10, install Windows 10 and the application. Next, run LoadState on the test computer and verify that all settings migrate. Make corrections if necessary and repeat the process until all the necessary settings are migrated correctly.
To speed up the time it takes to collect and migrate the data, you can migrate only one user at a time, and you can exclude all other components from the migration except the application that you are testing. To specify only User1 in the migration, type: **/ue:\*\\\* /ui:user1**. For more information, see [Exclude Files and Settings](usmt-exclude-files-and-settings.md) and User options in the [ScanState Syntax](usmt-scanstate-syntax.md) topic. To troubleshoot a problem, check the progress log, and the ScanState and LoadState logs, which contain warnings and errors that may point to problems with the migration.
## Related topics
[USMT XML Reference](usmt-xml-reference.md)
[Conflicts and Precedence](usmt-conflicts-and-precedence.md)
[XML Elements Library](usmt-xml-elements-library.md)
[Log Files](usmt-log-files.md)

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

@ -1,81 +1,83 @@
---
title: Migration Store Types Overview (Windows 10)
description: Migration Store Types Overview
ms.assetid: 3b6ce746-76c6-43ff-8cd5-02ed0ae0cf70
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# Migration Store Types Overview
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 are using a local share, network share, or storage device.
## In This Topic
[Migration Store Types](#bkmk-types)
[Local Store vs. Remote Store](#bkmk-localvremote)
[The /localonly Command-Line Option](#bkmk-localonly)
## <a href="" id="bkmk-types"></a>Migration Store Types
This section describes the three migration store types available in USMT.
### Uncompressed (UNC)
The uncompressed (UNC) migration store is an uncompressed directory with a mirror image of the folder hierarchy being migrated. Each directory and file retains the same access permissions that it has on the local file system. You can use Windows Explorer to view this migration store type. Settings are stored in a catalog file that also describes how to restore files on the destination computer.
### Compressed
The compressed migration store is a single image file that contains all files being migrated and a catalog file. This image file is often encrypted and protected with a password, and cannot be navigated with Windows Explorer.
### Hard-Link
A hard-link migration store functions as a map that defines how a collection of bits on the hard disk are “wired” into the file system. You use the new USMT hard-link migration store in the PC Refresh scenario only. This is because the hard-link migration store is maintained on the local computer while the old operating system is removed and the new operating system is installed. Using a hard-link migration store saves network bandwidth and minimizes the server use needed to accomplish the migration.
You use a command-line option,**/hardlink** , to create a hard-link migration store, which functions the same as an uncompressed migration store. Files are not duplicated on the local computer when user state is captured, nor are they duplicated when user state is restored. For more information, see [Hard-Link Migration Store](usmt-hard-link-migration-store.md).
The following flowchart illustrates the procedural differences between a local migration store and a remote migration store. In this example, a hard-link migration store is used for the local store.
![migration store comparison](images/dep-win8-l-usmt-migrationcomparemigstores.gif)
## <a href="" id="bkmk-localvremote"></a>Local Store vs. Remote Store
If you have enough space and you are migrating the user state back to the same computer, storing data on a local device is normally the best option to reduce server storage costs and network performance issues. You can store the data locally either on a different partition or on a removable device such as a USB flash drive (UFD). Also, depending on the imaging technology that you are using, you might be able to store the data on the partition that is being re-imaged, if the data will be protected from deletion during the process. To increase performance, store the data on high-speed drives that use a high-speed network connection. It is also good practice to ensure that the migration is the only task the server is performing.
If there is not enough local disk space, or if you are moving the user state to another computer, then you must store the data remotely. For example, you can store it in on a shared folder, on removable media such as a UFD drive, or you can store it directly on the destination computer. For example, create and share C:\\store on the destination computer. Then run the ScanState command on the source computer and save the files and settings to \\\\*DestinationComputerName*\\store. Then, run the **LoadState** command on the destination computer and specify **C:\\Store** as the store location. By doing this, you do not need to save the files to a server.
**Important**  
If possible, have users store their data within their %UserProfile%\\My Documents and %UserProfile%\\Application Data folders. This will reduce the chance of USMT missing critical user data that is located in a directory that USMT is not configured to check.
### <a href="" id="bkmk-localonly"></a>The /localonly Command-Line Option
You should use this option to exclude the data from removable drives and network drives mapped on the source computer. For more information about what is excluded when you specify **/LocalOnly**, see [ScanState Syntax](usmt-scanstate-syntax.md).
## Related topics
[Plan Your Migration](usmt-plan-your-migration.md)
---
title: Migration Store Types Overview (Windows 10)
description: In this article, you'll learn about the Migration Store Types available in the User State Migration Tool (USMT).
ms.custom: seo-marvel-apr2020
ms.assetid: 3b6ce746-76c6-43ff-8cd5-02ed0ae0cf70
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# Migration Store Types Overview
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 are using a local share, network share, or storage device.
## In This Topic
[Migration Store Types](#bkmk-types)
[Local Store vs. Remote Store](#bkmk-localvremote)
[The /localonly Command-Line Option](#bkmk-localonly)
## <a href="" id="bkmk-types"></a>Migration Store Types
This section describes the three migration store types available in USMT.
### Uncompressed (UNC)
The uncompressed (UNC) migration store is an uncompressed directory with a mirror image of the folder hierarchy being migrated. Each directory and file retains the same access permissions that it has on the local file system. You can use Windows Explorer to view this migration store type. Settings are stored in a catalog file that also describes how to restore files on the destination computer.
### Compressed
The compressed migration store is a single image file that contains all files being migrated and a catalog file. This image file is often encrypted and protected with a password, and cannot be navigated with Windows Explorer.
### Hard-Link
A hard-link migration store functions as a map that defines how a collection of bits on the hard disk are “wired” into the file system. You use the new USMT hard-link migration store in the PC Refresh scenario only. This is because the hard-link migration store is maintained on the local computer while the old operating system is removed and the new operating system is installed. Using a hard-link migration store saves network bandwidth and minimizes the server use needed to accomplish the migration.
You use a command-line option,**/hardlink** , to create a hard-link migration store, which functions the same as an uncompressed migration store. Files are not duplicated on the local computer when user state is captured, nor are they duplicated when user state is restored. For more information, see [Hard-Link Migration Store](usmt-hard-link-migration-store.md).
The following flowchart illustrates the procedural differences between a local migration store and a remote migration store. In this example, a hard-link migration store is used for the local store.
![migration store comparison](images/dep-win8-l-usmt-migrationcomparemigstores.gif)
## <a href="" id="bkmk-localvremote"></a>Local Store vs. Remote Store
If you have enough space and you are migrating the user state back to the same computer, storing data on a local device is normally the best option to reduce server storage costs and network performance issues. You can store the data locally either on a different partition or on a removable device such as a USB flash drive (UFD). Also, depending on the imaging technology that you are using, you might be able to store the data on the partition that is being re-imaged, if the data will be protected from deletion during the process. To increase performance, store the data on high-speed drives that use a high-speed network connection. It is also good practice to ensure that the migration is the only task the server is performing.
If there is not enough local disk space, or if you are moving the user state to another computer, then you must store the data remotely. For example, you can store it in on a shared folder, on removable media such as a UFD drive, or you can store it directly on the destination computer. For example, create and share C:\\store on the destination computer. Then run the ScanState command on the source computer and save the files and settings to \\\\*DestinationComputerName*\\store. Then, run the **LoadState** command on the destination computer and specify **C:\\Store** as the store location. By doing this, you do not need to save the files to a server.
**Important**  
If possible, have users store their data within their %UserProfile%\\My Documents and %UserProfile%\\Application Data folders. This will reduce the chance of USMT missing critical user data that is located in a directory that USMT is not configured to check.
### <a href="" id="bkmk-localonly"></a>The /localonly Command-Line Option
You should use this option to exclude the data from removable drives and network drives mapped on the source computer. For more information about what is excluded when you specify **/LocalOnly**, see [ScanState Syntax](usmt-scanstate-syntax.md).
## Related topics
[Plan Your Migration](usmt-plan-your-migration.md)

3
windows/deployment/usmt/offline-migration-reference.md
View File

@ -1,6 +1,7 @@
---
title: Offline Migration Reference (Windows 10)
description: Offline Migration Reference
description: This article is a reference guide for Offline Migration.
ms.custom: seo-marvel-apr2020
ms.assetid: f347547c-d601-4c3e-8f2d-0138edeacfda
ms.reviewer:
manager: laurawi

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

@ -1,6 +1,7 @@
---
title: Understanding Migration XML Files (Windows 10)
description: Understanding Migration XML Files
description: Learn about the Migration XML Files. Migration XML Files provide instructions on where & how the USMT tools should gather & apply files & settings.
ms.custom: seo-marvel-apr2020
ms.assetid: d3d1fe89-085c-4da8-9657-fd54b8bfc4b7
ms.reviewer:
manager: laurawi

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

@ -1,6 +1,7 @@
---
title: USMT Best Practices (Windows 10)
description: USMT Best Practices
description: This article discusses general and security-related best practices when using User State Migration Tool (USMT) 10.0.
ms.custom: seo-marvel-apr2020
ms.assetid: e3cb1e78-4230-4eae-b179-e6e9160542d2
ms.reviewer:
manager: laurawi

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

@ -1,65 +1,67 @@
---
title: Choose a Migration Store Type (Windows 10)
description: Choose a Migration Store Type
ms.assetid: 4e163e90-9c57-490b-b849-2ed52ab6765f
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# Choose a Migration Store Type
One of the main considerations for planning your migration is to 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, and how much space is needed to create and host the migration store, whether you are using a local share, network share, or storage device. The final consideration is ensuring that user date integrity is maintained by encrypting the migration store.
## In This Section
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<tbody>
<tr class="odd">
<td align="left"><p><a href="migration-store-types-overview.md" data-raw-source="[Migration Store Types Overview](migration-store-types-overview.md)">Migration Store Types Overview</a></p></td>
<td align="left"><p>Choose the migration store type that works best for your needs and migration scenario.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-estimate-migration-store-size.md" data-raw-source="[Estimate Migration Store Size](usmt-estimate-migration-store-size.md)">Estimate Migration Store Size</a></p></td>
<td align="left"><p>Estimate the amount of disk space needed for computers in your organization based on information about your organization&#39;s infrastructure.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="usmt-hard-link-migration-store.md" data-raw-source="[Hard-Link Migration Store](usmt-hard-link-migration-store.md)">Hard-Link Migration Store</a></p></td>
<td align="left"><p>Learn about hard-link migration stores and the scenarios in which they are used.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-migration-store-encryption.md" data-raw-source="[Migration Store Encryption](usmt-migration-store-encryption.md)">Migration Store Encryption</a></p></td>
<td align="left"><p>Learn about the using migration store encryption to protect user data integrity during a migration.</p></td>
</tr>
</tbody>
</table>
## Related topics
[Plan Your Migration](usmt-plan-your-migration.md)
[User State Migration Tool (USMT) How-to topics](usmt-how-to.md)
---
title: Choose a Migration Store Type (Windows 10)
description: This article guides you through the considerations you need to make when you choose a Migration Store Type.
ms.custom: seo-marvel-apr2020
ms.assetid: 4e163e90-9c57-490b-b849-2ed52ab6765f
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# Choose a Migration Store Type
One of the main considerations for planning your migration is to 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, and how much space is needed to create and host the migration store, whether you are using a local share, network share, or storage device. The final consideration is ensuring that user date integrity is maintained by encrypting the migration store.
## In This Section
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<tbody>
<tr class="odd">
<td align="left"><p><a href="migration-store-types-overview.md" data-raw-source="[Migration Store Types Overview](migration-store-types-overview.md)">Migration Store Types Overview</a></p></td>
<td align="left"><p>Choose the migration store type that works best for your needs and migration scenario.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-estimate-migration-store-size.md" data-raw-source="[Estimate Migration Store Size](usmt-estimate-migration-store-size.md)">Estimate Migration Store Size</a></p></td>
<td align="left"><p>Estimate the amount of disk space needed for computers in your organization based on information about your organization&#39;s infrastructure.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="usmt-hard-link-migration-store.md" data-raw-source="[Hard-Link Migration Store](usmt-hard-link-migration-store.md)">Hard-Link Migration Store</a></p></td>
<td align="left"><p>Learn about hard-link migration stores and the scenarios in which they are used.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-migration-store-encryption.md" data-raw-source="[Migration Store Encryption](usmt-migration-store-encryption.md)">Migration Store Encryption</a></p></td>
<td align="left"><p>Learn about the using migration store encryption to protect user data integrity during a migration.</p></td>
</tr>
</tbody>
</table>
## Related topics
[Plan Your Migration](usmt-plan-your-migration.md)
[User State Migration Tool (USMT) How-to topics](usmt-how-to.md)

110
windows/deployment/usmt/usmt-command-line-syntax.md
View File

@ -1,54 +1,56 @@
---
title: User State Migration Tool (USMT) Command-line Syntax (Windows 10)
description: User State Migration Tool (USMT) Command-line Syntax
ms.assetid: f9d205c9-e824-46c7-8d8b-d7e4b52fd514
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# User State Migration Tool (USMT) Command-line Syntax
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
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<tbody>
<tr class="odd">
<td align="left"><p><a href="usmt-scanstate-syntax.md" data-raw-source="[ScanState Syntax](usmt-scanstate-syntax.md)">ScanState Syntax</a></p></td>
<td align="left"><p>Lists the command-line options for using the ScanState tool.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-loadstate-syntax.md" data-raw-source="[LoadState Syntax](usmt-loadstate-syntax.md)">LoadState Syntax</a></p></td>
<td align="left"><p>Lists the command-line options for using the LoadState tool.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="usmt-utilities.md" data-raw-source="[UsmtUtils Syntax](usmt-utilities.md)">UsmtUtils Syntax</a></p></td>
<td align="left"><p>Lists the command-line options for using the UsmtUtils tool.</p></td>
</tr>
</tbody>
</table>
---
title: User State Migration Tool (USMT) Command-line Syntax (Windows 10)
description: In this article, you will learn about the Command-line Syntax in the User State Migration Tool (USMT).
ms.custom: seo-marvel-apr2020
ms.assetid: f9d205c9-e824-46c7-8d8b-d7e4b52fd514
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# User State Migration Tool (USMT) Command-line Syntax
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
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<tbody>
<tr class="odd">
<td align="left"><p><a href="usmt-scanstate-syntax.md" data-raw-source="[ScanState Syntax](usmt-scanstate-syntax.md)">ScanState Syntax</a></p></td>
<td align="left"><p>Lists the command-line options for using the ScanState tool.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-loadstate-syntax.md" data-raw-source="[LoadState Syntax](usmt-loadstate-syntax.md)">LoadState Syntax</a></p></td>
<td align="left"><p>Lists the command-line options for using the LoadState tool.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="usmt-utilities.md" data-raw-source="[UsmtUtils Syntax](usmt-utilities.md)">UsmtUtils Syntax</a></p></td>
<td align="left"><p>Lists the command-line options for using the UsmtUtils tool.</p></td>
</tr>
</tbody>
</table>

682
windows/deployment/usmt/usmt-common-issues.md
View File

@ -1,340 +1,342 @@
---
title: Common Issues (Windows 10)
description: Common Issues
ms.assetid: 5a37e390-8617-4768-9eee-50397fbbb2e1
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.date: 09/19/2017
audience: itpro author: greg-lindsay
ms.topic: article
---
# 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)
[Command-line Problems](#command)
[XML File Problems](#xml)
[Migration Problems](#migration)
[Offline Migration Problems](#bkmk-offline)
[Hard Link Migration Problems](#bkmk-hardlink)
[USMT does not migrate the Start layout](#usmt-does-not-migrate-the-start-layout)
## 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.
In most cases, the ScanState and LoadState logs indicate why a USMT migration is failing. We recommend that you use the **/v**<em>:5</em> 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**<em>:5</em> 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 in 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).
- Use the **/Extract** option in the UsmtUtils tool to extract files from a compressed migration store. For more information, see [Extract Files from a Compressed USMT Migration Store](usmt-extract-files-from-a-compressed-migration-store.md).
- Create a progress log using the **/Progress** option to monitor your migration.
- 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.
- Log off after you run the LoadState tool. Some settings—for example, fonts, desktop backgrounds, and screen-saver settings—will not 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.
**Note**
USMT will fail if it cannot 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 did not migrate.
## <a href="" id="user"></a>User Account Problems
The following sections describe common user account problems. Expand the section to see recommended solutions.
### I'm having problems creating local accounts on the destination computer.
**Resolution:** For more information about creating accounts and migrating local accounts, see [Migrate User Accounts](usmt-migrate-user-accounts.md).
### Not all of the user accounts were migrated to the destination computer.
**Causes/Resolutions** There are two possible causes for this problem:
When running the ScanState tool on Windows Vista, or 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. Click **Start**.
2. Click **All Programs**.
3. Click **Accessories**.
4. Right-click **Command Prompt**.
5. Click **Run as administrator**.
Then specify your LoadState or ScanState command. If you do not run USMT in Administrator mode, only the user profile that is logged on will be included in the migration.
Any user accounts on the computer that have not been used will not be migrated. For example, if you add User1 to the computer, but User1 never logs on, then USMT will not migrate the User1 account.
### User accounts that I excluded were migrated to the destination computer.
**Cause:** The command that you specified might have had conflicting **/ui** and **/ue** options. If a user is specified with the **/ui** option and is also specified to be excluded with either the **/ue** or **/uel** options, the user will be included in the migration. For example, if you specify `/ui:domain1\* /ue:domain1\user1`, then User1 will be migrated because the **/ui** option takes precedence.
**Resolution:** For more information about how to use the **/ui** and **/ue** options together, see the examples in the [ScanState Syntax](usmt-scanstate-syntax.md) topic.
### I am using the /uel option, but many accounts are still being included in the migration.
**Cause** The **/uel** option depends on the last modified date of the users' NTUser.dat file. There are scenarios in which this last modified date might not match the users' last logon date.
**Resolution** This is a limitation of the **/uel** option. You might need to exclude these users manually with the **/ue** option.
### 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 will not 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:
1. Open the registry editor by typing `regedit` at an elevated command prompt.
2. Navigate to `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList`.
Each user profile is stored in a System Identifier key under `ProfileList`.
3. Delete the key for the user profile you are trying to remove.
### Files that were not 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.
**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 log on to 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,
``` syntax
loadstate /i:migapp.xml /i:migdocs.xml \\server\share\migration\mystore
/progress:prog.log /l:load.log /mu:fareast\user1:farwest\user1
```
## <a href="" id="command"></a>Command-line Problems
The following sections describe common command-line problems. Expand the section to see recommended solutions.
### I received the following error message: "Usage Error: You cannot 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 do not 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—the store path plus the current directory—does not exceed 256 characters.
### 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 are running the ScanState or LoadState tools from a shared network resource, you will receive this error message if you do not specify **/l**.
**Resolution:** To fix this issue in this scenario, specify the **/l:scan.log** or **/l:load.log** option.
## <a href="" id="xml"></a>XML File Problems
The following sections describe common XML file problems. Expand the section to see recommended solutions.
### I used the /genconfig option to create a Config.xml file, but I see only a few applications and components that are in MigApp.xml. Why does Config.xml not contain all of the same applications?
**Cause:** Config.xml will contain only operating system components, applications, and the user document sections that are in both of the .xml files and are installed on the computer when you run the **/genconfig** option. Otherwise, these applications and components will not appear in the Config.xml file.
**Resolution:** Install all of the desired applications on the computer before running the **/genconfig** option. Then run ScanState with all of the .xml files. For example, run the following:
`scanstate /genconfig:config.xml /i:migdocs.xml /i:migapp.xml /v:5 /l:scanstate.log`
### I am having problems with a custom .xml file that I authored, and I cannot verify that the syntax is correct.
**Resolution:** You can load the XML schema (MigXML.xsd), included with USMT, into your XML authoring tool. For examples, see the [Visual Studio Development Center](https://go.microsoft.com/fwlink/p/?LinkId=74513). Then, load your .xml file in the authoring tool to see if there is a syntax error. In addition, see [USMT XML Reference](usmt-xml-reference.md) for more information about using the XML elements.
### <a href="" id="i-am-using-a-migxml-helper-function--but-the-migration-isn-t-working-the-way-i-expected-it-to---how-do-i-troubleshoot-this-issue-"></a>I am using a MigXML helper function, but the migration isn’t working the way I expected it to.  How do I troubleshoot this issue?
**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 did not 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 which contains the MigXML helper function, or the MigXML helper function title, so that you can locate the related warning in the log file.
## <a href="" id="migration"></a>Migration Problems
The following sections describe common migration problems. Expand the section to see recommended solutions.
### Files that I specified to exclude are still being migrated.
**Cause:** There might be another rule that is including the files. If there is a more specific rule or a conflicting rule, the files will be included in the migration.
**Resolution:** For more information, see [Conflicts and Precedence](usmt-conflicts-and-precedence.md) and the Diagnostic Log section in [Log Files](usmt-log-files.md).
### I specified rules to move a folder to a specific location on the destination computer, but it has not migrated correctly.
**Cause:** There might be an error in the XML syntax.
**Resolution:** You can use the USMT XML schema (MigXML.xsd) to write and validate migration .xml files. Also see the XML examples in the following topics:
[Conflicts and Precedence](usmt-conflicts-and-precedence.md)
[Exclude Files and Settings](usmt-exclude-files-and-settings.md)
[Reroute Files and Settings](usmt-reroute-files-and-settings.md)
[Include Files and Settings](usmt-include-files-and-settings.md)
[Custom XML Examples](usmt-custom-xml-examples.md)
### After LoadState completes, the new desktop background does not appear on the destination computer.
There are three typical causes for this issue.
**Cause \#1:**: Some settings such as fonts, desktop backgrounds, and screen-saver settings are not applied by LoadState until after the destination computer has been restarted.
**Resolution:** To fix this issue, log off, and then log back on to see the migrated desktop background.
**Cause \#2:** If the source computer was running Windows® XP and the desktop background was stored in the *Drive*:\\WINDOWS\\Web\\Wallpaper folder—the default folder where desktop backgrounds are stored in Windows XP—the desktop background will not be migrated. Instead, the destination computer will have the default Windows® desktop background. This will occur even if the desktop background was a custom picture that was added to the \\WINDOWS\\Web\\Wallpaper folder. However, if the end user sets a picture as the desktop background that was saved in another location, for example, My Pictures, then the desktop background will migrate.
**Resolution:** Ensure that the desktop background images that you want to migrate are not in the \\WINDOWS\\Web\\Wallpaper folder on the source computer.
**Cause \#3:** If ScanState was not run on Windows XP from an account with administrative credentials, some operating system settings will not 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 will not migrate.
**Resolution:** Run the ScanState and LoadState tools from within an account with administrative credentials.
### <a href="" id="i-included-migapp-xml-in-the-migration--but-some-pst-files-aren-t-migrating-"></a>I included MigApp.xml in the migration, but some PST files aren’t migrating.
**Cause:** The MigApp.xml file migrates only the PST files that are linked to Outlook profiles.
**Resolution:** To migrate PST files that are not linked to Outlook profiles, you must create a separate migration rule to capture these files.
### USMT does not migrate the Start layout
**Description:** You are using USMT to migrate profiles from one installation of Windows 10 to another installation of Windows 10 on different hardware. After migration, the user signs in on the new device and does not have the Start menu layout they had previously configured.
**Cause:** A code change in the Start Menu with Windows 10 version 1607 and later is incompatible with this USMT function.
**Resolution:** The following workaround is available:
1. With the user signed in, back up the Start layout using the following Windows PowerShell command. You can specify a different path if desired:
```
Export-StartLayout -Path "C:\Layout\user1.xml"
```
2. Migrate the user's profile with USMT.
3. Before the user signs in on the new device, import the Start layout using the following Windows PowerShell command:
```
Import-StartLayout –LayoutPath "C:\Layout\user1.xml" –MountPath %systemdrive%
```
This workaround changes the Default user's Start layout. The workaround does not scale to a mass migrations or multiuser devices, but it can potentially unblock some scenarios. If other users will sign on to the device you should delete layoutmodification.xml from the Default user profile. Otherwise, all users who sign on to that device will use the imported Start layout.
## <a href="" id="bkmk-offline"></a>Offline Migration Problems
The following sections describe common offline migration problems. Expand the section to see recommended solutions.
### Some of my system settings do not migrate in an offline migration.
**Cause:** Some system settings, such as desktop backgrounds and network printers, are not supported in an offline migration. For more information, see [What Does USMT Migrate?](usmt-what-does-usmt-migrate.md)
**Resolution:** In an offline migration, these system settings must be restored manually.
### 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".
**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 do not work the same offline as they do online.
**Cause:** When offline, the DNS server cannot 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:
``` syntax
Scanstate /ui:S1-5-21-124525095-708259637-1543119021*
```
The wild card (\*) at the end of the SID will migrate the *SID*\_Classes key as well.
You can also use patterns for SIDs that identify generic users or groups. For example, you can use the */ue:\*-500* option to exclude the local administrator accounts. For more information about Windows SIDs, see [this Microsoft Web site](https://go.microsoft.com/fwlink/p/?LinkId=190277).
### My script to wipe the disk fails after running the ScanState tool on a 64-bit system.
**Cause:** The HKLM registry hive is not 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:
``` syntax
reg.exe unload hklm\$dest$software
```
## <a href="" id="bkmk-hardlink"></a>Hard-Link Migration Problems
The following sections describe common hard-link migration problems. Expand the section to see recommended solutions.
### EFS files are not restored to the new partition.
**Cause:** EFS files cannot be moved to a new partition with a hard link. The **/efs:hardlink** command-line option is only applicable to files migrated on the same partition.
**Resolution:** Use the **/efs:copyraw** command-line option to copy EFS files during the migration instead of creating hard links, or manually copy the EFS files from the hard-link store.
### The ScanState tool cannot delete a previous hard-link migration store.
**Cause:** The migration store contains hard links to locked files.
**Resolution:** Use the UsmtUtils tool to delete the store or change the store name. For example, at a command prompt, type:
``` syntax
USMTutils /rd <storedir>
```
You should also reboot the machine.
## Related topics
[User State Migration Tool (USMT) Troubleshooting](usmt-troubleshooting.md)
[Frequently Asked Questions](usmt-faq.md)
[Return Codes](usmt-return-codes.md)
[UsmtUtils Syntax](usmt-utilities.md)
---
title: Common Issues (Windows 10)
description: Learn about the common issues that you might see when you run the User State Migration Tool (USMT) 10.0 tools.
ms.custom: seo-marvel-apr2020
ms.assetid: 5a37e390-8617-4768-9eee-50397fbbb2e1
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.date: 09/19/2017
audience: itpro
author: greg-lindsay
ms.topic: article
---
# 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)
[Command-line Problems](#command)
[XML File Problems](#xml)
[Migration Problems](#migration)
[Offline Migration Problems](#bkmk-offline)
[Hard Link Migration Problems](#bkmk-hardlink)
[USMT does not migrate the Start layout](#usmt-does-not-migrate-the-start-layout)
## 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.
In most cases, the ScanState and LoadState logs indicate why a USMT migration is failing. We recommend that you use the **/v**<em>:5</em> 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**<em>:5</em> 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 in 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).
- Use the **/Extract** option in the UsmtUtils tool to extract files from a compressed migration store. For more information, see [Extract Files from a Compressed USMT Migration Store](usmt-extract-files-from-a-compressed-migration-store.md).
- Create a progress log using the **/Progress** option to monitor your migration.
- 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.
- Log off after you run the LoadState tool. Some settings—for example, fonts, desktop backgrounds, and screen-saver settings—will not 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.
**Note**
USMT will fail if it cannot 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 did not migrate.
## <a href="" id="user"></a>User Account Problems
The following sections describe common user account problems. Expand the section to see recommended solutions.
### I'm having problems creating local accounts on the destination computer.
**Resolution:** For more information about creating accounts and migrating local accounts, see [Migrate User Accounts](usmt-migrate-user-accounts.md).
### Not all of the user accounts were migrated to the destination computer.
**Causes/Resolutions** There are two possible causes for this problem:
When running the ScanState tool on Windows Vista, or 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. Click **Start**.
2. Click **All Programs**.
3. Click **Accessories**.
4. Right-click **Command Prompt**.
5. Click **Run as administrator**.
Then specify your LoadState or ScanState command. If you do not run USMT in Administrator mode, only the user profile that is logged on will be included in the migration.
Any user accounts on the computer that have not been used will not be migrated. For example, if you add User1 to the computer, but User1 never logs on, then USMT will not migrate the User1 account.
### User accounts that I excluded were migrated to the destination computer.
**Cause:** The command that you specified might have had conflicting **/ui** and **/ue** options. If a user is specified with the **/ui** option and is also specified to be excluded with either the **/ue** or **/uel** options, the user will be included in the migration. For example, if you specify `/ui:domain1\* /ue:domain1\user1`, then User1 will be migrated because the **/ui** option takes precedence.
**Resolution:** For more information about how to use the **/ui** and **/ue** options together, see the examples in the [ScanState Syntax](usmt-scanstate-syntax.md) topic.
### I am using the /uel option, but many accounts are still being included in the migration.
**Cause** The **/uel** option depends on the last modified date of the users' NTUser.dat file. There are scenarios in which this last modified date might not match the users' last logon date.
**Resolution** This is a limitation of the **/uel** option. You might need to exclude these users manually with the **/ue** option.
### 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 will not 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:
1. Open the registry editor by typing `regedit` at an elevated command prompt.
2. Navigate to `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList`.
Each user profile is stored in a System Identifier key under `ProfileList`.
3. Delete the key for the user profile you are trying to remove.
### Files that were not 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.
**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 log on to 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,
``` syntax
loadstate /i:migapp.xml /i:migdocs.xml \\server\share\migration\mystore
/progress:prog.log /l:load.log /mu:fareast\user1:farwest\user1
```
## <a href="" id="command"></a>Command-line Problems
The following sections describe common command-line problems. Expand the section to see recommended solutions.
### I received the following error message: "Usage Error: You cannot 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 do not 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—the store path plus the current directory—does not exceed 256 characters.
### 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 are running the ScanState or LoadState tools from a shared network resource, you will receive this error message if you do not specify **/l**.
**Resolution:** To fix this issue in this scenario, specify the **/l:scan.log** or **/l:load.log** option.
## <a href="" id="xml"></a>XML File Problems
The following sections describe common XML file problems. Expand the section to see recommended solutions.
### I used the /genconfig option to create a Config.xml file, but I see only a few applications and components that are in MigApp.xml. Why does Config.xml not contain all of the same applications?
**Cause:** Config.xml will contain only operating system components, applications, and the user document sections that are in both of the .xml files and are installed on the computer when you run the **/genconfig** option. Otherwise, these applications and components will not appear in the Config.xml file.
**Resolution:** Install all of the desired applications on the computer before running the **/genconfig** option. Then run ScanState with all of the .xml files. For example, run the following:
`scanstate /genconfig:config.xml /i:migdocs.xml /i:migapp.xml /v:5 /l:scanstate.log`
### I am having problems with a custom .xml file that I authored, and I cannot verify that the syntax is correct.
**Resolution:** You can load the XML schema (MigXML.xsd), included with USMT, into your XML authoring tool. For examples, see the [Visual Studio Development Center](https://go.microsoft.com/fwlink/p/?LinkId=74513). Then, load your .xml file in the authoring tool to see if there is a syntax error. In addition, see [USMT XML Reference](usmt-xml-reference.md) for more information about using the XML elements.
### <a href="" id="i-am-using-a-migxml-helper-function--but-the-migration-isn-t-working-the-way-i-expected-it-to---how-do-i-troubleshoot-this-issue-"></a>I am using a MigXML helper function, but the migration isn’t working the way I expected it to.  How do I troubleshoot this issue?
**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 did not 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 which contains the MigXML helper function, or the MigXML helper function title, so that you can locate the related warning in the log file.
## <a href="" id="migration"></a>Migration Problems
The following sections describe common migration problems. Expand the section to see recommended solutions.
### Files that I specified to exclude are still being migrated.
**Cause:** There might be another rule that is including the files. If there is a more specific rule or a conflicting rule, the files will be included in the migration.
**Resolution:** For more information, see [Conflicts and Precedence](usmt-conflicts-and-precedence.md) and the Diagnostic Log section in [Log Files](usmt-log-files.md).
### I specified rules to move a folder to a specific location on the destination computer, but it has not migrated correctly.
**Cause:** There might be an error in the XML syntax.
**Resolution:** You can use the USMT XML schema (MigXML.xsd) to write and validate migration .xml files. Also see the XML examples in the following topics:
[Conflicts and Precedence](usmt-conflicts-and-precedence.md)
[Exclude Files and Settings](usmt-exclude-files-and-settings.md)
[Reroute Files and Settings](usmt-reroute-files-and-settings.md)
[Include Files and Settings](usmt-include-files-and-settings.md)
[Custom XML Examples](usmt-custom-xml-examples.md)
### After LoadState completes, the new desktop background does not appear on the destination computer.
There are three typical causes for this issue.
**Cause \#1:**: Some settings such as fonts, desktop backgrounds, and screen-saver settings are not applied by LoadState until after the destination computer has been restarted.
**Resolution:** To fix this issue, log off, and then log back on to see the migrated desktop background.
**Cause \#2:** If the source computer was running Windows® XP and the desktop background was stored in the *Drive*:\\WINDOWS\\Web\\Wallpaper folder—the default folder where desktop backgrounds are stored in Windows XP—the desktop background will not be migrated. Instead, the destination computer will have the default Windows® desktop background. This will occur even if the desktop background was a custom picture that was added to the \\WINDOWS\\Web\\Wallpaper folder. However, if the end user sets a picture as the desktop background that was saved in another location, for example, My Pictures, then the desktop background will migrate.
**Resolution:** Ensure that the desktop background images that you want to migrate are not in the \\WINDOWS\\Web\\Wallpaper folder on the source computer.
**Cause \#3:** If ScanState was not run on Windows XP from an account with administrative credentials, some operating system settings will not 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 will not migrate.
**Resolution:** Run the ScanState and LoadState tools from within an account with administrative credentials.
### <a href="" id="i-included-migapp-xml-in-the-migration--but-some-pst-files-aren-t-migrating-"></a>I included MigApp.xml in the migration, but some PST files aren’t migrating.
**Cause:** The MigApp.xml file migrates only the PST files that are linked to Outlook profiles.
**Resolution:** To migrate PST files that are not linked to Outlook profiles, you must create a separate migration rule to capture these files.
### USMT does not migrate the Start layout
**Description:** You are using USMT to migrate profiles from one installation of Windows 10 to another installation of Windows 10 on different hardware. After migration, the user signs in on the new device and does not have the Start menu layout they had previously configured.
**Cause:** A code change in the Start Menu with Windows 10 version 1607 and later is incompatible with this USMT function.
**Resolution:** The following workaround is available:
1. With the user signed in, back up the Start layout using the following Windows PowerShell command. You can specify a different path if desired:
```
Export-StartLayout -Path "C:\Layout\user1.xml"
```
2. Migrate the user's profile with USMT.
3. Before the user signs in on the new device, import the Start layout using the following Windows PowerShell command:
```
Import-StartLayout –LayoutPath "C:\Layout\user1.xml" –MountPath %systemdrive%
```
This workaround changes the Default user's Start layout. The workaround does not scale to a mass migrations or multiuser devices, but it can potentially unblock some scenarios. If other users will sign on to the device you should delete layoutmodification.xml from the Default user profile. Otherwise, all users who sign on to that device will use the imported Start layout.
## <a href="" id="bkmk-offline"></a>Offline Migration Problems
The following sections describe common offline migration problems. Expand the section to see recommended solutions.
### Some of my system settings do not migrate in an offline migration.
**Cause:** Some system settings, such as desktop backgrounds and network printers, are not supported in an offline migration. For more information, see [What Does USMT Migrate?](usmt-what-does-usmt-migrate.md)
**Resolution:** In an offline migration, these system settings must be restored manually.
### 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".
**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 do not work the same offline as they do online.
**Cause:** When offline, the DNS server cannot 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:
``` syntax
Scanstate /ui:S1-5-21-124525095-708259637-1543119021*
```
The wild card (\*) at the end of the SID will migrate the *SID*\_Classes key as well.
You can also use patterns for SIDs that identify generic users or groups. For example, you can use the */ue:\*-500* option to exclude the local administrator accounts. For more information about Windows SIDs, see [this Microsoft Web site](https://go.microsoft.com/fwlink/p/?LinkId=190277).
### My script to wipe the disk fails after running the ScanState tool on a 64-bit system.
**Cause:** The HKLM registry hive is not 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:
``` syntax
reg.exe unload hklm\$dest$software
```
## <a href="" id="bkmk-hardlink"></a>Hard-Link Migration Problems
The following sections describe common hard-link migration problems. Expand the section to see recommended solutions.
### EFS files are not restored to the new partition.
**Cause:** EFS files cannot be moved to a new partition with a hard link. The **/efs:hardlink** command-line option is only applicable to files migrated on the same partition.
**Resolution:** Use the **/efs:copyraw** command-line option to copy EFS files during the migration instead of creating hard links, or manually copy the EFS files from the hard-link store.
### The ScanState tool cannot delete a previous hard-link migration store.
**Cause:** The migration store contains hard links to locked files.
**Resolution:** Use the UsmtUtils tool to delete the store or change the store name. For example, at a command prompt, type:
``` syntax
USMTutils /rd <storedir>
```
You should also reboot the machine.
## Related topics
[User State Migration Tool (USMT) Troubleshooting](usmt-troubleshooting.md)
[Frequently Asked Questions](usmt-faq.md)
[Return Codes](usmt-return-codes.md)
[UsmtUtils Syntax](usmt-utilities.md)

3
windows/deployment/usmt/usmt-common-migration-scenarios.md
View File

@ -1,6 +1,7 @@
---
title: Common Migration Scenarios (Windows 10)
description: Common Migration Scenarios
description: Learn about the common migration scenarios when you perform hardware and/or operating system upgrades using the User State Migration Tool (USMT) 10.0.
ms.custom: seo-marvel-apr2020
ms.assetid: 1d8170d5-e775-4963-b7a5-b55e8987c1e4
ms.reviewer:
manager: laurawi

3
windows/deployment/usmt/usmt-configxml-file.md
View File

@ -1,6 +1,7 @@
---
title: Config.xml File (Windows 10)
description: Config.xml File
description: Learn about the Config.xml, that can be used to customize the store-creation or profile-migration behavior.
ms.custom: seo-marvel-apr2020
ms.assetid: 9dc98e76-5155-4641-bcb3-81915db538e8
ms.reviewer:
manager: laurawi

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

@ -1,6 +1,7 @@
---
title: Conflicts and Precedence (Windows 10)
description: Conflicts and Precedence
description: In this article, you'll learn about the how User State Migration Tool (USMT) 10.0 deals with conflicts and precedence.
ms.custom: seo-marvel-apr2020
ms.assetid: 0e2691a8-ff1e-4424-879b-4d5a2f8a113a
ms.reviewer:
manager: laurawi

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

@ -1,6 +1,7 @@
---
title: Custom XML Examples (Windows 10)
description: Custom XML Examples
description: In this article, you will find out templates for custom XML files that can help you modify migration.
ms.custom: seo-marvel-apr2020
ms.assetid: 48f441d9-6c66-43ef-91e9-7c78cde6fcc0
ms.reviewer:
manager: laurawi

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

@ -1,138 +1,140 @@
---
title: Customize USMT XML Files (Windows 10)
description: Customize USMT XML Files
ms.assetid: d58363c1-fd13-4f65-8b91-9986659dc93e
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# Customize USMT XML Files
## In This Topic
[Overview](#bkmk-overview)
[Migration .xml Files](#bkmk-migxml)
[Custom .xml Files](#bkmk-customxmlfiles)
[The Config.xml File](#bkmk-configxml)
[Examples](#bkmk-examples)
[Additional Information](#bkmk-addlinfo)
## <a href="" id="bkmk-overview"></a>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** and **LoadState** commands. However, you do not 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 do this, modify the Config.xml file and specify the updated file with the **LoadState** command. Then the **LoadState** command will migrate only the files and settings that you want to migrate.
If you leave out an .xml file from the **LoadState** command, all of the data in the store that was migrated with the missing .xml files will be migrated. However, the migration rules that were specified with the **ScanState** command will not apply. For example, if you leave out an .xml file, and it contains a rerouting rule such as: `MigsysHelperFunction.RelativeMove("c:\data", "%CSIDL_PERSONAL%")`, USMT will not reroute the files, and they will be migrated to C:\\data.
To modify the migration, do one or more of the following.
- **Modify the migration .xml files.** If you want to exclude a portion of a component—for example, you want to migrate C:\\ but exclude all of the .mp3 files—or if you want to move data to a new location on the destination computer, modify the .xml files. To modify these files, you must be familiar with the migration rules and syntax. If you want **ScanState** and **LoadState** to use these files, specify them at the command line when each command is entered.
- **Create a custom .xml file.** You can also create a custom .xml file to migrate settings for another application, or to change the migration behavior to suit your needs. For **ScanState** and **LoadState** to use this file, specify them on both command lines.
- **Create and modify a Config.xml file.** Do this if you want to exclude an entire component from the migration. For example, you can use a Config.xml file to exclude the entire My Documents folder, or exclude the settings for an application. Excluding components using a Config.xml file is easier than modifying the migration .xml files because you do not need to be familiar with the migration rules and syntax. In addition, using a Config.xml file is the only way to exclude the operating system settings from being migrated.
For more information about excluding data, see the [Exclude Files and Settings](usmt-exclude-files-and-settings.md) topic.
## <a href="" id="bkmk-migxml"></a>Migration .xml Files
This section describes the migration .xml files that are included with USMT. Each file contains migration rules that control which components are migrated and where they are migrated to on the destination computer.
**Note**  
You can use the asterisk (\*) wildcard character in each of these files. However, you cannot use a question mark (?) as a wildcard character.
- **The MigApp.xml file.** Specify this file with both the **ScanState** and **LoadState** commands to migrate application settings.
- **The MigDocs.xml file.** Specify this file with both the **ScanState** and **LoadState** tools to migrate all user folders and files that are found by the **MigXmlHelper.GenerateDocPatterns** helper function. This helper function finds user data that resides on the root of any drive and in the Users directory. However, it does not find and migrate any application data, program files, or any files in the Windows directory. You can modify the MigDocs.xml file.
- **The MigUser.xml file.** Specify this file with both the **ScanState** and **LoadState** commands to migrate user folders, files, and file types. You can modify the MigUser.xml file. This file does not contain rules that migrate specific user accounts. The only way to specify which user accounts to migrate is on the command line using the **ScanState** and the **LoadState** user options.
**Note**  
Do not use the MigUser.xml and MigDocs.xml files together. For more information, see the [Identify File Types, Files, and Folders](usmt-identify-file-types-files-and-folders.md) and [USMT Best Practices](usmt-best-practices.md) topics.
## <a href="" id="bkmk-customxmlfiles"></a>Custom .xml Files
You can create custom .xml files to customize the migration for your unique needs. For example, you may want to create a custom file to migrate a line-of-business application or to modify the default migration behavior. If you want **ScanState** and **LoadState** to use this file, specify it with both commands. For more information, see the How to Create a Custom .xml File topic.
## <a href="" id="bkmk-configxml"></a>The Config.xml File
The Config.xml file is an optional file that you create using the **/genconfig** option with the **ScanState** command. You should create and modify this file if you want to exclude certain components from the migration. In addition, you must create and modify this file if you want to exclude any of the operating system settings from being migrated. The Config.xml file format is different from that of the migration .xml files because it does not contain any migration rules. It contains only a list of the operating system components, applications, and the user documents that can be migrated. For an example, see the [Config.xml File](usmt-configxml-file.md) topic. For this reason, excluding components using this file is easier than modifying the migration .xml files because you do not need to be familiar with the migration rules and syntax. However, you cannot use wildcard characters in a Config.xml file.
If you want to include all of the default components, you do not need to create the Config.xml file. Alternatively, if you are satisfied with the default migration behavior defined in the MigApp.xml, MigDocs.xml, and MigUser.xml files, and you want to exclude only some components, you can create and modify a Config.xml file and leave the other .xml files in their original state.
When you run the **ScanState** command with the **/genconfig** option, **ScanState** reads the other .xml files that you specify using the **/i** option to create a custom list of components that can be migrated from the computer. This file will contain only operating system components, applications, and the user document sections that are in both of the .xml files and that are installed on the computer when you run the **ScanState** command with the **/genconfig** option. Therefore, you should create this file on a source computer that contains all of the components, applications, and settings that will be present on the destination computers. This will ensure that this file contains every component that can be migrated. The components are organized into sections: &lt;Applications&gt;, &lt;WindowsComponents&gt;, and &lt;Documents&gt;. To choose not to migrate a component, change its entry to `migrate="no"`.
After you create this file, you need to specify it only with the **ScanState** command using the **/Config** option for it to affect the migration. However, if you want to exclude additional data that you migrated to the store, modify the Config.xml file and specify the updated file with the **LoadState** command. For example, if you collected the My Documents folder in the store, but you decide that you do not want to migrate the My Documents folder to a destination computer, you can modify the Config.xml file to indicate `migrate="no"` before you run the **LoadState** command, and the file will not be migrated. For more information about the precedence that takes place when excluding data, see the [Exclude Files and Settings](usmt-exclude-files-and-settings.md) topic.
In addition, note the following functionality with the Config.xml file:
- If a parent component is removed from the migration in the Config.xml file by specifying `migrate="no"`, all of its child components will automatically be removed from the migration, even if the child component is set to `migrate="yes"`.
- If you mistakenly have two lines of code for the same component where one line specifies `migrate="no"` and the other line specifies `migrate="yes"`, the component will be migrated.
- In USMT there are several migration policies that can be configured in the Config.xml file. For example, you can configure additional **&lt;ErrorControl&gt;**, **&lt;ProfileControl&gt;**, and **&lt;HardLinkStoreControl&gt;** options. For more information, see the [Config.xml File](usmt-configxml-file.md) topic.
**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.
### <a href="" id="bkmk-examples"></a>Examples
- The following command creates a Config.xml file in the current directory, but it does not create a store:
`scanstate /i:migapp.xml /i:migdocs.xml /genconfig:config.xml /v:5`
- The following command creates an encrypted store using the Config.xml file and the default migration .xml files:
`scanstate \\server\share\migration\mystore /i:migapp.xml /i:migdocs.xml /o /config:config.xml /v:5 /encrypt /key:"mykey"`
- The following command decrypts the store and migrates the files and settings:
`loadstate \\server\share\migration\mystore /i:migapp.xml /i:migdocs.xml /v:5 /decrypt /key:"mykey"`
## <a href="" id="bkmk-addlinfo"></a>Additional Information
- For more information about how to change the files and settings that are migrated, see the [User State Migration Tool (USMT) How-to topics](usmt-how-to.md).
- For more information about each .xml element, see the [XML Elements Library](usmt-xml-elements-library.md) topic.
- For answers to common questions, see ".xml files" in the [Frequently Asked Questions](usmt-faq.md) topic.
## Related topics
[User State Migration Tool (USMT) Command-line Syntax](usmt-command-line-syntax.md)
[USMT Resources](usmt-resources.md)
---
title: Customize USMT XML Files (Windows 10)
description: In this article, you will learn how to customize User State Migration Tool (USMT) XML files to modify migration.
ms.custom: seo-marvel-apr2020
ms.assetid: d58363c1-fd13-4f65-8b91-9986659dc93e
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# Customize USMT XML Files
## In This Topic
[Overview](#bkmk-overview)
[Migration .xml Files](#bkmk-migxml)
[Custom .xml Files](#bkmk-customxmlfiles)
[The Config.xml File](#bkmk-configxml)
[Examples](#bkmk-examples)
[Additional Information](#bkmk-addlinfo)
## <a href="" id="bkmk-overview"></a>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** and **LoadState** commands. However, you do not 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 do this, modify the Config.xml file and specify the updated file with the **LoadState** command. Then the **LoadState** command will migrate only the files and settings that you want to migrate.
If you leave out an .xml file from the **LoadState** command, all of the data in the store that was migrated with the missing .xml files will be migrated. However, the migration rules that were specified with the **ScanState** command will not apply. For example, if you leave out an .xml file, and it contains a rerouting rule such as: `MigsysHelperFunction.RelativeMove("c:\data", "%CSIDL_PERSONAL%")`, USMT will not reroute the files, and they will be migrated to C:\\data.
To modify the migration, do one or more of the following.
- **Modify the migration .xml files.** If you want to exclude a portion of a component—for example, you want to migrate C:\\ but exclude all of the .mp3 files—or if you want to move data to a new location on the destination computer, modify the .xml files. To modify these files, you must be familiar with the migration rules and syntax. If you want **ScanState** and **LoadState** to use these files, specify them at the command line when each command is entered.
- **Create a custom .xml file.** You can also create a custom .xml file to migrate settings for another application, or to change the migration behavior to suit your needs. For **ScanState** and **LoadState** to use this file, specify them on both command lines.
- **Create and modify a Config.xml file.** Do this if you want to exclude an entire component from the migration. For example, you can use a Config.xml file to exclude the entire My Documents folder, or exclude the settings for an application. Excluding components using a Config.xml file is easier than modifying the migration .xml files because you do not need to be familiar with the migration rules and syntax. In addition, using a Config.xml file is the only way to exclude the operating system settings from being migrated.
For more information about excluding data, see the [Exclude Files and Settings](usmt-exclude-files-and-settings.md) topic.
## <a href="" id="bkmk-migxml"></a>Migration .xml Files
This section describes the migration .xml files that are included with USMT. Each file contains migration rules that control which components are migrated and where they are migrated to on the destination computer.
**Note**  
You can use the asterisk (\*) wildcard character in each of these files. However, you cannot use a question mark (?) as a wildcard character.
- **The MigApp.xml file.** Specify this file with both the **ScanState** and **LoadState** commands to migrate application settings.
- **The MigDocs.xml file.** Specify this file with both the **ScanState** and **LoadState** tools to migrate all user folders and files that are found by the **MigXmlHelper.GenerateDocPatterns** helper function. This helper function finds user data that resides on the root of any drive and in the Users directory. However, it does not find and migrate any application data, program files, or any files in the Windows directory. You can modify the MigDocs.xml file.
- **The MigUser.xml file.** Specify this file with both the **ScanState** and **LoadState** commands to migrate user folders, files, and file types. You can modify the MigUser.xml file. This file does not contain rules that migrate specific user accounts. The only way to specify which user accounts to migrate is on the command line using the **ScanState** and the **LoadState** user options.
**Note**  
Do not use the MigUser.xml and MigDocs.xml files together. For more information, see the [Identify File Types, Files, and Folders](usmt-identify-file-types-files-and-folders.md) and [USMT Best Practices](usmt-best-practices.md) topics.
## <a href="" id="bkmk-customxmlfiles"></a>Custom .xml Files
You can create custom .xml files to customize the migration for your unique needs. For example, you may want to create a custom file to migrate a line-of-business application or to modify the default migration behavior. If you want **ScanState** and **LoadState** to use this file, specify it with both commands. For more information, see the How to Create a Custom .xml File topic.
## <a href="" id="bkmk-configxml"></a>The Config.xml File
The Config.xml file is an optional file that you create using the **/genconfig** option with the **ScanState** command. You should create and modify this file if you want to exclude certain components from the migration. In addition, you must create and modify this file if you want to exclude any of the operating system settings from being migrated. The Config.xml file format is different from that of the migration .xml files because it does not contain any migration rules. It contains only a list of the operating system components, applications, and the user documents that can be migrated. For an example, see the [Config.xml File](usmt-configxml-file.md) topic. For this reason, excluding components using this file is easier than modifying the migration .xml files because you do not need to be familiar with the migration rules and syntax. However, you cannot use wildcard characters in a Config.xml file.
If you want to include all of the default components, you do not need to create the Config.xml file. Alternatively, if you are satisfied with the default migration behavior defined in the MigApp.xml, MigDocs.xml, and MigUser.xml files, and you want to exclude only some components, you can create and modify a Config.xml file and leave the other .xml files in their original state.
When you run the **ScanState** command with the **/genconfig** option, **ScanState** reads the other .xml files that you specify using the **/i** option to create a custom list of components that can be migrated from the computer. This file will contain only operating system components, applications, and the user document sections that are in both of the .xml files and that are installed on the computer when you run the **ScanState** command with the **/genconfig** option. Therefore, you should create this file on a source computer that contains all of the components, applications, and settings that will be present on the destination computers. This will ensure that this file contains every component that can be migrated. The components are organized into sections: &lt;Applications&gt;, &lt;WindowsComponents&gt;, and &lt;Documents&gt;. To choose not to migrate a component, change its entry to `migrate="no"`.
After you create this file, you need to specify it only with the **ScanState** command using the **/Config** option for it to affect the migration. However, if you want to exclude additional data that you migrated to the store, modify the Config.xml file and specify the updated file with the **LoadState** command. For example, if you collected the My Documents folder in the store, but you decide that you do not want to migrate the My Documents folder to a destination computer, you can modify the Config.xml file to indicate `migrate="no"` before you run the **LoadState** command, and the file will not be migrated. For more information about the precedence that takes place when excluding data, see the [Exclude Files and Settings](usmt-exclude-files-and-settings.md) topic.
In addition, note the following functionality with the Config.xml file:
- If a parent component is removed from the migration in the Config.xml file by specifying `migrate="no"`, all of its child components will automatically be removed from the migration, even if the child component is set to `migrate="yes"`.
- If you mistakenly have two lines of code for the same component where one line specifies `migrate="no"` and the other line specifies `migrate="yes"`, the component will be migrated.
- In USMT there are several migration policies that can be configured in the Config.xml file. For example, you can configure additional **&lt;ErrorControl&gt;**, **&lt;ProfileControl&gt;**, and **&lt;HardLinkStoreControl&gt;** options. For more information, see the [Config.xml File](usmt-configxml-file.md) topic.
**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.
### <a href="" id="bkmk-examples"></a>Examples
- The following command creates a Config.xml file in the current directory, but it does not create a store:
`scanstate /i:migapp.xml /i:migdocs.xml /genconfig:config.xml /v:5`
- The following command creates an encrypted store using the Config.xml file and the default migration .xml files:
`scanstate \\server\share\migration\mystore /i:migapp.xml /i:migdocs.xml /o /config:config.xml /v:5 /encrypt /key:"mykey"`
- The following command decrypts the store and migrates the files and settings:
`loadstate \\server\share\migration\mystore /i:migapp.xml /i:migdocs.xml /v:5 /decrypt /key:"mykey"`
## <a href="" id="bkmk-addlinfo"></a>Additional Information
- For more information about how to change the files and settings that are migrated, see the [User State Migration Tool (USMT) How-to topics](usmt-how-to.md).
- For more information about each .xml element, see the [XML Elements Library](usmt-xml-elements-library.md) topic.
- For answers to common questions, see ".xml files" in the [Frequently Asked Questions](usmt-faq.md) topic.
## Related topics
[User State Migration Tool (USMT) Command-line Syntax](usmt-command-line-syntax.md)
[USMT Resources](usmt-resources.md)

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

@ -1,67 +1,69 @@
---
title: Determine What to Migrate (Windows 10)
description: Determine What to Migrate
ms.assetid: 01ae1d13-c3eb-4618-b39d-ee5d18d55761
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# Determine What to Migrate
By default, User State Migration Tool (USMT) 10.0 migrates the items listed in [What Does USMT Migrate?](usmt-what-does-usmt-migrate.md), depending on the migration .xml files you specify. These default settings are often enough for a basic migration.
However, when considering what settings to migrate, you should also consider what settings you would like the user to be able to configure, if any, and what settings you would like to standardize. Many organizations use their migration as an opportunity to create and begin enforcing a better-managed environment. Some of the settings that users can configure on unmanaged computers prior to the migration can be locked on the new, managed computers. For example, standard wallpaper, Internet Explorer security settings, and desktop configuration are some of the items you can choose to standardize.
To reduce complexity and increase standardization, your organization should consider creating a *standard operating environment (SOE)*. An SOE is a combination of hardware and software that you distribute to all users. This means selecting a baseline for all computers, including standard hardware drivers; core operating system features; core productivity applications, especially if they are under volume licensing; and core utilities. This environment should also include a standard set of security features, as outlined in the organization’s corporate policy. Using a standard operating environment can vastly simplify the migration and reduce overall deployment challenges.
## In This Section
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<tbody>
<tr class="odd">
<td align="left"><p><a href="usmt-identify-users.md" data-raw-source="[Identify Users](usmt-identify-users.md)">Identify Users</a></p></td>
<td align="left"><p>Use command-line options to specify which users to migrate and how they should be migrated.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-identify-application-settings.md" data-raw-source="[Identify Applications Settings](usmt-identify-application-settings.md)">Identify Applications Settings</a></p></td>
<td align="left"><p>Determine which applications you want to migrate and prepare a list of application settings to be migrated.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="usmt-identify-operating-system-settings.md" data-raw-source="[Identify Operating System Settings](usmt-identify-operating-system-settings.md)">Identify Operating System Settings</a></p></td>
<td align="left"><p>Use migration to create a new standard environment on each of the destination computers.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-identify-file-types-files-and-folders.md" data-raw-source="[Identify File Types, Files, and Folders](usmt-identify-file-types-files-and-folders.md)">Identify File Types, Files, and Folders</a></p></td>
<td align="left"><p>Determine and locate the standard, company-specified, and non-standard locations of the file types, files, folders, and settings that you want to migrate.</p></td>
</tr>
</tbody>
</table>
## Related topics
[What Does USMT Migrate?](usmt-what-does-usmt-migrate.md)
---
title: Determine What to Migrate (Windows 10)
description: In this article, you will find guidelines and resources that can help you determine what items to migrate.
ms.custom: seo-marvel-apr2020
ms.assetid: 01ae1d13-c3eb-4618-b39d-ee5d18d55761
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# Determine What to Migrate
By default, User State Migration Tool (USMT) 10.0 migrates the items listed in [What Does USMT Migrate?](usmt-what-does-usmt-migrate.md), depending on the migration .xml files you specify. These default settings are often enough for a basic migration.
However, when considering what settings to migrate, you should also consider what settings you would like the user to be able to configure, if any, and what settings you would like to standardize. Many organizations use their migration as an opportunity to create and begin enforcing a better-managed environment. Some of the settings that users can configure on unmanaged computers prior to the migration can be locked on the new, managed computers. For example, standard wallpaper, Internet Explorer security settings, and desktop configuration are some of the items you can choose to standardize.
To reduce complexity and increase standardization, your organization should consider creating a *standard operating environment (SOE)*. An SOE is a combination of hardware and software that you distribute to all users. This means selecting a baseline for all computers, including standard hardware drivers; core operating system features; core productivity applications, especially if they are under volume licensing; and core utilities. This environment should also include a standard set of security features, as outlined in the organization’s corporate policy. Using a standard operating environment can vastly simplify the migration and reduce overall deployment challenges.
## In This Section
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<tbody>
<tr class="odd">
<td align="left"><p><a href="usmt-identify-users.md" data-raw-source="[Identify Users](usmt-identify-users.md)">Identify Users</a></p></td>
<td align="left"><p>Use command-line options to specify which users to migrate and how they should be migrated.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-identify-application-settings.md" data-raw-source="[Identify Applications Settings](usmt-identify-application-settings.md)">Identify Applications Settings</a></p></td>
<td align="left"><p>Determine which applications you want to migrate and prepare a list of application settings to be migrated.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="usmt-identify-operating-system-settings.md" data-raw-source="[Identify Operating System Settings](usmt-identify-operating-system-settings.md)">Identify Operating System Settings</a></p></td>
<td align="left"><p>Use migration to create a new standard environment on each of the destination computers.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-identify-file-types-files-and-folders.md" data-raw-source="[Identify File Types, Files, and Folders](usmt-identify-file-types-files-and-folders.md)">Identify File Types, Files, and Folders</a></p></td>
<td align="left"><p>Determine and locate the standard, company-specified, and non-standard locations of the file types, files, folders, and settings that you want to migrate.</p></td>
</tr>
</tbody>
</table>
## Related topics
[What Does USMT Migrate?](usmt-what-does-usmt-migrate.md)

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

@ -1,139 +1,141 @@
---
title: Estimate Migration Store Size (Windows 10)
description: Estimate Migration Store Size
ms.assetid: cfb9062b-7a2a-467a-a24e-0b31ce830093
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# Estimate Migration Store Size
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](#bkmk-spacereqs). 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](#bkmk-calcdiskspace). Describes how to use the ScanState tool to determine how big the migration store will be on a particular computer.
- [Estimate Migration Store Size](#bkmk-estmigstoresize). Describes how to estimate the average size of migration stores for the computers in your organization, based on your infrastructure.
## <a href="" id="bkmk-spacereqs"></a>Hard Disk Space Requirements
- **Store.** For non-hard-link migrations, you should ensure that there is enough available disk space at the location where you will 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).
- **Source Computer.** The source computer needs enough available space for the following:
- [E250 megabytes (MB) minimum of hard disk space.](#bkmk-estmigstoresize) Space is needed to support the User State Migration Tool (USMT) 10.0 operations, for example, growth in the page file. Provided that every volume involved in the migration is formatted as NTFS, 250 MB should be enough space to ensure success for almost every hard-link migration, regardless of the size of the migration. The USMT tools will not create the migration store if 250 MB of disk space is not available.
- [Temporary space for USMT to run.](#bkmk-estmigstoresize) Additional disk space for the USMT tools to operate is required. This does not include the minimum 250 MB needed to create the migration store. The amount of temporary space required can be calculated using the ScanState tool.
- [Hard-link migration store.](#bkmk-estmigstoresize) It is not necessary to estimate the size of a hard-link migration store. The only case where the hard-link store can be quite large is when non-NTFS file systems exist on the system and contain data being migrated.
- [Destination computer.](#bkmk-estmigstoresize) The destination computer needs enough available space for the following:
- [Operating system.](#bkmk-estmigstoresize)
- [Applications.](#bkmk-estmigstoresize)
- [Data being migrated.](#bkmk-estmigstoresize) It is important to consider that in addition to the files being migrated, registry information will also require hard disk space for storage.
- [Temporary space for USMT to run.](#bkmk-estmigstoresize) Additional disk space for the USMT tools to operate is required. The amount of temporary space required can be calculated using the ScanState tool.
## <a href="" id="bkmk-calcdiskspace"></a>Calculate Disk Space Requirements using the ScanState Tool
You can use the ScanState tool to calculate the disk space requirements for a particular compressed or uncompressed migration. It is not necessary to estimate the migration store size for a hard-link migration since this method does not create a separate migration store. The ScanState tool provides disk space requirements for the state of the computer at the time the tool is run. The state of the computer may change during day to day use so it is recommended that you use the calculations as an estimate when planning your migration.
**To run the ScanState tool on the source computer with USMT installed,**
1. Open a command prompt with administrator privileges.
2. Navigate to the USMT tools. For example, type
``` syntax
cd /d "C:\Program Files (x86)\Windows Kits\8.0\Assessment and Deployment Kit\User State Migration Tool\<architecture>"
```
Where *&lt;architecture&gt;* is x86 or amd64.
3. Run the **ScanState** tool to generate an XML report of the space requirements. At the command prompt, type
``` syntax
ScanState.exe <StorePath> /p:<path to a file>
```
Where *&lt;StorePath&gt;* is a path to a directory where the migration store will be saved and *&lt;path to a file&gt;* is the path and filename where the XML report for space requirements will be saved. For example,
``` syntax
ScanState.exe c:\store /p:c:\spaceRequirements.xml
```
The migration store will not be created by running this command, but `StorePath` is a required parameter.
The ScanState tool also allows you to estimate disk space requirements based on a customized migration. For example, you might not want to migrate the My Documents folder to the destination computer. You can specify this in a configuration file when you run the ScanState tool. For more information, see [Customize USMT XML Files](usmt-customize-xml-files.md).
**Note**  
To preserve the functionality of existing applications or scripts that require the previous behavior of USMT, the **/p** option, without specifying *&lt;path to a file&gt;* is still available in USMT.
The space requirements report provides two elements, &lt;**storeSize**&gt; and &lt;**temporarySpace**&gt;. The &lt;**temporarySpace**&gt; value shows the disk space, in bytes, that USMT uses to operate during the migration—this does not include the minimum 250 MB needed to support USMT. The &lt;**storeSize**&gt; value shows the disk space, in bytes, required to host the migration store contents on both the source and destination computers. The following example shows a report generated using **/p:***&lt;path to a file&gt;*.
```xml
<?xml version="1.0" encoding="UTF-8"?>
<PreMigration>
<storeSize>
<size clusterSize="4096">11010592768</size>
</storeSize>
<temporarySpace>
<size>58189144</size>
</temporarySpace>
</PreMigration>
```
Additionally, USMT performs a compliance check for a required minimum of 250 MB of available disk space and will not create a store if the compliance check fails.
## <a href="" id="bkmk-estmigstoresize"></a>Estimate Migration Store Size
Determine how much space you will need to store the migrated data. You should base your calculations on the volume of e-mail, personal documents, and system settings for each user. The best way to estimate these is to survey several computers to arrive at an average for the size of the store that you will need.
The amount of space that is required in the store will vary, depending on the local storage strategies your organization uses. For example, one key element that determines the size of migration data sets is e-mail storage. If e-mail is stored centrally, data sets will be smaller. If e-mail is stored locally, such as offline-storage files, data sets will be larger. Mobile users will typically have larger data sets than workstation users. You should perform tests and inventory the network to determine the average data set size in your organization.
**Note**  
You can create a space-estimate file (Usmtsize.txt), by using the legacy **/p** command-line option to estimate the size of the store.
When trying to determine how much disk space you will need, consider the following issues:
- **E-mail** : If users deal with a large volume of e-mail or keep e-mail on their local computers instead of on a mail server, the e-mail can take up as much disk space as all other user files combined. Prior to migrating user data, make sure that users who store e-mail locally synchronize their inboxes with their mail server.
- **User documents**: Frequently, all of a user's documents fit into less than 50 MB of space, depending on the types of files involved. This estimate assumes typical office work, such as word-processing documents and spreadsheets. This estimate can vary substantially based on the types of documents that your organization uses. For example, an architectural firm that predominantly uses computer-aided design (CAD) files needs much more space than a law firm that primarily uses word-processing documents. You do not need to migrate the documents that users store on file servers through mechanisms such as Folder Redirection, as long as users will have access to these locations after the migration.
- **User system settings** Five megabytes is usually adequate space to save the registry settings. This requirement can fluctuate, however, based on the number of applications that have been installed. It is rare, however, for the user-specific portion of the registry to exceed 5 MB.
## Related topics
[Common Migration Scenarios](usmt-common-migration-scenarios.md)
---
title: Estimate Migration Store Size (Windows 10)
description: In this article, you will learn how to estimate size of the migration store using the ScanState tool.
ms.custom: seo-marvel-apr2020
ms.assetid: cfb9062b-7a2a-467a-a24e-0b31ce830093
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# Estimate Migration Store Size
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](#bkmk-spacereqs). 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](#bkmk-calcdiskspace). Describes how to use the ScanState tool to determine how big the migration store will be on a particular computer.
- [Estimate Migration Store Size](#bkmk-estmigstoresize). Describes how to estimate the average size of migration stores for the computers in your organization, based on your infrastructure.
## <a href="" id="bkmk-spacereqs"></a>Hard Disk Space Requirements
- **Store.** For non-hard-link migrations, you should ensure that there is enough available disk space at the location where you will 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).
- **Source Computer.** The source computer needs enough available space for the following:
- [E250 megabytes (MB) minimum of hard disk space.](#bkmk-estmigstoresize) Space is needed to support the User State Migration Tool (USMT) 10.0 operations, for example, growth in the page file. Provided that every volume involved in the migration is formatted as NTFS, 250 MB should be enough space to ensure success for almost every hard-link migration, regardless of the size of the migration. The USMT tools will not create the migration store if 250 MB of disk space is not available.
- [Temporary space for USMT to run.](#bkmk-estmigstoresize) Additional disk space for the USMT tools to operate is required. This does not include the minimum 250 MB needed to create the migration store. The amount of temporary space required can be calculated using the ScanState tool.
- [Hard-link migration store.](#bkmk-estmigstoresize) It is not necessary to estimate the size of a hard-link migration store. The only case where the hard-link store can be quite large is when non-NTFS file systems exist on the system and contain data being migrated.
- [Destination computer.](#bkmk-estmigstoresize) The destination computer needs enough available space for the following:
- [Operating system.](#bkmk-estmigstoresize)
- [Applications.](#bkmk-estmigstoresize)
- [Data being migrated.](#bkmk-estmigstoresize) It is important to consider that in addition to the files being migrated, registry information will also require hard disk space for storage.
- [Temporary space for USMT to run.](#bkmk-estmigstoresize) Additional disk space for the USMT tools to operate is required. The amount of temporary space required can be calculated using the ScanState tool.
## <a href="" id="bkmk-calcdiskspace"></a>Calculate Disk Space Requirements using the ScanState Tool
You can use the ScanState tool to calculate the disk space requirements for a particular compressed or uncompressed migration. It is not necessary to estimate the migration store size for a hard-link migration since this method does not create a separate migration store. The ScanState tool provides disk space requirements for the state of the computer at the time the tool is run. The state of the computer may change during day to day use so it is recommended that you use the calculations as an estimate when planning your migration.
**To run the ScanState tool on the source computer with USMT installed,**
1. Open a command prompt with administrator privileges.
2. Navigate to the USMT tools. For example, type
``` syntax
cd /d "C:\Program Files (x86)\Windows Kits\8.0\Assessment and Deployment Kit\User State Migration Tool\<architecture>"
```
Where *&lt;architecture&gt;* is x86 or amd64.
3. Run the **ScanState** tool to generate an XML report of the space requirements. At the command prompt, type
``` syntax
ScanState.exe <StorePath> /p:<path to a file>
```
Where *&lt;StorePath&gt;* is a path to a directory where the migration store will be saved and *&lt;path to a file&gt;* is the path and filename where the XML report for space requirements will be saved. For example,
``` syntax
ScanState.exe c:\store /p:c:\spaceRequirements.xml
```
The migration store will not be created by running this command, but `StorePath` is a required parameter.
The ScanState tool also allows you to estimate disk space requirements based on a customized migration. For example, you might not want to migrate the My Documents folder to the destination computer. You can specify this in a configuration file when you run the ScanState tool. For more information, see [Customize USMT XML Files](usmt-customize-xml-files.md).
**Note**  
To preserve the functionality of existing applications or scripts that require the previous behavior of USMT, the **/p** option, without specifying *&lt;path to a file&gt;* is still available in USMT.
The space requirements report provides two elements, &lt;**storeSize**&gt; and &lt;**temporarySpace**&gt;. The &lt;**temporarySpace**&gt; value shows the disk space, in bytes, that USMT uses to operate during the migration—this does not include the minimum 250 MB needed to support USMT. The &lt;**storeSize**&gt; value shows the disk space, in bytes, required to host the migration store contents on both the source and destination computers. The following example shows a report generated using **/p:***&lt;path to a file&gt;*.
```xml
<?xml version="1.0" encoding="UTF-8"?>
<PreMigration>
<storeSize>
<size clusterSize="4096">11010592768</size>
</storeSize>
<temporarySpace>
<size>58189144</size>
</temporarySpace>
</PreMigration>
```
Additionally, USMT performs a compliance check for a required minimum of 250 MB of available disk space and will not create a store if the compliance check fails.
## <a href="" id="bkmk-estmigstoresize"></a>Estimate Migration Store Size
Determine how much space you will need to store the migrated data. You should base your calculations on the volume of e-mail, personal documents, and system settings for each user. The best way to estimate these is to survey several computers to arrive at an average for the size of the store that you will need.
The amount of space that is required in the store will vary, depending on the local storage strategies your organization uses. For example, one key element that determines the size of migration data sets is e-mail storage. If e-mail is stored centrally, data sets will be smaller. If e-mail is stored locally, such as offline-storage files, data sets will be larger. Mobile users will typically have larger data sets than workstation users. You should perform tests and inventory the network to determine the average data set size in your organization.
**Note**  
You can create a space-estimate file (Usmtsize.txt), by using the legacy **/p** command-line option to estimate the size of the store.
When trying to determine how much disk space you will need, consider the following issues:
- **E-mail** : If users deal with a large volume of e-mail or keep e-mail on their local computers instead of on a mail server, the e-mail can take up as much disk space as all other user files combined. Prior to migrating user data, make sure that users who store e-mail locally synchronize their inboxes with their mail server.
- **User documents**: Frequently, all of a user's documents fit into less than 50 MB of space, depending on the types of files involved. This estimate assumes typical office work, such as word-processing documents and spreadsheets. This estimate can vary substantially based on the types of documents that your organization uses. For example, an architectural firm that predominantly uses computer-aided design (CAD) files needs much more space than a law firm that primarily uses word-processing documents. You do not need to migrate the documents that users store on file servers through mechanisms such as Folder Redirection, as long as users will have access to these locations after the migration.
- **User system settings** Five megabytes is usually adequate space to save the registry settings. This requirement can fluctuate, however, based on the number of applications that have been installed. It is rare, however, for the user-specific portion of the registry to exceed 5 MB.
## Related topics
[Common Migration Scenarios](usmt-common-migration-scenarios.md)

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

@ -1,279 +1,281 @@
---
title: Exclude Files and Settings (Windows 10)
description: Exclude Files and Settings
ms.assetid: df85baf1-6e29-4995-a4bb-ba3f8f7fed0b
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# Exclude Files and Settings
When you specify the migration .xml files, MigApp.xml, Migdocs, and MigUser.xml, the User State Migration Tool (USMT) 10.0 migrates the settings and components listed, as discussed in [What Does USMT Migrate?](usmt-what-does-usmt-migrate.md) You can create a custom .xml file to further specify what to include or exclude in the migration. In addition you can create a Config.xml file to exclude an entire component from a migration. You cannot, however, exclude users by using the migration .xml files or the Config.xml file. The only way to specify which users to include and exclude is by using the User options on the command line in the ScanState tool. For more information, see [ScanState Syntax](usmt-scanstate-syntax.md).
In this topic:
- [Create a custom .xml file](#create-a-custom-xml-file). You can use the following elements to specify what to exclude:
- include and exclude: You can use the &lt;include&gt; and &lt;exclude&gt; elements to exclude objects with conditions. For example, you can migrate all files located in the C:\\ drive, except any .mp3 files. It is important to remember that [Conflicts and Precedence](usmt-conflicts-and-precedence.md) apply to these elements.
- [unconditionalExclude](#example-1-how-to-migrate-all-files-from-c-except-mp3-files): You can use the &lt;unconditionalExclude&gt; element to globally exclude data. This element takes precedence over all other include and exclude rules in the .xml files. Therefore, this element excludes objects regardless of any other &lt;include&gt; rules that are in the .xml files. For example, you can exclude all .mp3 files on the computer, or you can exclude all files from C:\\UserData.
- [Create a Config.xml File](#create-a-config-xml-file): You can create and modify a Config.xml file to exclude an entire component from the migration. For example, you can use this file to exclude the settings for one of the default applications. In addition, creating and modifying a Config.xml file is the only way to exclude the operating-system settings that are migrated to computers running Windows. Excluding components using this file is easier than modifying the migration .xml files because you do not need to be familiar with the migration rules and syntax.
## Create a custom .xml file
We recommend that you create a custom .xml file instead of modifying the default migration .xml files. When you use a custom .xml file, you can keep your changes separate from the default .xml files, which makes it easier to track your modifications.
### &lt;include&gt; and &lt;exclude&gt;
The migration .xml files, MigApp.xml, MigDocs, and MigUser.xml, contain the &lt;component&gt; element, which typically represents a self-contained component or an application such as Microsoft® Office Outlook® and Word. To exclude the files and registry settings that are associated with these components, use the &lt;include&gt; and &lt;exclude&gt; elements. For example, you can use these elements to migrate all files and settings with pattern X except files and settings with pattern Y, where Y is more specific than X. For the syntax of these elements, see [USMT XML Reference](usmt-xml-reference.md).
**Note**  
If you specify an &lt;exclude&gt; rule, always specify a corresponding &lt;include&gt; rule. Otherwise, if you do not specify an &lt;include&gt; rule, the specific files or settings will not be included. They will already be excluded from the migration. Thus, an unaccompanied &lt;exclude&gt; rule is unnecessary.
- [Example 1: How to migrate all files from C:\\ except .mp3 files](#example-1-how-to-migrate-all-files-from-c-except-mp3-files)
- [Example 2: How to migrate all files located in C:\\Data except files in C:\\Data\\tmp](#example-2-how-to-migrate-all-files-located-in-cdata-except-files-in-cdatatmp)
- [Example 3: How to exclude the files in a folder but include all subfolders](#example-3-how-to-exclude-the-files-in-a-folder-but-include-all-subfolders)
- [Example 4: How to exclude a file from a specific folder](#example-4-how-to-exclude-a-file-from-a-specific-folder)
- [Example 5: How to exclude a file from any location](#example-5-how-to-exclude-a-file-from-any-location)
### Example 1: How to migrate all files from C:\\ except .mp3 files
The following .xml file migrates all files located on the C: drive, except any .mp3 files.
``` xml
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/mp3files">
<!-- This component migrates all files except those with .mp3 extension-->
<component type="Documents" context="UserAndSystem">
<displayName _locID="miguser.sharedvideo">MP3 Files</displayName>
<role role="Data">
<rules>
<include filter='MigXmlHelper.IgnoreIrrelevantLinks()'>
<objectSet>
<pattern type="File">C:\* [*]</pattern>
</objectSet>
</include>
<exclude>
<objectSet>
<pattern type="File">C:\* [*.mp3]</pattern>
</objectSet>
</exclude>
</rules>
</role>
</component>
</migration>
```
### Example 2: How to migrate all files located in C:\\Data except files in C:\\Data\\tmp
The following .xml file migrates all files and subfolders in C:\\Data, except the files and subfolders in C:\\Data\\tmp.
``` xml
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test">
<component type="Documents" context="System">
<displayName _locID="miguser.sharedvideo">Test component</displayName>
<role role="Data">
<rules>
<include>
<objectSet>
<pattern type="File">C:\Data\* [*]</pattern>
</objectSet>
</include>
<exclude>
<objectSet>
<pattern type="File"> C:\Data\temp\* [*]</pattern>
</objectSet>
</exclude>
</rules>
</role>
</component>
</migration>
```
### Example 3: How to exclude the files in a folder but include all subfolders
The following .xml file migrates any subfolders in C:\\EngineeringDrafts, but excludes all files that are in C:\\EngineeringDrafts.
``` xml
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test">
<component type="Documents" context="System">
<displayName>Component to migrate all Engineering Drafts Documents without subfolders</displayName>
<role role="Data">
<rules>
<include>
<objectSet>
<pattern type="File"> C:\EngineeringDrafts\* [*]</pattern>
</objectSet>
</include>
<exclude>
<objectSet>
<pattern type="File"> C:\EngineeringDrafts\ [*]</pattern>
</objectSet>
</exclude>
</rules>
</role>
</component>
</migration>
```
### Example 4: How to exclude a file from a specific folder
The following .xml file migrates all files and subfolders in C:\\EngineeringDrafts, except for the Sample.doc file in C:\\EngineeringDrafts.
``` xml
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test">
<component type="Documents" context="System">
<displayName>Component to migrate all Engineering Drafts Documents except Sample.doc</displayName>
<role role="Data">
<rules>
<include>
<objectSet>
<pattern type="File"> C:\EngineeringDrafts\* [*]</pattern>
</objectSet>
</include>
<exclude>
<objectSet>
<pattern type="File"> C:\EngineeringDrafts\ [Sample.doc]</pattern>
</objectSet>
</exclude>
</rules>
</role>
</component>
</migration>
```
### Example 5: How to exclude a file from any location
To exclude a Sample.doc file from any location on the C: drive, use the &lt;pattern&gt; element. If multiple files exist with the same name on the C: drive, all of these files will be excluded.
``` xml
<pattern type="File"> C:\* [Sample.doc] </pattern>
```
To exclude a Sample.doc file from any drive on the computer, use the &lt;script&gt; element. If multiple files exist with the same name, all of these files will be excluded.
``` xml
<script>MigXmlHelper.GenerateDrivePatterns("* [sample.doc]", "Fixed")</script>
```
#### Examples of how to use XML to exclude files, folders, and registry keys
Here are some examples of how to use XML to exclude files, folders, and registry keys. For more info, see [USMT XML Reference](usmt-xml-reference.md)
**Example 1: How to exclude all .mp3 files**<br>
The following .xml file excludes all .mp3 files from the migration:
``` xml
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/excludefiles">
<component context="System" type="Documents">
<displayName>Test</displayName>
<role role="Data">
<rules>
<unconditionalExclude>
<objectSet>
<script>MigXmlHelper.GenerateDrivePatterns ("* [*.mp3]", "Fixed")</script>
</objectSet>
</unconditionalExclude>
</rules>
</role>
</component>
</migration>
```
**Example 2: How to exclude all of the files on a specific drive**<br>
The following .xml file excludes only the files located on the C: drive.
``` xml
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/allfiles">
<component type="Documents" context="System">
<displayName>Test</displayName>
<role role="Data">
<rules>
<unconditionalExclude>
<objectSet>
<pattern type="File">c:\*[*]</pattern>
</objectSet>
</unconditionalExclude>
</rules>
</role>
</component>
</migration>
```
**Example 3: How to exclude registry keys**<br>
The following .xml file unconditionally excludes the HKEY_CURRENT_USER registry key and all of its subkeys.
``` xml
<?xml version="1.0" encoding="UTF-8"?>
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/miguser">
<component type="Documents" context="User">
<displayName>Test</displayName>
<role role="Data">
<rules>
<include>
<objectSet>
<pattern type="Registry">HKCU\testReg[*]</pattern>
</objectSet>
</include>
<unconditionalExclude>
<objectSet>
<pattern type="Registry">HKCU\*[*]</pattern>
</objectSet>
</unconditionalExclude>
</rules>
</role>
</component>
</migration>
```
**Example 4: How to Exclude `C:\Windows` and `C:\Program Files`**<br>
The following .xml file unconditionally excludes the system folders of `C:\Windows` and `C:\Program Files`. Note that all \*.docx, \*.xls and \*.ppt files will not be migrated because the &lt;unconditionalExclude&gt; element takes precedence over the &lt;include&gt; element.
``` xml
<?xml version="1.0" encoding="UTF-8"?>
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/miguser">
<component type="Documents" context="System">
<displayName>Test</displayName>
<role role="Data">
<rules>
<include>
<objectSet>
<script>MigXmlHelper.GenerateDrivePatterns ("* [*.doc]", "Fixed")</script>
<script>MigXmlHelper.GenerateDrivePatterns ("* [*.xls]", "Fixed")</script>
<script>MigXmlHelper.GenerateDrivePatterns ("* [*.ppt]", "Fixed")</script>
</objectSet>
</include>
<unconditionalExclude>
<objectSet>
<pattern type="File">C:\Program Files\* [*]</pattern>
<pattern type="File">C:\Windows\* [*]</pattern>
</objectSet>
</unconditionalExclude>
</rules>
</role>
</component>
</migration>
```
## Create a Config XML File
You can create and modify a Config.xml file if you want to exclude components from the migration. Excluding components using this file is easier than modifying the migration .xml files because you do not need to be familiar with the migration rules and syntax. Config.xml is an optional file that you can create using the **/genconfig** command-line option with the ScanState tool. For example, you can use the Config.xml file to exclude the settings for one of the default applications. In addition, creating and modifying this file is the only way to exclude the operating-system settings that are migrated to computers running Windows.
- **To exclude the settings for a default application:** Specify `migrate="no"` for the application under the &lt;Applications&gt; section of the Config.xml file.
- **To exclude an operating system setting:** Specify `migrate="no"` for the setting under the &lt;WindowsComponents&gt; section.
- **To exclude My Documents:** Specify `migrate="no"` for My Documents under the &lt;Documents&gt; section. Note that any &lt;include&gt; rules in the .xml files will still apply. For example, if you have a rule that includes all the .docx files in My Documents, then only the .docx files will be migrated, but the rest of the files will not.
See [Config.xml File](usmt-configxml-file.md) for more information.
**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.
## Related topics
- [Customize USMT XML Files](usmt-customize-xml-files.md)
- [USMT XML Reference](usmt-xml-reference.md)
---
title: Exclude Files and Settings (Windows 10)
description: In this article, you will learn how to exclude files and settings from migrating when using the User State Migration Tool (USMT) 10.0.
ms.custom: seo-marvel-apr2020
ms.assetid: df85baf1-6e29-4995-a4bb-ba3f8f7fed0b
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# Exclude Files and Settings
When you specify the migration .xml files, MigApp.xml, Migdocs, and MigUser.xml, the User State Migration Tool (USMT) 10.0 migrates the settings and components listed, as discussed in [What Does USMT Migrate?](usmt-what-does-usmt-migrate.md) You can create a custom .xml file to further specify what to include or exclude in the migration. In addition you can create a Config.xml file to exclude an entire component from a migration. You cannot, however, exclude users by using the migration .xml files or the Config.xml file. The only way to specify which users to include and exclude is by using the User options on the command line in the ScanState tool. For more information, see [ScanState Syntax](usmt-scanstate-syntax.md).
In this topic:
- [Create a custom .xml file](#create-a-custom-xml-file). You can use the following elements to specify what to exclude:
- include and exclude: You can use the &lt;include&gt; and &lt;exclude&gt; elements to exclude objects with conditions. For example, you can migrate all files located in the C:\\ drive, except any .mp3 files. It is important to remember that [Conflicts and Precedence](usmt-conflicts-and-precedence.md) apply to these elements.
- [unconditionalExclude](#example-1-how-to-migrate-all-files-from-c-except-mp3-files): You can use the &lt;unconditionalExclude&gt; element to globally exclude data. This element takes precedence over all other include and exclude rules in the .xml files. Therefore, this element excludes objects regardless of any other &lt;include&gt; rules that are in the .xml files. For example, you can exclude all .mp3 files on the computer, or you can exclude all files from C:\\UserData.
- [Create a Config.xml File](#create-a-config-xml-file): You can create and modify a Config.xml file to exclude an entire component from the migration. For example, you can use this file to exclude the settings for one of the default applications. In addition, creating and modifying a Config.xml file is the only way to exclude the operating-system settings that are migrated to computers running Windows. Excluding components using this file is easier than modifying the migration .xml files because you do not need to be familiar with the migration rules and syntax.
## Create a custom .xml file
We recommend that you create a custom .xml file instead of modifying the default migration .xml files. When you use a custom .xml file, you can keep your changes separate from the default .xml files, which makes it easier to track your modifications.
### &lt;include&gt; and &lt;exclude&gt;
The migration .xml files, MigApp.xml, MigDocs, and MigUser.xml, contain the &lt;component&gt; element, which typically represents a self-contained component or an application such as Microsoft® Office Outlook® and Word. To exclude the files and registry settings that are associated with these components, use the &lt;include&gt; and &lt;exclude&gt; elements. For example, you can use these elements to migrate all files and settings with pattern X except files and settings with pattern Y, where Y is more specific than X. For the syntax of these elements, see [USMT XML Reference](usmt-xml-reference.md).
**Note**  
If you specify an &lt;exclude&gt; rule, always specify a corresponding &lt;include&gt; rule. Otherwise, if you do not specify an &lt;include&gt; rule, the specific files or settings will not be included. They will already be excluded from the migration. Thus, an unaccompanied &lt;exclude&gt; rule is unnecessary.
- [Example 1: How to migrate all files from C:\\ except .mp3 files](#example-1-how-to-migrate-all-files-from-c-except-mp3-files)
- [Example 2: How to migrate all files located in C:\\Data except files in C:\\Data\\tmp](#example-2-how-to-migrate-all-files-located-in-cdata-except-files-in-cdatatmp)
- [Example 3: How to exclude the files in a folder but include all subfolders](#example-3-how-to-exclude-the-files-in-a-folder-but-include-all-subfolders)
- [Example 4: How to exclude a file from a specific folder](#example-4-how-to-exclude-a-file-from-a-specific-folder)
- [Example 5: How to exclude a file from any location](#example-5-how-to-exclude-a-file-from-any-location)
### Example 1: How to migrate all files from C:\\ except .mp3 files
The following .xml file migrates all files located on the C: drive, except any .mp3 files.
``` xml
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/mp3files">
<!-- This component migrates all files except those with .mp3 extension-->
<component type="Documents" context="UserAndSystem">
<displayName _locID="miguser.sharedvideo">MP3 Files</displayName>
<role role="Data">
<rules>
<include filter='MigXmlHelper.IgnoreIrrelevantLinks()'>
<objectSet>
<pattern type="File">C:\* [*]</pattern>
</objectSet>
</include>
<exclude>
<objectSet>
<pattern type="File">C:\* [*.mp3]</pattern>
</objectSet>
</exclude>
</rules>
</role>
</component>
</migration>
```
### Example 2: How to migrate all files located in C:\\Data except files in C:\\Data\\tmp
The following .xml file migrates all files and subfolders in C:\\Data, except the files and subfolders in C:\\Data\\tmp.
``` xml
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test">
<component type="Documents" context="System">
<displayName _locID="miguser.sharedvideo">Test component</displayName>
<role role="Data">
<rules>
<include>
<objectSet>
<pattern type="File">C:\Data\* [*]</pattern>
</objectSet>
</include>
<exclude>
<objectSet>
<pattern type="File"> C:\Data\temp\* [*]</pattern>
</objectSet>
</exclude>
</rules>
</role>
</component>
</migration>
```
### Example 3: How to exclude the files in a folder but include all subfolders
The following .xml file migrates any subfolders in C:\\EngineeringDrafts, but excludes all files that are in C:\\EngineeringDrafts.
``` xml
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test">
<component type="Documents" context="System">
<displayName>Component to migrate all Engineering Drafts Documents without subfolders</displayName>
<role role="Data">
<rules>
<include>
<objectSet>
<pattern type="File"> C:\EngineeringDrafts\* [*]</pattern>
</objectSet>
</include>
<exclude>
<objectSet>
<pattern type="File"> C:\EngineeringDrafts\ [*]</pattern>
</objectSet>
</exclude>
</rules>
</role>
</component>
</migration>
```
### Example 4: How to exclude a file from a specific folder
The following .xml file migrates all files and subfolders in C:\\EngineeringDrafts, except for the Sample.doc file in C:\\EngineeringDrafts.
``` xml
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test">
<component type="Documents" context="System">
<displayName>Component to migrate all Engineering Drafts Documents except Sample.doc</displayName>
<role role="Data">
<rules>
<include>
<objectSet>
<pattern type="File"> C:\EngineeringDrafts\* [*]</pattern>
</objectSet>
</include>
<exclude>
<objectSet>
<pattern type="File"> C:\EngineeringDrafts\ [Sample.doc]</pattern>
</objectSet>
</exclude>
</rules>
</role>
</component>
</migration>
```
### Example 5: How to exclude a file from any location
To exclude a Sample.doc file from any location on the C: drive, use the &lt;pattern&gt; element. If multiple files exist with the same name on the C: drive, all of these files will be excluded.
``` xml
<pattern type="File"> C:\* [Sample.doc] </pattern>
```
To exclude a Sample.doc file from any drive on the computer, use the &lt;script&gt; element. If multiple files exist with the same name, all of these files will be excluded.
``` xml
<script>MigXmlHelper.GenerateDrivePatterns("* [sample.doc]", "Fixed")</script>
```
#### Examples of how to use XML to exclude files, folders, and registry keys
Here are some examples of how to use XML to exclude files, folders, and registry keys. For more info, see [USMT XML Reference](usmt-xml-reference.md)
**Example 1: How to exclude all .mp3 files**<br>
The following .xml file excludes all .mp3 files from the migration:
``` xml
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/excludefiles">
<component context="System" type="Documents">
<displayName>Test</displayName>
<role role="Data">
<rules>
<unconditionalExclude>
<objectSet>
<script>MigXmlHelper.GenerateDrivePatterns ("* [*.mp3]", "Fixed")</script>
</objectSet>
</unconditionalExclude>
</rules>
</role>
</component>
</migration>
```
**Example 2: How to exclude all of the files on a specific drive**<br>
The following .xml file excludes only the files located on the C: drive.
``` xml
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/allfiles">
<component type="Documents" context="System">
<displayName>Test</displayName>
<role role="Data">
<rules>
<unconditionalExclude>
<objectSet>
<pattern type="File">c:\*[*]</pattern>
</objectSet>
</unconditionalExclude>
</rules>
</role>
</component>
</migration>
```
**Example 3: How to exclude registry keys**<br>
The following .xml file unconditionally excludes the HKEY_CURRENT_USER registry key and all of its subkeys.
``` xml
<?xml version="1.0" encoding="UTF-8"?>
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/miguser">
<component type="Documents" context="User">
<displayName>Test</displayName>
<role role="Data">
<rules>
<include>
<objectSet>
<pattern type="Registry">HKCU\testReg[*]</pattern>
</objectSet>
</include>
<unconditionalExclude>
<objectSet>
<pattern type="Registry">HKCU\*[*]</pattern>
</objectSet>
</unconditionalExclude>
</rules>
</role>
</component>
</migration>
```
**Example 4: How to Exclude `C:\Windows` and `C:\Program Files`**<br>
The following .xml file unconditionally excludes the system folders of `C:\Windows` and `C:\Program Files`. Note that all \*.docx, \*.xls and \*.ppt files will not be migrated because the &lt;unconditionalExclude&gt; element takes precedence over the &lt;include&gt; element.
``` xml
<?xml version="1.0" encoding="UTF-8"?>
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/miguser">
<component type="Documents" context="System">
<displayName>Test</displayName>
<role role="Data">
<rules>
<include>
<objectSet>
<script>MigXmlHelper.GenerateDrivePatterns ("* [*.doc]", "Fixed")</script>
<script>MigXmlHelper.GenerateDrivePatterns ("* [*.xls]", "Fixed")</script>
<script>MigXmlHelper.GenerateDrivePatterns ("* [*.ppt]", "Fixed")</script>
</objectSet>
</include>
<unconditionalExclude>
<objectSet>
<pattern type="File">C:\Program Files\* [*]</pattern>
<pattern type="File">C:\Windows\* [*]</pattern>
</objectSet>
</unconditionalExclude>
</rules>
</role>
</component>
</migration>
```
## Create a Config XML File
You can create and modify a Config.xml file if you want to exclude components from the migration. Excluding components using this file is easier than modifying the migration .xml files because you do not need to be familiar with the migration rules and syntax. Config.xml is an optional file that you can create using the **/genconfig** command-line option with the ScanState tool. For example, you can use the Config.xml file to exclude the settings for one of the default applications. In addition, creating and modifying this file is the only way to exclude the operating-system settings that are migrated to computers running Windows.
- **To exclude the settings for a default application:** Specify `migrate="no"` for the application under the &lt;Applications&gt; section of the Config.xml file.
- **To exclude an operating system setting:** Specify `migrate="no"` for the setting under the &lt;WindowsComponents&gt; section.
- **To exclude My Documents:** Specify `migrate="no"` for My Documents under the &lt;Documents&gt; section. Note that any &lt;include&gt; rules in the .xml files will still apply. For example, if you have a rule that includes all the .docx files in My Documents, then only the .docx files will be migrated, but the rest of the files will not.
See [Config.xml File](usmt-configxml-file.md) for more information.
**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.
## Related topics
- [Customize USMT XML Files](usmt-customize-xml-files.md)
- [USMT XML Reference](usmt-xml-reference.md)

246
windows/deployment/usmt/usmt-extract-files-from-a-compressed-migration-store.md
View File

@ -1,122 +1,124 @@
---
title: Extract Files from a Compressed USMT Migration Store (Windows 10)
description: Extract Files from a Compressed USMT Migration Store
ms.assetid: ad9fbd6e-f89e-4444-8538-9b11566b1f33
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# Extract Files from a Compressed USMT Migration Store
When you migrate files and settings during a typical PC-refresh migration, you usually create a compressed migration store file on the intermediate store. This migration store is a single image file that contains all files being migrated as well as a catalog file. To protect the compressed file, you can encrypt it by using different encryption algorithms. When you migrate the file back to the source computer after the operating system is installed, you can run the **Usmtutils** command with the **/extract** option to recover the files from the compressed migration store. You can also use the **Usmtutils** command with the **/extract** option any time you need to recover data from a migration store.
Options used with the **/extract** option can specify:
- The cryptographic algorithm that was used to create the migration store.
- The encryption key or the text file that contains the encryption key.
- 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](#bkmk-extractsyntax)
- [To extract all files from a compressed migration store](#bkmk-extractallfiles)
- [To extract specific file types from an encrypted compressed migration store](#bkmk-extractspecificfiles)
- [To extract all but one, or more, file types from an encrypted compressed migration store](#bkmk-excludefilepattern)
- [To extract file types using the include pattern and the exclude pattern](#bkmk-includeexcludefiles)
### <a href="" id="bkmk-extractsyntax"></a>To run the USMTutils tool with the /extract option
To extract files from the compressed migration store onto the destination computer, use the following USMTutils syntax:
Cd /d &lt;USMTpath&gt; usmtutils /extract &lt;filePath&gt; &lt;destinationPath&gt; \[/i:&lt;includePattern&gt;\] \[/e:&lt;excludePattern&gt;\] \[/l:&lt;logfile&gt;\] \[/decrypt\[:&lt;AlgID&gt;\] {/key:&lt;keystring&gt; | /keyfile:&lt;filename&gt;}\] \[/o\]
Where the placeholders have the following values:
- *&lt;USMTpath&gt;* is the location where you have saved the USMT files and tools.
- *&lt;filePath&gt;* is the location of the migration store.
- *&lt;destination path&gt;* is the location of the file where you want the **/extract** option to put the extracted migration store contents.
- *&lt;includePattern&gt;* specifies the pattern for the files to include in the extraction.
- *&lt;excludePattern&gt;* specifies the pattern for the files to omit from the extraction.
- *&lt;AlgID&gt;* is the cryptographic algorithm that was used to create the migration store on the **ScanState** command line.
- *&lt;logfile&gt;* is the location and name of the log file.
- *&lt;keystring&gt;* is the encryption key that was used to encrypt the migration store.
- *&lt;filename&gt;* is the location and name of the text file that contains the encryption key.
### <a href="" id="bkmk-extractallfiles"></a>To extract all files from a compressed migration store
To extract everything from a compressed migration store to a file on the C:\\ drive, type:
``` syntax
usmtutils /extract D:\MyMigrationStore\USMT\store.mig C:\ExtractedStore
```
### <a href="" id="bkmk-extractspecificfiles"></a>To extract specific file types from an encrypted compressed migration store
To extract specific files, such as .txt and .pdf files, from an encrypted compressed migration store, type:
``` syntax
usmtutils /extract D:\MyMigrationStore\USMT\store.mig /i:"*.txt,*.pdf" C:\ExtractedStore /decrypt /keyfile:D:\encryptionKey.txt
```
In this example, the file is encrypted and the encryption key is located in a text file called encryptionKey.
### <a href="" id="bkmk-excludefilepattern"></a>To extract all but one, or more, file types from an encrypted compressed migration store
To extract all files except for one file type, such as .exe files, from an encrypted compressed migration store, type:
``` syntax
usmtutils /extract D:\MyMigrationStore\USMT\store.mig /e:*.exe C:\ExtractedStore /decrypt:AES_128 /key:password /l:C:\usmtutilslog.txt
```
### <a href="" id="bkmk-includeexcludefiles"></a>To extract file types using the include pattern and the exclude pattern
To extract files from a compressed migration store, and to exclude files of one type (such as .exe files) while including only specific files, use both the include pattern and the exclude pattern, as in this example:
``` syntax
usmtutils /extract D:\MyMigrationStore\USMT\store.mig /i:myProject.* /e:*.exe C:\ExtractedStore /o
```
In this example, if there is a myProject.exe file, it will also be extracted because the include pattern option takes precedence over the exclude pattern option.
## Related topics
[UsmtUtils Syntax](usmt-utilities.md)
[Return Codes](usmt-return-codes.md)
[Verify the Condition of a Compressed Migration Store](verify-the-condition-of-a-compressed-migration-store.md)
 
 
---
title: Extract Files from a Compressed USMT Migration Store (Windows 10)
description: In this article, you will learn how to extract files from a Compressed User State Migration Tool (USMT) migration store.
ms.custom: seo-marvel-apr2020
ms.assetid: ad9fbd6e-f89e-4444-8538-9b11566b1f33
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# Extract Files from a Compressed USMT Migration Store
When you migrate files and settings during a typical PC-refresh migration, you usually create a compressed migration store file on the intermediate store. This migration store is a single image file that contains all files being migrated as well as a catalog file. To protect the compressed file, you can encrypt it by using different encryption algorithms. When you migrate the file back to the source computer after the operating system is installed, you can run the **Usmtutils** command with the **/extract** option to recover the files from the compressed migration store. You can also use the **Usmtutils** command with the **/extract** option any time you need to recover data from a migration store.
Options used with the **/extract** option can specify:
- The cryptographic algorithm that was used to create the migration store.
- The encryption key or the text file that contains the encryption key.
- 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](#bkmk-extractsyntax)
- [To extract all files from a compressed migration store](#bkmk-extractallfiles)
- [To extract specific file types from an encrypted compressed migration store](#bkmk-extractspecificfiles)
- [To extract all but one, or more, file types from an encrypted compressed migration store](#bkmk-excludefilepattern)
- [To extract file types using the include pattern and the exclude pattern](#bkmk-includeexcludefiles)
### <a href="" id="bkmk-extractsyntax"></a>To run the USMTutils tool with the /extract option
To extract files from the compressed migration store onto the destination computer, use the following USMTutils syntax:
Cd /d &lt;USMTpath&gt; usmtutils /extract &lt;filePath&gt; &lt;destinationPath&gt; \[/i:&lt;includePattern&gt;\] \[/e:&lt;excludePattern&gt;\] \[/l:&lt;logfile&gt;\] \[/decrypt\[:&lt;AlgID&gt;\] {/key:&lt;keystring&gt; | /keyfile:&lt;filename&gt;}\] \[/o\]
Where the placeholders have the following values:
- *&lt;USMTpath&gt;* is the location where you have saved the USMT files and tools.
- *&lt;filePath&gt;* is the location of the migration store.
- *&lt;destination path&gt;* is the location of the file where you want the **/extract** option to put the extracted migration store contents.
- *&lt;includePattern&gt;* specifies the pattern for the files to include in the extraction.
- *&lt;excludePattern&gt;* specifies the pattern for the files to omit from the extraction.
- *&lt;AlgID&gt;* is the cryptographic algorithm that was used to create the migration store on the **ScanState** command line.
- *&lt;logfile&gt;* is the location and name of the log file.
- *&lt;keystring&gt;* is the encryption key that was used to encrypt the migration store.
- *&lt;filename&gt;* is the location and name of the text file that contains the encryption key.
### <a href="" id="bkmk-extractallfiles"></a>To extract all files from a compressed migration store
To extract everything from a compressed migration store to a file on the C:\\ drive, type:
``` syntax
usmtutils /extract D:\MyMigrationStore\USMT\store.mig C:\ExtractedStore
```
### <a href="" id="bkmk-extractspecificfiles"></a>To extract specific file types from an encrypted compressed migration store
To extract specific files, such as .txt and .pdf files, from an encrypted compressed migration store, type:
``` syntax
usmtutils /extract D:\MyMigrationStore\USMT\store.mig /i:"*.txt,*.pdf" C:\ExtractedStore /decrypt /keyfile:D:\encryptionKey.txt
```
In this example, the file is encrypted and the encryption key is located in a text file called encryptionKey.
### <a href="" id="bkmk-excludefilepattern"></a>To extract all but one, or more, file types from an encrypted compressed migration store
To extract all files except for one file type, such as .exe files, from an encrypted compressed migration store, type:
``` syntax
usmtutils /extract D:\MyMigrationStore\USMT\store.mig /e:*.exe C:\ExtractedStore /decrypt:AES_128 /key:password /l:C:\usmtutilslog.txt
```
### <a href="" id="bkmk-includeexcludefiles"></a>To extract file types using the include pattern and the exclude pattern
To extract files from a compressed migration store, and to exclude files of one type (such as .exe files) while including only specific files, use both the include pattern and the exclude pattern, as in this example:
``` syntax
usmtutils /extract D:\MyMigrationStore\USMT\store.mig /i:myProject.* /e:*.exe C:\ExtractedStore /o
```
In this example, if there is a myProject.exe file, it will also be extracted because the include pattern option takes precedence over the exclude pattern option.
## Related topics
[UsmtUtils Syntax](usmt-utilities.md)
[Return Codes](usmt-return-codes.md)
[Verify the Condition of a Compressed Migration Store](verify-the-condition-of-a-compressed-migration-store.md)
 
 

276
windows/deployment/usmt/usmt-faq.md
View File

@ -1,137 +1,139 @@
---
title: Frequently Asked Questions (Windows 10)
description: Frequently Asked Questions
ms.assetid: 813c13a7-6818-4e6e-9284-7ee49493241b
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# Frequently Asked Questions
The following sections provide frequently asked questions and recommended solutions for migrations using User State Migration Tool (USMT) 10.0.
## <a href="" id="bkmk-generalquestions"></a>General
### <a href="" id="bkmk-1"></a>How much space is needed on the destination computer?
The destination computer needs enough available space for the following:
- Operating system
- Applications
- Uncompressed store
### <a href="" id="bkmk-directly"></a>Can I store the files and settings directly on the destination computer or do I need a server?
You do not need to save the files to a server. If you are moving the user state to a new computer, you can create the store on a shared folder, on media that you can remove, such as a USB flash drive (UFD), or you can store it directly on the destination computer, as in the following steps:
1. Create and share the directory C:\\store on the destination computer.
2. Run the ScanState tool on the source computer and save the files and settings to \\\\*DestinationComputerName*\\store
3. Run the LoadState tool on the destination computer and specify C:\\store as the store location.
### <a href="" id="no"></a>Can I migrate data between operating systems with different languages?
No. USMT does not support migrating data between operating systems with different languages; the source computer's operating-system language must match the destination computer's operating-system language.
### <a href="" id="bkmk-2"></a>Can I change the location of the temporary directory on the destination computer?
Yes. The environment variable USMT\_WORKING\_DIR can be changed to an alternative temporary directory. There are some offline migration scenarios where this is necessary, for example, when the USMT binaries are located on read-only Windows Preinstallation Environment (WinPE) boot media.
### How do I install USMT?
Because USMT is included in Windows Assessment and Deployment Kit (Windows ADK), you need to install the Windows ADK package on at least one computer in your environment. However, the USMT binaries are designed to be deployed using xcopy. This means that they are installed on a computer simply by recursively copying the USMT directory from the computer containing the Windows ADK to each client computer.
### <a href="" id="uninstall"></a>How do I uninstall USMT?
If you have installed the Windows ADK on the computer, uninstalling Windows ADK will uninstall USMT. For client computers that do not have the Windows ADK installed, you can simply delete the USMT directory to uninstall USMT.
## <a href="" id="bkmk-filesandsettings"></a>Files and Settings
### <a href="" id="bkmk-8"></a>How can I exclude a folder or a certain type of file from the migration?
You can use the **&lt;unconditionalExclude&gt;** element to globally exclude data from the migration. For example, you can use this element to exclude all MP3 files on the computer or to exclude all files from C:\\UserData. This element excludes objects regardless of any other &lt;include&gt; rules that are in the .xml files. For an example, see &lt;unconditionalExclude&gt; in the [Exclude Files and Settings](usmt-exclude-files-and-settings.md) topic. For the syntax of this element, see [XML Elements Library](usmt-xml-elements-library.md).
### <a href="" id="bkmk-location"></a>What happens to files that were located on a drive that does not exist on the destination computer?
USMT migrates the files to the %SystemDrive% while maintaining the correct folder hierarchy. For example, if E:\\data\\File.pst is on the source computer, but the destination computer does not have an E:\\ drive, the file will be migrated to C:\\data\\File.pst, if C:\\ is the system drive. This holds true even when &lt;locationModify&gt; rules attempt to move data to a drive that does not exist on the destination computer.
## <a href="" id="bkmk-usmtxmlfiles"></a>USMT .xml Files
### <a href="" id="bkmk-111"></a>Where can I get examples of USMT .xml files?
The following topics include examples of USMT .xml files:
- [Exclude Files and Settings](usmt-exclude-files-and-settings.md)
- [Reroute Files and Settings](usmt-reroute-files-and-settings.md)
- [Include Files and Settings](usmt-include-files-and-settings.md)
- [Custom XML Examples](usmt-custom-xml-examples.md)
### <a href="" id="bkmk-16"></a>Can I use custom .xml files that were written for USMT 5.0?
Yes. You can use custom .xml files that were written for USMT 5.0 with USMT for Windows 10. However, in order to use new USMT functionality, you must revisit your custom USMT files and refresh them to include the new command-line options and XML elements.
### <a href="" id="how"></a>How can I validate the .xml files?
You can use the USMT XML Schema (MigXML.xsd) to write and validate migration .xml files.
### <a href="" id="bkmk-3"></a>Why must I list the .xml files with both the ScanState and LoadState commands?
The .xml files are not copied to the store as in previous versions of USMT. Because the ScanState and LoadState tools need the .xml files to control the migration, you must specify the same set of .xml files for the **ScanState** and **LoadState** commands. If you used a particular set of mig\*.xml files in the ScanState tool, either called through the "/auto" option, or individually through the "/i" option, then you should use same option to call the exact same mig\*.xml files in the LoadState tool. However, you do not have to specify the Config.xml file, 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 do this, modify the Config.xml file and specify the updated file with the **LoadState** command. **LoadState** will migrate only the files and settings that you want to migrate.
If you exclude an .xml file from the **LoadState** command, then all of the data that is in the store that was migrated with the missing .xml files will be migrated. However, the migration rules that were specified for the **ScanState** command will not apply. For example, if you exclude a MigApp.xml file that has a rerouting rule such as `MigsysHelperFunction.RelativeMove("c:\data", "%CSIDL_PERSONAL%")`, USMT will not reroute the files. Instead, it will migrate them to C:\\data.
### <a href="" id="bkmk-4"></a>Which files can I modify and specify on the command line?
You can specify the MigUser.xml and MigApp.xml files on the command line. You can modify each of these files. The migration of operating system settings is controlled by the manifests, which you cannot modify. If you want to exclude certain operating-system settings or any other components, create and modify the Config.xml file.
### <a href="" id="bkmk-7"></a>What happens if I do not specify the .xml files on the command line?
- **ScanState**
If you do not specify any files with the **ScanState** command, all user accounts and default operating system components are migrated.
- **LoadState**
If you do not specify any files with the **LoadState** command, all data that is in the store is migrated. However, any target-specific migration rules that were specified in .xml files with the **ScanState** command will not apply. For example, if you exclude a MigApp.xml file that has a rerouting rule such as `MigsysHelperFunction.RelativeMove("c:\data", "%CSIDL_PERSONAL%")`, USMT will not reroute the files. Instead, it will migrate them to C:\\data.
## Conflicts and Precedence
### <a href="" id="conflicts"></a>What happens when there are conflicting XML rules or conflicting objects on the destination computer?
For more information, see [Conflicts and Precedence](usmt-conflicts-and-precedence.md).
## Related topics
[User State Migration Tool (USMT) Troubleshooting](usmt-troubleshooting.md)
[Extract Files from a Compressed USMT Migration Store](usmt-extract-files-from-a-compressed-migration-store.md)
[Verify the Condition of a Compressed Migration Store](verify-the-condition-of-a-compressed-migration-store.md)
 
 
---
title: Frequently Asked Questions (Windows 10)
description: This article contains frequently asked questions and recommended solutions for migrations using User State Migration Tool (USMT) 10.0.
ms.custom: seo-marvel-apr2020
ms.assetid: 813c13a7-6818-4e6e-9284-7ee49493241b
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# Frequently Asked Questions
The following sections provide frequently asked questions and recommended solutions for migrations using User State Migration Tool (USMT) 10.0.
## <a href="" id="bkmk-generalquestions"></a>General
### <a href="" id="bkmk-1"></a>How much space is needed on the destination computer?
The destination computer needs enough available space for the following:
- Operating system
- Applications
- Uncompressed store
### <a href="" id="bkmk-directly"></a>Can I store the files and settings directly on the destination computer or do I need a server?
You do not need to save the files to a server. If you are moving the user state to a new computer, you can create the store on a shared folder, on media that you can remove, such as a USB flash drive (UFD), or you can store it directly on the destination computer, as in the following steps:
1. Create and share the directory C:\\store on the destination computer.
2. Run the ScanState tool on the source computer and save the files and settings to \\\\*DestinationComputerName*\\store
3. Run the LoadState tool on the destination computer and specify C:\\store as the store location.
### <a href="" id="no"></a>Can I migrate data between operating systems with different languages?
No. USMT does not support migrating data between operating systems with different languages; the source computer's operating-system language must match the destination computer's operating-system language.
### <a href="" id="bkmk-2"></a>Can I change the location of the temporary directory on the destination computer?
Yes. The environment variable USMT\_WORKING\_DIR can be changed to an alternative temporary directory. There are some offline migration scenarios where this is necessary, for example, when the USMT binaries are located on read-only Windows Preinstallation Environment (WinPE) boot media.
### How do I install USMT?
Because USMT is included in Windows Assessment and Deployment Kit (Windows ADK), you need to install the Windows ADK package on at least one computer in your environment. However, the USMT binaries are designed to be deployed using xcopy. This means that they are installed on a computer simply by recursively copying the USMT directory from the computer containing the Windows ADK to each client computer.
### <a href="" id="uninstall"></a>How do I uninstall USMT?
If you have installed the Windows ADK on the computer, uninstalling Windows ADK will uninstall USMT. For client computers that do not have the Windows ADK installed, you can simply delete the USMT directory to uninstall USMT.
## <a href="" id="bkmk-filesandsettings"></a>Files and Settings
### <a href="" id="bkmk-8"></a>How can I exclude a folder or a certain type of file from the migration?
You can use the **&lt;unconditionalExclude&gt;** element to globally exclude data from the migration. For example, you can use this element to exclude all MP3 files on the computer or to exclude all files from C:\\UserData. This element excludes objects regardless of any other &lt;include&gt; rules that are in the .xml files. For an example, see &lt;unconditionalExclude&gt; in the [Exclude Files and Settings](usmt-exclude-files-and-settings.md) topic. For the syntax of this element, see [XML Elements Library](usmt-xml-elements-library.md).
### <a href="" id="bkmk-location"></a>What happens to files that were located on a drive that does not exist on the destination computer?
USMT migrates the files to the %SystemDrive% while maintaining the correct folder hierarchy. For example, if E:\\data\\File.pst is on the source computer, but the destination computer does not have an E:\\ drive, the file will be migrated to C:\\data\\File.pst, if C:\\ is the system drive. This holds true even when &lt;locationModify&gt; rules attempt to move data to a drive that does not exist on the destination computer.
## <a href="" id="bkmk-usmtxmlfiles"></a>USMT .xml Files
### <a href="" id="bkmk-111"></a>Where can I get examples of USMT .xml files?
The following topics include examples of USMT .xml files:
- [Exclude Files and Settings](usmt-exclude-files-and-settings.md)
- [Reroute Files and Settings](usmt-reroute-files-and-settings.md)
- [Include Files and Settings](usmt-include-files-and-settings.md)
- [Custom XML Examples](usmt-custom-xml-examples.md)
### <a href="" id="bkmk-16"></a>Can I use custom .xml files that were written for USMT 5.0?
Yes. You can use custom .xml files that were written for USMT 5.0 with USMT for Windows 10. However, in order to use new USMT functionality, you must revisit your custom USMT files and refresh them to include the new command-line options and XML elements.
### <a href="" id="how"></a>How can I validate the .xml files?
You can use the USMT XML Schema (MigXML.xsd) to write and validate migration .xml files.
### <a href="" id="bkmk-3"></a>Why must I list the .xml files with both the ScanState and LoadState commands?
The .xml files are not copied to the store as in previous versions of USMT. Because the ScanState and LoadState tools need the .xml files to control the migration, you must specify the same set of .xml files for the **ScanState** and **LoadState** commands. If you used a particular set of mig\*.xml files in the ScanState tool, either called through the "/auto" option, or individually through the "/i" option, then you should use same option to call the exact same mig\*.xml files in the LoadState tool. However, you do not have to specify the Config.xml file, 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 do this, modify the Config.xml file and specify the updated file with the **LoadState** command. **LoadState** will migrate only the files and settings that you want to migrate.
If you exclude an .xml file from the **LoadState** command, then all of the data that is in the store that was migrated with the missing .xml files will be migrated. However, the migration rules that were specified for the **ScanState** command will not apply. For example, if you exclude a MigApp.xml file that has a rerouting rule such as `MigsysHelperFunction.RelativeMove("c:\data", "%CSIDL_PERSONAL%")`, USMT will not reroute the files. Instead, it will migrate them to C:\\data.
### <a href="" id="bkmk-4"></a>Which files can I modify and specify on the command line?
You can specify the MigUser.xml and MigApp.xml files on the command line. You can modify each of these files. The migration of operating system settings is controlled by the manifests, which you cannot modify. If you want to exclude certain operating-system settings or any other components, create and modify the Config.xml file.
### <a href="" id="bkmk-7"></a>What happens if I do not specify the .xml files on the command line?
- **ScanState**
If you do not specify any files with the **ScanState** command, all user accounts and default operating system components are migrated.
- **LoadState**
If you do not specify any files with the **LoadState** command, all data that is in the store is migrated. However, any target-specific migration rules that were specified in .xml files with the **ScanState** command will not apply. For example, if you exclude a MigApp.xml file that has a rerouting rule such as `MigsysHelperFunction.RelativeMove("c:\data", "%CSIDL_PERSONAL%")`, USMT will not reroute the files. Instead, it will migrate them to C:\\data.
## Conflicts and Precedence
### <a href="" id="conflicts"></a>What happens when there are conflicting XML rules or conflicting objects on the destination computer?
For more information, see [Conflicts and Precedence](usmt-conflicts-and-precedence.md).
## Related topics
[User State Migration Tool (USMT) Troubleshooting](usmt-troubleshooting.md)
[Extract Files from a Compressed USMT Migration Store](usmt-extract-files-from-a-compressed-migration-store.md)
[Verify the Condition of a Compressed Migration Store](verify-the-condition-of-a-compressed-migration-store.md)
 
 

214
windows/deployment/usmt/usmt-general-conventions.md
View File

@ -1,106 +1,108 @@
---
title: General Conventions (Windows 10)
description: General Conventions
ms.assetid: 5761986e-a847-41bd-bf8e-7c1bd01acbc6
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# General Conventions
This topic describes the XML helper functions.
## In This Topic
[General XML Guidelines](#bkmk-general)
[Helper Functions](#bkmk-helperfunctions)
## <a href="" id="bkmk-general"></a>General XML Guidelines
Before you modify the .xml files, become familiar with the following guidelines:
- **XML schema**
You can use the User State Migration Tool (USMT) 10.0 XML schema, MigXML.xsd, to write and validate migration .xml files.
- **Conflits**
In general, when there are conflicts within the XML schema, the most specific pattern takes precedence. For more information, see [Conflicts and Precedence](usmt-conflicts-and-precedence.md).
- **Required elements**
The required elements for a migration .xml file are **&lt;migration&gt;**, **&lt;component&gt;**, **&lt;role&gt;**, and **&lt;rules&gt;**.
- **Required child elements**
- USMT does not fail with an error if you do not specify the required child elements. However, you must specify the required child elements for the parent element to affect the migration.
- The required child elements apply only to the first definition of the element. If these elements are defined and then referred to using their name, the required child elements do not apply. For example, if you define `<detects name="Example">` in **&lt;namedElements&gt;**, and you specify `<detects name="Example"/>` in **&lt;component&gt;** to refer to this element, the definition inside **&lt;namedElements&gt;** must have the required child elements, but the **&lt;component&gt;** element does not need to have the required child elements.
- **File names with brackets**
If you are migrating a file that has a bracket character (\[ or \]) in the file name, you must insert a carat (^) character directly before the bracket for the bracket character to be valid. For example, if there is a file named **file].txt**, you must specify `<pattern type="File">c:\documents\mydocs [file^].txt]</pattern>` instead of `<pattern type="File">c:\documents\mydocs [file].txt]</pattern>`.
- **Using quotation marks**
When you surround code in quotation marks, you can use either double ("") or single (') quotation marks.
## <a href="" id="bkmk-helperfunctions"></a> Helper Functions
You can use the XML helper functions in the [XML Elements Library](usmt-xml-elements-library.md) to change migration behavior. Before you use these functions in an .xml file, note the following:
- **All of the parameters are strings**
- **You can leave NULL parameters blank**
As with parameters with a default value convention, if you have a NULL parameter at the end of a list, you can leave it out. For example, the following function:
``` syntax
SomeFunction("My String argument",NULL,NULL)
```
is equivalent to:
``` syntax
SomeFunction("My String argument")
```
- **The encoded location used in all the helper functions is an unambiguous string representation for the name of an object**
It is composed of the node part, optionally followed by the leaf enclosed in square brackets. This makes a clear distinction between nodes and leaves.
For example, specify the file C:\\Windows\\Notepad.exe: **c:\\Windows\[Notepad.exe\]**. Similarly, specify the directory C:\\Windows\\System32 like this: **c:\\Windows\\System32**; note the absence of the \[\] characters.
The registry is represented in a similar way. The default value of a registry key is represented as an empty \[\] construct. For example, the default value for the HKLM\\SOFTWARE\\MyKey registry key is **HKLM\\SOFTWARE\\MyKey\[\]**.
- **You specify a location pattern in a way that is similar to how you specify an actual location**
The exception is that both the node and leaf part accept patterns. However, a pattern from the node does not extend to the leaf.
For example, the pattern **c:\\Windows\\\\*** will match the \\Windows directory and all subdirectories, but it will not match any of the files in those directories. To match the files as well, you must specify **c:\\Windows\\\*\[\*\]**.
## Related topics
[USMT XML Reference](usmt-xml-reference.md)
---
title: General Conventions (Windows 10)
description: In this article, you will learn about the General guidelines for XML files in USMT and XML helper functions.
ms.custom: seo-marvel-apr2020
ms.assetid: 5761986e-a847-41bd-bf8e-7c1bd01acbc6
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# General Conventions
This topic describes the XML helper functions.
## In This Topic
[General XML Guidelines](#bkmk-general)
[Helper Functions](#bkmk-helperfunctions)
## <a href="" id="bkmk-general"></a>General XML Guidelines
Before you modify the .xml files, become familiar with the following guidelines:
- **XML schema**
You can use the User State Migration Tool (USMT) 10.0 XML schema, MigXML.xsd, to write and validate migration .xml files.
- **Conflits**
In general, when there are conflicts within the XML schema, the most specific pattern takes precedence. For more information, see [Conflicts and Precedence](usmt-conflicts-and-precedence.md).
- **Required elements**
The required elements for a migration .xml file are **&lt;migration&gt;**, **&lt;component&gt;**, **&lt;role&gt;**, and **&lt;rules&gt;**.
- **Required child elements**
- USMT does not fail with an error if you do not specify the required child elements. However, you must specify the required child elements for the parent element to affect the migration.
- The required child elements apply only to the first definition of the element. If these elements are defined and then referred to using their name, the required child elements do not apply. For example, if you define `<detects name="Example">` in **&lt;namedElements&gt;**, and you specify `<detects name="Example"/>` in **&lt;component&gt;** to refer to this element, the definition inside **&lt;namedElements&gt;** must have the required child elements, but the **&lt;component&gt;** element does not need to have the required child elements.
- **File names with brackets**
If you are migrating a file that has a bracket character (\[ or \]) in the file name, you must insert a carat (^) character directly before the bracket for the bracket character to be valid. For example, if there is a file named **file].txt**, you must specify `<pattern type="File">c:\documents\mydocs [file^].txt]</pattern>` instead of `<pattern type="File">c:\documents\mydocs [file].txt]</pattern>`.
- **Using quotation marks**
When you surround code in quotation marks, you can use either double ("") or single (') quotation marks.
## <a href="" id="bkmk-helperfunctions"></a> Helper Functions
You can use the XML helper functions in the [XML Elements Library](usmt-xml-elements-library.md) to change migration behavior. Before you use these functions in an .xml file, note the following:
- **All of the parameters are strings**
- **You can leave NULL parameters blank**
As with parameters with a default value convention, if you have a NULL parameter at the end of a list, you can leave it out. For example, the following function:
``` syntax
SomeFunction("My String argument",NULL,NULL)
```
is equivalent to:
``` syntax
SomeFunction("My String argument")
```
- **The encoded location used in all the helper functions is an unambiguous string representation for the name of an object**
It is composed of the node part, optionally followed by the leaf enclosed in square brackets. This makes a clear distinction between nodes and leaves.
For example, specify the file C:\\Windows\\Notepad.exe: **c:\\Windows\[Notepad.exe\]**. Similarly, specify the directory C:\\Windows\\System32 like this: **c:\\Windows\\System32**; note the absence of the \[\] characters.
The registry is represented in a similar way. The default value of a registry key is represented as an empty \[\] construct. For example, the default value for the HKLM\\SOFTWARE\\MyKey registry key is **HKLM\\SOFTWARE\\MyKey\[\]**.
- **You specify a location pattern in a way that is similar to how you specify an actual location**
The exception is that both the node and leaf part accept patterns. However, a pattern from the node does not extend to the leaf.
For example, the pattern **c:\\Windows\\\\*** will match the \\Windows directory and all subdirectories, but it will not match any of the files in those directories. To match the files as well, you must specify **c:\\Windows\\\*\[\*\]**.
## Related topics
[USMT XML Reference](usmt-xml-reference.md)

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

@ -1,6 +1,7 @@
---
title: Hard-Link Migration Store (Windows 10)
description: Hard-Link Migration Store
description: In this article, you will learn about the Hard-Link migration store which enables you to perform an in-place migration.
ms.custom: seo-marvel-apr2020
ms.assetid: b0598418-4607-4952-bfa3-b6e4aaa2c574
ms.reviewer:
manager: laurawi

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

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

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

@ -1,35 +1,37 @@
---
title: User State Migration Tool (USMT) How-to topics (Windows 10)
description: User State Migration Tool (USMT) How-to topics
ms.assetid: 7b9a2f2a-a43a-4984-9746-a767f9f1c7e3
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# User State Migration Tool (USMT) How-to topics
The following table lists topics that describe how to use User State Migration Tool (USMT) 10.0 to perform specific tasks.
## In This Section
|Topic |Description|
|------|-----------|
|[Exclude Files and Settings](usmt-exclude-files-and-settings.md)|Create a custom .xml file to exclude files, file types, folders, or registry settings from your migration.|
|[Extract Files from a Compressed USMT Migration Store](usmt-extract-files-from-a-compressed-migration-store.md)|Recover files from a compressed migration store after installing the operating system.|
|[Include Files and Settings](usmt-include-files-and-settings.md)|Create a custom .xml file to include files, file types, folders, or registry settings in your migration.|
|[Migrate Application Settings](migrate-application-settings.md)|Migrate the settings of an application that the MigApp.xml file does not include by default.|
|[Migrate EFS Files and Certificates](usmt-migrate-efs-files-and-certificates.md)|Migrate Encrypting File System (EFS) certificates by using USMT.|
|[Migrate User Accounts](usmt-migrate-user-accounts.md)|Specify the users to include and exclude in your migration.|
|[Reroute Files and Settings](usmt-reroute-files-and-settings.md)|Create a custom .xml file to reroute files and settings during a migration.|
|[Verify the Condition of a Compressed Migration Store](verify-the-condition-of-a-compressed-migration-store.md)|Determine whether a compressed migration store is intact, or whether it contains corrupt files or a corrupt catalog.|
## Related topics
- [User State Migration Tool (USMT) Overview Topics](usmt-topics.md)
- [User State Migration Tool (USMT) Troubleshooting](usmt-troubleshooting.md)
- [User State Migration Toolkit (USMT) Reference](usmt-reference.md)
---
title: User State Migration Tool (USMT) How-to topics (Windows 10)
description: This article contains a list topics that describe how to use User State Migration Tool (USMT) 10.0 to perform specific tasks.
ms.custom: seo-marvel-apr2020
ms.assetid: 7b9a2f2a-a43a-4984-9746-a767f9f1c7e3
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# User State Migration Tool (USMT) How-to topics
The following table lists topics that describe how to use User State Migration Tool (USMT) 10.0 to perform specific tasks.
## In This Section
|Topic |Description|
|------|-----------|
|[Exclude Files and Settings](usmt-exclude-files-and-settings.md)|Create a custom .xml file to exclude files, file types, folders, or registry settings from your migration.|
|[Extract Files from a Compressed USMT Migration Store](usmt-extract-files-from-a-compressed-migration-store.md)|Recover files from a compressed migration store after installing the operating system.|
|[Include Files and Settings](usmt-include-files-and-settings.md)|Create a custom .xml file to include files, file types, folders, or registry settings in your migration.|
|[Migrate Application Settings](migrate-application-settings.md)|Migrate the settings of an application that the MigApp.xml file does not include by default.|
|[Migrate EFS Files and Certificates](usmt-migrate-efs-files-and-certificates.md)|Migrate Encrypting File System (EFS) certificates by using USMT.|
|[Migrate User Accounts](usmt-migrate-user-accounts.md)|Specify the users to include and exclude in your migration.|
|[Reroute Files and Settings](usmt-reroute-files-and-settings.md)|Create a custom .xml file to reroute files and settings during a migration.|
|[Verify the Condition of a Compressed Migration Store](verify-the-condition-of-a-compressed-migration-store.md)|Determine whether a compressed migration store is intact, or whether it contains corrupt files or a corrupt catalog.|
## Related topics
- [User State Migration Tool (USMT) Overview Topics](usmt-topics.md)
- [User State Migration Tool (USMT) Troubleshooting](usmt-troubleshooting.md)
- [User State Migration Toolkit (USMT) Reference](usmt-reference.md)

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

@ -1,62 +1,64 @@
---
title: Identify Applications Settings (Windows 10)
description: Identify Applications Settings
ms.assetid: eda68031-9b02-4a5b-a893-3786a6505381
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# Identify Applications Settings
When planning for your migration, you should identify which applications and settings you want to migrate. For more information about how to create a custom .xml file to migrate the settings of another application, see [Customize USMT XML Files](usmt-customize-xml-files.md).
## Applications
First, create and prioritize a list of applications that to be migrated. It may be helpful to review the application lists and decide which applications will be redeployed and which applications will be retired. Often, the applications are prioritized based on a combination of how widely the application is used and how complex the application is.
Next, identify an application owner to be in charge of each application. This is necessary because the developers will not be experts on all of the applications in the organization. The application owner should have the most experience with an application. The application owner provides insight into how the organization installs, configures, and uses the application.
## Application Settings
Next, determine and locate the application settings to be migrated. You can acquire much of the information that you need for this step when you are testing the new applications for compatibility with the new operating system.
After completing the list of applications to be migrated, review the list and work with each application owner on a list of settings to be migrated. For each setting, determine whether it needs to be migrated or if the default settings are adequate. Then, determine where the setting is located; for example, in the registry or in an .ini file. Next, consider the following questions to determine what needs to be done to migrate the setting successfully:
- Is the destination version of the application newer than the source version?
- Do these settings work with the new version?
- Do the settings need to be moved or altered?
- Can the first-run process force the application to appear as if it had run already? If so, does this work correctly, or does it break the application?
After answering these questions, create a custom .xml file to migrate settings. Work with the application owner to develop test cases and to determine the file types that need to be migrated for the application.
## Locating Where Settings Are Stored
See [Migrate Application Settings](migrate-application-settings.md) and follow the directions.
## Related topics
[Determine What to Migrate](usmt-determine-what-to-migrate.md)
 
 
---
title: Identify Applications Settings (Windows 10)
description: This article acts as a guidance to help you plan migration and identify which applications and settings you want to migrate.
ms.custom: seo-marvel-apr2020
ms.assetid: eda68031-9b02-4a5b-a893-3786a6505381
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# Identify Applications Settings
When planning for your migration, you should identify which applications and settings you want to migrate. For more information about how to create a custom .xml file to migrate the settings of another application, see [Customize USMT XML Files](usmt-customize-xml-files.md).
## Applications
First, create and prioritize a list of applications that to be migrated. It may be helpful to review the application lists and decide which applications will be redeployed and which applications will be retired. Often, the applications are prioritized based on a combination of how widely the application is used and how complex the application is.
Next, identify an application owner to be in charge of each application. This is necessary because the developers will not be experts on all of the applications in the organization. The application owner should have the most experience with an application. The application owner provides insight into how the organization installs, configures, and uses the application.
## Application Settings
Next, determine and locate the application settings to be migrated. You can acquire much of the information that you need for this step when you are testing the new applications for compatibility with the new operating system.
After completing the list of applications to be migrated, review the list and work with each application owner on a list of settings to be migrated. For each setting, determine whether it needs to be migrated or if the default settings are adequate. Then, determine where the setting is located; for example, in the registry or in an .ini file. Next, consider the following questions to determine what needs to be done to migrate the setting successfully:
- Is the destination version of the application newer than the source version?
- Do these settings work with the new version?
- Do the settings need to be moved or altered?
- Can the first-run process force the application to appear as if it had run already? If so, does this work correctly, or does it break the application?
After answering these questions, create a custom .xml file to migrate settings. Work with the application owner to develop test cases and to determine the file types that need to be migrated for the application.
## Locating Where Settings Are Stored
See [Migrate Application Settings](migrate-application-settings.md) and follow the directions.
## Related topics
[Determine What to Migrate](usmt-determine-what-to-migrate.md)
 
 

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

@ -1,51 +1,53 @@
---
title: Identify File Types, Files, and Folders (Windows 10)
description: Identify File Types, Files, and Folders
ms.assetid: 93bb2a33-c126-4f7a-a961-6c89686d54e0
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# Identify File Types, Files, and Folders
When planning for your migration, if not using MigDocs.xml, you should identify the file types, files, folders, and settings that you want to migrate. First, you should determine the standard file locations on each computer, such as **My Documents.** , **C:\\Data** , and company-specified locations, such as **\\EngineeringDrafts**. Next, you should determine and locate the non-standard locations. For non-standard locations, consider the following:
- **File types**. Consider which file types need to be included and excluded from the migration. You can create this list based on common applications used in your organization. Applications normally use specific file name extensions. For example, Microsoft Office Word primarily uses .doc, .docx and .dotx file name extension. However, it also uses other file types, such as templates (.dot files), on a less frequent basis.
- **Excluded locations**. Consider the locations on the computer that should be excluded from the migration (for example, %WINDIR% and Program Files).
- **New locations**. Decide where files should be migrated to on the destination computer for example, \\My Documents, a designated folder, or a folder matching the files' name and location on the source computer. For example, you might have shared data on source machine or you might wish to clean up documents outside the user profiles on the source system. Identify any data that needs to be redirected to a new location in the apply phase. This can be accomplished with location modify rules.
Once you have verified which files and file types that the end users work with regularly, you will need to locate them. Files may be saved to a single folder or scattered across a drive. A good starting point for finding files types to include is to look at the registered file types on the computer.
**To find the registered file types on a computer running Windows 7 or Windows 8**
1. Click **Start**. Open **Control Panel**, click **Control Panel Home**, and click **Programs**.
2. Click **Default Programs**, and click **Associate a file type or protocol with a program**.
3. On this screen, the registered file types are displayed.
For more information about how to change the file types, files, and folders that are migrated when you specify the MigUser.xml file, see [User State Migration Tool (USMT) How-to topics](usmt-how-to.md).
## Related topics
[Determine What to Migrate](usmt-determine-what-to-migrate.md)
 
 
---
title: Identify File Types, Files, and Folders (Windows 10)
description: Learn what to consider when you have to identify the file types, files, folders, and settings that you want to migrate.
ms.custom: seo-marvel-apr2020
ms.assetid: 93bb2a33-c126-4f7a-a961-6c89686d54e0
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# Identify File Types, Files, and Folders
When planning for your migration, if not using MigDocs.xml, you should identify the file types, files, folders, and settings that you want to migrate. First, you should determine the standard file locations on each computer, such as **My Documents.** , **C:\\Data** , and company-specified locations, such as **\\EngineeringDrafts**. Next, you should determine and locate the non-standard locations. For non-standard locations, consider the following:
- **File types**. Consider which file types need to be included and excluded from the migration. You can create this list based on common applications used in your organization. Applications normally use specific file name extensions. For example, Microsoft Office Word primarily uses .doc, .docx and .dotx file name extension. However, it also uses other file types, such as templates (.dot files), on a less frequent basis.
- **Excluded locations**. Consider the locations on the computer that should be excluded from the migration (for example, %WINDIR% and Program Files).
- **New locations**. Decide where files should be migrated to on the destination computer for example, \\My Documents, a designated folder, or a folder matching the files' name and location on the source computer. For example, you might have shared data on source machine or you might wish to clean up documents outside the user profiles on the source system. Identify any data that needs to be redirected to a new location in the apply phase. This can be accomplished with location modify rules.
Once you have verified which files and file types that the end users work with regularly, you will need to locate them. Files may be saved to a single folder or scattered across a drive. A good starting point for finding files types to include is to look at the registered file types on the computer.
**To find the registered file types on a computer running Windows 7 or Windows 8**
1. Click **Start**. Open **Control Panel**, click **Control Panel Home**, and click **Programs**.
2. Click **Default Programs**, and click **Associate a file type or protocol with a program**.
3. On this screen, the registered file types are displayed.
For more information about how to change the file types, files, and folders that are migrated when you specify the MigUser.xml file, see [User State Migration Tool (USMT) How-to topics](usmt-how-to.md).
## Related topics
[Determine What to Migrate](usmt-determine-what-to-migrate.md)
 
 

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

@ -1,60 +1,62 @@
---
title: Identify Operating System Settings (Windows 10)
description: Identify Operating System Settings
ms.assetid: 1704ab18-1765-41fb-a27c-3aa3128fa242
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# Identify Operating System Settings
When planning for your migration, you should identify which operating system settings you want to migrate and to what extent you want to create a new standard environment on each of the computers. User State Migration Tool (USMT) 10.0 enables you to migrate select settings and keep the default values for all others. The operating system settings include the following:
- **Apperance.**
This includes items such as wallpaper, colors, sounds, and the location of the taskbar.
- **Action.**
This includes items such as the key-repeat rate, whether double-clicking a folder opens it in a new window or the same window, and whether you need to single-click or double-click an item to open it.
- **Internet.**
These are the settings that let you connect to the Internet and control how your browser operates. This includes items such as your home page URL, favorites, bookmarks, cookies, security settings, dial-up connections, and proxy settings.
- **Mail.**
This includes the information that you need to connect to your mail server, your signature file, views, mail rules, local mail, and contacts.
To help you decide which settings to migrate, you should consider any previous migration experiences as well as the results of any surveys and tests that you have conducted. You should also consider the number of help-desk calls related to operating-system settings that you have had in the past, and are able to handle in the future. Also decide how much of the new operating-system functionality you want to take advantage of.
You should migrate any settings that users need to get their jobs done, those that make the work environment comfortable, and those that will reduce help-desk calls after the migration. Although it is easy to dismiss migrating user preferences, you should consider that users can spend a significant amount of time restoring items such as wallpaper, screen savers, and other customizable user-interface features. Most users do not remember how these settings were applied. Although these items are not critical to migration success, migrating these items increases user productivity and overall satisfaction of the migration process.
**Note**  
For more information about how to change the operating-system settings that are migrated, see [User State Migration Tool (USMT) How-to topics](usmt-how-to.md).
For information about the operating-system settings that USMT migrates, see [What Does USMT Migrate?](usmt-what-does-usmt-migrate.md)
## Related topics
[Determine What to Migrate](usmt-determine-what-to-migrate.md)
---
title: Identify Operating System Settings (Windows 10)
description: In this article, you'll learn about what to consider when identifying operating system settings for migration.
ms.custom: seo-marvel-apr2020
ms.assetid: 1704ab18-1765-41fb-a27c-3aa3128fa242
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# Identify Operating System Settings
When planning for your migration, you should identify which operating system settings you want to migrate and to what extent you want to create a new standard environment on each of the computers. User State Migration Tool (USMT) 10.0 enables you to migrate select settings and keep the default values for all others. The operating system settings include the following:
- **Apperance.**
This includes items such as wallpaper, colors, sounds, and the location of the taskbar.
- **Action.**
This includes items such as the key-repeat rate, whether double-clicking a folder opens it in a new window or the same window, and whether you need to single-click or double-click an item to open it.
- **Internet.**
These are the settings that let you connect to the Internet and control how your browser operates. This includes items such as your home page URL, favorites, bookmarks, cookies, security settings, dial-up connections, and proxy settings.
- **Mail.**
This includes the information that you need to connect to your mail server, your signature file, views, mail rules, local mail, and contacts.
To help you decide which settings to migrate, you should consider any previous migration experiences as well as the results of any surveys and tests that you have conducted. You should also consider the number of help-desk calls related to operating-system settings that you have had in the past, and are able to handle in the future. Also decide how much of the new operating-system functionality you want to take advantage of.
You should migrate any settings that users need to get their jobs done, those that make the work environment comfortable, and those that will reduce help-desk calls after the migration. Although it is easy to dismiss migrating user preferences, you should consider that users can spend a significant amount of time restoring items such as wallpaper, screen savers, and other customizable user-interface features. Most users do not remember how these settings were applied. Although these items are not critical to migration success, migrating these items increases user productivity and overall satisfaction of the migration process.
**Note**  
For more information about how to change the operating-system settings that are migrated, see [User State Migration Tool (USMT) How-to topics](usmt-how-to.md).
For information about the operating-system settings that USMT migrates, see [What Does USMT Migrate?](usmt-what-does-usmt-migrate.md)
## Related topics
[Determine What to Migrate](usmt-determine-what-to-migrate.md)

3
windows/deployment/usmt/usmt-identify-users.md
View File

@ -1,6 +1,7 @@
---
title: Identify Users (Windows 10)
description: Identify Users
description: In this article, you will learn about what to consider when you identify users that are to migrated.
ms.custom: seo-marvel-apr2020
ms.assetid: 957a4fe9-79fd-44a2-8c26-33e50f71f9de
ms.reviewer:
manager: laurawi

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

@ -1,6 +1,7 @@
---
title: Include Files and Settings (Windows 10)
description: Include Files and Settings
description: In this article, you'll learn how to define a custom .xml file to migrate files and settings according to your needs.
ms.custom: seo-marvel-apr2020
ms.assetid: 9009c6a5-0612-4478-8742-abe5eb6cbac8
ms.reviewer:
manager: laurawi

5
windows/deployment/usmt/usmt-loadstate-syntax.md
View File

@ -1,6 +1,7 @@
---
title: LoadState Syntax (Windows 10)
description: LoadState Syntax
description: In this article, you will learn about the syntax of the LoadState command and the options it provides.
ms.custom: seo-marvel-apr2020
ms.assetid: 53d2143b-cbe9-4cfc-8506-36e9d429f6d4
ms.reviewer:
manager: laurawi
@ -17,7 +18,7 @@ ms.topic: article
# LoadState Syntax
This topic discusses the **LoadState** command syntax and options.
This topic discusses the **LoadState** command syntax and options available with it.
## In This Topic

3
windows/deployment/usmt/usmt-log-files.md
View File

@ -1,6 +1,7 @@
---
title: Log files for User State Migration Tool (USMT)
description: Log Files
description: Learn how to use the User State Migration Tool (USMT) 10.0 logs to monitor your migration and to troubleshoot errors and failed migrations.
ms.custom: seo-marvel-apr2020
ms.assetid: 28185ebd-630a-4bbd-94f4-8c48aad05649
ms.reviewer:
manager: laurawi

112
windows/deployment/usmt/usmt-migrate-efs-files-and-certificates.md
View File

@ -1,55 +1,57 @@
---
title: Migrate EFS Files and Certificates (Windows 10)
description: Migrate EFS Files and Certificates
ms.assetid: 7f19a753-ec45-4433-b297-cc30f16fdee1
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# Migrate EFS Files and Certificates
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
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.
**Note**  
The **/efs** options are not used with the LoadState 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.
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:
``` syntax
Cipher /D /S:<PATH>
```
Where *&lt;Path&gt;* 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)
---
title: Migrate EFS Files and Certificates (Windows 10)
description: In this article, you will learn how to migrate Encrypting File System (EFS) files and certificates using USMT.
ms.custom: seo-marvel-apr2020
ms.assetid: 7f19a753-ec45-4433-b297-cc30f16fdee1
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# Migrate EFS Files and Certificates
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
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.
**Note**  
The **/efs** options are not used with the LoadState 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.
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:
``` syntax
Cipher /D /S:<PATH>
```
Where *&lt;Path&gt;* 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)

194
windows/deployment/usmt/usmt-migrate-user-accounts.md
View File

@ -1,96 +1,98 @@
---
title: Migrate User Accounts (Windows 10)
description: Migrate User Accounts
ms.assetid: a3668361-43c8-4fd2-b26e-9a2deaeaeb09
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# 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 cannot specify users in the migration XML files or by using the Config.xml file.
## In this Topic
- [To migrate all user accounts and user settings](#bkmk-migrateall)
- [To migrate two domain accounts (User1 and User2)](#bkmk-migratetwo)
- [To migrate two domain accounts (User1 and User2) and move User1 from the Contoso domain to the Fabrikam domain](#bkmk-migratemoveuserone)
## <a href="" id="bkmk-migrateall"></a>To migrate all user accounts and user settings
Links to detailed explanations of commands are available in the Related Topics section.
1. Log on to the source computer as an administrator, and specify the following in a **Command-Prompt** window:
`scanstate \\server\share\migration\mystore /i:migdocs.xml /i:migapp.xml /o`
2. Log on to the destination computer as an administrator.
3. Do one of the following:
- If you are migrating domain accounts, specify:
`loadstate \\server\share\migration\mystore /i:migdocs.xml /i:migapp.xml`
- If you are migrating local accounts along with domain accounts, specify:
`loadstate \\server\share\migration\mystore /i:migdocs.xml /i:migapp.xml /lac /lae`
**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.
## <a href="" id="bkmk-migratetwo"></a>To migrate two domain accounts (User1 and User2)
Links to detailed explanations of commands are available in the Related Topics section.
1. Log on to the source computer as an administrator, and specify:
`scanstate \\server\share\migration\mystore /ue:*\* /ui:contoso\user1 /ui:fabrikam\user2 /i:migdocs.xml /i:migapp.xml /o`
2. Log on to the destination computer as an administrator.
3. Specify the following:
`loadstate \\server\share\migration\mystore /i:migdocs.xml /i:migapp.xml`
## <a href="" id="bkmk-migratemoveuserone"></a>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.
1. Log on to the source computer as an administrator, and type the following at the command-line prompt:
`scanstate \\server\share\migration\mystore /ue:*\* /ui:contoso\user1 /ui:contoso\user2 /i:migdocs.xml /i:migapp.xml /o`
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)
---
title: Migrate User Accounts (Windows 10)
description: In this article, you will learn how to use the user options in the command line to customize user account migration.
ms.custom: seo-marvel-apr2020
ms.assetid: a3668361-43c8-4fd2-b26e-9a2deaeaeb09
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# 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 cannot specify users in the migration XML files or by using the Config.xml file.
## In this Topic
- [To migrate all user accounts and user settings](#bkmk-migrateall)
- [To migrate two domain accounts (User1 and User2)](#bkmk-migratetwo)
- [To migrate two domain accounts (User1 and User2) and move User1 from the Contoso domain to the Fabrikam domain](#bkmk-migratemoveuserone)
## <a href="" id="bkmk-migrateall"></a>To migrate all user accounts and user settings
Links to detailed explanations of commands are available in the Related Topics section.
1. Log on to the source computer as an administrator, and specify the following in a **Command-Prompt** window:
`scanstate \\server\share\migration\mystore /i:migdocs.xml /i:migapp.xml /o`
2. Log on to the destination computer as an administrator.
3. Do one of the following:
- If you are migrating domain accounts, specify:
`loadstate \\server\share\migration\mystore /i:migdocs.xml /i:migapp.xml`
- If you are migrating local accounts along with domain accounts, specify:
`loadstate \\server\share\migration\mystore /i:migdocs.xml /i:migapp.xml /lac /lae`
**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.
## <a href="" id="bkmk-migratetwo"></a>To migrate two domain accounts (User1 and User2)
Links to detailed explanations of commands are available in the Related Topics section.
1. Log on to the source computer as an administrator, and specify:
`scanstate \\server\share\migration\mystore /ue:*\* /ui:contoso\user1 /ui:fabrikam\user2 /i:migdocs.xml /i:migapp.xml /o`
2. Log on to the destination computer as an administrator.
3. Specify the following:
`loadstate \\server\share\migration\mystore /i:migdocs.xml /i:migapp.xml`
## <a href="" id="bkmk-migratemoveuserone"></a>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.
1. Log on to the source computer as an administrator, and type the following at the command-line prompt:
`scanstate \\server\share\migration\mystore /ue:*\* /ui:contoso\user1 /ui:contoso\user2 /i:migdocs.xml /i:migapp.xml /o`
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)

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

@ -1,76 +1,78 @@
---
title: Migration Store Encryption (Windows 10)
description: Migration Store Encryption
ms.assetid: b28c2657-b986-4487-bd38-cb81500b831d
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# 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.
## 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 following table describes the command-line encryption options in USMT.
<table>
<colgroup>
<col width="33%" />
<col width="33%" />
<col width="33%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Component</th>
<th align="left">Option</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p><strong>ScanState</strong></p></td>
<td align="left"><p><strong>/encrypt</strong><em>&lt;AES, AES_128, AES_192, AES_256, 3DES, 3DES_112&gt;</em></p></td>
<td align="left"><p>This option and argument specify that the migration store is encrypted and which algorithm to use. When the algorithm argument is not provided, the <strong>ScanState</strong> tool employs the 3DES algorithm.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>LoadState</strong></p></td>
<td align="left"><p><strong>/decrypt</strong><em>&lt;AES, AES_128, AES_192, AES_256, 3DES, 3DES_112&gt;</em></p></td>
<td align="left"><p>This option and argument specify that the store must be decrypted and which algorithm to use. When the algorithm argument is not provided, the <strong>LoadState</strong> tool employs the 3DES algorithm.</p></td>
</tr>
</tbody>
</table>
**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)
## Related topics
[Plan Your Migration](usmt-plan-your-migration.md)
---
title: Migration Store Encryption (Windows 10)
description: Learn about the options available for the migration store encryption in the User State Migration Tool (USMT) 10.0.
ms.custom: seo-marvel-apr2020
ms.assetid: b28c2657-b986-4487-bd38-cb81500b831d
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# 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.
## 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 following table describes the command-line encryption options in USMT.
<table>
<colgroup>
<col width="33%" />
<col width="33%" />
<col width="33%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Component</th>
<th align="left">Option</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p><strong>ScanState</strong></p></td>
<td align="left"><p><strong>/encrypt</strong><em>&lt;AES, AES_128, AES_192, AES_256, 3DES, 3DES_112&gt;</em></p></td>
<td align="left"><p>This option and argument specify that the migration store is encrypted and which algorithm to use. When the algorithm argument is not provided, the <strong>ScanState</strong> tool employs the 3DES algorithm.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>LoadState</strong></p></td>
<td align="left"><p><strong>/decrypt</strong><em>&lt;AES, AES_128, AES_192, AES_256, 3DES, 3DES_112&gt;</em></p></td>
<td align="left"><p>This option and argument specify that the store must be decrypted and which algorithm to use. When the algorithm argument is not provided, the <strong>LoadState</strong> tool employs the 3DES algorithm.</p></td>
</tr>
</tbody>
</table>
**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)
## Related topics
[Plan Your Migration](usmt-plan-your-migration.md)

122
windows/deployment/usmt/usmt-overview.md
View File

@ -1,60 +1,62 @@
---
title: User State Migration Tool (USMT) Overview (Windows 10)
description: User State Migration Tool (USMT) Overview
ms.assetid: 3b649431-ad09-4b17-895a-3fec7ac0a81f
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.date: 10/16/2017
ms.topic: article
---
# 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).
USMT enables you to do the following:
- 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).
## 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.
## 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 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:
- Migrations that require end-user interaction.
- Migrations that require customization on a machine-by-machine basis.
## Related topics
- [User State Migration Tool (USMT) Technical Reference](usmt-technical-reference.md)
 
---
title: User State Migration Tool (USMT) Overview (Windows 10)
description: Learn about the User State Migration Tool (USMT), that can help you in user state migration during large deployments of Windows operating systems.
ms.custom: seo-marvel-apr2020
ms.assetid: 3b649431-ad09-4b17-895a-3fec7ac0a81f
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.date: 10/16/2017
ms.topic: article
---
# 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).
USMT enables you to do the following:
- 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).
## 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.
## 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 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:
- Migrations that require end-user interaction.
- Migrations that require customization on a machine-by-machine basis.
## Related topics
- [User State Migration Tool (USMT) Technical Reference](usmt-technical-reference.md)
 

144
windows/deployment/usmt/usmt-plan-your-migration.md
View File

@ -1,71 +1,73 @@
---
title: Plan Your Migration (Windows 10)
description: Plan Your Migration
ms.assetid: c951f7df-850e-47ad-b31b-87f902955e3e
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# 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.
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.
## In This Section
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<tbody>
<tr class="odd">
<td align="left"><p><a href="usmt-common-migration-scenarios.md" data-raw-source="[Common Migration Scenarios](usmt-common-migration-scenarios.md)">Common Migration Scenarios</a></p></td>
<td align="left"><p>Determine whether you will perform a refresh migration or a replace migration.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-what-does-usmt-migrate.md" data-raw-source="[What Does USMT Migrate?](usmt-what-does-usmt-migrate.md)">What Does USMT Migrate?</a></p></td>
<td align="left"><p>Learn which applications, user data, and operating system components USMT migrates.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="usmt-choose-migration-store-type.md" data-raw-source="[Choose a Migration Store Type](usmt-choose-migration-store-type.md)">Choose a Migration Store Type</a></p></td>
<td align="left"><p>Choose an uncompressed, compressed, or hard-link migration store.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-determine-what-to-migrate.md" data-raw-source="[Determine What to Migrate](usmt-determine-what-to-migrate.md)">Determine What to Migrate</a></p></td>
<td align="left"><p>Identify user accounts, application settings, operating system settings, and files that you want to migrate inside your organization.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="usmt-test-your-migration.md" data-raw-source="[Test Your Migration](usmt-test-your-migration.md)">Test Your Migration</a></p></td>
<td align="left"><p>Test your migration before you deploy Windows to all users.</p></td>
</tr>
</tbody>
</table>
## Related topics
[USMT XML Reference](usmt-xml-reference.md)
---
title: Plan Your Migration (Windows 10)
description: In this article, you'll learn about how to plan your migration before using the User State Migration Tool (USMT) 10.0 to perform migration.
ms.custom: seo-marvel-apr2020
ms.assetid: c951f7df-850e-47ad-b31b-87f902955e3e
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# 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.
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.
## In This Section
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<tbody>
<tr class="odd">
<td align="left"><p><a href="usmt-common-migration-scenarios.md" data-raw-source="[Common Migration Scenarios](usmt-common-migration-scenarios.md)">Common Migration Scenarios</a></p></td>
<td align="left"><p>Determine whether you will perform a refresh migration or a replace migration.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-what-does-usmt-migrate.md" data-raw-source="[What Does USMT Migrate?](usmt-what-does-usmt-migrate.md)">What Does USMT Migrate?</a></p></td>
<td align="left"><p>Learn which applications, user data, and operating system components USMT migrates.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="usmt-choose-migration-store-type.md" data-raw-source="[Choose a Migration Store Type](usmt-choose-migration-store-type.md)">Choose a Migration Store Type</a></p></td>
<td align="left"><p>Choose an uncompressed, compressed, or hard-link migration store.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-determine-what-to-migrate.md" data-raw-source="[Determine What to Migrate](usmt-determine-what-to-migrate.md)">Determine What to Migrate</a></p></td>
<td align="left"><p>Identify user accounts, application settings, operating system settings, and files that you want to migrate inside your organization.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="usmt-test-your-migration.md" data-raw-source="[Test Your Migration](usmt-test-your-migration.md)">Test Your Migration</a></p></td>
<td align="left"><p>Test your migration before you deploy Windows to all users.</p></td>
</tr>
</tbody>
</table>
## Related topics
[USMT XML Reference](usmt-xml-reference.md)

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

@ -1,470 +1,472 @@
---
title: Recognized Environment Variables (Windows 10)
description: Recognized Environment Variables
ms.assetid: 2b0ac412-e131-456e-8f0c-c26249b5f3df
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# 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\\&lt;Username&gt;\\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)
## <a href="" id="bkmk-1"></a>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`.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Variable</th>
<th align="left">Explanation</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p><strong>ALLUSERSAPPDATA</strong></p></td>
<td align="left"><p>Same as <strong>CSIDL_COMMON_APPDATA</strong>.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>ALLUSERSPROFILE</strong></p></td>
<td align="left"><p>Refers to %<strong>PROFILESFOLDER</strong>%\Public or %<strong>PROFILESFOLDER</strong>%\all users.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>COMMONPROGRAMFILES</strong></p></td>
<td align="left"><p>Same as <strong>CSIDL_PROGRAM_FILES_COMMON</strong>.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>COMMONPROGRAMFILES</strong>(X86)</p></td>
<td align="left"><p>Refers to the C:\Program Files (x86)\Common Files folder on 64-bit systems.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_COMMON_ADMINTOOLS</strong></p></td>
<td align="left"><p>Version 10.0. The file-system directory that contains administrative tools for all users of the computer.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_COMMON_ALTSTARTUP</strong></p></td>
<td align="left"><p>The file-system directory that corresponds to the non-localized Startup program group for all users.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_COMMON_APPDATA</strong></p></td>
<td align="left"><p>The file-system directory that contains application data for all users. A typical path Windows is C:\ProgramData.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_COMMON_DESKTOPDIRECTORY</strong></p></td>
<td align="left"><p>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.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_COMMON_DOCUMENTS</strong></p></td>
<td align="left"><p>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.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_COMMON_FAVORITES</strong></p></td>
<td align="left"><p>The file-system directory that serves as a common repository for favorites common to all users. A typical path is C:\Users\Public\Favorites.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_COMMON_MUSIC</strong></p></td>
<td align="left"><p>The file-system directory that serves as a repository for music files common to all users. A typical path is C:\Users\Public\Music.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_COMMON_PICTURES</strong></p></td>
<td align="left"><p>The file-system directory that serves as a repository for image files common to all users. A typical path is C:\Users\Public\Pictures.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_COMMON_PROGRAMS</strong></p></td>
<td align="left"><p>The file-system directory that contains the directories for the common program groups that appear on the <strong>Start</strong> menu for all users. A typical path is C:\ProgramData\Microsoft\Windows\Start Menu\Programs.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_COMMON_STARTMENU</strong></p></td>
<td align="left"><p>The file-system directory that contains the programs and folders which appear on the <strong>Start</strong> menu for all users. A typical path in Windows is C:\ProgramData\Microsoft\Windows\Start Menu.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_COMMON_STARTUP</strong></p></td>
<td align="left"><p>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.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_COMMON_TEMPLATES</strong></p></td>
<td align="left"><p>The file-system directory that contains the templates that are available to all users. A typical path is C:\ProgramData\Microsoft\Windows\Templates.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_COMMON_VIDEO</strong></p></td>
<td align="left"><p>The file-system directory that serves as a repository for video files common to all users. A typical path is C:\Users\Public\Videos.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_APPDATA</strong></p></td>
<td align="left"><p>Refers to the Appdata folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>C<strong>SIDL_DEFAULT_LOCAL_APPDATA</strong></p></td>
<td align="left"><p>Refers to the local Appdata folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_COOKIES</strong></p></td>
<td align="left"><p>Refers to the Cookies folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DEFAULT_CONTACTS</strong></p></td>
<td align="left"><p>Refers to the Contacts folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_DESKTOP</strong></p></td>
<td align="left"><p>Refers to the Desktop folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DEFAULT_DOWNLOADS</strong></p></td>
<td align="left"><p>Refers to the Downloads folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_FAVORITES</strong></p></td>
<td align="left"><p>Refers to the Favorites folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DEFAULT_HISTORY</strong></p></td>
<td align="left"><p>Refers to the History folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_INTERNET_CACHE</strong></p></td>
<td align="left"><p>Refers to the Internet Cache folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DEFAULT_PERSONAL</strong></p></td>
<td align="left"><p>Refers to the Personal folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_MYDOCUMENTS</strong></p></td>
<td align="left"><p>Refers to the My Documents folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DEFAULT_MYPICTURES</strong></p></td>
<td align="left"><p>Refers to the My Pictures folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_MYMUSIC</strong></p></td>
<td align="left"><p>Refers to the My Music folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DEFAULT_MYVIDEO</strong></p></td>
<td align="left"><p>Refers to the My Videos folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_RECENT</strong></p></td>
<td align="left"><p>Refers to the Recent folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DEFAULT_SENDTO</strong></p></td>
<td align="left"><p>Refers to the Send To folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_STARTMENU</strong></p></td>
<td align="left"><p>Refers to the Start Menu folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DEFAULT_PROGRAMS</strong></p></td>
<td align="left"><p>Refers to the Programs folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_STARTUP</strong></p></td>
<td align="left"><p>Refers to the Startup folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DEFAULT_TEMPLATES</strong></p></td>
<td align="left"><p>Refers to the Templates folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_QUICKLAUNCH</strong></p></td>
<td align="left"><p>Refers to the Quick Launch folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_FONTS</strong></p></td>
<td align="left"><p>A virtual folder containing fonts. A typical path is C:\Windows\Fonts.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_PROGRAM_FILESX86</strong></p></td>
<td align="left"><p>The Program Files folder on 64-bit systems. A typical path is C:\Program Files(86).</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_PROGRAM_FILES_COMMONX86</strong></p></td>
<td align="left"><p>A folder for components that are shared across applications on 64-bit systems. A typical path is C:\Program Files(86)\Common.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_PROGRAM_FILES</strong></p></td>
<td align="left"><p>The Program Files folder. A typical path is C:\Program Files.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_PROGRAM_FILES_COMMON</strong></p></td>
<td align="left"><p>A folder for components that are shared across applications. A typical path is C:\Program Files\Common.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_RESOURCES</strong></p></td>
<td align="left"><p>The file-system directory that contains resource data. A typical path is C:\Windows\Resources.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_SYSTEM</strong></p></td>
<td align="left"><p>The Windows System folder. A typical path is C:\Windows\System32.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_WINDOWS</strong></p></td>
<td align="left"><p>The Windows directory or system root. This corresponds to the %<strong>WINDIR</strong>% or %<strong>SYSTEMROOT</strong>% environment variables. A typical path is C:\Windows.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>DEFAULTUSERPROFILE</strong></p></td>
<td align="left"><p>Refers to the value in <strong>HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList [DefaultUserProfile]</strong>.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>PROFILESFOLDER</strong></p></td>
<td align="left"><p>Refers to the value in <strong>HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList [ProfilesDirectory]</strong>.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>PROGRAMFILES</strong></p></td>
<td align="left"><p>Same as <strong>CSIDL_PROGRAM_FILES</strong>.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>PROGRAMFILES(X86)</strong></p></td>
<td align="left"><p>Refers to the C:\Program Files (x86) folder on 64-bit systems.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>SYSTEM</strong></p></td>
<td align="left"><p>Refers to %<strong>WINDIR</strong>%\system32.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>SYSTEM16</strong></p></td>
<td align="left"><p>Refers to %<strong>WINDIR</strong>%\system.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>SYSTEM32</strong></p></td>
<td align="left"><p>Refers to %<strong>WINDIR</strong>%\system32.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>SYSTEMPROFILE</strong></p></td>
<td align="left"><p>Refers to the value in <strong>HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-18 [ProfileImagePath]</strong>.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>SYSTEMROOT</strong></p></td>
<td align="left"><p>Refers to the root of the system drive.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>WINDIR</strong></p></td>
<td align="left"><p>Refers to the Windows folder located on the system drive.</p></td>
</tr>
</tbody>
</table>
 
## <a href="" id="bkmk-2"></a>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`.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Variable</th>
<th align="left">Explanation</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p><strong>APPDATA</strong></p></td>
<td align="left"><p>Same as <strong>CSIDL_APPDATA</strong>.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_ADMINTOOLS</strong></p></td>
<td align="left"><p>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.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_ALTSTARTUP</strong></p></td>
<td align="left"><p>The file-system directory that corresponds to the user's non-localized Startup program group.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_APPDATA</strong></p></td>
<td align="left"><p>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.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_BITBUCKET</strong></p></td>
<td align="left"><p>The virtual folder that contains the objects in the user's Recycle Bin.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_CDBURN_AREA</strong></p></td>
<td align="left"><p>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.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_CONNECTIONS</strong></p></td>
<td align="left"><p>The virtual folder representing Network Connections that contains network and dial-up connections.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_CONTACTS</strong></p></td>
<td align="left"><p>This refers to the Contacts folder in %<strong>CSIDL_PROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_CONTROLS</strong></p></td>
<td align="left"><p>The virtual folder that contains icons for the Control Panel items.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_COOKIES</strong></p></td>
<td align="left"><p>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.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DESKTOP</strong></p></td>
<td align="left"><p>The virtual folder representing the Windows desktop.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DESKTOPDIRECTORY</strong></p></td>
<td align="left"><p>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.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DRIVES</strong></p></td>
<td align="left"><p>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.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_FAVORITES</strong></p></td>
<td align="left"><p>The file-system directory that serves as a common repository for the user's favorites. A typical path is C:\Users\Username\Favorites.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_HISTORY</strong></p></td>
<td align="left"><p>The file-system directory that serves as a common repository for Internet history items.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_INTERNET</strong></p></td>
<td align="left"><p>A virtual folder for Internet Explorer.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_INTERNET_CACHE</strong></p></td>
<td align="left"><p>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</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_LOCAL_APPDATA</strong></p></td>
<td align="left"><p>The file-system directory that serves as a data repository for local, non-roaming applications. A typical path is C:\Users\username\AppData\Local.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_MYDOCUMENTS</strong></p></td>
<td align="left"><p>The virtual folder representing My Documents.A typical path is C:\Users\Username\Documents.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_MYMUSIC</strong></p></td>
<td align="left"><p>The file-system directory that serves as a common repository for music files. A typical path is C:\Users\Username\Music.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_MYPICTURES</strong></p></td>
<td align="left"><p>The file-system directory that serves as a common repository for image files. A typical path is C:\Users\Username\Pictures.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_MYVIDEO</strong></p></td>
<td align="left"><p>The file-system directory that serves as a common repository for video files. A typical path is C:\Users\Username\Videos.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_NETHOOD</strong></p></td>
<td align="left"><p>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.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_NETWORK</strong></p></td>
<td align="left"><p>A virtual folder representing My Network Places, the root of the network namespace hierarchy.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_PERSONAL</strong></p></td>
<td align="left"><p>The virtual folder representing the My Documents desktop item. This is equivalent to <strong>CSIDL_MYDOCUMENTS</strong>.</p>
<p>A typical path is C:\Documents and Settings\username\My Documents.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_PLAYLISTS</strong></p></td>
<td align="left"><p>The virtual folder used to store play albums, typically C:\Users\username\My Music\Playlists.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_PRINTERS</strong></p></td>
<td align="left"><p>The virtual folder that contains installed printers.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_PRINTHOOD</strong></p></td>
<td align="left"><p>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.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_PROFILE</strong></p></td>
<td align="left"><p>The user's profile folder. A typical path is C:\Users\Username.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_PROGRAMS</strong></p></td>
<td align="left"><p>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.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_RECENT</strong></p></td>
<td align="left"><p>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.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_SENDTO</strong></p></td>
<td align="left"><p>The file-system directory that contains <strong>Send To</strong> menu items. A typical path is C:\Users\username\AppData\Roaming\Microsoft\Windows\SendTo.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_STARTMENU</strong></p></td>
<td align="left"><p>The file-system directory that contains <strong>Start</strong> 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.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_STARTUP</strong></p></td>
<td align="left"><p>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.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_TEMPLATES</strong></p></td>
<td align="left"><p>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.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>HOMEPATH</strong></p></td>
<td align="left"><p>Same as the standard environment variable.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>TEMP</strong></p></td>
<td align="left"><p>The temporary folder on the computer. A typical path is %<strong>USERPROFILE</strong>%\AppData\Local\Temp.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>TMP</strong></p></td>
<td align="left"><p>The temporary folder on the computer. A typical path is %<strong>USERPROFILE</strong>%\AppData\Local\Temp.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>USERPROFILE</strong></p></td>
<td align="left"><p>Same as <strong>CSIDL_PROFILE</strong>.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>USERSID</strong></p></td>
<td align="left"><p>Represents the current user-account security identifier (SID). For example,</p>
<p>S-1-5-21-1714567821-1326601894-715345443-1026.</p></td>
</tr>
</tbody>
</table>
 
## Related topics
[USMT XML Reference](usmt-xml-reference.md)
 
 
---
title: Recognized Environment Variables (Windows 10)
description: Learn about the recognized environment variables that can be used during migration to identify folders that are different across computers.
ms.custom: seo-marvel-apr2020
ms.assetid: 2b0ac412-e131-456e-8f0c-c26249b5f3df
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# 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\\&lt;Username&gt;\\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)
## <a href="" id="bkmk-1"></a>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`.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Variable</th>
<th align="left">Explanation</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p><strong>ALLUSERSAPPDATA</strong></p></td>
<td align="left"><p>Same as <strong>CSIDL_COMMON_APPDATA</strong>.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>ALLUSERSPROFILE</strong></p></td>
<td align="left"><p>Refers to %<strong>PROFILESFOLDER</strong>%\Public or %<strong>PROFILESFOLDER</strong>%\all users.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>COMMONPROGRAMFILES</strong></p></td>
<td align="left"><p>Same as <strong>CSIDL_PROGRAM_FILES_COMMON</strong>.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>COMMONPROGRAMFILES</strong>(X86)</p></td>
<td align="left"><p>Refers to the C:\Program Files (x86)\Common Files folder on 64-bit systems.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_COMMON_ADMINTOOLS</strong></p></td>
<td align="left"><p>Version 10.0. The file-system directory that contains administrative tools for all users of the computer.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_COMMON_ALTSTARTUP</strong></p></td>
<td align="left"><p>The file-system directory that corresponds to the non-localized Startup program group for all users.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_COMMON_APPDATA</strong></p></td>
<td align="left"><p>The file-system directory that contains application data for all users. A typical path Windows is C:\ProgramData.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_COMMON_DESKTOPDIRECTORY</strong></p></td>
<td align="left"><p>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.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_COMMON_DOCUMENTS</strong></p></td>
<td align="left"><p>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.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_COMMON_FAVORITES</strong></p></td>
<td align="left"><p>The file-system directory that serves as a common repository for favorites common to all users. A typical path is C:\Users\Public\Favorites.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_COMMON_MUSIC</strong></p></td>
<td align="left"><p>The file-system directory that serves as a repository for music files common to all users. A typical path is C:\Users\Public\Music.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_COMMON_PICTURES</strong></p></td>
<td align="left"><p>The file-system directory that serves as a repository for image files common to all users. A typical path is C:\Users\Public\Pictures.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_COMMON_PROGRAMS</strong></p></td>
<td align="left"><p>The file-system directory that contains the directories for the common program groups that appear on the <strong>Start</strong> menu for all users. A typical path is C:\ProgramData\Microsoft\Windows\Start Menu\Programs.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_COMMON_STARTMENU</strong></p></td>
<td align="left"><p>The file-system directory that contains the programs and folders which appear on the <strong>Start</strong> menu for all users. A typical path in Windows is C:\ProgramData\Microsoft\Windows\Start Menu.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_COMMON_STARTUP</strong></p></td>
<td align="left"><p>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.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_COMMON_TEMPLATES</strong></p></td>
<td align="left"><p>The file-system directory that contains the templates that are available to all users. A typical path is C:\ProgramData\Microsoft\Windows\Templates.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_COMMON_VIDEO</strong></p></td>
<td align="left"><p>The file-system directory that serves as a repository for video files common to all users. A typical path is C:\Users\Public\Videos.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_APPDATA</strong></p></td>
<td align="left"><p>Refers to the Appdata folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>C<strong>SIDL_DEFAULT_LOCAL_APPDATA</strong></p></td>
<td align="left"><p>Refers to the local Appdata folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_COOKIES</strong></p></td>
<td align="left"><p>Refers to the Cookies folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DEFAULT_CONTACTS</strong></p></td>
<td align="left"><p>Refers to the Contacts folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_DESKTOP</strong></p></td>
<td align="left"><p>Refers to the Desktop folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DEFAULT_DOWNLOADS</strong></p></td>
<td align="left"><p>Refers to the Downloads folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_FAVORITES</strong></p></td>
<td align="left"><p>Refers to the Favorites folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DEFAULT_HISTORY</strong></p></td>
<td align="left"><p>Refers to the History folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_INTERNET_CACHE</strong></p></td>
<td align="left"><p>Refers to the Internet Cache folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DEFAULT_PERSONAL</strong></p></td>
<td align="left"><p>Refers to the Personal folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_MYDOCUMENTS</strong></p></td>
<td align="left"><p>Refers to the My Documents folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DEFAULT_MYPICTURES</strong></p></td>
<td align="left"><p>Refers to the My Pictures folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_MYMUSIC</strong></p></td>
<td align="left"><p>Refers to the My Music folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DEFAULT_MYVIDEO</strong></p></td>
<td align="left"><p>Refers to the My Videos folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_RECENT</strong></p></td>
<td align="left"><p>Refers to the Recent folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DEFAULT_SENDTO</strong></p></td>
<td align="left"><p>Refers to the Send To folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_STARTMENU</strong></p></td>
<td align="left"><p>Refers to the Start Menu folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DEFAULT_PROGRAMS</strong></p></td>
<td align="left"><p>Refers to the Programs folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_STARTUP</strong></p></td>
<td align="left"><p>Refers to the Startup folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DEFAULT_TEMPLATES</strong></p></td>
<td align="left"><p>Refers to the Templates folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_QUICKLAUNCH</strong></p></td>
<td align="left"><p>Refers to the Quick Launch folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_FONTS</strong></p></td>
<td align="left"><p>A virtual folder containing fonts. A typical path is C:\Windows\Fonts.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_PROGRAM_FILESX86</strong></p></td>
<td align="left"><p>The Program Files folder on 64-bit systems. A typical path is C:\Program Files(86).</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_PROGRAM_FILES_COMMONX86</strong></p></td>
<td align="left"><p>A folder for components that are shared across applications on 64-bit systems. A typical path is C:\Program Files(86)\Common.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_PROGRAM_FILES</strong></p></td>
<td align="left"><p>The Program Files folder. A typical path is C:\Program Files.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_PROGRAM_FILES_COMMON</strong></p></td>
<td align="left"><p>A folder for components that are shared across applications. A typical path is C:\Program Files\Common.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_RESOURCES</strong></p></td>
<td align="left"><p>The file-system directory that contains resource data. A typical path is C:\Windows\Resources.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_SYSTEM</strong></p></td>
<td align="left"><p>The Windows System folder. A typical path is C:\Windows\System32.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_WINDOWS</strong></p></td>
<td align="left"><p>The Windows directory or system root. This corresponds to the %<strong>WINDIR</strong>% or %<strong>SYSTEMROOT</strong>% environment variables. A typical path is C:\Windows.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>DEFAULTUSERPROFILE</strong></p></td>
<td align="left"><p>Refers to the value in <strong>HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList [DefaultUserProfile]</strong>.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>PROFILESFOLDER</strong></p></td>
<td align="left"><p>Refers to the value in <strong>HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList [ProfilesDirectory]</strong>.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>PROGRAMFILES</strong></p></td>
<td align="left"><p>Same as <strong>CSIDL_PROGRAM_FILES</strong>.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>PROGRAMFILES(X86)</strong></p></td>
<td align="left"><p>Refers to the C:\Program Files (x86) folder on 64-bit systems.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>SYSTEM</strong></p></td>
<td align="left"><p>Refers to %<strong>WINDIR</strong>%\system32.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>SYSTEM16</strong></p></td>
<td align="left"><p>Refers to %<strong>WINDIR</strong>%\system.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>SYSTEM32</strong></p></td>
<td align="left"><p>Refers to %<strong>WINDIR</strong>%\system32.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>SYSTEMPROFILE</strong></p></td>
<td align="left"><p>Refers to the value in <strong>HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-18 [ProfileImagePath]</strong>.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>SYSTEMROOT</strong></p></td>
<td align="left"><p>Refers to the root of the system drive.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>WINDIR</strong></p></td>
<td align="left"><p>Refers to the Windows folder located on the system drive.</p></td>
</tr>
</tbody>
</table>
 
## <a href="" id="bkmk-2"></a>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`.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Variable</th>
<th align="left">Explanation</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p><strong>APPDATA</strong></p></td>
<td align="left"><p>Same as <strong>CSIDL_APPDATA</strong>.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_ADMINTOOLS</strong></p></td>
<td align="left"><p>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.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_ALTSTARTUP</strong></p></td>
<td align="left"><p>The file-system directory that corresponds to the user's non-localized Startup program group.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_APPDATA</strong></p></td>
<td align="left"><p>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.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_BITBUCKET</strong></p></td>
<td align="left"><p>The virtual folder that contains the objects in the user's Recycle Bin.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_CDBURN_AREA</strong></p></td>
<td align="left"><p>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.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_CONNECTIONS</strong></p></td>
<td align="left"><p>The virtual folder representing Network Connections that contains network and dial-up connections.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_CONTACTS</strong></p></td>
<td align="left"><p>This refers to the Contacts folder in %<strong>CSIDL_PROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_CONTROLS</strong></p></td>
<td align="left"><p>The virtual folder that contains icons for the Control Panel items.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_COOKIES</strong></p></td>
<td align="left"><p>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.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DESKTOP</strong></p></td>
<td align="left"><p>The virtual folder representing the Windows desktop.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DESKTOPDIRECTORY</strong></p></td>
<td align="left"><p>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.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DRIVES</strong></p></td>
<td align="left"><p>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.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_FAVORITES</strong></p></td>
<td align="left"><p>The file-system directory that serves as a common repository for the user's favorites. A typical path is C:\Users\Username\Favorites.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_HISTORY</strong></p></td>
<td align="left"><p>The file-system directory that serves as a common repository for Internet history items.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_INTERNET</strong></p></td>
<td align="left"><p>A virtual folder for Internet Explorer.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_INTERNET_CACHE</strong></p></td>
<td align="left"><p>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</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_LOCAL_APPDATA</strong></p></td>
<td align="left"><p>The file-system directory that serves as a data repository for local, non-roaming applications. A typical path is C:\Users\username\AppData\Local.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_MYDOCUMENTS</strong></p></td>
<td align="left"><p>The virtual folder representing My Documents.A typical path is C:\Users\Username\Documents.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_MYMUSIC</strong></p></td>
<td align="left"><p>The file-system directory that serves as a common repository for music files. A typical path is C:\Users\Username\Music.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_MYPICTURES</strong></p></td>
<td align="left"><p>The file-system directory that serves as a common repository for image files. A typical path is C:\Users\Username\Pictures.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_MYVIDEO</strong></p></td>
<td align="left"><p>The file-system directory that serves as a common repository for video files. A typical path is C:\Users\Username\Videos.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_NETHOOD</strong></p></td>
<td align="left"><p>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.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_NETWORK</strong></p></td>
<td align="left"><p>A virtual folder representing My Network Places, the root of the network namespace hierarchy.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_PERSONAL</strong></p></td>
<td align="left"><p>The virtual folder representing the My Documents desktop item. This is equivalent to <strong>CSIDL_MYDOCUMENTS</strong>.</p>
<p>A typical path is C:\Documents and Settings\username\My Documents.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_PLAYLISTS</strong></p></td>
<td align="left"><p>The virtual folder used to store play albums, typically C:\Users\username\My Music\Playlists.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_PRINTERS</strong></p></td>
<td align="left"><p>The virtual folder that contains installed printers.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_PRINTHOOD</strong></p></td>
<td align="left"><p>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.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_PROFILE</strong></p></td>
<td align="left"><p>The user's profile folder. A typical path is C:\Users\Username.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_PROGRAMS</strong></p></td>
<td align="left"><p>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.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_RECENT</strong></p></td>
<td align="left"><p>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.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_SENDTO</strong></p></td>
<td align="left"><p>The file-system directory that contains <strong>Send To</strong> menu items. A typical path is C:\Users\username\AppData\Roaming\Microsoft\Windows\SendTo.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_STARTMENU</strong></p></td>
<td align="left"><p>The file-system directory that contains <strong>Start</strong> 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.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_STARTUP</strong></p></td>
<td align="left"><p>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.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_TEMPLATES</strong></p></td>
<td align="left"><p>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.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>HOMEPATH</strong></p></td>
<td align="left"><p>Same as the standard environment variable.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>TEMP</strong></p></td>
<td align="left"><p>The temporary folder on the computer. A typical path is %<strong>USERPROFILE</strong>%\AppData\Local\Temp.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>TMP</strong></p></td>
<td align="left"><p>The temporary folder on the computer. A typical path is %<strong>USERPROFILE</strong>%\AppData\Local\Temp.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>USERPROFILE</strong></p></td>
<td align="left"><p>Same as <strong>CSIDL_PROFILE</strong>.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>USERSID</strong></p></td>
<td align="left"><p>Represents the current user-account security identifier (SID). For example,</p>
<p>S-1-5-21-1714567821-1326601894-715345443-1026.</p></td>
</tr>
</tbody>
</table>
 
## Related topics
[USMT XML Reference](usmt-xml-reference.md)
 
 

156
windows/deployment/usmt/usmt-reference.md
View File

@ -1,77 +1,79 @@
---
title: User State Migration Toolkit (USMT) Reference (Windows 10)
description: User State Migration Toolkit (USMT) Reference
ms.assetid: 2135dbcf-de49-4cea-b2fb-97dd016e1a1a
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# User State Migration Toolkit (USMT) Reference
## In This Section
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<tbody>
<tr class="odd">
<td align="left"><p><a href="usmt-requirements.md" data-raw-source="[USMT Requirements](usmt-requirements.md)">USMT Requirements</a></p></td>
<td align="left"><p>Describes operating system, hardware, and software requirements, and user prerequisites.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-best-practices.md" data-raw-source="[USMT Best Practices](usmt-best-practices.md)">USMT Best Practices</a></p></td>
<td align="left"><p>Discusses general and security-related best practices when using USMT.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="usmt-how-it-works.md" data-raw-source="[How USMT Works](usmt-how-it-works.md)">How USMT Works</a></p></td>
<td align="left"><p>Learn about the processes behind the ScanState and LoadState tools.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-plan-your-migration.md" data-raw-source="[Plan Your Migration](usmt-plan-your-migration.md)">Plan Your Migration</a></p></td>
<td align="left"><p>Choose what to migrate and the best migration scenario for your enterprise.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="usmt-command-line-syntax.md" data-raw-source="[User State Migration Tool (USMT) Command-line Syntax](usmt-command-line-syntax.md)">User State Migration Tool (USMT) Command-line Syntax</a></p></td>
<td align="left"><p>Explore command-line options for the ScanState, LoadState, and UsmtUtils tools.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-xml-reference.md" data-raw-source="[USMT XML Reference](usmt-xml-reference.md)">USMT XML Reference</a></p></td>
<td align="left"><p>Learn about customizing a migration with XML files.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="offline-migration-reference.md" data-raw-source="[Offline Migration Reference](offline-migration-reference.md)">Offline Migration Reference</a></p></td>
<td align="left"><p>Find requirements, best practices, and other considerations for performing a migration offline.</p></td>
</tr>
</tbody>
</table>
## Related topics
[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) Troubleshooting](usmt-troubleshooting.md)
---
title: User State Migration Toolkit (USMT) Reference (Windows 10)
description: In this article, you will find references to the resources for the User State Migration Toolkit (USMT).
ms.custom: seo-marvel-apr2020
ms.assetid: 2135dbcf-de49-4cea-b2fb-97dd016e1a1a
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# User State Migration Toolkit (USMT) Reference
## In This Section
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<tbody>
<tr class="odd">
<td align="left"><p><a href="usmt-requirements.md" data-raw-source="[USMT Requirements](usmt-requirements.md)">USMT Requirements</a></p></td>
<td align="left"><p>Describes operating system, hardware, and software requirements, and user prerequisites.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-best-practices.md" data-raw-source="[USMT Best Practices](usmt-best-practices.md)">USMT Best Practices</a></p></td>
<td align="left"><p>Discusses general and security-related best practices when using USMT.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="usmt-how-it-works.md" data-raw-source="[How USMT Works](usmt-how-it-works.md)">How USMT Works</a></p></td>
<td align="left"><p>Learn about the processes behind the ScanState and LoadState tools.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-plan-your-migration.md" data-raw-source="[Plan Your Migration](usmt-plan-your-migration.md)">Plan Your Migration</a></p></td>
<td align="left"><p>Choose what to migrate and the best migration scenario for your enterprise.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="usmt-command-line-syntax.md" data-raw-source="[User State Migration Tool (USMT) Command-line Syntax](usmt-command-line-syntax.md)">User State Migration Tool (USMT) Command-line Syntax</a></p></td>
<td align="left"><p>Explore command-line options for the ScanState, LoadState, and UsmtUtils tools.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-xml-reference.md" data-raw-source="[USMT XML Reference](usmt-xml-reference.md)">USMT XML Reference</a></p></td>
<td align="left"><p>Learn about customizing a migration with XML files.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="offline-migration-reference.md" data-raw-source="[Offline Migration Reference](offline-migration-reference.md)">Offline Migration Reference</a></p></td>
<td align="left"><p>Find requirements, best practices, and other considerations for performing a migration offline.</p></td>
</tr>
</tbody>
</table>
## Related topics
[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) Troubleshooting](usmt-troubleshooting.md)

324
windows/deployment/usmt/usmt-requirements.md
View File

@ -1,161 +1,163 @@
---
title: USMT Requirements (Windows 10)
description: USMT Requirements
ms.assetid: 2b0cf3a3-9032-433f-9622-1f9df59d6806
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.date: 05/03/2017
ms.topic: article
---
# USMT Requirements
## In This Topic
- [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)
## <a href="" id="bkmk-1"></a>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 following table lists the operating systems supported in USMT.
<table>
<colgroup>
<col width="33%" />
<col width="33%" />
<col width="33%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Operating Systems</th>
<th align="left">ScanState (source computer)</th>
<th align="left">LoadState (destination computer)</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>32-bit versions of Windows 7</p></td>
<td align="left"><p>X</p></td>
<td align="left"><p>X</p></td>
</tr>
<tr class="even">
<td align="left"><p>64-bit versions of Windows 7</p></td>
<td align="left"><p>X</p></td>
<td align="left"><p>X</p></td>
</tr>
<tr class="odd">
<td align="left"><p>32-bit versions of Windows 8</p></td>
<td align="left"><p>X</p></td>
<td align="left"><p>X</p></td>
</tr>
<tr class="even">
<td align="left"><p>64-bit versions of Windows 8</p></td>
<td align="left"><p>X</p></td>
<td align="left"><p>X</p></td>
</tr>
<tr class="odd">
<td align="left"><p>32-bit versions of Windows 10</p></td>
<td align="left"><p>X</p></td>
<td align="left"><p>X</p></td>
</tr>
<tr class="even">
<td align="left"><p>64-bit versions of Windows 10</p></td>
<td align="left"><p>X</p></td>
<td align="left"><p>X</p></td>
</tr>
</tbody>
</table>
**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.
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](https://go.microsoft.com/fwlink/p/?LinkId=246564). 
## Windows PE
- **Must use latest version of Window 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](https://msdn.microsoft.com/library/windows/hardware/dn938350.aspx).
## 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.
To open an elevated command prompt:
1. Click **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.
**Important**<BR>
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)
## Config.xml
- **Specify the /c option and &lt;ErrorControl&gt; settings in the Config.xml file.**<BR>
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 **&lt;ErrorControl&gt;** element, see [Config.xml File](usmt-configxml-file.md), [Log Files](usmt-log-files.md), and [XML Elements Library](usmt-xml-elements-library.md).
## LoadState
- **Install applications before running the LoadState command.**<BR>
Install all applications on the destination computer before restoring the user state. This ensures that migrated settings are preserved.
## <a href="" id="bkmk-3"></a>Hard-Disk Requirements
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).
## <a href="" id="bkmk-userprereqs"></a>User Prerequisites
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:
- 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.
## Related topics
[Plan Your Migration](usmt-plan-your-migration.md)<BR>
[Estimate Migration Store Size](usmt-estimate-migration-store-size.md)<BR>
[User State Migration Tool (USMT) Overview Topics](usmt-topics.md)<BR>
---
title: USMT Requirements (Windows 10)
description: In this article, you will learn about the requirements for the User State Migration Toolkit (USMT) 10.0.
ms.custom: seo-marvel-apr2020
ms.assetid: 2b0cf3a3-9032-433f-9622-1f9df59d6806
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.date: 05/03/2017
ms.topic: article
---
# USMT Requirements
## In This Topic
- [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)
## <a href="" id="bkmk-1"></a>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 following table lists the operating systems supported in USMT.
<table>
<colgroup>
<col width="33%" />
<col width="33%" />
<col width="33%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Operating Systems</th>
<th align="left">ScanState (source computer)</th>
<th align="left">LoadState (destination computer)</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>32-bit versions of Windows 7</p></td>
<td align="left"><p>X</p></td>
<td align="left"><p>X</p></td>
</tr>
<tr class="even">
<td align="left"><p>64-bit versions of Windows 7</p></td>
<td align="left"><p>X</p></td>
<td align="left"><p>X</p></td>
</tr>
<tr class="odd">
<td align="left"><p>32-bit versions of Windows 8</p></td>
<td align="left"><p>X</p></td>
<td align="left"><p>X</p></td>
</tr>
<tr class="even">
<td align="left"><p>64-bit versions of Windows 8</p></td>
<td align="left"><p>X</p></td>
<td align="left"><p>X</p></td>
</tr>
<tr class="odd">
<td align="left"><p>32-bit versions of Windows 10</p></td>
<td align="left"><p>X</p></td>
<td align="left"><p>X</p></td>
</tr>
<tr class="even">
<td align="left"><p>64-bit versions of Windows 10</p></td>
<td align="left"><p>X</p></td>
<td align="left"><p>X</p></td>
</tr>
</tbody>
</table>
**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.
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](https://go.microsoft.com/fwlink/p/?LinkId=246564). 
## Windows PE
- **Must use latest version of Window 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](https://msdn.microsoft.com/library/windows/hardware/dn938350.aspx).
## 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.
To open an elevated command prompt:
1. Click **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.
**Important**<BR>
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)
## Config.xml
- **Specify the /c option and &lt;ErrorControl&gt; settings in the Config.xml file.**<BR>
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 **&lt;ErrorControl&gt;** element, see [Config.xml File](usmt-configxml-file.md), [Log Files](usmt-log-files.md), and [XML Elements Library](usmt-xml-elements-library.md).
## LoadState
- **Install applications before running the LoadState command.**<BR>
Install all applications on the destination computer before restoring the user state. This ensures that migrated settings are preserved.
## <a href="" id="bkmk-3"></a>Hard-Disk Requirements
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).
## <a href="" id="bkmk-userprereqs"></a>User Prerequisites
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:
- 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.
## Related topics
[Plan Your Migration](usmt-plan-your-migration.md)<BR>
[Estimate Migration Store Size](usmt-estimate-migration-store-size.md)<BR>
[User State Migration Tool (USMT) Overview Topics](usmt-topics.md)<BR>

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

@ -1,6 +1,7 @@
---
title: Reroute Files and Settings (Windows 10)
description: Reroute Files and Settings
description: In this article, you will find examples on how to create custom .xml files to reroute files and settings.
ms.custom: seo-marvel-apr2020
ms.assetid: 905e6a24-922c-4549-9732-60fa11862a6c
ms.reviewer:
manager: laurawi

101
windows/deployment/usmt/usmt-resources.md
View File

@ -1,50 +1,51 @@
---
title: USMT Resources (Windows 10)
description: USMT Resources
ms.assetid: a0b266c7-4bcb-49f1-b63c-48c6ace86b43
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# USMT Resources
## USMT Online Resources
- [ADK Release Notes](https://msdn.microsoft.com/library/windows/hardware/dn927348.aspx)
- Microsoft Visual Studio
- You can use the User State Migration Tool (USMT) XML schema (the MigXML.xsd file) to validate the migration .xml files using an XML authoring tool such as Microsoft® Visual Studio®.
For more information about how to use the schema with your XML authoring environment, see the environment’s documentation.
- [Ask the Directory Services Team blog](https://go.microsoft.com/fwlink/p/?LinkId=226365)
- Forums:
- [Microsoft Deployment Toolkit](https://go.microsoft.com/fwlink/p/?LinkId=226386)
- [Configuration Manager Operating System Deployment](https://go.microsoft.com/fwlink/p/?LinkId=226388)
## Related topics
[User State Migration Tool (USMT) Overview Topics](usmt-topics.md)
 
 
---
title: USMT Resources (Windows 10)
description: USMT Resources
ms.assetid: a0b266c7-4bcb-49f1-b63c-48c6ace86b43
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# USMT Resources
## USMT Online Resources
- [ADK Release Notes](https://msdn.microsoft.com/library/windows/hardware/dn927348.aspx)
- Microsoft Visual Studio
- You can use the User State Migration Tool (USMT) XML schema (the MigXML.xsd file) to validate the migration .xml files using an XML authoring tool such as Microsoft® Visual Studio®.
For more information about how to use the schema with your XML authoring environment, see the environment’s documentation.
- [Ask the Directory Services Team blog](https://go.microsoft.com/fwlink/p/?LinkId=226365)
- Forums:
- [Microsoft Deployment Toolkit](https://go.microsoft.com/fwlink/p/?LinkId=226386)
- [Configuration Manager Operating System Deployment](https://go.microsoft.com/fwlink/p/?LinkId=226388)
## Related topics
[User State Migration Tool (USMT) Overview Topics](usmt-topics.md)
 
 

1574
windows/deployment/usmt/usmt-return-codes.md
View File

File diff suppressed because it is too large Load Diff

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

File diff suppressed because it is too large Load Diff

3
windows/deployment/usmt/usmt-test-your-migration.md
View File

@ -1,6 +1,7 @@
---
title: Test Your Migration (Windows 10)
description: Test Your Migration
description: This article will help you learn, how to test your migration plan before you deploy it to your entire organization.
ms.custom: seo-marvel-apr2020
ms.assetid: 754af276-8386-4eac-8079-3d1e45964a0d
ms.reviewer:
manager: laurawi

62
windows/deployment/usmt/usmt-topics.md
View File

@ -1,30 +1,32 @@
---
title: User State Migration Tool (USMT) Overview Topics (Windows 10)
description: User State Migration Tool (USMT) Overview Topics
ms.assetid: 23170271-130b-416f-a7a7-c2f6adc32eee
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# User State Migration Tool (USMT) Overview Topics
The User State Migration Tool (USMT) 10.0 provides a highly customizable user-profile migration experience for IT professionals. USMT includes three command-line tools: ScanState.exe, LoadState.exe, and UsmtUtils.exe. USMT also includes a set of three modifiable .xml files: MigApp.xml, MigDocs.xml, and MigUser.xml. Additionally, you can create custom .xml files to support your migration needs. You can also create a Config.xml file to specify files or settings to exclude from the migration.
## In This Section
|Topic |Description|
|------|-----------|
|[User State Migration Tool (USMT) Overview](usmt-overview.md)|Describes the benefits and limitations of using USMT.|
|[Getting Started with the User State Migration Tool (USMT)](getting-started-with-the-user-state-migration-tool.md)|Describes the general process to follow to migrate files and settings, and provides links to more information.|
|[Windows Upgrade and Migration Considerations](../upgrade/windows-upgrade-and-migration-considerations.md)|Discusses the Microsoft® tools you can use to move files and settings between installations, as well as special considerations for performing an upgrade or migration.|
## Related topics
- [User State Migration Tool (USMT) How-to topics](usmt-how-to.md)
- [User State Migration Tool (USMT) Troubleshooting](usmt-troubleshooting.md)
- [User State Migration Toolkit (USMT) Reference](usmt-reference.md)
---
title: User State Migration Tool (USMT) Overview Topics (Windows 10)
description: This article contains a list of topics that will help you get started with migration using the User State Migration Tool (USMT).
ms.custom: seo-marvel-apr2020
ms.assetid: 23170271-130b-416f-a7a7-c2f6adc32eee
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# User State Migration Tool (USMT) Overview Topics
The User State Migration Tool (USMT) 10.0 provides a highly customizable user-profile migration experience for IT professionals. USMT includes three command-line tools: ScanState.exe, LoadState.exe, and UsmtUtils.exe. USMT also includes a set of three modifiable .xml files: MigApp.xml, MigDocs.xml, and MigUser.xml. Additionally, you can create custom .xml files to support your migration needs. You can also create a Config.xml file to specify files or settings to exclude from the migration.
## In This Section
|Topic |Description|
|------|-----------|
|[User State Migration Tool (USMT) Overview](usmt-overview.md)|Describes the benefits and limitations of using USMT.|
|[Getting Started with the User State Migration Tool (USMT)](getting-started-with-the-user-state-migration-tool.md)|Describes the general process to follow to migrate files and settings, and provides links to more information.|
|[Windows Upgrade and Migration Considerations](../upgrade/windows-upgrade-and-migration-considerations.md)|Discusses the Microsoft® tools you can use to move files and settings between installations, as well as special considerations for performing an upgrade or migration.|
## Related topics
- [User State Migration Tool (USMT) How-to topics](usmt-how-to.md)
- [User State Migration Tool (USMT) Troubleshooting](usmt-troubleshooting.md)
- [User State Migration Toolkit (USMT) Reference](usmt-reference.md)

148
windows/deployment/usmt/usmt-troubleshooting.md
View File

@ -1,73 +1,75 @@
---
title: User State Migration Tool (USMT) Troubleshooting (Windows 10)
description: User State Migration Tool (USMT) Troubleshooting
ms.assetid: 770f45bb-2284-463f-a29c-69c04f437533
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# User State Migration Tool (USMT) Troubleshooting
The following table describes topics that address common User State Migration Tool (USMT) 10.0 issues and questions. These topics describe tools that you can use to troubleshoot issues that arise during your migration.
## In This Section
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<tbody>
<tr class="odd">
<td align="left"><p><a href="usmt-common-issues.md" data-raw-source="[Common Issues](usmt-common-issues.md)">Common Issues</a></p></td>
<td align="left"><p>Find troubleshooting solutions for common problems in USMT.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-faq.md" data-raw-source="[Frequently Asked Questions](usmt-faq.md)">Frequently Asked Questions</a></p></td>
<td align="left"><p>Find answers to questions about how to use USMT.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="usmt-log-files.md" data-raw-source="[Log Files](usmt-log-files.md)">Log Files</a></p></td>
<td align="left"><p>Learn how to enable logging to help you troubleshoot issues in USMT.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-return-codes.md" data-raw-source="[Return Codes](usmt-return-codes.md)">Return Codes</a></p></td>
<td align="left"><p>Learn how to use return codes to identify problems in USMT.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="usmt-resources.md" data-raw-source="[USMT Resources](usmt-resources.md)">USMT Resources</a></p></td>
<td align="left"><p>Find more information and support for using USMT.</p></td>
</tr>
</tbody>
</table>
## Related topics
[USMT Best Practices](usmt-best-practices.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 Toolkit (USMT) Reference](usmt-reference.md)
---
title: User State Migration Tool (USMT) Troubleshooting (Windows 10)
description: In this article, you'll find a list of topics that address common User State Migration Tool (USMT) 10.0 issues and questions.
ms.custom: seo-marvel-apr2020
ms.assetid: 770f45bb-2284-463f-a29c-69c04f437533
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# User State Migration Tool (USMT) Troubleshooting
The following table describes topics that address common User State Migration Tool (USMT) 10.0 issues and questions. These topics describe tools that you can use to troubleshoot issues that arise during your migration.
## In This Section
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<tbody>
<tr class="odd">
<td align="left"><p><a href="usmt-common-issues.md" data-raw-source="[Common Issues](usmt-common-issues.md)">Common Issues</a></p></td>
<td align="left"><p>Find troubleshooting solutions for common problems in USMT.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-faq.md" data-raw-source="[Frequently Asked Questions](usmt-faq.md)">Frequently Asked Questions</a></p></td>
<td align="left"><p>Find answers to questions about how to use USMT.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="usmt-log-files.md" data-raw-source="[Log Files](usmt-log-files.md)">Log Files</a></p></td>
<td align="left"><p>Learn how to enable logging to help you troubleshoot issues in USMT.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-return-codes.md" data-raw-source="[Return Codes](usmt-return-codes.md)">Return Codes</a></p></td>
<td align="left"><p>Learn how to use return codes to identify problems in USMT.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="usmt-resources.md" data-raw-source="[USMT Resources](usmt-resources.md)">USMT Resources</a></p></td>
<td align="left"><p>Find more information and support for using USMT.</p></td>
</tr>
</tbody>
</table>
## Related topics
[USMT Best Practices](usmt-best-practices.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 Toolkit (USMT) Reference](usmt-reference.md)

704
windows/deployment/usmt/usmt-utilities.md
View File

@ -1,351 +1,353 @@
---
title: UsmtUtils Syntax (Windows 10)
description: UsmtUtils Syntax
ms.assetid: cdab7f2d-dd68-4016-b9ed-41ffa743b65c
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# UsmtUtils Syntax
This topic describes the syntax for the utilities available in User State Migration Tool (USMT) 10.0 through the command-line interface. These utilities:
- Improve your ability to determine cryptographic options for your migration.
- Assist in removing hard-link stores that cannot otherwise be deleted due to a sharing lock.
- Verify whether the catalog file or any of the other files in the compressed migration store have become corrupted.
- Extract files from the compressed migration store when you migrate files and settings to the destination computer.
## In This Topic
[Usmtutils.exe](#bkmk-usmtutils-exe)
[Verify Options](#bkmk-verifyoptions)
[Extract Options](#bkmk-extractoptions)
## <a href="" id="bkmk-usmtutils-exe"></a>Usmtutils.exe
The following table lists command-line options for USMTutils.exe. The sections that follow provide further command-line options for the **/verify** and the **/extract** options.
The syntax for UsmtUtils.exe is:
usmtutils \[/ec | /rd *&lt;storeDir&gt;* | /verify *&lt;filepath&gt;* \[options\] | /extract *&lt;filepath&gt;* *&lt;destinationPath&gt;* \[options\]\]
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Command-line Option</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p><strong>/ec</strong></p></td>
<td align="left"><p>Returns a list of supported cryptographic algorithms (AlgIDs) on the current system. You can use this on a destination computer to determine which algorithm to use with the <strong>/encrypt</strong> command before you run the ScanState tool on the source computer.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/rd</strong><em>&lt;storeDir&gt;</em></p></td>
<td align="left"><p>Removes the directory path specified by the <em>&lt;storeDir&gt;</em> argument on the computer. You can use this command to delete hard-link migration stores that cannot otherwise be deleted at a command prompt due to a sharing lock. If the migration store spans multiple volumes on a given drive, it will be deleted from all of these volumes.</p>
<p>For example:</p>
<p><code>usmtutils /rd D:\MyHardLinkStore</code></p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>/y</strong></p></td>
<td align="left"><p>Overrides the accept deletions prompt when used with the <strong>/rd</strong> option. When you use the <strong>/y</strong> option with the <strong>/rd</strong> option, you will not be prompted to accept the deletions before USMT deletes the directories.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/verify</strong></p></td>
<td align="left"><p>Returns information on whether the compressed migration store is intact or whether it contains corrupted files or a corrupted catalog.</p>
<p>See <a href="#bkmk-verifyoptions" data-raw-source="[Verify Options](#bkmk-verifyoptions)">Verify Options</a> for syntax and options to use with <strong>/verify</strong>.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>/extract</strong></p></td>
<td align="left"><p>Recovers files from a compressed USMT migration store.</p>
<p>See <a href="#bkmk-extractoptions" data-raw-source="[Extract Options](#bkmk-extractoptions)">Extract Options</a> for syntax and options to use with <strong>/extract</strong>.</p></td>
</tr>
</tbody>
</table>
## <a href="" id="bkmk-verifyoptions"></a>Verify Options
Use the **/verify** option when you want to determine whether a compressed migration store is intact or whether it contains corrupted files or a corrupted catalog. For more information on how to use the **/verify** option, see [Verify the Condition of a Compressed Migration Store](verify-the-condition-of-a-compressed-migration-store.md).
The syntax for **/verify** is:
usmtutils /verify\[:*&lt;reportType&gt;*\] *&lt;filePath&gt;* \[/l:*&lt;logfile&gt;*\] \[/v:*VerbosityLevel*\] \[/decrypt \[:*&lt;AlgID&gt;*\] {/key:*&lt;keystring&gt;* | /keyfile:*&lt;filename&gt;*}\]
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Command-line Option</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p><em>&lt;reportType&gt;</em></p></td>
<td align="left"><p>Specifies whether to report on all files, corrupted files only, or the status of the catalog.</p>
<ul>
<li><p><strong>Summary</strong>. Returns both the number of files that are intact and the number of files that are corrupted in the migration store. If no algorithm is specified, the summary report is displayed as a default.</p></li>
<li><p><strong>all</strong>. Returns a tab-delimited list of all of the files in the compressed migration store and the status for each file. Each line contains the file name followed by a tab spacing, and either “CORRUPTED” or “OK” depending on the status of the file. The last entry reports the corruption status of the &quot;CATALOG&quot; of the store. A catalog file contains metadata for all files in a migration store. The LoadState tool requires a valid catalog file in order to open the migration store. Returns &quot;OK&quot; if the catalog file is intact and LoadState can open the migration store and &quot;CORRUPTED&quot; if the migration store is corrupted.</p></li>
<li><p><strong>failureonly</strong>. Returns a tab-delimited list of only the files that are corrupted in the compressed migration store.</p></li>
<li><p><strong>Catalog</strong>. Returns only the status of the catalog file.</p></li>
</ul></td>
</tr>
<tr class="even">
<td align="left"><strong>/l:</strong>
<p><em>&lt;logfilePath&gt;</em></p></td>
<td align="left"><p>Specifies the location and name of the log file.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>/v:</strong><em>&lt;VerbosityLevel&gt;</em></p></td>
<td align="left"><p><strong>(Verbosity)</strong></p>
<p>Enables verbose output in the UsmtUtils log file. The default value is 0.</p>
<p>You can set the <em>VerbosityLevel</em> to one of the following levels:</p>
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Level</th>
<th align="left">Explanation</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>0</p></td>
<td align="left"><p>Only the default errors and warnings are enabled.</p></td>
</tr>
<tr class="even">
<td align="left"><p>1</p></td>
<td align="left"><p>Enables verbose output.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>4</p></td>
<td align="left"><p>Enables error and status output.</p></td>
</tr>
<tr class="even">
<td align="left"><p>5</p></td>
<td align="left"><p>Enables verbose and status output.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>8</p></td>
<td align="left"><p>Enables error output to a debugger.</p></td>
</tr>
<tr class="even">
<td align="left"><p>9</p></td>
<td align="left"><p>Enables verbose output to a debugger.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>12</p></td>
<td align="left"><p>Enables error and status output to a debugger.</p></td>
</tr>
<tr class="even">
<td align="left"><p>13</p></td>
<td align="left"><p>Enables verbose, status, and debugger output.</p></td>
</tr>
</tbody>
</table>
<p> </p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/decrypt</strong><em>&lt;AlgID&gt;</em><strong>/</strong>:<em>&lt;KeyString&gt;</em></p>
<p>or</p>
<p><strong>/decrypt</strong><em>&lt;AlgID&gt;</em><strong>/</strong>:<em>&lt;“Key String”&gt;</em></p>
<p>or</p>
<p><strong>/decrypt:</strong><em>&lt;AlgID&gt;</em><strong>/keyfile</strong>:<em>&lt;FileName&gt;</em></p></td>
<td align="left"><p>Specifies that the <strong>/encrypt</strong> option was used to create the migration store with the ScanState tool. To decrypt the migration store, specify a <strong>/key</strong> or <strong>/keyfile</strong> option as follows:</p>
<ul>
<li><p><em>&lt;AlgID&gt;</em> specifies the cryptographic algorithm that was used to create the migration store on the ScanState command line. If no algorithm is specified, ScanState and UsmtUtils use the 3DES algorithm as a default.</p>
<p><em>&lt;AlgID&gt;</em> valid values include: AES_128, AES_192, AES_256, 3DES, or 3DES_112.</p></li>
<li><p><strong>/key:</strong><em>&lt;KeyString&gt;</em> specifies the encryption key. If there is a space in <em>&lt;KeyString&gt;</em>, you must surround the argument with quotation marks.</p></li>
<li><p><strong>/keyfile</strong>: <em>&lt;FileName&gt;</em> specifies the location and name of a text (.txt) file that contains the encryption key.</p></li>
</ul>
<p>For more information about supported encryption algorithms, see <a href="usmt-migration-store-encryption.md" data-raw-source="[Migration Store Encryption](usmt-migration-store-encryption.md)">Migration Store Encryption</a></p></td>
</tr>
</tbody>
</table>
Some examples of **/verify** commands:
- `usmtutils /verify D:\MyMigrationStore\store.mig`
- `usmtutils /verify:catalog D:\MyMigrationStore\store.mig`
- `usmtutils /verify:all D:\MyMigrationStore\store.mig /decrypt /l:D:\UsmtUtilsLog.txt`
- `usmtutils /verify:failureonly D:\MyMigrationStore\store.mig /decrypt:AES_192 /keyfile:D:\encryptionKey.txt`
## <a href="" id="bkmk-extractoptions"></a>Extract Options
Use the **/extract** option to recover files from a compressed USMT migration store if it will not restore normally with loadstate. For more information on how to use the **/extract** option, see [Extract Files from a Compressed USMT Migration Store](usmt-extract-files-from-a-compressed-migration-store.md).
The syntax for **/extract** is:
/extract *&lt;filePath&gt;* *&lt;destinationPath&gt;* \[/i:*&lt;includePattern&gt;*\] \[/e: *&lt;excludePattern&gt;*\] \[/l: *&lt;logfile&gt;*\] \[/v: *VerbosityLevel&gt;*\] \[/decrypt\[:*&lt;AlgID&gt;*\] {key: *&lt;keystring&gt;* | /keyfile: *&lt;filename&gt;*}\] \[/o\]
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Command-line Option</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p><em>&lt;filePath&gt;</em></p></td>
<td align="left"><p>Path to the USMT migration store.</p>
<p>For example:</p>
<p><code>D:\MyMigrationStore\USMT\store.mig</code></p></td>
</tr>
<tr class="even">
<td align="left"><p><em>&lt;destinationPath&gt;</em></p></td>
<td align="left"><p>Path to the folder where the tool puts the individual files.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>/i</strong>:<em>&lt;includePattern&gt;</em></p></td>
<td align="left"><p>Specifies a pattern for files to include in the extraction. You can specify more than one pattern. Separate patterns with a comma or a semicolon. You can use <strong>/i</strong>: <em>&lt;includePattern&gt;</em> and <strong>/e</strong>: <em>&lt;excludePattern&gt;</em> options in the same command. When both include and exclude patterns are used on the command line, include patterns take precedence over exclude patterns.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/e</strong>:<em>&lt;excludePattern&gt;</em></p></td>
<td align="left"><p>Specifies a pattern for files to omit from the extraction. You can specify more than one pattern. Separate patterns with a comma or a semicolon. You can use <strong>/i</strong>: <em>&lt;includePattern&gt;</em> and <strong>/e</strong>: <em>&lt;excludePattern&gt;</em> options in the same command. When both include and exclude patterns are used on the command line, include patterns take precedence over exclude patterns.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>/l</strong>:<em>&lt;logfilePath&gt;</em></p></td>
<td align="left"><p>Specifies the location and name of the log file.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/v:</strong><em>&lt;VerbosityLevel&gt;</em></p></td>
<td align="left"><p><strong>(Verbosity)</strong></p>
<p>Enables verbose output in the UsmtUtils log file. The default value is 0.</p>
<p>You can set the <em>VerbosityLevel</em> to one of the following levels:</p>
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Level</th>
<th align="left">Explanation</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>0</p></td>
<td align="left"><p>Only the default errors and warnings are enabled.</p></td>
</tr>
<tr class="even">
<td align="left"><p>1</p></td>
<td align="left"><p>Enables verbose output.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>4</p></td>
<td align="left"><p>Enables error and status output.</p></td>
</tr>
<tr class="even">
<td align="left"><p>5</p></td>
<td align="left"><p>Enables verbose and status output.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>8</p></td>
<td align="left"><p>Enables error output to a debugger.</p></td>
</tr>
<tr class="even">
<td align="left"><p>9</p></td>
<td align="left"><p>Enables verbose output to a debugger.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>12</p></td>
<td align="left"><p>Enables error and status output to a debugger.</p></td>
</tr>
<tr class="even">
<td align="left"><p>13</p></td>
<td align="left"><p>Enables verbose, status, and debugger output.</p></td>
</tr>
</tbody>
</table>
<p> </p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>/decrypt</strong><em>&lt;AlgID&gt;</em><strong>/key</strong>:<em>&lt;KeyString&gt;</em></p>
<p>or</p>
<p><strong>/decrypt</strong><em>&lt;AlgID&gt;</em><strong>/</strong>:<em>&lt;“Key String”&gt;</em></p>
<p>or</p>
<p><strong>/decrypt:</strong><em>&lt;AlgID&gt;</em><strong>/keyfile</strong>:<em>&lt;FileName&gt;</em></p></td>
<td align="left"><p>Specifies that the <strong>/encrypt</strong> option was used to create the migration store with the ScanState tool. To decrypt the migration store, you must also specify a <strong>/key</strong> or <strong>/keyfile</strong> option as follows:</p>
<ul>
<li><p><em>&lt;AlgID&gt;</em> specifies the cryptographic algorithm that was used to create the migration store on the ScanState command line. If no algorithm is specified, ScanState and UsmtUtils use the 3DES algorithm as a default.</p>
<p><em>&lt;AlgID&gt;</em> valid values include: AES_128, AES_192, AES_256, 3DES, or 3DES_112.</p></li>
<li><p><strong>/key</strong>: <em>&lt;KeyString&gt;</em> specifies the encryption key. If there is a space in <em>&lt;KeyString&gt;</em>, you must surround the argument with quotation marks.</p></li>
<li><p><strong>/keyfile</strong>:<em>&lt;FileName&gt;</em> specifies a text (.txt) file that contains the encryption key</p></li>
</ul>
<p>For more information about supported encryption algorithms, see <a href="usmt-migration-store-encryption.md" data-raw-source="[Migration Store Encryption](usmt-migration-store-encryption.md)">Migration Store Encryption</a>.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/o</strong></p></td>
<td align="left"><p>Overwrites existing output files.</p></td>
</tr>
</tbody>
</table>
Some examples of **/extract** commands:
- `usmtutils /extract D:\MyMigrationStore\USMT\store.mig C:\ExtractedStore`
- `usmtutils /extract D:\MyMigrationStore\USMT\store.mig /i:"*.txt, *.pdf" C:\ExtractedStore /decrypt /keyfile:D:\encryptionKey.txt`
- `usmtutils /extract D:\MyMigrationStore\USMT\store.mig /e:*.exe C:\ExtractedStore /decrypt:AES_128 /key:password /l:C:\usmtlog.txt`
- `usmtutils /extract D:\MyMigrationStore\USMT\store.mig /i:myProject.* /e:*.exe C:\ExtractedStore /o`
## Related topics
[User State Migration Tool (USMT) Command-line Syntax](usmt-command-line-syntax.md)
[Return Codes](usmt-return-codes.md)
---
title: UsmtUtils Syntax (Windows 10)
description: This article describes the syntax for the utilities available in User State Migration Tool (USMT) 10.0 through the command-line interface.
ms.custom: seo-marvel-apr2020
ms.assetid: cdab7f2d-dd68-4016-b9ed-41ffa743b65c
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# UsmtUtils Syntax
This topic describes the syntax for the utilities available in User State Migration Tool (USMT) 10.0 through the command-line interface. These utilities:
- Improve your ability to determine cryptographic options for your migration.
- Assist in removing hard-link stores that cannot otherwise be deleted due to a sharing lock.
- Verify whether the catalog file or any of the other files in the compressed migration store have become corrupted.
- Extract files from the compressed migration store when you migrate files and settings to the destination computer.
## In This Topic
[Usmtutils.exe](#bkmk-usmtutils-exe)
[Verify Options](#bkmk-verifyoptions)
[Extract Options](#bkmk-extractoptions)
## <a href="" id="bkmk-usmtutils-exe"></a>Usmtutils.exe
The following table lists command-line options for USMTutils.exe. The sections that follow provide further command-line options for the **/verify** and the **/extract** options.
The syntax for UsmtUtils.exe is:
usmtutils \[/ec | /rd *&lt;storeDir&gt;* | /verify *&lt;filepath&gt;* \[options\] | /extract *&lt;filepath&gt;* *&lt;destinationPath&gt;* \[options\]\]
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Command-line Option</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p><strong>/ec</strong></p></td>
<td align="left"><p>Returns a list of supported cryptographic algorithms (AlgIDs) on the current system. You can use this on a destination computer to determine which algorithm to use with the <strong>/encrypt</strong> command before you run the ScanState tool on the source computer.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/rd</strong><em>&lt;storeDir&gt;</em></p></td>
<td align="left"><p>Removes the directory path specified by the <em>&lt;storeDir&gt;</em> argument on the computer. You can use this command to delete hard-link migration stores that cannot otherwise be deleted at a command prompt due to a sharing lock. If the migration store spans multiple volumes on a given drive, it will be deleted from all of these volumes.</p>
<p>For example:</p>
<p><code>usmtutils /rd D:\MyHardLinkStore</code></p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>/y</strong></p></td>
<td align="left"><p>Overrides the accept deletions prompt when used with the <strong>/rd</strong> option. When you use the <strong>/y</strong> option with the <strong>/rd</strong> option, you will not be prompted to accept the deletions before USMT deletes the directories.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/verify</strong></p></td>
<td align="left"><p>Returns information on whether the compressed migration store is intact or whether it contains corrupted files or a corrupted catalog.</p>
<p>See <a href="#bkmk-verifyoptions" data-raw-source="[Verify Options](#bkmk-verifyoptions)">Verify Options</a> for syntax and options to use with <strong>/verify</strong>.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>/extract</strong></p></td>
<td align="left"><p>Recovers files from a compressed USMT migration store.</p>
<p>See <a href="#bkmk-extractoptions" data-raw-source="[Extract Options](#bkmk-extractoptions)">Extract Options</a> for syntax and options to use with <strong>/extract</strong>.</p></td>
</tr>
</tbody>
</table>
## <a href="" id="bkmk-verifyoptions"></a>Verify Options
Use the **/verify** option when you want to determine whether a compressed migration store is intact or whether it contains corrupted files or a corrupted catalog. For more information on how to use the **/verify** option, see [Verify the Condition of a Compressed Migration Store](verify-the-condition-of-a-compressed-migration-store.md).
The syntax for **/verify** is:
usmtutils /verify\[:*&lt;reportType&gt;*\] *&lt;filePath&gt;* \[/l:*&lt;logfile&gt;*\] \[/v:*VerbosityLevel*\] \[/decrypt \[:*&lt;AlgID&gt;*\] {/key:*&lt;keystring&gt;* | /keyfile:*&lt;filename&gt;*}\]
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Command-line Option</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p><em>&lt;reportType&gt;</em></p></td>
<td align="left"><p>Specifies whether to report on all files, corrupted files only, or the status of the catalog.</p>
<ul>
<li><p><strong>Summary</strong>. Returns both the number of files that are intact and the number of files that are corrupted in the migration store. If no algorithm is specified, the summary report is displayed as a default.</p></li>
<li><p><strong>all</strong>. Returns a tab-delimited list of all of the files in the compressed migration store and the status for each file. Each line contains the file name followed by a tab spacing, and either “CORRUPTED” or “OK” depending on the status of the file. The last entry reports the corruption status of the &quot;CATALOG&quot; of the store. A catalog file contains metadata for all files in a migration store. The LoadState tool requires a valid catalog file in order to open the migration store. Returns &quot;OK&quot; if the catalog file is intact and LoadState can open the migration store and &quot;CORRUPTED&quot; if the migration store is corrupted.</p></li>
<li><p><strong>failureonly</strong>. Returns a tab-delimited list of only the files that are corrupted in the compressed migration store.</p></li>
<li><p><strong>Catalog</strong>. Returns only the status of the catalog file.</p></li>
</ul></td>
</tr>
<tr class="even">
<td align="left"><strong>/l:</strong>
<p><em>&lt;logfilePath&gt;</em></p></td>
<td align="left"><p>Specifies the location and name of the log file.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>/v:</strong><em>&lt;VerbosityLevel&gt;</em></p></td>
<td align="left"><p><strong>(Verbosity)</strong></p>
<p>Enables verbose output in the UsmtUtils log file. The default value is 0.</p>
<p>You can set the <em>VerbosityLevel</em> to one of the following levels:</p>
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Level</th>
<th align="left">Explanation</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>0</p></td>
<td align="left"><p>Only the default errors and warnings are enabled.</p></td>
</tr>
<tr class="even">
<td align="left"><p>1</p></td>
<td align="left"><p>Enables verbose output.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>4</p></td>
<td align="left"><p>Enables error and status output.</p></td>
</tr>
<tr class="even">
<td align="left"><p>5</p></td>
<td align="left"><p>Enables verbose and status output.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>8</p></td>
<td align="left"><p>Enables error output to a debugger.</p></td>
</tr>
<tr class="even">
<td align="left"><p>9</p></td>
<td align="left"><p>Enables verbose output to a debugger.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>12</p></td>
<td align="left"><p>Enables error and status output to a debugger.</p></td>
</tr>
<tr class="even">
<td align="left"><p>13</p></td>
<td align="left"><p>Enables verbose, status, and debugger output.</p></td>
</tr>
</tbody>
</table>
<p> </p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/decrypt</strong><em>&lt;AlgID&gt;</em><strong>/</strong>:<em>&lt;KeyString&gt;</em></p>
<p>or</p>
<p><strong>/decrypt</strong><em>&lt;AlgID&gt;</em><strong>/</strong>:<em>&lt;“Key String”&gt;</em></p>
<p>or</p>
<p><strong>/decrypt:</strong><em>&lt;AlgID&gt;</em><strong>/keyfile</strong>:<em>&lt;FileName&gt;</em></p></td>
<td align="left"><p>Specifies that the <strong>/encrypt</strong> option was used to create the migration store with the ScanState tool. To decrypt the migration store, specify a <strong>/key</strong> or <strong>/keyfile</strong> option as follows:</p>
<ul>
<li><p><em>&lt;AlgID&gt;</em> specifies the cryptographic algorithm that was used to create the migration store on the ScanState command line. If no algorithm is specified, ScanState and UsmtUtils use the 3DES algorithm as a default.</p>
<p><em>&lt;AlgID&gt;</em> valid values include: AES_128, AES_192, AES_256, 3DES, or 3DES_112.</p></li>
<li><p><strong>/key:</strong><em>&lt;KeyString&gt;</em> specifies the encryption key. If there is a space in <em>&lt;KeyString&gt;</em>, you must surround the argument with quotation marks.</p></li>
<li><p><strong>/keyfile</strong>: <em>&lt;FileName&gt;</em> specifies the location and name of a text (.txt) file that contains the encryption key.</p></li>
</ul>
<p>For more information about supported encryption algorithms, see <a href="usmt-migration-store-encryption.md" data-raw-source="[Migration Store Encryption](usmt-migration-store-encryption.md)">Migration Store Encryption</a></p></td>
</tr>
</tbody>
</table>
Some examples of **/verify** commands:
- `usmtutils /verify D:\MyMigrationStore\store.mig`
- `usmtutils /verify:catalog D:\MyMigrationStore\store.mig`
- `usmtutils /verify:all D:\MyMigrationStore\store.mig /decrypt /l:D:\UsmtUtilsLog.txt`
- `usmtutils /verify:failureonly D:\MyMigrationStore\store.mig /decrypt:AES_192 /keyfile:D:\encryptionKey.txt`
## <a href="" id="bkmk-extractoptions"></a>Extract Options
Use the **/extract** option to recover files from a compressed USMT migration store if it will not restore normally with loadstate. For more information on how to use the **/extract** option, see [Extract Files from a Compressed USMT Migration Store](usmt-extract-files-from-a-compressed-migration-store.md).
The syntax for **/extract** is:
/extract *&lt;filePath&gt;* *&lt;destinationPath&gt;* \[/i:*&lt;includePattern&gt;*\] \[/e: *&lt;excludePattern&gt;*\] \[/l: *&lt;logfile&gt;*\] \[/v: *VerbosityLevel&gt;*\] \[/decrypt\[:*&lt;AlgID&gt;*\] {key: *&lt;keystring&gt;* | /keyfile: *&lt;filename&gt;*}\] \[/o\]
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Command-line Option</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p><em>&lt;filePath&gt;</em></p></td>
<td align="left"><p>Path to the USMT migration store.</p>
<p>For example:</p>
<p><code>D:\MyMigrationStore\USMT\store.mig</code></p></td>
</tr>
<tr class="even">
<td align="left"><p><em>&lt;destinationPath&gt;</em></p></td>
<td align="left"><p>Path to the folder where the tool puts the individual files.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>/i</strong>:<em>&lt;includePattern&gt;</em></p></td>
<td align="left"><p>Specifies a pattern for files to include in the extraction. You can specify more than one pattern. Separate patterns with a comma or a semicolon. You can use <strong>/i</strong>: <em>&lt;includePattern&gt;</em> and <strong>/e</strong>: <em>&lt;excludePattern&gt;</em> options in the same command. When both include and exclude patterns are used on the command line, include patterns take precedence over exclude patterns.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/e</strong>:<em>&lt;excludePattern&gt;</em></p></td>
<td align="left"><p>Specifies a pattern for files to omit from the extraction. You can specify more than one pattern. Separate patterns with a comma or a semicolon. You can use <strong>/i</strong>: <em>&lt;includePattern&gt;</em> and <strong>/e</strong>: <em>&lt;excludePattern&gt;</em> options in the same command. When both include and exclude patterns are used on the command line, include patterns take precedence over exclude patterns.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>/l</strong>:<em>&lt;logfilePath&gt;</em></p></td>
<td align="left"><p>Specifies the location and name of the log file.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/v:</strong><em>&lt;VerbosityLevel&gt;</em></p></td>
<td align="left"><p><strong>(Verbosity)</strong></p>
<p>Enables verbose output in the UsmtUtils log file. The default value is 0.</p>
<p>You can set the <em>VerbosityLevel</em> to one of the following levels:</p>
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Level</th>
<th align="left">Explanation</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>0</p></td>
<td align="left"><p>Only the default errors and warnings are enabled.</p></td>
</tr>
<tr class="even">
<td align="left"><p>1</p></td>
<td align="left"><p>Enables verbose output.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>4</p></td>
<td align="left"><p>Enables error and status output.</p></td>
</tr>
<tr class="even">
<td align="left"><p>5</p></td>
<td align="left"><p>Enables verbose and status output.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>8</p></td>
<td align="left"><p>Enables error output to a debugger.</p></td>
</tr>
<tr class="even">
<td align="left"><p>9</p></td>
<td align="left"><p>Enables verbose output to a debugger.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>12</p></td>
<td align="left"><p>Enables error and status output to a debugger.</p></td>
</tr>
<tr class="even">
<td align="left"><p>13</p></td>
<td align="left"><p>Enables verbose, status, and debugger output.</p></td>
</tr>
</tbody>
</table>
<p> </p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>/decrypt</strong><em>&lt;AlgID&gt;</em><strong>/key</strong>:<em>&lt;KeyString&gt;</em></p>
<p>or</p>
<p><strong>/decrypt</strong><em>&lt;AlgID&gt;</em><strong>/</strong>:<em>&lt;“Key String”&gt;</em></p>
<p>or</p>
<p><strong>/decrypt:</strong><em>&lt;AlgID&gt;</em><strong>/keyfile</strong>:<em>&lt;FileName&gt;</em></p></td>
<td align="left"><p>Specifies that the <strong>/encrypt</strong> option was used to create the migration store with the ScanState tool. To decrypt the migration store, you must also specify a <strong>/key</strong> or <strong>/keyfile</strong> option as follows:</p>
<ul>
<li><p><em>&lt;AlgID&gt;</em> specifies the cryptographic algorithm that was used to create the migration store on the ScanState command line. If no algorithm is specified, ScanState and UsmtUtils use the 3DES algorithm as a default.</p>
<p><em>&lt;AlgID&gt;</em> valid values include: AES_128, AES_192, AES_256, 3DES, or 3DES_112.</p></li>
<li><p><strong>/key</strong>: <em>&lt;KeyString&gt;</em> specifies the encryption key. If there is a space in <em>&lt;KeyString&gt;</em>, you must surround the argument with quotation marks.</p></li>
<li><p><strong>/keyfile</strong>:<em>&lt;FileName&gt;</em> specifies a text (.txt) file that contains the encryption key</p></li>
</ul>
<p>For more information about supported encryption algorithms, see <a href="usmt-migration-store-encryption.md" data-raw-source="[Migration Store Encryption](usmt-migration-store-encryption.md)">Migration Store Encryption</a>.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/o</strong></p></td>
<td align="left"><p>Overwrites existing output files.</p></td>
</tr>
</tbody>
</table>
Some examples of **/extract** commands:
- `usmtutils /extract D:\MyMigrationStore\USMT\store.mig C:\ExtractedStore`
- `usmtutils /extract D:\MyMigrationStore\USMT\store.mig /i:"*.txt, *.pdf" C:\ExtractedStore /decrypt /keyfile:D:\encryptionKey.txt`
- `usmtutils /extract D:\MyMigrationStore\USMT\store.mig /e:*.exe C:\ExtractedStore /decrypt:AES_128 /key:password /l:C:\usmtlog.txt`
- `usmtutils /extract D:\MyMigrationStore\USMT\store.mig /i:myProject.* /e:*.exe C:\ExtractedStore /o`
## Related topics
[User State Migration Tool (USMT) Command-line Syntax](usmt-command-line-syntax.md)
[Return Codes](usmt-return-codes.md)

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

@ -1,429 +1,431 @@
---
title: What does USMT migrate (Windows 10)
description: What does USMT migrate
ms.assetid: f613987d-0f17-43fe-9717-6465865ceda7
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.date: 09/12/2017
ms.topic: article
---
# What does USMT migrate?
## In this topic
- [Default migration scripts](#bkmk-defaultmigscripts)
- [User Data](#bkmk-3)
- [Operating-system components](#bkmk-4)
- [Supported applications](#bkmk-2)
- [What USMT does not migrate](#no)
## <a href="" id="bkmk-defaultmigscripts"></a>Default migration scripts
The User State Migration Tool (USMT) 10.0 is designed so that an IT engineer can precisely define migrations using the USMT .xml scripting language. USMT provides the following sample scripts:
- **MigApp.XML.** Rules to migrate application settings.
- **MigDocs.XML.** Rules that use the **MigXmlHelper.GenerateDocPatterns** helper function, which can be used to automatically find user documents on a computer without the need to author extensive custom migration .xml files.
- **MigUser.XML.** Rules to migrate user profiles and user data.
MigUser.xml gathers everything in a user’s profile and then does a file extension- based search of most of the system for other user data. If data doesn’t match either of these criteria, the data won’t be migrated. For the most part, this file describes a "core" migration.
The following data does not migrate with MigUser.xml:
- Files outside the user profile that don’t match one of the file extensions in MigUser.xml.
- Access control lists (ACLs) for folders outside the user profile.
## <a href="" id="bkmk-3"></a>User data
This section describes the user data that USMT migrates by default, using the MigUser.xml file. It also defines how to migrate ACLs.
- **Folders from each user profile.** When you specify the MigUser.xml file, USMT migrates everything in a user’s profiles including the following:
My Documents, My Video, My Music, My Pictures, desktop files, Start menu, Quick Launch settings, and Favorites.
>[!IMPORTANT]
>Starting in Windows 10, version 1607 the USMT does not migrate the Start menu layout. To migrate a user's Start menu, you must export and then import settings using the Windows PowerShell cmdlets **Export-StartLayout** and **Import-StartLayout**. For more information, see [USMT common issues](https://docs.microsoft.com/windows/deployment/usmt/usmt-common-issues#usmt-does-not-migrate-the-start-layout).
- **Folders from the All Users and Public profiles.** When you specify the MigUser.xml file, USMT also migrates the following from the **All Users** profile in Windows® XP, or the **Public** profile in Windows Vista, Windows 7, or Windows 8:
- Shared Documents
- Shared Video
- Shared Music
- Shared desktop files
- Shared Pictures
- Shared Start menu
- Shared Favorites
- **File types.** When you specify the MigUser.xml file, the ScanState tool searches the fixed drives, collects and then migrates files with any of the following file extensions:
**.accdb, .ch3, .csv, .dif, .doc\*, .dot\*, .dqy, .iqy, .mcw, .mdb\*, .mpp, .one\*, .oqy, .or6, .pot\*, .ppa, .pps\*, .ppt\*, .pre, .pst, .pub, .qdf, .qel, .qph, .qsd, .rqy, .rtf, .scd, .sh3, .slk, .txt, .vl\*, .vsd, .wk\*, .wpd, .wps, .wq1, .wri, .xl\*, .xla, .xlb, .xls\*.**
**Note**  
The asterisk (\*) stands for zero or more characters.
- **Access control lists.** USMT migrates ACLs for specified files and folders from computers running both Windows® XP and Windows Vista. For example, if you migrate a file named File1.txt that is read-only for User1 and read/write for User2, these settings will still apply on the destination computer after the migration.
**Important**  
To migrate ACLs, you must specify the directory to migrate in the MigUser.xml file. Using file patterns like \*.doc will not migrate a directory. The source ACL information is migrated only when you explicitly specify the directory. For example, `<pattern type="File">c:\test docs</pattern>`.
## <a href="" id="bkmk-4"></a>Operating-system components
USMT migrates operating-system components to a destination computer from computers running Windows 7 and Windows 8
The following components are migrated by default using the manifest files:
- Accessibility settings
- Address book
- Command-prompt settings
- \*Desktop wallpaper
- EFS files
- Favorites
- Folder options
- Fonts
- Group membership. USMT migrates users’ group settings. The groups to which a user belongs can be found by right-clicking **My Computer** on the Start menu and then clicking **Manage**. When running an offline migration, the use of a **&lt;ProfileControl&gt;** section in the Config.xml file is required.
- \*Windows Internet Explorer® settings
- Microsoft® Open Database Connectivity (ODBC) settings
- Mouse and keyboard settings
- Network drive mapping
- \*Network printer mapping
- \*Offline files
- \*Phone and modem options
- RAS connection and phone book (.pbk) files
- \*Regional settings
- Remote Access
- \*Taskbar settings
- User personal certificates (all)
- Windows Mail.
- \*Windows Media Player
- Windows Rights Management
\* These settings are not available for an offline migration. For more information, see [Offline Migration Reference](offline-migration-reference.md).
**Important**  
This list may not be complete. There may be additional components that are migrated.
**Note**  
Some settings, such as fonts, are not applied by the LoadState tool until after the destination computer has been restarted. For this reason, restart the destination computer after you run the LoadState tool.
## <a href="" id="bkmk-2"></a>Supported applications
Although it is not required for all applications, it is good practice to install all applications on the destination computer before restoring the user state. Installing applications before migrating settings helps to ensure that the migrated settings are not overwritten by the application installers.
**Note**  
The versions of installed applications must match on the source and destination computers. USMT does not support migrating the settings of an earlier version of an application to a later version, except for Microsoft Office.
**Note**  
USMT migrates only the settings that have been used or modified by the user. If there is an application setting on the source computer that was not touched by the user, the setting may not migrate.
When you specify the MigApp.xml file, USMT migrates the settings for the following applications:
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Product</th>
<th align="left">Version</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Adobe Acrobat Reader</p></td>
<td align="left"><p>9</p></td>
</tr>
<tr class="even">
<td align="left"><p>AOL Instant Messenger</p></td>
<td align="left"><p>6.8</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Adobe Creative Suite</p></td>
<td align="left"><p>2</p></td>
</tr>
<tr class="even">
<td align="left"><p>Adobe Photoshop CS</p></td>
<td align="left"><p>8, 9</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Adobe ImageReady CS</p></td>
<td align="left"><p></p></td>
</tr>
<tr class="even">
<td align="left"><p>Apple iTunes</p></td>
<td align="left"><p>6, 7, 8</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Apple QuickTime Player</p></td>
<td align="left"><p>5, 6, 7</p></td>
</tr>
<tr class="even">
<td align="left"><p>Apple Safari</p></td>
<td align="left"><p>3.1.2</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Google Chrome</p></td>
<td align="left"><p>beta</p></td>
</tr>
<tr class="even">
<td align="left"><p>Google Picasa</p></td>
<td align="left"><p>3</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Google Talk</p></td>
<td align="left"><p>beta</p></td>
</tr>
<tr class="even">
<td align="left"><p>IBM Lotus 1-2-3</p></td>
<td align="left"><p>9</p></td>
</tr>
<tr class="odd">
<td align="left"><p>IBM Lotus Notes</p></td>
<td align="left"><p>6,7, 8</p></td>
</tr>
<tr class="even">
<td align="left"><p>IBM Lotus Organizer</p></td>
<td align="left"><p>5</p></td>
</tr>
<tr class="odd">
<td align="left"><p>IBM Lotus WordPro</p></td>
<td align="left"><p>9.9</p></td>
</tr>
<tr class="even">
<td align="left"><p>Intuit Quicken Deluxe</p></td>
<td align="left"><p>2009</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Money Plus Business</p></td>
<td align="left"><p>2008</p></td>
</tr>
<tr class="even">
<td align="left"><p>Money Plus Home</p></td>
<td align="left"><p>2008</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Mozilla Firefox</p></td>
<td align="left"><p>3</p></td>
</tr>
<tr class="even">
<td align="left"><p>Microsoft Office</p></td>
<td align="left"><p>2003, 2007, 2010</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Microsoft Office Access®</p></td>
<td align="left"><p>2003, 2007, 2010</p></td>
</tr>
<tr class="even">
<td align="left"><p>Microsoft Office Excel®</p></td>
<td align="left"><p>2003, 2007, 2010</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Microsoft Office FrontPage®</p></td>
<td align="left"><p>2003, 2007, 2010</p></td>
</tr>
<tr class="even">
<td align="left"><p>Microsoft Office OneNote®</p></td>
<td align="left"><p>2003, 2007, 2010</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Microsoft Office Outlook®</p></td>
<td align="left"><p>2003, 2007, 2010</p></td>
</tr>
<tr class="even">
<td align="left"><p>Microsoft Office PowerPoint®</p></td>
<td align="left"><p>2003, 2007, 2010</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Microsoft Office Publisher</p></td>
<td align="left"><p>2003, 2007, 2010</p></td>
</tr>
<tr class="even">
<td align="left"><p>Microsoft Office Word</p></td>
<td align="left"><p>2003, 2007, 2010</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Opera Software Opera</p></td>
<td align="left"><p>9.5</p></td>
</tr>
<tr class="even">
<td align="left"><p>Microsoft Outlook Express</p></td>
<td align="left"><p>(only mailbox file)</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Microsoft Project</p></td>
<td align="left"><p>2003, 2007</p></td>
</tr>
<tr class="even">
<td align="left"><p>Microsoft Office Visio®</p></td>
<td align="left"><p>2003, 2007</p></td>
</tr>
<tr class="odd">
<td align="left"><p>RealPlayer Basic</p></td>
<td align="left"><p>11</p></td>
</tr>
<tr class="even">
<td align="left"><p>Sage Peachtree</p></td>
<td align="left"><p>2009</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Skype</p></td>
<td align="left"><p>3.8</p></td>
</tr>
<tr class="even">
<td align="left"><p>Windows Live Mail</p></td>
<td align="left"><p>12, 14</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Windows Live Messenger</p></td>
<td align="left"><p>8.5, 14</p></td>
</tr>
<tr class="even">
<td align="left"><p>Windows Live MovieMaker</p></td>
<td align="left"><p>14</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Windows Live Photo Gallery</p></td>
<td align="left"><p>12, 14</p></td>
</tr>
<tr class="even">
<td align="left"><p>Windows Live Writer</p></td>
<td align="left"><p>12, 14</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Windows Mail</p></td>
<td align="left"><p>(Windows 7 and 8)</p></td>
</tr>
<tr class="even">
<td align="left"><p>Microsoft Works</p></td>
<td align="left"><p>9</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Yahoo Messenger</p></td>
<td align="left"><p>9</p></td>
</tr>
<tr class="even">
<td align="left"><p>Microsoft Zune™ Software</p></td>
<td align="left"><p>3</p></td>
</tr>
</tbody>
</table>
## <a href="" id="no"></a>What USMT does not migrate
The following is a list of the settings that USMT does not migrate. If you are having a problem that is not listed here, see [Common Issues](usmt-common-issues.md).
### Application settings
USMT does not migrate the following application settings:
- Settings from earlier versions of an application. The versions of each application must match on the source and destination computers. USMT does not support migrating the settings of an earlier version of an application to a later version, except for Microsoft Office. USMT can migrate from an earlier version of Microsoft Office to a later version.
- Application settings and some operating-system settings when a local account is created. For example, if you run /lac to create a local account on the destination computer, USMT will migrate the user data, but only some of the operating-system settings, such as wallpaper and screensaver settings, and no application settings will migrate.
- Microsoft Project settings, when migrating from Office 2003 to Office 2007 system.
- ICQ Pro settings, if ICQ Pro is installed in a different location on the destination computer. To successfully migrate the settings of ICQ Pro, you must install ICQ Pro in the same location on the destination computer as it was on the source computer. Otherwise, after you run the LoadState tool, the application will not start. You may encounter problems when:
- You change the default installation location on 32-bit destination computers.
- You attempt to migrate from a 32-bit computer to a 64-bit computer. This is because the ICQ Pro default installation directory is different on the two types of computers. When you install ICQ Pro on a 32-bit computer, the default location is "C:\\Program Files\\...". The ICQ Pro default installation directory on an x64-based computer, however, is “C:\\Program Files (x86)\\...”.
### Operating-System settings
USMT does not migrate the following operating-system settings.
- Local printers, hardware-related settings, drivers, passwords, application binary files, synchronization files, DLL files, or other executable files.
- Permissions for shared folders. After migration, you must manually re-share any folders that were shared on the source computer.
- Files and settings migrating between operating systems with different languages. The operating system of the source computer must match the language of the operating system on the destination computer.
- Customized icons for shortcuts may not migrate.
- Taskbar settings, when the source computer is running Windows XP.
You should also note the following:
- You should run USMT from an account with administrative credentials. Otherwise, some data will not migrate. When running the ScanState and LoadState tools you must run the tools in Administrator mode from an account with administrative credentials. If you do not run USMT in Administrator mode, only the user profile that is logged on will be included in the migration. In addition, you must run the ScanState tool on Windows XP from an account with administrative credentials. Otherwise, some operating-system settings will not migrate. To run in Administrator mode, click **Start**, click **All Programs**, click **Accessories**, right-click **Command Prompt**, and then click **Run as administrator**.
- You can use the /**localonly** option to exclude the data from removable drives and network drives mapped on the source computer. For more information about what is excluded when you specify /**localonly**, see [ScanState Syntax](usmt-scanstate-syntax.md).
### Start menu layout
Starting in Windows 10, version 1607 the USMT does not migrate the Start menu layout. To migrate a user's Start menu, you must export and then import settings using the Windows PowerShell cmdlets **Export-StartLayout** and **Import-StartLayout**. For more information, see [USMT common issues](https://docs.microsoft.com/windows/deployment/usmt/usmt-common-issues#usmt-does-not-migrate-the-start-layout).
## Related topics
[Plan your migration](usmt-plan-your-migration.md)
---
title: What does USMT migrate (Windows 10)
description: In this article, you will learn about what kind of data, components, applications and settings are migrated by the User State Migration Tool (USMT).
ms.custom: seo-marvel-apr2020
ms.assetid: f613987d-0f17-43fe-9717-6465865ceda7
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.date: 09/12/2017
ms.topic: article
---
# What does USMT migrate?
## In this topic
- [Default migration scripts](#bkmk-defaultmigscripts)
- [User Data](#bkmk-3)
- [Operating-system components](#bkmk-4)
- [Supported applications](#bkmk-2)
- [What USMT does not migrate](#no)
## <a href="" id="bkmk-defaultmigscripts"></a>Default migration scripts
The User State Migration Tool (USMT) 10.0 is designed so that an IT engineer can precisely define migrations using the USMT .xml scripting language. USMT provides the following sample scripts:
- **MigApp.XML.** Rules to migrate application settings.
- **MigDocs.XML.** Rules that use the **MigXmlHelper.GenerateDocPatterns** helper function, which can be used to automatically find user documents on a computer without the need to author extensive custom migration .xml files.
- **MigUser.XML.** Rules to migrate user profiles and user data.
MigUser.xml gathers everything in a user’s profile and then does a file extension- based search of most of the system for other user data. If data doesn’t match either of these criteria, the data won’t be migrated. For the most part, this file describes a "core" migration.
The following data does not migrate with MigUser.xml:
- Files outside the user profile that don’t match one of the file extensions in MigUser.xml.
- Access control lists (ACLs) for folders outside the user profile.
## <a href="" id="bkmk-3"></a>User data
This section describes the user data that USMT migrates by default, using the MigUser.xml file. It also defines how to migrate ACLs.
- **Folders from each user profile.** When you specify the MigUser.xml file, USMT migrates everything in a user’s profiles including the following:
My Documents, My Video, My Music, My Pictures, desktop files, Start menu, Quick Launch settings, and Favorites.
>[!IMPORTANT]
>Starting in Windows 10, version 1607 the USMT does not migrate the Start menu layout. To migrate a user's Start menu, you must export and then import settings using the Windows PowerShell cmdlets **Export-StartLayout** and **Import-StartLayout**. For more information, see [USMT common issues](https://docs.microsoft.com/windows/deployment/usmt/usmt-common-issues#usmt-does-not-migrate-the-start-layout).
- **Folders from the All Users and Public profiles.** When you specify the MigUser.xml file, USMT also migrates the following from the **All Users** profile in Windows® XP, or the **Public** profile in Windows Vista, Windows 7, or Windows 8:
- Shared Documents
- Shared Video
- Shared Music
- Shared desktop files
- Shared Pictures
- Shared Start menu
- Shared Favorites
- **File types.** When you specify the MigUser.xml file, the ScanState tool searches the fixed drives, collects and then migrates files with any of the following file extensions:
**.accdb, .ch3, .csv, .dif, .doc\*, .dot\*, .dqy, .iqy, .mcw, .mdb\*, .mpp, .one\*, .oqy, .or6, .pot\*, .ppa, .pps\*, .ppt\*, .pre, .pst, .pub, .qdf, .qel, .qph, .qsd, .rqy, .rtf, .scd, .sh3, .slk, .txt, .vl\*, .vsd, .wk\*, .wpd, .wps, .wq1, .wri, .xl\*, .xla, .xlb, .xls\*.**
**Note**  
The asterisk (\*) stands for zero or more characters.
- **Access control lists.** USMT migrates ACLs for specified files and folders from computers running both Windows® XP and Windows Vista. For example, if you migrate a file named File1.txt that is read-only for User1 and read/write for User2, these settings will still apply on the destination computer after the migration.
**Important**  
To migrate ACLs, you must specify the directory to migrate in the MigUser.xml file. Using file patterns like \*.doc will not migrate a directory. The source ACL information is migrated only when you explicitly specify the directory. For example, `<pattern type="File">c:\test docs</pattern>`.
## <a href="" id="bkmk-4"></a>Operating-system components
USMT migrates operating-system components to a destination computer from computers running Windows 7 and Windows 8
The following components are migrated by default using the manifest files:
- Accessibility settings
- Address book
- Command-prompt settings
- \*Desktop wallpaper
- EFS files
- Favorites
- Folder options
- Fonts
- Group membership. USMT migrates users’ group settings. The groups to which a user belongs can be found by right-clicking **My Computer** on the Start menu and then clicking **Manage**. When running an offline migration, the use of a **&lt;ProfileControl&gt;** section in the Config.xml file is required.
- \*Windows Internet Explorer® settings
- Microsoft® Open Database Connectivity (ODBC) settings
- Mouse and keyboard settings
- Network drive mapping
- \*Network printer mapping
- \*Offline files
- \*Phone and modem options
- RAS connection and phone book (.pbk) files
- \*Regional settings
- Remote Access
- \*Taskbar settings
- User personal certificates (all)
- Windows Mail.
- \*Windows Media Player
- Windows Rights Management
\* These settings are not available for an offline migration. For more information, see [Offline Migration Reference](offline-migration-reference.md).
**Important**  
This list may not be complete. There may be additional components that are migrated.
**Note**  
Some settings, such as fonts, are not applied by the LoadState tool until after the destination computer has been restarted. For this reason, restart the destination computer after you run the LoadState tool.
## <a href="" id="bkmk-2"></a>Supported applications
Although it is not required for all applications, it is good practice to install all applications on the destination computer before restoring the user state. Installing applications before migrating settings helps to ensure that the migrated settings are not overwritten by the application installers.
**Note**  
The versions of installed applications must match on the source and destination computers. USMT does not support migrating the settings of an earlier version of an application to a later version, except for Microsoft Office.
**Note**  
USMT migrates only the settings that have been used or modified by the user. If there is an application setting on the source computer that was not touched by the user, the setting may not migrate.
When you specify the MigApp.xml file, USMT migrates the settings for the following applications:
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Product</th>
<th align="left">Version</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Adobe Acrobat Reader</p></td>
<td align="left"><p>9</p></td>
</tr>
<tr class="even">
<td align="left"><p>AOL Instant Messenger</p></td>
<td align="left"><p>6.8</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Adobe Creative Suite</p></td>
<td align="left"><p>2</p></td>
</tr>
<tr class="even">
<td align="left"><p>Adobe Photoshop CS</p></td>
<td align="left"><p>8, 9</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Adobe ImageReady CS</p></td>
<td align="left"><p></p></td>
</tr>
<tr class="even">
<td align="left"><p>Apple iTunes</p></td>
<td align="left"><p>6, 7, 8</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Apple QuickTime Player</p></td>
<td align="left"><p>5, 6, 7</p></td>
</tr>
<tr class="even">
<td align="left"><p>Apple Safari</p></td>
<td align="left"><p>3.1.2</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Google Chrome</p></td>
<td align="left"><p>beta</p></td>
</tr>
<tr class="even">
<td align="left"><p>Google Picasa</p></td>
<td align="left"><p>3</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Google Talk</p></td>
<td align="left"><p>beta</p></td>
</tr>
<tr class="even">
<td align="left"><p>IBM Lotus 1-2-3</p></td>
<td align="left"><p>9</p></td>
</tr>
<tr class="odd">
<td align="left"><p>IBM Lotus Notes</p></td>
<td align="left"><p>6,7, 8</p></td>
</tr>
<tr class="even">
<td align="left"><p>IBM Lotus Organizer</p></td>
<td align="left"><p>5</p></td>
</tr>
<tr class="odd">
<td align="left"><p>IBM Lotus WordPro</p></td>
<td align="left"><p>9.9</p></td>
</tr>
<tr class="even">
<td align="left"><p>Intuit Quicken Deluxe</p></td>
<td align="left"><p>2009</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Money Plus Business</p></td>
<td align="left"><p>2008</p></td>
</tr>
<tr class="even">
<td align="left"><p>Money Plus Home</p></td>
<td align="left"><p>2008</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Mozilla Firefox</p></td>
<td align="left"><p>3</p></td>
</tr>
<tr class="even">
<td align="left"><p>Microsoft Office</p></td>
<td align="left"><p>2003, 2007, 2010</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Microsoft Office Access®</p></td>
<td align="left"><p>2003, 2007, 2010</p></td>
</tr>
<tr class="even">
<td align="left"><p>Microsoft Office Excel®</p></td>
<td align="left"><p>2003, 2007, 2010</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Microsoft Office FrontPage®</p></td>
<td align="left"><p>2003, 2007, 2010</p></td>
</tr>
<tr class="even">
<td align="left"><p>Microsoft Office OneNote®</p></td>
<td align="left"><p>2003, 2007, 2010</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Microsoft Office Outlook®</p></td>
<td align="left"><p>2003, 2007, 2010</p></td>
</tr>
<tr class="even">
<td align="left"><p>Microsoft Office PowerPoint®</p></td>
<td align="left"><p>2003, 2007, 2010</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Microsoft Office Publisher</p></td>
<td align="left"><p>2003, 2007, 2010</p></td>
</tr>
<tr class="even">
<td align="left"><p>Microsoft Office Word</p></td>
<td align="left"><p>2003, 2007, 2010</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Opera Software Opera</p></td>
<td align="left"><p>9.5</p></td>
</tr>
<tr class="even">
<td align="left"><p>Microsoft Outlook Express</p></td>
<td align="left"><p>(only mailbox file)</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Microsoft Project</p></td>
<td align="left"><p>2003, 2007</p></td>
</tr>
<tr class="even">
<td align="left"><p>Microsoft Office Visio®</p></td>
<td align="left"><p>2003, 2007</p></td>
</tr>
<tr class="odd">
<td align="left"><p>RealPlayer Basic</p></td>
<td align="left"><p>11</p></td>
</tr>
<tr class="even">
<td align="left"><p>Sage Peachtree</p></td>
<td align="left"><p>2009</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Skype</p></td>
<td align="left"><p>3.8</p></td>
</tr>
<tr class="even">
<td align="left"><p>Windows Live Mail</p></td>
<td align="left"><p>12, 14</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Windows Live Messenger</p></td>
<td align="left"><p>8.5, 14</p></td>
</tr>
<tr class="even">
<td align="left"><p>Windows Live MovieMaker</p></td>
<td align="left"><p>14</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Windows Live Photo Gallery</p></td>
<td align="left"><p>12, 14</p></td>
</tr>
<tr class="even">
<td align="left"><p>Windows Live Writer</p></td>
<td align="left"><p>12, 14</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Windows Mail</p></td>
<td align="left"><p>(Windows 7 and 8)</p></td>
</tr>
<tr class="even">
<td align="left"><p>Microsoft Works</p></td>
<td align="left"><p>9</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Yahoo Messenger</p></td>
<td align="left"><p>9</p></td>
</tr>
<tr class="even">
<td align="left"><p>Microsoft Zune™ Software</p></td>
<td align="left"><p>3</p></td>
</tr>
</tbody>
</table>
## <a href="" id="no"></a>What USMT does not migrate
The following is a list of the settings that USMT does not migrate. If you are having a problem that is not listed here, see [Common Issues](usmt-common-issues.md).
### Application settings
USMT does not migrate the following application settings:
- Settings from earlier versions of an application. The versions of each application must match on the source and destination computers. USMT does not support migrating the settings of an earlier version of an application to a later version, except for Microsoft Office. USMT can migrate from an earlier version of Microsoft Office to a later version.
- Application settings and some operating-system settings when a local account is created. For example, if you run /lac to create a local account on the destination computer, USMT will migrate the user data, but only some of the operating-system settings, such as wallpaper and screensaver settings, and no application settings will migrate.
- Microsoft Project settings, when migrating from Office 2003 to Office 2007 system.
- ICQ Pro settings, if ICQ Pro is installed in a different location on the destination computer. To successfully migrate the settings of ICQ Pro, you must install ICQ Pro in the same location on the destination computer as it was on the source computer. Otherwise, after you run the LoadState tool, the application will not start. You may encounter problems when:
- You change the default installation location on 32-bit destination computers.
- You attempt to migrate from a 32-bit computer to a 64-bit computer. This is because the ICQ Pro default installation directory is different on the two types of computers. When you install ICQ Pro on a 32-bit computer, the default location is "C:\\Program Files\\...". The ICQ Pro default installation directory on an x64-based computer, however, is “C:\\Program Files (x86)\\...”.
### Operating-System settings
USMT does not migrate the following operating-system settings.
- Local printers, hardware-related settings, drivers, passwords, application binary files, synchronization files, DLL files, or other executable files.
- Permissions for shared folders. After migration, you must manually re-share any folders that were shared on the source computer.
- Files and settings migrating between operating systems with different languages. The operating system of the source computer must match the language of the operating system on the destination computer.
- Customized icons for shortcuts may not migrate.
- Taskbar settings, when the source computer is running Windows XP.
You should also note the following:
- You should run USMT from an account with administrative credentials. Otherwise, some data will not migrate. When running the ScanState and LoadState tools you must run the tools in Administrator mode from an account with administrative credentials. If you do not run USMT in Administrator mode, only the user profile that is logged on will be included in the migration. In addition, you must run the ScanState tool on Windows XP from an account with administrative credentials. Otherwise, some operating-system settings will not migrate. To run in Administrator mode, click **Start**, click **All Programs**, click **Accessories**, right-click **Command Prompt**, and then click **Run as administrator**.
- You can use the /**localonly** option to exclude the data from removable drives and network drives mapped on the source computer. For more information about what is excluded when you specify /**localonly**, see [ScanState Syntax](usmt-scanstate-syntax.md).
### Start menu layout
Starting in Windows 10, version 1607 the USMT does not migrate the Start menu layout. To migrate a user's Start menu, you must export and then import settings using the Windows PowerShell cmdlets **Export-StartLayout** and **Import-StartLayout**. For more information, see [USMT common issues](https://docs.microsoft.com/windows/deployment/usmt/usmt-common-issues#usmt-does-not-migrate-the-start-layout).
## Related topics
[Plan your migration](usmt-plan-your-migration.md)

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

@ -1,6 +1,7 @@
---
title: XML Elements Library (Windows 10)
description: XML Elements Library
description: Learn about the XML elements and helper functions that you can employ to author migration .xml files to use with User State Migration Tool (USMT).
ms.custom: seo-marvel-apr2020
ms.assetid: f5af0f6d-c3bf-4a4c-a0ca-9db7985f954f
ms.reviewer:
manager: laurawi

158
windows/deployment/usmt/usmt-xml-reference.md
View File

@ -1,78 +1,80 @@
---
title: USMT XML Reference (Windows 10)
description: USMT XML Reference
ms.assetid: fb946975-0fee-4ec0-b3ef-7c34945ee96f
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# USMT XML Reference
This section contains topics that you can use to work with and to customize the migration XML files.
## In This Section
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<tbody>
<tr class="odd">
<td align="left"><p><a href="understanding-migration-xml-files.md" data-raw-source="[Understanding Migration XML Files](understanding-migration-xml-files.md)">Understanding Migration XML Files</a></p></td>
<td align="left"><p>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.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-configxml-file.md" data-raw-source="[Config.xml File](usmt-configxml-file.md)">Config.xml File</a></p></td>
<td align="left"><p>Describes the Config.xml file and policies concerning its configuration.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="usmt-customize-xml-files.md" data-raw-source="[Customize USMT XML Files](usmt-customize-xml-files.md)">Customize USMT XML Files</a></p></td>
<td align="left"><p>Describes how to customize USMT XML files.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-custom-xml-examples.md" data-raw-source="[Custom XML Examples](usmt-custom-xml-examples.md)">Custom XML Examples</a></p></td>
<td align="left"><p>Gives examples of XML files for various migration scenarios.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="usmt-conflicts-and-precedence.md" data-raw-source="[Conflicts and Precedence](usmt-conflicts-and-precedence.md)">Conflicts and Precedence</a></p></td>
<td align="left"><p>Describes the precedence of migration rules and how conflicts are handled.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-general-conventions.md" data-raw-source="[General Conventions](usmt-general-conventions.md)">General Conventions</a></p></td>
<td align="left"><p>Describes the XML helper functions.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="xml-file-requirements.md" data-raw-source="[XML File Requirements](xml-file-requirements.md)">XML File Requirements</a></p></td>
<td align="left"><p>Describes the requirements for custom XML files.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-recognized-environment-variables.md" data-raw-source="[Recognized Environment Variables](usmt-recognized-environment-variables.md)">Recognized Environment Variables</a></p></td>
<td align="left"><p>Describes environment variables recognized by USMT.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="usmt-xml-elements-library.md" data-raw-source="[XML Elements Library](usmt-xml-elements-library.md)">XML Elements Library</a></p></td>
<td align="left"><p>Describes the XML elements and helper functions for authoring migration XML files to use with USMT.</p></td>
</tr>
</tbody>
</table>
---
title: USMT XML Reference (Windows 10)
description: This article contains a list of topics that you can use to work with and to customize the migration XML files.
ms.custom: seo-marvel-apr2020
ms.assetid: fb946975-0fee-4ec0-b3ef-7c34945ee96f
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# USMT XML Reference
This section contains topics that you can use to work with and to customize the migration XML files.
## In This Section
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<tbody>
<tr class="odd">
<td align="left"><p><a href="understanding-migration-xml-files.md" data-raw-source="[Understanding Migration XML Files](understanding-migration-xml-files.md)">Understanding Migration XML Files</a></p></td>
<td align="left"><p>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.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-configxml-file.md" data-raw-source="[Config.xml File](usmt-configxml-file.md)">Config.xml File</a></p></td>
<td align="left"><p>Describes the Config.xml file and policies concerning its configuration.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="usmt-customize-xml-files.md" data-raw-source="[Customize USMT XML Files](usmt-customize-xml-files.md)">Customize USMT XML Files</a></p></td>
<td align="left"><p>Describes how to customize USMT XML files.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-custom-xml-examples.md" data-raw-source="[Custom XML Examples](usmt-custom-xml-examples.md)">Custom XML Examples</a></p></td>
<td align="left"><p>Gives examples of XML files for various migration scenarios.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="usmt-conflicts-and-precedence.md" data-raw-source="[Conflicts and Precedence](usmt-conflicts-and-precedence.md)">Conflicts and Precedence</a></p></td>
<td align="left"><p>Describes the precedence of migration rules and how conflicts are handled.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-general-conventions.md" data-raw-source="[General Conventions](usmt-general-conventions.md)">General Conventions</a></p></td>
<td align="left"><p>Describes the XML helper functions.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="xml-file-requirements.md" data-raw-source="[XML File Requirements](xml-file-requirements.md)">XML File Requirements</a></p></td>
<td align="left"><p>Describes the requirements for custom XML files.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-recognized-environment-variables.md" data-raw-source="[Recognized Environment Variables](usmt-recognized-environment-variables.md)">Recognized Environment Variables</a></p></td>
<td align="left"><p>Describes environment variables recognized by USMT.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="usmt-xml-elements-library.md" data-raw-source="[XML Elements Library](usmt-xml-elements-library.md)">XML Elements Library</a></p></td>
<td align="left"><p>Describes the XML elements and helper functions for authoring migration XML files to use with USMT.</p></td>
</tr>
</tbody>
</table>

259
windows/deployment/usmt/verify-the-condition-of-a-compressed-migration-store.md
View File

@ -1,128 +1,131 @@
---
title: Verify the Condition of a Compressed Migration Store (Windows 10)
description: Verify the Condition of a Compressed Migration Store
ms.assetid: 4a3fda96-5f7d-494a-955f-6b865ec9fcae
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# Verify the Condition of a Compressed Migration Store
When you migrate files and settings during a typical PC-refresh migration, the user state is usually stored in a compressed folder on the intermediate store. This compressed folder, also called the compressed migration store, is a single image file that contains:
- All of the files being migrated.
- The user’s settings.
- A catalog file that contains metadata for all files in the migration store.
When you run the **LoadState** command to load the data from these files to the destination computer, LoadState requires a valid catalog file in order to open the migration store. You can run the **UsmtUtils** command with the **/verify** option to determine whether the compressed migration store is intact, or whether it contains corrupted files or a corrupted catalog. You should run the **/verify** option on the migration store before you overwrite the original user-state files and settings.
When you use the **/verify** option, you can specify what type of information to report in the UsmtUtils log file. These report types are:
- **Catalog**: Displays the status of only the catalog file.
- **All**: Displays the status of all files, including the catalog file.
- **Failure only**: Displays only the files that are corrupted.
## In This Topic
The following sections demonstrate how to run the **UsmtUtils** command with the **/verify** option, and how to specify the information to display in the UsmtUtils log file.
- [The UsmtUtils syntax for the /verify option](#bkmk-verifysyntax)
- [To verify that the migration store is intact](#bkmk-verifyintactstore)
- [To verify the status of only the catalog file](#bkmk-verifycatalog)
- [To verify the status of all files](#bkmk-verifyallfiles)
- [To verify the status of the files and return only the corrupted files](#bkmk-returncorrupted)
### <a href="" id="bkmk-verifysyntax"></a>The UsmtUtils Syntax for the /verify Option
To verify the condition of a compressed migration store, use the following UsmtUtils syntax:
cd /d&lt;USMTpath&gt;usmtutils /verify\[:&lt;reportType&gt;\] &lt;filePath&gt; \[/l:&lt;logfile&gt;\] \[/decrypt \[:&lt;AlgID&gt;\] {/key:&lt;keystring&gt; | /keyfile:&lt;filename&gt;}\]
Where the placeholders have the following values:
- *&lt;USMTpath&gt;* is the location where you have saved the USMT files and tools.
- *&lt;reportType&gt;* specifies whether to report on all files, corrupted files only, or the status of the catalog.
- *&lt;filePath&gt;* is the location of the compressed migration store.
- *&lt;logfile&gt;* is the location and name of the log file.
- *&lt;AlgID&gt;* is the cryptographic algorithm that was used to create the migration store on the **ScanState** command line.
- *&lt;keystring&gt;* is the encryption key that was used to encrypt the migration store.
- *&lt;filename&gt;* is the location and name of the text file that contains the encryption key.
### <a href="" id="bkmk-verifyintactstore"></a>To Verify that the Migration Store is Intact
To verify whether the migration store is intact or whether it contains corrupted files or a corrupted catalog, type:
``` syntax
usmtutils /verify D:\MyMigrationStore\store.mig
```
Because no report type is specified, UsmtUtils displays the default summary report.
### <a href="" id="bkmk-verifycatalog"></a>To Verify the Status of Only the Catalog File
To verify whether the catalog file is corrupted or intact, type:
``` syntax
usmtutils /verify:catalog D:\MyMigrationStore\store.mig
```
### <a href="" id="bkmk-verifyallfiles"></a>To Verify the Status of all Files
To verify whether there are any corrupted files in the compressed migration store, and to specify the name and location of the log file, type:
`usmtutils /verify:all D:\MyMigrationStore\store.mig /decrypt /l:D:\UsmtUtilsLog.txt`
In addition to verifying the status of all files, this example decrypts the files. Because no encryption algorithm is specified, UsmtUtils uses the default 3DES cryptographic algorithm.
### <a href="" id="bkmk-returncorrupted"></a>To Verify the Status of the Files and Return Only the Corrupted Files
In this example, the log file will only list the files that became corrupted during the ScanState process. This list will include the catalog file if it is also corrupted.
``` syntax
usmtutils /verify:failureonly D:\MyMigrationStore\USMT\store.mig /decrypt:AES_192 /keyfile:D:\encryptionKey.txt
```
This example also decrypts the files by specifying the cryptographic algorithm and the location of the file that contains the encryption key.
### Next Steps
If the **/verify** option indicates that there are corrupted files in the migration store, you can use the **/extract** option in the UsmtUtils tool to recover data from some corrupted stores. For more information, see [Extract Files from a Compressed USMT Migration Store](usmt-extract-files-from-a-compressed-migration-store.md).
## Related topics
[UsmtUtils Syntax](usmt-utilities.md)
[Return Codes](usmt-return-codes.md)
 
 
---
title: Verify the Condition of a Compressed Migration Store (Windows 10)
description: In this article you will learn how to verify the Condition of a Compressed Migration Store by displaying information in the UsmtUtils log file.
ms.custom: seo-marvel-apr2020
ms.assetid: 4a3fda96-5f7d-494a-955f-6b865ec9fcae
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# Verify the Condition of a Compressed Migration Store
When you migrate files and settings during a typical PC-refresh migration, the user state is usually stored in a compressed folder on the intermediate store. This compressed folder, also called the compressed migration store, is a single image file that contains:
- All of the files being migrated.
- The user’s settings.
- A catalog file that contains metadata for all files in the migration store.
When you run the **LoadState** command to load the data from these files to the destination computer, LoadState requires a valid catalog file in order to open the migration store. You can run the **UsmtUtils** command with the **/verify** option to determine whether the compressed migration store is intact, or whether it contains corrupted files or a corrupted catalog. You should run the **/verify** option on the migration store before you overwrite the original user-state files and settings.
When you use the **/verify** option, you can specify what type of information to report in the UsmtUtils log file. These report types are:
- **Catalog**: Displays the status of only the catalog file.
- **All**: Displays the status of all files, including the catalog file.
- **Failure only**: Displays only the files that are corrupted.
## In This Topic
The following sections demonstrate how to run the **UsmtUtils** command with the **/verify** option, and how to specify the information to display in the UsmtUtils log file.
- [The UsmtUtils syntax for the /verify option](#bkmk-verifysyntax)
- [To verify that the migration store is intact](#bkmk-verifyintactstore)
- [To verify the status of only the catalog file](#bkmk-verifycatalog)
- [To verify the status of all files](#bkmk-verifyallfiles)
- [To verify the status of the files and return only the corrupted files](#bkmk-returncorrupted)
### <a href="" id="bkmk-verifysyntax"></a>The UsmtUtils Syntax for the /verify Option
To verify the condition of a compressed migration store, use the following UsmtUtils syntax:
cd /d&lt;USMTpath&gt;usmtutils /verify\[:&lt;reportType&gt;\] &lt;filePath&gt; \[/l:&lt;logfile&gt;\] \[/decrypt \[:&lt;AlgID&gt;\] {/key:&lt;keystring&gt; | /keyfile:&lt;filename&gt;}\]
Where the placeholders have the following values:
- *&lt;USMTpath&gt;* is the location where you have saved the USMT files and tools.
- *&lt;reportType&gt;* specifies whether to report on all files, corrupted files only, or the status of the catalog.
- *&lt;filePath&gt;* is the location of the compressed migration store.
- *&lt;logfile&gt;* is the location and name of the log file.
- *&lt;AlgID&gt;* is the cryptographic algorithm that was used to create the migration store on the **ScanState** command line.
- *&lt;keystring&gt;* is the encryption key that was used to encrypt the migration store.
- *&lt;filename&gt;* is the location and name of the text file that contains the encryption key.
### <a href="" id="bkmk-verifyintactstore"></a>To Verify that the Migration Store is Intact
To verify whether the migration store is intact or whether it contains corrupted files or a corrupted catalog, type:
``` syntax
usmtutils /verify D:\MyMigrationStore\store.mig
```
Because no report type is specified, UsmtUtils displays the default summary report.
### <a href="" id="bkmk-verifycatalog"></a>To Verify the Status of Only the Catalog File
To verify whether the catalog file is corrupted or intact, type:
``` syntax
usmtutils /verify:catalog D:\MyMigrationStore\store.mig
```
### <a href="" id="bkmk-verifyallfiles"></a>To Verify the Status of all Files
To verify whether there are any corrupted files in the compressed migration store, and to specify the name and location of the log file, type:
`usmtutils /verify:all D:\MyMigrationStore\store.mig /decrypt /l:D:\UsmtUtilsLog.txt`
In addition to verifying the status of all files, this example decrypts the files. Because no encryption algorithm is specified, UsmtUtils uses the default 3DES cryptographic algorithm.
### <a href="" id="bkmk-returncorrupted"></a>To Verify the Status of the Files and Return Only the Corrupted Files
In this example, the log file will only list the files that became corrupted during the ScanState process. This list will include the catalog file if it is also corrupted.
``` syntax
usmtutils /verify:failureonly D:\MyMigrationStore\USMT\store.mig /decrypt:AES_192 /keyfile:D:\encryptionKey.txt
```
This example also decrypts the files by specifying the cryptographic algorithm and the location of the file that contains the encryption key.
### Next Steps
If the **/verify** option indicates that there are corrupted files in the migration store, you can use the **/extract** option in the UsmtUtils tool to recover data from some corrupted stores. For more information, see [Extract Files from a Compressed USMT Migration Store](usmt-extract-files-from-a-compressed-migration-store.md).
## Related topics
[UsmtUtils Syntax](usmt-utilities.md)
[Return Codes](usmt-return-codes.md)