diff --git a/windows/deployment/update/update-compliance-monitor.md b/windows/deployment/update/update-compliance-monitor.md
index 6b1014bbe6..56ce0e97cc 100644
--- a/windows/deployment/update/update-compliance-monitor.md
+++ b/windows/deployment/update/update-compliance-monitor.md
@@ -25,8 +25,6 @@ ms.custom: seo-marvel-apr2020
> * The Perspectives feature of Update Compliance will also be removed on March 31, 2020 in favor of a better experience. The Perspectives feature is part of the Log Search portal of Log Analytics, which was deprecated on February 15, 2019 in favor of [Azure Monitor Logs](https://docs.microsoft.com/azure/azure-monitor/log-query/log-search-transition). Your Update Compliance solution will be automatically upgraded to Azure Monitor Logs, and the data available in Perspectives will be migrated to a set of queries in the [Needs Attention section](update-compliance-need-attention.md) of Update Compliance.
-## Introduction
-
Update Compliance enables organizations to:
* Monitor security, quality, and feature updates for Windows 10 Professional, Education, and Enterprise editions.
diff --git a/windows/deployment/upgrade/upgrade-windows-phone-8-1-to-10.md b/windows/deployment/upgrade/upgrade-windows-phone-8-1-to-10.md
index cf222b3355..88d908aaf4 100644
--- a/windows/deployment/upgrade/upgrade-windows-phone-8-1-to-10.md
+++ b/windows/deployment/upgrade/upgrade-windows-phone-8-1-to-10.md
@@ -22,8 +22,6 @@ ms.custom: seo-marvel-apr2020
- Windows 10 Mobile
-## Summary
-
This article describes how system administrators can upgrade eligible Windows Phone 8.1 devices to Windows 10 Mobile using [Mobile Device Management](https://docs.microsoft.com/windows/client-management/mdm/) (MDM).
>[!IMPORTANT]
diff --git a/windows/deployment/usmt/getting-started-with-the-user-state-migration-tool.md b/windows/deployment/usmt/getting-started-with-the-user-state-migration-tool.md
index 131b599b72..5bc165ab05 100644
--- a/windows/deployment/usmt/getting-started-with-the-user-state-migration-tool.md
+++ b/windows/deployment/usmt/getting-started-with-the-user-state-migration-tool.md
@@ -17,7 +17,7 @@ ms.topic: article
# Getting Started with the User State Migration Tool (USMT)
This topic outlines the general process that you should follow to migrate files and settings.
-## In this Topic
+## In this topic
- [Step 1: Plan Your Migration](#step-1-plan-your-migration)
- [Step 2: Collect files and settings from the source computer](#step-2-collect-files-and-settings-from-the-source-computer)
@@ -49,7 +49,7 @@ This topic outlines the general process that you should follow to migrate files
## Step 2: Collect files and settings from the source computer
1. Back up the source computer.
-2. Close all applications. If some applications are running when you run the **ScanState** command, USMT might not migrate all of the specified data. For example, if Microsoft® Office Outlook® is open, USMT might not migrate PST files.
+2. Close all applications. If some applications are running when you run the **ScanState** command, USMT might not migrate all of the specified data. For example, if Microsoft® Office 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 will ignore the errors, and log an error every time that it encounters a file that is being used that USMT did not migrate. You can use the **<ErrorControl>** section in the Config.xml file to specify which errors should be ignored, and which should cause the migration to fail.
@@ -69,7 +69,7 @@ This topic outlines the general process that you should follow to migrate files
2. Install all applications that were on the source computer. Although it is not always required, we recommend installing all applications on the destination computer before you restore the user state. This makes sure that migrated settings are preserved.
**Note**
- The application version that is installed on the destination computer should be the same version as the one on the source computer. USMT does not support migrating the settings for an older version of an application to a newer version. The exception to this is Microsoft® Office, which USMT can migrate from an older version to a newer version.
+ The application version that is installed on the destination computer should be the same version as the one on the source computer. USMT does not support migrating the settings for an older version of an application to a newer version. The exception to this is Microsoft® Office, which USMT can migrate from an older version to a newer version.
3. Close all applications. If some applications are running when you run the **LoadState** command, USMT might not migrate all of the specified data. For example, if Microsoft Office Outlook is open, USMT might not migrate PST files.
diff --git a/windows/deployment/usmt/migrate-application-settings.md b/windows/deployment/usmt/migrate-application-settings.md
index 24900c7784..6225836dae 100644
--- a/windows/deployment/usmt/migrate-application-settings.md
+++ b/windows/deployment/usmt/migrate-application-settings.md
@@ -24,7 +24,7 @@ This topic defines how to author a custom migration .xml file that migrates the
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.
-## In this Topic
+## In this topic
- [Before You Begin](#bkmk-beforebegin)
@@ -47,19 +47,19 @@ You should identify a test computer that contains the operating system of your s
## 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.
+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.
+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.
+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.
## Step 2: Identify settings to collect and determine where each setting is stored on the computer.
diff --git a/windows/deployment/usmt/migration-store-types-overview.md b/windows/deployment/usmt/migration-store-types-overview.md
index 443bfb87fd..abda074409 100644
--- a/windows/deployment/usmt/migration-store-types-overview.md
+++ b/windows/deployment/usmt/migration-store-types-overview.md
@@ -20,7 +20,7 @@ ms.topic: article
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
+## In This topic
[Migration Store Types](#bkmk-types)
@@ -44,7 +44,7 @@ The compressed migration store is a single image file that contains all files be
### 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.
+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).
diff --git a/windows/deployment/usmt/offline-migration-reference.md b/windows/deployment/usmt/offline-migration-reference.md
index 30242f8266..d8af170029 100644
--- a/windows/deployment/usmt/offline-migration-reference.md
+++ b/windows/deployment/usmt/offline-migration-reference.md
@@ -18,7 +18,7 @@ ms.topic: article
# Offline Migration Reference
-Offline migration enables the ScanState tool to run inside a different Windows® operating system than the Windows operating system from which ScanState is gathering files and settings. There are two primary offline scenarios:
+Offline migration enables the ScanState tool to run inside a different Windows® operating system than the Windows operating system from which ScanState is gathering files and settings. There are two primary offline scenarios:
- **Windows PE.** The ScanState tool can be run from within Windows PE, gathering files and settings from the offline Windows operating system on that machine.
@@ -32,7 +32,7 @@ When you use User State Migration Tool (USMT) 10.0 to gather and restore user s
- **New recovery scenario.** In scenarios where a machine no longer restarts properly, it might be possible to gather user state with the ScanState tool from within WinPE.
-## In This Topic
+## In This topic
- [What Will Migrate Offline?](#bkmk-whatwillmigrate)
@@ -62,7 +62,7 @@ The following user data and settings migrate offline, similar to an online migra
- EFS files
-- Internet Explorer® Favorites
+- Internet Explorer® Favorites
For exceptions to what you can migrate offline, see [What Does USMT Migrate?](usmt-what-does-usmt-migrate.md)
@@ -193,7 +193,7 @@ The following system environment variables are necessary in the scenarios outlin
MIG_OFFLINE_PLATFORM_ARCH |
32 or 64 |
-While operating offline, this environment variable defines the architecture of the offline system, if the system does not match the WinPE and Scanstate.exe architecture. This environment variable enables the 32-bit ScanState application to gather data from a computer with 64-bit architecture, or the 64-bit ScanState application to gather data from a computer with 32-bit architecture. This is required when auto-detection of the offline architecture doesn’t function properly, for example, when the source system is running a 64-bit version of Windows XP. For example, to set this system environment variable for a 32-bit architecture, at a command prompt type the following:
+ | While operating offline, this environment variable defines the architecture of the offline system, if the system does not match the WinPE and Scanstate.exe architecture. This environment variable enables the 32-bit ScanState application to gather data from a computer with 64-bit architecture, or the 64-bit ScanState application to gather data from a computer with 32-bit architecture. This is required when auto-detection of the offline architecture doesn't function properly, for example, when the source system is running a 64-bit version of Windows XP. For example, to set this system environment variable for a 32-bit architecture, at a command prompt type the following:
Set MIG_OFFLINE_PLATFORM_ARCH=32
|
@@ -220,7 +220,7 @@ Syntax: < winDir > </ winDir >
### <path>
-This element is a required child of **<winDir>** and contains a file path pointing to a valid Windows directory. Relative paths are interpreted from the ScanState tool’s working directory.
+This element is a required child of **<winDir>** and contains a file path pointing to a valid Windows directory. Relative paths are interpreted from the ScanState tool's working directory.
Syntax: <path> c:\\windows </path>
@@ -236,7 +236,7 @@ Syntax: <mappings> </mappings>
### <failOnMultipleWinDir>
-This element is an optional child of **<offline>**. The **<failOnMultipleWinDir>** element allows the user to specify that the migration should fail when USMT detects that there are multiple instances of Windows installed on the source machine. When the **<failOnMultipleWinDir>** element isn’t present, the default behavior is that the migration does not fail.
+This element is an optional child of **<offline>**. The **<failOnMultipleWinDir>** element allows the user to specify that the migration should fail when USMT detects that there are multiple instances of Windows installed on the source machine. When the **<failOnMultipleWinDir>** element isn't present, the default behavior is that the migration does not fail.
Syntax: <failOnMultipleWinDir>1</failOnMultipleWinDir> or Syntax: <failOnMultipleWinDir>0</failOnMultipleWinDir>
diff --git a/windows/deployment/usmt/understanding-migration-xml-files.md b/windows/deployment/usmt/understanding-migration-xml-files.md
index 268d8fa8f3..b0443df9cf 100644
--- a/windows/deployment/usmt/understanding-migration-xml-files.md
+++ b/windows/deployment/usmt/understanding-migration-xml-files.md
@@ -22,7 +22,7 @@ You can modify the behavior of a basic User State Migration Tool (USMT)10.0 migr
This topic provides an overview of the default and custom migration XML files and includes guidelines for creating and editing a customized version of the MigDocs.xml file. The MigDocs.xml file uses the new **GenerateDocPatterns** function available in USMT to automatically find user documents on a source computer.
-## In This Topic
+## In This topic
[Overview of the Config.xml file](#bkmk-config)
@@ -436,7 +436,7 @@ In the examples below, the source computer has a .txt file called "new text docu
-To exclude the new text document.txt file as well as any .txt files in “new folder”, you can do the following:
+To exclude the new text document.txt file as well as any .txt files in "new folder", you can do the following:
**Example 1: Exclude all .txt files in a folder**
diff --git a/windows/deployment/usmt/usmt-choose-migration-store-type.md b/windows/deployment/usmt/usmt-choose-migration-store-type.md
index a05fe14811..f292f6b380 100644
--- a/windows/deployment/usmt/usmt-choose-migration-store-type.md
+++ b/windows/deployment/usmt/usmt-choose-migration-store-type.md
@@ -20,7 +20,7 @@ ms.topic: article
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
+## In this section
diff --git a/windows/deployment/usmt/usmt-command-line-syntax.md b/windows/deployment/usmt/usmt-command-line-syntax.md
index bfc63bf785..844336d1cd 100644
--- a/windows/deployment/usmt/usmt-command-line-syntax.md
+++ b/windows/deployment/usmt/usmt-command-line-syntax.md
@@ -20,7 +20,7 @@ ms.topic: article
The User State Migration Tool (USMT) 10.0 migrates user files and settings during large deployments of Windows. To improve and simplify the migration process, USMT captures desktop, network, and application settings in addition to a user's files. USMT then migrates these items to a new Windows installation.
-## In This Section
+## In this section
diff --git a/windows/deployment/usmt/usmt-common-issues.md b/windows/deployment/usmt/usmt-common-issues.md
index aed839d9b2..99a442791a 100644
--- a/windows/deployment/usmt/usmt-common-issues.md
+++ b/windows/deployment/usmt/usmt-common-issues.md
@@ -20,7 +20,7 @@ ms.topic: article
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
+## In this topic
[User Account Problems](#user)
@@ -42,7 +42,7 @@ The following sections discuss common issues that you might see when you run the
When you encounter a problem or error message during migration, you can use the following general guidelines to help determine the source of the problem:
-- Examine the ScanState, LoadState, and UsmtUtils logs to obtain the exact USMT error messages and Windows® application programming interface (API) error messages. For more information about USMT return codes and error messages, see [Return Codes](usmt-return-codes.md). For more information about Windows API error messages, type **nethelpmsg** on the command line.
+- Examine the ScanState, LoadState, and UsmtUtils logs to obtain the exact USMT error messages and Windows® application programming interface (API) error messages. For more information about USMT return codes and error messages, see [Return Codes](usmt-return-codes.md). For more information about Windows API error messages, type **nethelpmsg** on the command line.
In most cases, the ScanState and LoadState logs indicate why a USMT migration is failing. We recommend that you use the **/v**:5 option when testing your migration. This verbosity level can be adjusted in a production migration; however, reducing the verbosity level might make it more difficult to diagnose failures that are encountered during production migrations. You can use a verbosity level higher than 5 if you want the log files output to go to a debugger.
@@ -61,7 +61,7 @@ When you encounter a problem or error message during migration, you can use the
- 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.
+- 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.
@@ -176,9 +176,9 @@ The following sections describe common XML file problems. Expand the section to
**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.
-### 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?
+### 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.
+**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.
@@ -217,7 +217,7 @@ There are three typical causes for this issue.
**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.
+**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.
@@ -225,7 +225,7 @@ There are three typical causes for this issue.
**Resolution:** Run the ScanState and LoadState tools from within an account with administrative credentials.
-### I included MigApp.xml in the migration, but some PST files aren’t migrating.
+### 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.
diff --git a/windows/deployment/usmt/usmt-common-migration-scenarios.md b/windows/deployment/usmt/usmt-common-migration-scenarios.md
index 87937cf026..296e8476f9 100644
--- a/windows/deployment/usmt/usmt-common-migration-scenarios.md
+++ b/windows/deployment/usmt/usmt-common-migration-scenarios.md
@@ -22,7 +22,7 @@ You use the User State Migration Tool (USMT) 10.0 when hardware and/or operatin
One common scenario when only the operating system, and not the hardware, is being upgraded is referred to as *PC refresh*. A second common scenario is known as *PC replacement*, where one piece of hardware is being replaced, typically by newer hardware and a newer operating system.
-## In This Topic
+## In this topic
[PC Refresh](#bkmk-pcrefresh)
@@ -60,7 +60,7 @@ A company has just received funds to update the operating system on all of its c
1. On each computer, the administrator boots the machine into WinPE and runs the ScanState command-line tool, specifying the **/hardlink /nocompress** command-line options. ScanState saves the user state to a hard-link migration store on each computer, improving performance by minimizing network traffic as well as minimizing migration failures on computers with very limited space available on the hard drive.
-2. On each computer, the administrator installs the company’s standard operating environment (SOE) which includes Windows 10 and other company applications.
+2. On each computer, the administrator installs the company's standard operating environment (SOE) which includes Windows 10 and other company applications.
3. The administrator runs the LoadState command-line tool on each computer. LoadState restores each user state back to each computer.
@@ -90,7 +90,7 @@ A company has decided to update the operating system on all of its computers to
1. The administrator clean installs Windows 10 on each computer, making sure that the Windows.old directory is created by installing Windows 10 without formatting or repartitioning and by selecting a partition that contains the previous version of Windows.
-2. On each computer, the administrator installs the company’s SOE which includes company applications.
+2. On each computer, the administrator installs the company's SOE which includes company applications.
3. The administrator runs the ScanState and LoadState command-line tools successively on each computer while specifying the **/hardlink /nocompress** command-line options.
@@ -119,13 +119,13 @@ A company is allocating 20 new computers to users in the accounting department.
A company receives 50 new laptops for their managers and needs to reallocate 50 older laptops to new employees. In this scenario, an administrator runs the ScanState tool from the cmd prompt on each computer to collect the user states and save them to a server in a compressed migration store.
-1. The administrator runs the ScanState tool on each of the manager’s old laptops, and saves each user state to a server.
+1. The administrator runs the ScanState tool on each of the manager's old laptops, and saves each user state to a server.
2. On the new laptops, the administrator installs the company's SOE, which includes Windows 10 and other company applications.
-3. The administrator runs the LoadState tool on the new laptops to migrate the managers’ user states to the appropriate computer. The new laptops are now ready for the managers to use.
+3. The administrator runs the LoadState tool on the new laptops to migrate the managers' user states to the appropriate computer. The new laptops are now ready for the managers to use.
-4. On the old computers, the administrator installs the company’s SOE, which includes Windows 10, Microsoft Office, and other company applications. The old computers are now ready for the new employees to use.
+4. On the old computers, the administrator installs the company's SOE, which includes Windows 10, Microsoft Office, and other company applications. The old computers are now ready for the new employees to use.
### Scenario Three: Managed network migration
diff --git a/windows/deployment/usmt/usmt-conflicts-and-precedence.md b/windows/deployment/usmt/usmt-conflicts-and-precedence.md
index 3348799b41..7e373b5374 100644
--- a/windows/deployment/usmt/usmt-conflicts-and-precedence.md
+++ b/windows/deployment/usmt/usmt-conflicts-and-precedence.md
@@ -32,7 +32,7 @@ When you include, exclude, and reroute files and settings, it is important to kn
- **You can use the <unconditionalExclude> element to globally exclude data.** This element excludes objects, regardless of any other <include> rules that are in the .xml files. For example, you can use the <unconditionalExclude> element to exclude all MP3 files on the computer or to exclude all files from C:\\UserData.
-## In This Topic
+## In this topic
**General**
diff --git a/windows/deployment/usmt/usmt-customize-xml-files.md b/windows/deployment/usmt/usmt-customize-xml-files.md
index 3770ee86e0..7a29b0382d 100644
--- a/windows/deployment/usmt/usmt-customize-xml-files.md
+++ b/windows/deployment/usmt/usmt-customize-xml-files.md
@@ -18,7 +18,7 @@ ms.topic: article
# Customize USMT XML Files
-## In This Topic
+## In this topic
[Overview](#bkmk-overview)
diff --git a/windows/deployment/usmt/usmt-determine-what-to-migrate.md b/windows/deployment/usmt/usmt-determine-what-to-migrate.md
index 4a5d35d95c..10f7f5f4df 100644
--- a/windows/deployment/usmt/usmt-determine-what-to-migrate.md
+++ b/windows/deployment/usmt/usmt-determine-what-to-migrate.md
@@ -22,9 +22,9 @@ By default, User State Migration Tool (USMT) 10.0 migrates the items listed in
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.
+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
+## In this section
diff --git a/windows/deployment/usmt/usmt-estimate-migration-store-size.md b/windows/deployment/usmt/usmt-estimate-migration-store-size.md
index 352d5fca77..3d225ee2c1 100644
--- a/windows/deployment/usmt/usmt-estimate-migration-store-size.md
+++ b/windows/deployment/usmt/usmt-estimate-migration-store-size.md
@@ -20,7 +20,7 @@ ms.topic: article
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
+## 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.
diff --git a/windows/deployment/usmt/usmt-general-conventions.md b/windows/deployment/usmt/usmt-general-conventions.md
index 82bcd9bc5f..460d00ef62 100644
--- a/windows/deployment/usmt/usmt-general-conventions.md
+++ b/windows/deployment/usmt/usmt-general-conventions.md
@@ -20,7 +20,7 @@ ms.topic: article
This topic describes the XML helper functions.
-## In This Topic
+## In this topic
[General XML Guidelines](#bkmk-general)
diff --git a/windows/deployment/usmt/usmt-hard-link-migration-store.md b/windows/deployment/usmt/usmt-hard-link-migration-store.md
index 1d38669310..4296942235 100644
--- a/windows/deployment/usmt/usmt-hard-link-migration-store.md
+++ b/windows/deployment/usmt/usmt-hard-link-migration-store.md
@@ -20,7 +20,7 @@ ms.topic: article
A *hard-link migration store* enables you to perform an in-place migration where all user state is maintained on the computer while the old operating system is removed and the new operating system is installed; this is why it is best suited for the computer-refresh scenario. Use of a hard-link migration store for a computer-refresh scenario drastically improves migration performance and significantly reduces hard-disk utilization, reduces deployment costs and enables entirely new migration scenarios.
-## In This Topic
+## In this topic
[When to Use a Hard-Link Migration](#bkmk-when)
@@ -76,7 +76,7 @@ A hard link can only be created for a file on the same volume. If you copy a har
For more information about hard links, please see [Hard Links and Junctions](https://go.microsoft.com/fwlink/p/?LinkId=132934)
-In most aspects, a hard-link migration store is identical to an uncompressed migration store. It is located where specified by the Scanstate command-line tool and you can view the contents of the store by using Windows® Explorer. Once created, it can be deleted or copied to another location without changing user state. Restoring a hard-link migration store is similar to restoring any other migration store; however, as with creating the store, the same hard-link functionality is used to keep files in-place.
+In most aspects, a hard-link migration store is identical to an uncompressed migration store. It is located where specified by the Scanstate command-line tool and you can view the contents of the store by using Windows® Explorer. Once created, it can be deleted or copied to another location without changing user state. Restoring a hard-link migration store is similar to restoring any other migration store; however, as with creating the store, the same hard-link functionality is used to keep files in-place.
As a best practice, we recommend that you delete the hard-link migration store after you confirm that the Loadstate tool has successfully migrated the files. Since Loadstate has created new paths to the files on your new installation of a Windows operating system, deleting the hard links in the migration store will only delete one path to the files and will not delete the actual files or the paths to them from your new operating system.
diff --git a/windows/deployment/usmt/usmt-how-to.md b/windows/deployment/usmt/usmt-how-to.md
index 7a3ad5a79d..09cb357d91 100644
--- a/windows/deployment/usmt/usmt-how-to.md
+++ b/windows/deployment/usmt/usmt-how-to.md
@@ -18,7 +18,7 @@ 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
+## In this section
|Topic |Description|
|------|-----------|
diff --git a/windows/deployment/usmt/usmt-identify-users.md b/windows/deployment/usmt/usmt-identify-users.md
index 44ee021d2e..2f41e9ebc5 100644
--- a/windows/deployment/usmt/usmt-identify-users.md
+++ b/windows/deployment/usmt/usmt-identify-users.md
@@ -19,7 +19,7 @@ ms.localizationpriority: medium
It is important to carefully consider how you plan to migrate users. By default, all users are migrated by User State Migration Tool (USMT) 5.0. You must specify which users to include by using the command line. You cannot specify users in the .xml files. For instructions on how to migrate users, see [Migrate User Accounts](usmt-migrate-user-accounts.md).
-## In This Topic
+## In this topic
- [Migrating Local Accounts](#bkmk-8)
- [Migrating Domain Accounts](#bkmk-9)
diff --git a/windows/deployment/usmt/usmt-loadstate-syntax.md b/windows/deployment/usmt/usmt-loadstate-syntax.md
index 6883570c94..ce87454ae2 100644
--- a/windows/deployment/usmt/usmt-loadstate-syntax.md
+++ b/windows/deployment/usmt/usmt-loadstate-syntax.md
@@ -20,7 +20,7 @@ ms.topic: article
This topic discusses the **LoadState** command syntax and options available with it.
-## In This Topic
+## In this topic
[Before You Begin](#before)
@@ -463,7 +463,7 @@ You can use the **/uel**, **/ue** and **/ui** options together to migrate only t
**The /ui option has precedence over the /ue and /uel options.** If a user is specified to be included using the **/ui** option, and also specified to be excluded using either the **/ue** or **/uel** options, the user will be included in the migration. For example, if you specify `/ui:contoso\* /ue:contoso\user1`, then User1 will be migrated, because the **/ui** option takes precedence over the **/ue** option.
-**The /uel option takes precedence over the /ue option.** If a user has logged on within the specified time period set by the **/uel** option, that user’s profile will be migrated even if they are excluded by using the **/ue** option. For example, if you specify `/ue:contoso\user1 /uel:14`, the User1 will be migrated if they have logged on to the computer within the last 14 days.
+**The /uel option takes precedence over the /ue option.** If a user has logged on within the specified time period set by the **/uel** option, that user's profile will be migrated even if they are excluded by using the **/ue** option. For example, if you specify `/ue:contoso\user1 /uel:14`, the User1 will be migrated if they have logged on to the computer within the last 14 days.
diff --git a/windows/deployment/usmt/usmt-migrate-user-accounts.md b/windows/deployment/usmt/usmt-migrate-user-accounts.md
index c6d7c42cc5..7115519355 100644
--- a/windows/deployment/usmt/usmt-migrate-user-accounts.md
+++ b/windows/deployment/usmt/usmt-migrate-user-accounts.md
@@ -20,7 +20,7 @@ ms.topic: article
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
+## In this topic
- [To migrate all user accounts and user settings](#bkmk-migrateall)
diff --git a/windows/deployment/usmt/usmt-plan-your-migration.md b/windows/deployment/usmt/usmt-plan-your-migration.md
index 00b4eb2dca..e00ee63664 100644
--- a/windows/deployment/usmt/usmt-plan-your-migration.md
+++ b/windows/deployment/usmt/usmt-plan-your-migration.md
@@ -24,7 +24,7 @@ In migration planning, both organizations and individuals must first identify wh
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
+## In this section
diff --git a/windows/deployment/usmt/usmt-recognized-environment-variables.md b/windows/deployment/usmt/usmt-recognized-environment-variables.md
index 0f2611208d..abf21edfbc 100644
--- a/windows/deployment/usmt/usmt-recognized-environment-variables.md
+++ b/windows/deployment/usmt/usmt-recognized-environment-variables.md
@@ -20,7 +20,7 @@ ms.topic: article
When using the XML files MigDocs.xml, MigApp.xml, and MigUser.xml, you can use environment variables to identify folders that may be different on different computers. Constant special item ID list (CSIDL) values provide a way to identify folders that applications use frequently but may not have the same name or location on any given computer. For example, the documents folder may be C:\\Users\\<Username>\\My Documents on one computer and C:\\Documents and Settings on another. You can use the asterisk (\*) wildcard character in MigUser.xml, MigApp.xml and MigDoc.xml files. However, you cannot use the asterisk (\*) wildcard characters in the Config.xml file.
-## In This Topic
+## In this topic
- [Variables that are processed for the operating system and in the context of each user](#bkmk-1)
@@ -74,7 +74,7 @@ You can use these variables within sections in the .xml files with `context=User
CSIDL_COMMON_DESKTOPDIRECTORY |
-The file-system directory that contains files and folders that appear on the desktop for all users. A typical Windows® XP path is C:\Documents and Settings\All Users\Desktop. A typical path is C:\Users\Public\Desktop. |
+The file-system directory that contains files and folders that appear on the desktop for all users. A typical Windows® XP path is C:\Documents and Settings\All Users\Desktop. A typical path is C:\Users\Public\Desktop. |
CSIDL_COMMON_DOCUMENTS |
@@ -296,7 +296,7 @@ You can use these variables in the .xml files within sections with `context=User
CSIDL_ADMINTOOLS |
-The file-system directory that is used to store administrative tools for an individual user. The Microsoft® Management Console (MMC) saves customized consoles to this directory, which roams with the user profile. |
+The file-system directory that is used to store administrative tools for an individual user. The Microsoft® Management Console (MMC) saves customized consoles to this directory, which roams with the user profile. |
CSIDL_ALTSTARTUP |
diff --git a/windows/deployment/usmt/usmt-reference.md b/windows/deployment/usmt/usmt-reference.md
index a9cc89784f..c6269b85f8 100644
--- a/windows/deployment/usmt/usmt-reference.md
+++ b/windows/deployment/usmt/usmt-reference.md
@@ -18,7 +18,7 @@ ms.topic: article
# User State Migration Toolkit (USMT) Reference
-## In This Section
+## In this section
diff --git a/windows/deployment/usmt/usmt-requirements.md b/windows/deployment/usmt/usmt-requirements.md
index b40fc8aeb3..3ddff2420e 100644
--- a/windows/deployment/usmt/usmt-requirements.md
+++ b/windows/deployment/usmt/usmt-requirements.md
@@ -18,7 +18,7 @@ ms.topic: article
# USMT Requirements
-## In This Topic
+## In this topic
- [Supported Operating Systems](#bkmk-1)
@@ -89,10 +89,10 @@ The following table lists the operating systems supported in USMT.
**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 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).
+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
diff --git a/windows/deployment/usmt/usmt-return-codes.md b/windows/deployment/usmt/usmt-return-codes.md
index 3d82a3615a..79dc252072 100644
--- a/windows/deployment/usmt/usmt-return-codes.md
+++ b/windows/deployment/usmt/usmt-return-codes.md
@@ -22,7 +22,7 @@ This topic describes User State Migration Tool (USMT) 10.0 return codes and err
Understanding the requirements for running USMT can help minimize errors in your USMT migrations. For more information, see [USMT Requirements](usmt-requirements.md).
-## In This Topic
+## In this topic
[USMT Return Codes](#bkmk-returncodes)
@@ -53,7 +53,7 @@ As a best practice, we recommend that you set verbosity level to 5, **/v**:5
## USMT Error Messages
-Error messages provide more detailed information about the migration problem than the associated return code. For example, the **ScanState**, **LoadState**, or **USMTUtils** tool might return a code of "11” (for “USMT\_INVALID\_PARAMETERS") and a related error message that reads "/key and /keyfile both specified". The error message is displayed at the command prompt and is identified in the **ScanState**, **LoadState**, or **USMTUtils** log files to help you determine why the return code was received.
+Error messages provide more detailed information about the migration problem than the associated return code. For example, the **ScanState**, **LoadState**, or **USMTUtils** tool might return a code of "11" (for "USMT\_INVALID\_PARAMETERS") and a related error message that reads "/key and /keyfile both specified". The error message is displayed at the command prompt and is identified in the **ScanState**, **LoadState**, or **USMTUtils** log files to help you determine why the return code was received.
You can obtain more information about any listed Windows application programming interface (API) system error codes by typing **net helpmsg** on the command line and, then typing the error code number. For more information about System Error Codes, see [this Microsoft Web site](https://go.microsoft.com/fwlink/p/?LinkId=147060).
diff --git a/windows/deployment/usmt/usmt-scanstate-syntax.md b/windows/deployment/usmt/usmt-scanstate-syntax.md
index f4e1d266ea..aa2dd12fa0 100644
--- a/windows/deployment/usmt/usmt-scanstate-syntax.md
+++ b/windows/deployment/usmt/usmt-scanstate-syntax.md
@@ -20,7 +20,7 @@ ms.topic: article
The ScanState command is used with the User State Migration Tool (USMT) 10.0 to scan the source computer, collect the files and settings, and create a store.
-## In This Topic
+## In this topic
[Before You Begin](#bkmk-beforeyoubegin)
@@ -572,7 +572,7 @@ You can use the /**uel**, /**ue** and /**ui** options together to migrate only t
The /**ui** option has precedence over the /**ue** and /**uel** options. If a user is specified to be included using the /**ui** option, and also specified to be excluded using either the /**ue** or /**uel** options, the user will be included in the migration. For example, if you specify `/ui:contoso\* /ue:contoso\user1`, then User1 will be migrated, because the /**ui** option takes precedence over the /**ue** option.
-The /**uel** option takes precedence over the /**ue** option. If a user has logged on within the specified time period set by the /**uel** option, that user’s profile will be migrated even if they are excluded by using the /**ue** option. For example, if you specify `/ue:fixed\user1 /uel:14`, the User1 will be migrated if they have logged on to the computer within the last 14 days.
+The /**uel** option takes precedence over the /**ue** option. If a user has logged on within the specified time period set by the /**uel** option, that user's profile will be migrated even if they are excluded by using the /**ue** option. For example, if you specify `/ue:fixed\user1 /uel:14`, the User1 will be migrated if they have logged on to the computer within the last 14 days.
diff --git a/windows/deployment/usmt/usmt-technical-reference.md b/windows/deployment/usmt/usmt-technical-reference.md
index 74dbc40088..3c31b7bf4b 100644
--- a/windows/deployment/usmt/usmt-technical-reference.md
+++ b/windows/deployment/usmt/usmt-technical-reference.md
@@ -12,6 +12,7 @@ audience: itpro
author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
+ms.custom: seo-marvel-apr2020
---
# User State Migration Tool (USMT) Technical Reference
@@ -37,12 +38,12 @@ USMT also includes a set of three modifiable .xml files:
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.
-USMT tools can be used on several versions of Windows operating systems, for more information, see [USMT Requirements](usmt-requirements.md). 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).
+USMT tools can be used on several versions of Windows operating systems, for more information, see [USMT Requirements](usmt-requirements.md). 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).
-## In This Section
+## In this section
|Topic |Description|
|------|-----------|
-|[User State Migration Tool (USMT) Overview Topics](usmt-topics.md)|Describes what’s new in USMT, how to get started with USMT, and the benefits and limitations of using USMT.|
+|[User State Migration Tool (USMT) Overview Topics](usmt-topics.md)|Describes what's new in USMT, how to get started with USMT, and the benefits and limitations of using USMT.|
|[User State Migration Tool (USMT) How-to topics](usmt-how-to.md)|Includes step-by-step instructions for using USMT, as well as how-to topics for conducting tasks in USMT.|
|[User State Migration Tool (USMT) Troubleshooting](usmt-troubleshooting.md)|Provides answers to frequently asked questions and common issues in USMT, as well as a reference for return codes used in USMT.|
|[User State Migration Toolkit (USMT) Reference](usmt-reference.md)|Includes reference information for migration planning, migration best practices, command-line syntax, using XML, and requirements for using USMT.|
diff --git a/windows/deployment/usmt/usmt-topics.md b/windows/deployment/usmt/usmt-topics.md
index 86347d1de7..ddc565ecc8 100644
--- a/windows/deployment/usmt/usmt-topics.md
+++ b/windows/deployment/usmt/usmt-topics.md
@@ -18,13 +18,13 @@ 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
+## 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.|
+|[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)
diff --git a/windows/deployment/usmt/usmt-troubleshooting.md b/windows/deployment/usmt/usmt-troubleshooting.md
index cffc027a7b..6e61e9e253 100644
--- a/windows/deployment/usmt/usmt-troubleshooting.md
+++ b/windows/deployment/usmt/usmt-troubleshooting.md
@@ -20,7 +20,7 @@ ms.topic: article
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
+## In this section
diff --git a/windows/deployment/usmt/usmt-utilities.md b/windows/deployment/usmt/usmt-utilities.md
index 968da104f8..74a5c1fbc4 100644
--- a/windows/deployment/usmt/usmt-utilities.md
+++ b/windows/deployment/usmt/usmt-utilities.md
@@ -28,7 +28,7 @@ This topic describes the syntax for the utilities available in User State Migrat
- Extract files from the compressed migration store when you migrate files and settings to the destination computer.
-## In This Topic
+## In this topic
[Usmtutils.exe](#bkmk-usmtutils-exe)
@@ -113,7 +113,7 @@ usmtutils /verify\[:*<reportType>*\] *<filePath>* \[/l:*<logfile&
Specifies whether to report on all files, corrupted files only, or the status of the catalog.
Summary. 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.
-all. 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 "CATALOG" 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 "OK" if the catalog file is intact and LoadState can open the migration store and "CORRUPTED" if the migration store is corrupted.
+all. 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 "CATALOG" 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 "OK" if the catalog file is intact and LoadState can open the migration store and "CORRUPTED" if the migration store is corrupted.
failureonly. Returns a tab-delimited list of only the files that are corrupted in the compressed migration store.
Catalog. Returns only the status of the catalog file.
|
@@ -179,7 +179,7 @@ usmtutils /verify\[:*<reportType>*\] *<filePath>* \[/l:*<logfile&
/decrypt<AlgID>/:<KeyString>
or
-/decrypt<AlgID>/:<“Key String”>
+/decrypt<AlgID>/:<"Key String">
or
/decrypt:<AlgID>/keyfile:<FileName> |
Specifies that the /encrypt option was used to create the migration store with the ScanState tool. To decrypt the migration store, specify a /key or /keyfile option as follows:
@@ -305,7 +305,7 @@ The syntax for **/extract** is:
|
/decrypt<AlgID>/key:<KeyString>
or
-/decrypt<AlgID>/:<“Key String”>
+/decrypt<AlgID>/:<"Key String">
or
/decrypt:<AlgID>/keyfile:<FileName> |
Specifies that the /encrypt option was used to create the migration store with the ScanState tool. To decrypt the migration store, you must also specify a /key or /keyfile option as follows:
diff --git a/windows/deployment/usmt/usmt-xml-elements-library.md b/windows/deployment/usmt/usmt-xml-elements-library.md
index e47360d747..7eb2b658d5 100644
--- a/windows/deployment/usmt/usmt-xml-elements-library.md
+++ b/windows/deployment/usmt/usmt-xml-elements-library.md
@@ -18,12 +18,10 @@ ms.topic: article
# XML Elements Library
-## Overview
-
This topic describes the XML elements and helper functions that you can employ to author migration .xml files to use with User State Migration Tool (USMT). It is assumed that you understand the basics of XML. .
-## In This Topic
+## In this topic
In addition to XML elements and helper functions, this topic describes how to specify encoded locations and locations patterns, functions that are for internal USMT use only, and the version tags that you can use with helper functions.
@@ -327,7 +325,7 @@ Syntax:
## <component>
-The <component> element is required in a custom .xml file. This element defines the most basic construct of a migration .xml file. For example, in the MigApp.xml file, "Microsoft® Office 2003" is a component that contains another component, "Microsoft Office Access® 2003". You can use the child elements to define the component.
+The <component> element is required in a custom .xml file. This element defines the most basic construct of a migration .xml file. For example, in the MigApp.xml file, "Microsoft® Office 2003" is a component that contains another component, "Microsoft Office Access® 2003". You can use the child elements to define the component.
A component can be nested inside another component; that is, the <component> element can be a child of the <role> element within the <component> element in two cases: 1) when the parent <component> element is a container or 2) if the child <component> element has the same role as the parent <component> element.
@@ -366,7 +364,7 @@ hidden="Yes|No">
| Yes |
You can use the following to group settings, and define the type of the component.
-System: Operating system settings. All Windows® components are defined by this type.
+System: Operating system settings. All Windows® components are defined by this type.
When type="System" and defaultSupported="FALSE" the settings will not migrate unless there is an equivalent component in the .xml files that is specified on the LoadState command line. For example, the default MigSys.xml file contains components with type="System" and defaultSupported="FALSE". If you specify this file on the ScanState command line, you must also specify the file on the LoadState command line for the settings to migrate. This is because the LoadState tool must detect an equivalent component. That is, the component must have the same migration urlid of the .xml file and an identical display name. Otherwise, the LoadState tool will not migrate those settings from the store. This is helpful when the source computer is running Windows XP, and you are migrating to both Windows Vista and Windows XP because you can use the same store for both destination computers.
Application: Settings for an application.
Device: Settings for a device.
@@ -557,7 +555,7 @@ For example:
OSType |
Yes |
- Can be 9x or NT. If OSType does not match the type of the current operating system, then it returns FALSE. For example, if the current operating system is Windows NT-based and OSType is “9x”, the result will be FALSE. |
+ Can be 9x or NT. If OSType does not match the type of the current operating system, then it returns FALSE. For example, if the current operating system is Windows NT-based and OSType is "9x", the result will be FALSE. |
OSVersion |
@@ -599,7 +597,7 @@ For example:
OSType |
Yes |
- Can be 9x or NT. If OSType does not match the type of the current operating system, then it returns FALSE. For example, if the current operating system is Windows NT-based and OSType is “9x” the result will be FALSE. |
+ Can be 9x or NT. If OSType does not match the type of the current operating system, then it returns FALSE. For example, if the current operating system is Windows NT-based and OSType is "9x" the result will be FALSE. |
OSVersion |
@@ -3132,8 +3130,8 @@ This filter helper function can be used to filter the migration of files based o
valueToCompare |
The value we are comparing. For example:
-Date: “2008/05/15-2005/05/17”, “2008/05/15”
-Size: A numeral with B, KB, MB, or GB at the end. “5GB”, “1KB-1MB” |
+Date: "2008/05/15-2005/05/17", "2008/05/15"
+Size: A numeral with B, KB, MB, or GB at the end. "5GB", "1KB-1MB"
|
@@ -3465,8 +3463,8 @@ Syntax:
You can either:
-Specify up to three <role> elements within a <component> — one “Binaries” role element, one “Settings” role element and one “Data” role element. These parameters do not change the migration behavior — their only purpose is to help you categorize the settings that you are migrating. You can nest these <role> elements, but each nested element must be of the same role parameter.
-Specify one “Container” <role> element within a <component> element. In this case, you cannot specify any child <rules> elements, only other <component> elements. And each child <component> element must have the same type as that of parent <component> element. For example:
+Specify up to three <role> elements within a <component> — one "Binaries" role element, one "Settings" role element and one "Data" role element. These parameters do not change the migration behavior — their only purpose is to help you categorize the settings that you are migrating. You can nest these <role> elements, but each nested element must be of the same role parameter.
+Specify one "Container" <role> element within a <component> element. In this case, you cannot specify any child <rules> elements, only other <component> elements. And each child <component> element must have the same type as that of parent <component> element. For example:
<component context="UserAndSystem" type="Application">
<displayName _locID="migapp.msoffice2003">Microsoft Office 2003</displayName>
@@ -3847,7 +3845,7 @@ See the last component in the MigUser.xml file for an example of this element.
~~~
**Example:**
-If GenerateUserPattens('File','%userprofile% \[\*.doc\]','FALSE') is called while USMT is processing user A, then this function will only generate patterns for users B and C. You can use this helper function to build complex rules. For example, to migrate all .doc files from the source computer — but if user X is not migrated, then do not migrate any of the .doc files from user X’s profile.
+If GenerateUserPattens('File','%userprofile% \[\*.doc\]','FALSE') is called while USMT is processing user A, then this function will only generate patterns for users B and C. You can use this helper function to build complex rules. For example, to migrate all .doc files from the source computer — but if user X is not migrated, then do not migrate any of the .doc files from user X's profile.
The following is example code for this scenario. The first <rules> element migrates all.doc files on the source computer with the exception of those inside C:\\Documents and Settings. The second <rules> elements will migrate all .doc files from C:\\Documents and Settings with the exception of the .doc files in the profiles of the other users. Because the second <rules> element will be processed in each migrated user context, the end result will be the desired behavior. The end result is the one we expected.
@@ -4104,12 +4102,12 @@ Syntax:
name |
Yes |
-ID is a string value that is the name used to reference the environment variable. We recommend that ID start with the component’s name to avoid namespace collisions. For example, if your component’s name is MyComponent, and you want a variable that is your component’s install path, you could specify MyComponent.InstallPath . |
+ID is a string value that is the name used to reference the environment variable. We recommend that ID start with the component's name to avoid namespace collisions. For example, if your component's name is MyComponent, and you want a variable that is your component's install path, you could specify MyComponent.InstallPath . |
remap |
No, default = FALSE |
-Specifies whether to evaluate this environment variable as a remapping environment variable. Objects that are located in a path that is underneath this environment variable’s value are automatically moved to where the environment variable points on the destination computer. |
+Specifies whether to evaluate this environment variable as a remapping environment variable. Objects that are located in a path that is underneath this environment variable's value are automatically moved to where the environment variable points on the destination computer. |
@@ -4228,27 +4226,27 @@ The following functions are for internal USMT use only. Do not use them in an .x
You can use the following version tags with various helper functions:
-- “CompanyName”
+- "CompanyName"
-- “FileDescription”
+- "FileDescription"
-- “FileVersion”
+- "FileVersion"
-- “InternalName”
+- "InternalName"
-- “LegalCopyright”
+- "LegalCopyright"
-- “OriginalFilename”
+- "OriginalFilename"
-- “ProductName”
+- "ProductName"
-- “ProductVersion”
+- "ProductVersion"
The following version tags contain values that can be compared:
-- “FileVersion”
+- "FileVersion"
-- “ProductVersion”
+- "ProductVersion"
## Related topics
diff --git a/windows/deployment/usmt/usmt-xml-reference.md b/windows/deployment/usmt/usmt-xml-reference.md
index 06e514f5b7..e9f8587729 100644
--- a/windows/deployment/usmt/usmt-xml-reference.md
+++ b/windows/deployment/usmt/usmt-xml-reference.md
@@ -20,7 +20,7 @@ ms.topic: article
This section contains topics that you can use to work with and to customize the migration XML files.
-## In This Section
+## In this section
diff --git a/windows/deployment/usmt/verify-the-condition-of-a-compressed-migration-store.md b/windows/deployment/usmt/verify-the-condition-of-a-compressed-migration-store.md
index e5c224c42c..88176e8e84 100644
--- a/windows/deployment/usmt/verify-the-condition-of-a-compressed-migration-store.md
+++ b/windows/deployment/usmt/verify-the-condition-of-a-compressed-migration-store.md
@@ -23,7 +23,7 @@ When you migrate files and settings during a typical PC-refresh migration, the u
- All of the files being migrated.
-- The user’s settings.
+- The user's settings.
- A catalog file that contains metadata for all files in the migration store.
@@ -37,7 +37,7 @@ When you use the **/verify** option, you can specify what type of information to
- **Failure only**: Displays only the files that are corrupted.
-## In This Topic
+## 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.
diff --git a/windows/deployment/volume-activation/add-manage-products-vamt.md b/windows/deployment/volume-activation/add-manage-products-vamt.md
index d35f96bdc7..b86f415221 100644
--- a/windows/deployment/volume-activation/add-manage-products-vamt.md
+++ b/windows/deployment/volume-activation/add-manage-products-vamt.md
@@ -20,7 +20,7 @@ ms.topic: article
This section describes how to add client computers into the Volume Activation Management Tool (VAMT). After the computers are added, you can manage the products that are installed on your network.
-## In this Section
+## In this section
|Topic |Description |
|------|------------|
diff --git a/windows/deployment/volume-activation/install-configure-vamt.md b/windows/deployment/volume-activation/install-configure-vamt.md
index fe9b3114ee..21bedde961 100644
--- a/windows/deployment/volume-activation/install-configure-vamt.md
+++ b/windows/deployment/volume-activation/install-configure-vamt.md
@@ -21,7 +21,7 @@ ms.topic: article
This section describes how to install and configure the Volume Activation Management Tool (VAMT).
-## In this Section
+## In this section
|Topic |Description |
|------|------------|
diff --git a/windows/deployment/volume-activation/introduction-vamt.md b/windows/deployment/volume-activation/introduction-vamt.md
index 72013798ef..646d92f8a9 100644
--- a/windows/deployment/volume-activation/introduction-vamt.md
+++ b/windows/deployment/volume-activation/introduction-vamt.md
@@ -18,12 +18,12 @@ ms.topic: article
# Introduction to VAMT
-The Volume Activation Management Tool (VAMT) enables network administrators and other IT professionals to automate and centrally manage the Windows®, Microsoft® Office®, and select other Microsoft products volume and retail activation process. VAMT can manage volume activation using Multiple Activation Keys (MAKs) or the Windows Key Management Service (KMS). VAMT is a standard Microsoft Management Console (MMC) snap-in and can be installed on any computer that has one of the following Windows operating systems: Windows® 7, Windows 8, Windows 8.1, Windows 10,Windows Server 2008 R2, or Windows Server 2012.
+The Volume Activation Management Tool (VAMT) enables network administrators and other IT professionals to automate and centrally manage the Windows®, Microsoft® Office®, and select other Microsoft products volume and retail activation process. VAMT can manage volume activation using Multiple Activation Keys (MAKs) or the Windows Key Management Service (KMS). VAMT is a standard Microsoft Management Console (MMC) snap-in and can be installed on any computer that has one of the following Windows operating systems: Windows® 7, Windows 8, Windows 8.1, Windows 10,Windows Server 2008 R2, or Windows Server 2012.
**Note**
VAMT can be installed on, and can manage, physical or virtual instances. VAMT cannot detect whether or not the remote products are virtual. As long as the products can respond to Windows Management Instrumentation (WMI) calls, they will be discovered and activated.
-## In this Topic
+## In this topic
- [Managing Multiple Activation Key (MAK) and Retail Activation](#bkmk-managingmak)
- [Managing Key Management Service (KMS) Activation](#bkmk-managingkms)
- [Enterprise Environment](#bkmk-enterpriseenvironment)
@@ -46,7 +46,7 @@ VAMT is commonly implemented in enterprise environments. The following illustrat

-In the Core Network environment, all computers are within a common network managed by Active Directory® Domain Services (AD DS). The Secure Zone represents higher-security Core Network computers that have additional firewall protection.
+In the Core Network environment, all computers are within a common network managed by Active Directory® Domain Services (AD DS). The Secure Zone represents higher-security Core Network computers that have additional firewall protection.
The Isolated Lab environment is a workgroup that is physically separate from the Core Network, and its computers do not have Internet access. The network security policy states that no information that could identify a specific computer or user may be transferred out of the Isolated Lab.
## VAMT User Interface
diff --git a/windows/deployment/volume-activation/manage-activations-vamt.md b/windows/deployment/volume-activation/manage-activations-vamt.md
index f1f3ce5baf..a2699960b3 100644
--- a/windows/deployment/volume-activation/manage-activations-vamt.md
+++ b/windows/deployment/volume-activation/manage-activations-vamt.md
@@ -20,7 +20,7 @@ ms.topic: article
This section describes how to activate a client computer, by using a variety of activation methods.
-## In this Section
+## In this section
|Topic |Description |
|------|------------|
diff --git a/windows/deployment/volume-activation/manage-product-keys-vamt.md b/windows/deployment/volume-activation/manage-product-keys-vamt.md
index 64027a69f0..c363018e6d 100644
--- a/windows/deployment/volume-activation/manage-product-keys-vamt.md
+++ b/windows/deployment/volume-activation/manage-product-keys-vamt.md
@@ -19,7 +19,7 @@ ms.topic: article
# Manage Product Keys
This section describes how to add and remove a product key from the Volume Activation Management Tool (VAMT). After you add a product key to VAMT, you can install that product key on a product or products you select in the VAMT database.
-## In this Section
+## In this section
|Topic |Description |
|------|------------|
diff --git a/windows/deployment/volume-activation/manage-vamt-data.md b/windows/deployment/volume-activation/manage-vamt-data.md
index 889a9d6975..1d0a211e37 100644
--- a/windows/deployment/volume-activation/manage-vamt-data.md
+++ b/windows/deployment/volume-activation/manage-vamt-data.md
@@ -20,7 +20,7 @@ ms.topic: article
This section describes how to save, import, export, and merge a Computer Information List (CILX) file using the Volume Activation Management Tool (VAMT).
-## In this Section
+## In this section
|Topic |Description |
|------|------------|
|[Import and Export VAMT Data](import-export-vamt-data.md) |Describes how to import and export VAMT data. |
diff --git a/windows/deployment/volume-activation/monitor-activation-client.md b/windows/deployment/volume-activation/monitor-activation-client.md
index 75c2d8b3f0..c203fe7ea5 100644
--- a/windows/deployment/volume-activation/monitor-activation-client.md
+++ b/windows/deployment/volume-activation/monitor-activation-client.md
@@ -14,7 +14,7 @@ audience: itpro
author: greg-lindsay
ms.localizationpriority: medium
ms.topic: article
-ms.custom: seo-marvel-mar2020
+ms.custom: seo-marvel-apr2020
---
# Monitor activation
@@ -41,6 +41,6 @@ You can monitor the success of the activation process for a computer running Win
- See [Troubleshooting activation error codes](https://docs.microsoft.com/windows-server/get-started/activation-error-codes) for information about troubleshooting procedures for Multiple Activation Key (MAK) or the Key Management Service (KMS).
- The VAMT provides a single site from which to manage and monitor volume activations. This is explained in the next section.
-## See also
+## Related topics
[Volume Activation for Windows 10](volume-activation-windows-10.md)
diff --git a/windows/deployment/volume-activation/scenario-online-activation-vamt.md b/windows/deployment/volume-activation/scenario-online-activation-vamt.md
index 61096c7c82..4ce4e78992 100644
--- a/windows/deployment/volume-activation/scenario-online-activation-vamt.md
+++ b/windows/deployment/volume-activation/scenario-online-activation-vamt.md
@@ -28,7 +28,7 @@ The Secure Zone represents higher-security Core Network computers that have addi

-## In This Topic
+## In this topic
- [Install and start VAMT on a networked host computer](#bkmk-partone)
- [Configure the Windows Management Instrumentation firewall exception on target computers](#bkmk-parttwo)
- [Connect to VAMT database](#bkmk-partthree)
diff --git a/windows/deployment/volume-activation/vamt-step-by-step.md b/windows/deployment/volume-activation/vamt-step-by-step.md
index a99e7fd10a..98bc193c4f 100644
--- a/windows/deployment/volume-activation/vamt-step-by-step.md
+++ b/windows/deployment/volume-activation/vamt-step-by-step.md
@@ -20,13 +20,13 @@ ms.topic: article
This section provides step-by-step instructions on implementing the Volume Activation Management Tool (VAMT) in typical environments. VAMT supports many common scenarios; the scenarios in this section describe some of the most common to get you started.
-## In this Section
+## In this section
|Topic |Description |
|------|------------|
|[Scenario 1: Online Activation](scenario-online-activation-vamt.md) |Describes how to distribute Multiple Activation Keys (MAKs) to products installed on one or more connected computers within a network, and how to instruct these products to contact Microsoft over the Internet for activation. |
|[Scenario 2: Proxy Activation](scenario-proxy-activation-vamt.md) |Describes how to use two VAMT host computers — the first one with Internet access and a second computer within an isolated workgroup — as proxies to perform MAK volume activation for workgroup computers that do not have Internet access. |
-|[Scenario 3: KMS Client Activation](scenario-kms-activation-vamt.md) |Describes how to use VAMT to configure client products for Key Management Service (KMS) activation. By default, volume license editions of Windows 10, Windows Vista, Windows® 7, Windows 8, Windows Server 2008, Windows Server 2008 R2, or Windows Server® 2012, and Microsoft® Office 2010 use KMS for activation. |
+|[Scenario 3: KMS Client Activation](scenario-kms-activation-vamt.md) |Describes how to use VAMT to configure client products for Key Management Service (KMS) activation. By default, volume license editions of Windows 10, Windows Vista, Windows® 7, Windows 8, Windows Server 2008, Windows Server 2008 R2, or Windows Server® 2012, and Microsoft® Office 2010 use KMS for activation. |
## Related topics
- [Introduction to VAMT](introduction-vamt.md)
diff --git a/windows/deployment/volume-activation/volume-activation-management-tool.md b/windows/deployment/volume-activation/volume-activation-management-tool.md
index c73cbc4546..23c0a83614 100644
--- a/windows/deployment/volume-activation/volume-activation-management-tool.md
+++ b/windows/deployment/volume-activation/volume-activation-management-tool.md
@@ -13,13 +13,14 @@ audience: itpro
author: greg-lindsay
ms.date: 04/25/2017
ms.topic: article
+ms.custom: seo-marvel-apr2020
---
# Volume Activation Management Tool (VAMT) Technical Reference
-The Volume Activation Management Tool (VAMT) enables network administrators and other IT professionals to automate and centrally manage the Windows®, Microsoft® Office, and select other Microsoft products volume and retail-activation process.
+The Volume Activation Management Tool (VAMT) enables network administrators and other IT professionals to automate and centrally manage the Windows®, Microsoft® Office, and select other Microsoft products volume and retail-activation process.
VAMT can manage volume activation using Multiple Activation Keys (MAKs) or the Windows Key Management Service (KMS). VAMT is a standard Microsoft Management Console (MMC) snap-in that requires the Microsoft Management Console (MMC) 3.0. VAMT can be installed on any computer that has one of the following Windows operating systems:
-- Windows® 7 or above
+- Windows® 7 or above
- Windows Server 2008 R2 or above
@@ -28,7 +29,7 @@ VAMT is designed to manage volume activation for: Windows 7, Windows 8, Window
VAMT is only available in an EN-US (x86) package.
-## In this Section
+## In this section
|Topic |Description |
|------|------------|
diff --git a/windows/deployment/windows-autopilot/bitlocker.md b/windows/deployment/windows-autopilot/bitlocker.md
index 234ae17fcc..02790d704c 100644
--- a/windows/deployment/windows-autopilot/bitlocker.md
+++ b/windows/deployment/windows-autopilot/bitlocker.md
@@ -14,6 +14,7 @@ author: greg-lindsay
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
+ms.custom: seo-marvel-apr2020
---
@@ -49,6 +50,6 @@ Note: It is also recommended to set Windows Encryption -> Windows Settings -> En
Windows 10, version 1809 or later.
-## See also
+## Related topics
[Bitlocker overview](https://docs.microsoft.com/windows/security/information-protection/bitlocker/bitlocker-overview)