Freshness 04-12-2023 15

windows/deployment/usmt/migration-store-types-overview.md

@@ -1,11 +1,11 @@
 ---
-title: Migration Store Types Overview (Windows 10)
+title: Migration Store Types Overview
 description: Learn about the migration store types and how to determine which migration store type best suits your needs.
 manager: aaroncz
 ms.author: frankroj
 ms.prod: windows-client
 author: frankroj
-ms.date: 12/06/2023
+ms.date: 12/20/2023
 ms.topic: article
 ms.technology: itpro-deploy
 ---

windows/deployment/usmt/usmt-custom-xml-examples.md

@@ -1,5 +1,5 @@
 ---
-title: Custom XML Examples (Windows 10)
+title: Custom XML Examples
 description: Use custom XML examples to learn how to migrate an unsupported application, migrate files and registry keys, and migrate the My Videos folder.
 manager: aaroncz
 ms.author: frankroj
@@ -7,7 +7,7 @@ ms.prod: windows-client
 author: frankroj
 ms.topic: article
 ms.technology: itpro-deploy
-ms.date: 11/01/2022
+ms.date: 12/20/2023
 ---
 
 # Custom XML Examples
@@ -99,7 +99,7 @@ The following sample is a custom .xml file named `CustomFile.xml` that migrates
 
   `<include filter='MigXmlHelper.IgnoreIrrelevantLinks()'>`
 
-  This filter has no effect on files that aren't shortcuts. For example, if there's a shortcut in **My Videos** on the source computer that points to `C:\Folder1`, that shortcut will be migrated only if `C:\Folder1` exists on the destination computer. However, all other files, such as .mp3 files, migrate without any filtering.
+  This filter has no effect on files that aren't shortcuts. For example, if there's a shortcut in **My Videos** on the source computer that points to `C:\Folder1`, that shortcut is migrated only if `C:\Folder1` exists on the destination computer. However, all other files, such as .mp3 files, migrate without any filtering.
 
 - **Sample pattern**: Migrates **My Videos** for all users:
 
@@ -275,6 +275,5 @@ The behavior for this custom .xml file is described within the `<displayName>` t
 
 ## Related articles
 
-[USMT XML reference](usmt-xml-reference.md)
+- [USMT XML reference](usmt-xml-reference.md).
-
+- [Customize USMT XML files](usmt-customize-xml-files.md).
-[Customize USMT XML files](usmt-customize-xml-files.md)

windows/deployment/usmt/usmt-customize-xml-files.md

@@ -1,11 +1,11 @@
 ---
-title: Customize USMT XML Files (Windows 10)
+title: Customize USMT XML Files
 description: Learn how to customize USMT XML files. Also, learn about the migration XML files that are included with USMT.
 manager: aaroncz
 ms.author: frankroj
 ms.prod: windows-client
 author: frankroj
-ms.date: 11/01/2022
+ms.date: 12/20/2023
 ms.topic: article
 ms.technology: itpro-deploy
 ---
@@ -14,30 +14,31 @@ ms.technology: itpro-deploy
 
 ## Overview
 
-If you want the ScanState and LoadState tools to use any of the migration .xml files, specify these files at the command line using the `/i` option. Because the ScanState and LoadState tools need the .xml files to control the migration, specify the same set of .xml files for both the `ScanState.exe` and `LoadState.exe` commands. However, you don't have to specify the `Config.xml` file with the `/config` option, unless you want to exclude some of the files and settings that you migrated to the store. For example, you might want to migrate the My Documents folder to the store but not to the destination computer. To achieve this scenario, modify the `Config.xml` file and specify the updated file with the `LoadState.exe` command. Then the `LoadState.exe` command will migrate only the files and settings that you want to migrate.
+If you want the ScanState and LoadState tools to use any of the migration **.xml** files, specify these files at the command line using the `/i` option. Because the ScanState and LoadState tools need the **.xml** files to control the migration, specify the same set of **.xml** files for both the `ScanState.exe` and `LoadState.exe` commands. However, the `Config.xml` file with the `/config` option doesn't need to be specified, unless some of the migrated files and settings from the store need to be excluded. For example, you might want to migrate the My Documents folder to the store but not to the destination computer. To achieve this scenario, modify the `Config.xml` file and specify the updated file with the `LoadState.exe` command. The `LoadState.exe` command then migrates only the files and settings that you want to migrate.
 
-If you leave out an .xml file from the `LoadState.exe` 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.exe` command won't apply. For example, if you leave out an .xml file, and it contains a rerouting rule such as:
+If you leave out an **.xml** file from the `LoadState.exe` command, all of the data in the store that was migrated with the missing **.xml** files are migrated. However, the migration rules that were specified with the `ScanState.exe` command don't 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 won't reroute the files, and they'll be migrated to `C:\data`.
+USMT doesn't reroute the files, and they're 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.
+- **Modify the migration .xml files.** If you want to exclude a portion of a component, modify the **.xml** files. For example, to migrate C:\\ but exclude all of the .mp3 files, or to move data to a new location on the destination computer. 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 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.** Create and modify a `Config.xml` file 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 don't 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.
+- **Create and modify a Config.xml file.** Create and modify a `Config.xml` file 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 don't 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) article.
 
 ## 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're migrated to on the destination computer.
+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're 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.
+>
+> You can use the asterisk (\*) wildcard character in each of these files. However, you can't use a question mark (?) as a wildcard character.
 
 - **The MigApp.xml file.** Specify this file with both the `ScanState.exe` and `LoadState.exe` commands to migrate application settings.
 
@@ -46,32 +47,34 @@ This section describes the migration .xml files that are included with USMT. Eac
 - **The MigUser.xml file.** Specify this file with both the `ScanState.exe` and `LoadState.exe` commands to migrate user folders, files, and file types. You can modify the `MigUser.xml` file. This file doesn't 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]
+>
 > Don't 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) articles.
 
 ## 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.exe` and `LoadState.exe` to use this file, specify it with both commands. For more information, see the [Custom XML examples](usmt-custom-xml-examples.md) article.
+You can create custom **.xml** files to customize the migration for your unique needs. For example, you might want to create a custom file to migrate a line-of-business application or to modify the default migration behavior. If you want `ScanState.exe` and `LoadState.exe` to use this file, specify it with both commands. For more information, see the [Custom XML examples](usmt-custom-xml-examples.md) article.
 
 ## The Config.xml file
 
-The `Config.xml` file is an optional file that you create using the `/genconfig` option with the `ScanState.exe` 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 the migration .xml files because it doesn't 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) article. For this reason, excluding components using this file is easier than modifying the migration .xml files because you don't need to be familiar with the migration rules and syntax. However, you can't use wildcard characters in a `Config.xml` file.
+The `Config.xml` file is an optional file that you create using the `/genconfig` option with the `ScanState.exe` 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 the migration **.xml** files because it doesn't 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) article. For this reason, excluding components using the `Config.xml` file is easier than modifying the migration **.xml** files. With the `Config.xml`, you don't need to be familiar with the migration rules and syntax. However, you can't use wildcard characters in a `Config.xml` file.
 
-If you want to include all of the default components, you don't need to create the `Config.xml` file. Alternatively, if you're 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.
+If you want to include all of the default components, you don't need to create the `Config.xml` file. Alternatively, if you're 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.exe` command with the `/genconfig` option, `ScanState.exe` 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.exe` 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. Creating the file on the source computer will ensure that this file contains every component that can be migrated. The components are organized into sections: <Applications>, <WindowsComponents>, and <Documents>. To choose not to migrate a component, change its entry to `migrate="no"`.
+When you run the `ScanState.exe` command with the `/genconfig` option, `ScanState.exe` 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 contains 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.exe` 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 are present on the destination computers. Creating the file on the source computer ensures that this file contains every component that can be migrated. The components are organized into sections: <Applications>, <WindowsComponents>, and <Documents>. 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.exe` 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.exe` command. For example, if you collected the My Documents folder in the store, but you decide that you don't 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.exe` command, and the file won't 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) article.
+After you create this file, you need to specify it only with the `ScanState.exe` command using the `/Config` option for it to affect the migration. However, if additional data that was migrated to the store needs to be excluded, modify the `Config.xml` file and specify the updated file with the `LoadState.exe` command. For example, if you collected the My Documents folder in the store, but you decide that you don't 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.exe` command, and the file aren't 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) article.
 
 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 a parent component is removed from the migration in the `Config.xml` file by specifying `migrate="no"`, all of its child components are automatically 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.
+- 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 is migrated.
 
 - In USMT, there are several migration policies that can be configured in the `Config.xml` file. For example, you can configure additional **<ErrorControl>**, **<ProfileControl>**, and **<HardLinkStoreControl>** options. For more information, see the [Config.xml File](usmt-configxml-file.md) article.
 
 > [!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.
+>
+> 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 doesn't exclude the component from your migration.
 
 ### Examples
 
@@ -79,7 +82,7 @@ In addition, note the following functionality with the `Config.xml` file:
 
     `ScanState.exe /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:
+- The following command creates an encrypted store using the `Config.xml` file and the default migration **.xml** files:
 
     `ScanState.exe \\server\share\migration\mystore /i:MigApp.xml /i:MigDocs.xml /o /config:Config.xml /v:5 /encrypt /key:"mykey"`
 
@@ -89,14 +92,11 @@ In addition, note the following functionality with the `Config.xml` file:
 
 ## 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 how to change the files and settings that are migrated, see the [User State Migration Tool (USMT) how-to articles](usmt-how-to.md).
-
+- For more information about each **.xml** element, see the [XML elements library](usmt-xml-elements-library.md) article.
-- For more information about each .xml element, see the [XML elements library](usmt-xml-elements-library.md) article.
-
 - For answers to common questions, see ".xml files" in the [Frequently asked questions](usmt-faq.yml) article.
 
 ## Related articles
 
-[User State Migration Tool (USMT) command-line syntax](usmt-command-line-syntax.md)
+- [User State Migration Tool (USMT) command-line syntax](usmt-command-line-syntax.md).
-
+- [USMT resources](usmt-resources.md).
-[USMT resources](usmt-resources.md)

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

@@ -1,11 +1,11 @@
 ---
-title: Extract Files from a Compressed USMT Migration Store (Windows 10)
+title: Extract Files from a Compressed USMT Migration Store
 description: In this article, learn how to extract files from a compressed User State Migration Tool (USMT) migration store.
 manager: aaroncz
 ms.author: frankroj
 ms.prod: windows-client
 author: frankroj
-ms.date: 11/01/2022
+ms.date: 12/20/2023
 ms.topic: article
 ms.technology: itpro-deploy
 ---
@@ -22,7 +22,7 @@ Options used with the `/extract` option can specify:
 
 - Include and exclude patterns for selective data extraction.
 
-In addition, you can specify the file patterns that you want to extract by using the `/i` option to include file patterns or the `/e` option to exclude file patterns. When both the `/i` option and the `/e` option are used in the same command, include patterns take precedence over exclude patterns. Note that this is different from the include and exclude rules used in the **ScanState** and **LoadState** tools.
+In 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. The `/i` and the `/e` options are different from the include and exclude rules used in the **ScanState** and **LoadState** tools.
 
 ## To run the UsmtUtils tool with the /extract option
 
@@ -34,7 +34,7 @@ UsmtUtils.exe /extract <filePath> <destinationPath> [/i:<includePattern>] [/e:<e
 
 Where the placeholders have the following values:
 
-- **&lt;USMTpath&gt;** is the location where you have saved the USMT files and tools.
+- **&lt;USMTpath&gt;** is the location where the USMT files and tools are saved.
 
 - **&lt;filePath&gt;** is the location of the migration store.
 
@@ -80,18 +80,16 @@ UsmtUtils.exe /extract D:\MyMigrationStore\USMT\store.mig /e:*.exe C:\ExtractedS
 
 ### 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:
+When files are extracted from a compressed migration store, both the include and the exclude patterns can be used at the same time. Files of one type can be excluded while files of another type can be included. For example:
 
 ```cmd
 UsmtUtils.exe /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.
+In this example, if there's a **myProject.exe** file, the file is also extracted because the include pattern option takes precedence over the exclude pattern option.
 
 ## Related articles
 
-[UsmtUtils syntax](usmt-utilities.md)
+- [UsmtUtils syntax](usmt-utilities.md).
-
+- [Return codes](/troubleshoot/windows-client/deployment/usmt-return-codes).
-[Return codes](/troubleshoot/windows-client/deployment/usmt-return-codes)
+- [Verify the condition of a compressed migration store](verify-the-condition-of-a-compressed-migration-store.md).
-
-[Verify the condition of a compressed migration store](verify-the-condition-of-a-compressed-migration-store.md)

windows/deployment/usmt/usmt-hard-link-migration-store.md

@@ -1,11 +1,11 @@
 ---
-title: Hard-Link Migration Store (Windows 10)
+title: Hard-Link Migration Store
 description: Use of a hard-link migration store for a computer-refresh scenario drastically improves migration performance and significantly reduces hard-disk utilization.
 manager: aaroncz
 ms.author: frankroj
 ms.prod: windows-client
 author: frankroj
-ms.date: 11/01/2022
+ms.date: 12/20/2023
 ms.topic: article
 ms.technology: itpro-deploy
 ---
@@ -16,63 +16,67 @@ A **hard-link migration store** enables you to perform an in-place migration whe
 
 ## When to use a hard-link migration
 
-You can use a hard-link migration store when your planned migration meets both of the following criteria:
+A hard-link migration store can be used when the planned migration meets both of the following criteria:
 
-- You're upgrading the operating system on existing hardware rather than migrating to new computers.
+- The operating system is being upgraded on existing hardware rather than migrating to new computers.
 
-- You're upgrading the operating system on the same volume of the computer.
+- The operating system is being upgraded on the same volume of the computer.
 
 You can't use a hard-link migration store if your planned migration includes any of the following tasks:
 
-- You're migrating data from one computer to a second computer.
+- Data is being migrated from one computer to a different computer.
 
-- You're migrating data from one volume on a computer to another volume, for example from `C:` to `D:`.
+- Data is being migrating from one volume on a computer to another volume on the same computer, for example from `C:` to `D:`.
 
-- You're formatting or repartitioning the disk outside of Windows Setup, or specifying a disk format or repartition during Windows Setup that will remove the migration store.
+- The disk containing the migration store is being formatted or repartitioned disk either outside of Windows Setup or during Windows Setup.
 
 ## Understanding a hard-link migration
 
 The hard-link migration store is created using the command-line option, `/hardlink`, and is equivalent to other migration-store types. However, it differs in that hard links are utilized to keep files stored on the source computer during the migration. Keeping the files in place on the source computer eliminates the redundant work of duplicating files. It also enables the performance benefits and reduction in disk utilization that define this scenario.
 
-When you create a hard link, you give an existing file one more path. For instance, you could create a hard link to `c:\file1.txt` called `c:\hard link\myFile.txt`. These two paths relate to the same file. If you open `c:\file1.txt`, make changes, and save the file, you'll see those changes when you open `c:\hard link\myFile.txt`. If you delete `c:\file1.txt`, the file still exists on your computer as `c:\hardlink\myFile.txt`. You must delete both references to the file in order to delete the file.
+When you create a hard link, you give an existing file one more path. For instance, you could create a hard link to `c:\file1.txt` called `c:\hard link\myFile.txt`. These two paths relate to the same file. If you open `c:\file1.txt`, make changes, and save the file, you see those changes when you open `c:\hard link\myFile.txt`. If you delete `c:\file1.txt`, the file still exists on your computer as `c:\hardlink\myFile.txt`. You must delete both references to the file in order to delete the file.
 
 > [!NOTE]
 > A hard link can only be created for a file on the same volume. If you copy a hard-link migration store to another drive or external device, the files, and not the links, are copied, as in a non-compressed migration-store scenario.
 
 For more information about hard links, see [Hard Links and Junctions](/windows/win32/fileio/hard-links-and-junctions)
 
-In most aspects, a hard-link migration store is identical to an uncompressed migration store. It's located where specified by the **ScanState.exe** 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. The hard-link migration store is located as specified by the **ScanState.exe** command-line tool. The contents of the store can be viewed 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, it's recommended 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 the new installation of a Windows operating system, deleting the hard links in the migration store will only delete one path to the files, and won't delete the actual files or the paths to them from the new operating system.
+As a best practice, delete the hard-link migration store after you confirm that the files are successfully migrated via the **LoadState** tool. Since **LoadState** creates new paths to the files on the new installation of a Windows operating system, deleting the hard links in the migration store only deletes one path to the files. It doesn't delete the actual files or the paths to them from the new operating system.
 
 > [!IMPORTANT]
+>
 > Using the `/c` option will force the **LoadState** tool to continue applying files when non-fatal errors occur. If you use the `/c` option, you should verify that no errors are reported in the logs before deleting the hard-link migration store in order to avoid data loss.
 
 Keeping the hard-link migration store can result in extra disk space being consumed or problems with some applications for the following reasons:
 
-- Applications reporting file-system statistics, for example, space used and free space, might incorrectly report these statistics while the hard-link migration store is present. The file may be reported twice because of the two paths that reference that file.
+- Applications reporting file-system statistics, for example, space used and free space, might incorrectly report these statistics while the hard-link migration store is present. The file might be reported twice because of the two paths that reference that file.
 
-- A hard link may lose its connection to the original file. Some applications save changes to a file by creating a temporary file and then renaming the original to a backup filename. The path that wasn't used to open the file in this application will continue to refer to the unmodified file. The unmodified file that isn't in use is taking up more disk space. You should create the hard-link migration store just before you perform the migration, and not use applications once the store is created, in order to make sure you're migrating the latest versions of all files.
+- A hard link might lose its connection to the original file. Some applications save changes to a file by creating a temporary file and then renaming the original to a backup filename. The path that wasn't used to open the file in this application continues to refer to the unmodified file. The unmodified file that isn't in use is taking up more disk space. The hard-link migration store should be created just before the migration is performed. Once the store is created, applications shouldn't be used in order to make sure the latest versions of all files are being migrating.
 
-- Editing the file by using different paths simultaneously may result in data corruption.
+- Editing the file by using different paths simultaneously might result in data corruption.
 
 > [!IMPORTANT]
+>
 > The read-only file attribute on migrated files is lost when the hard-link migration store is deleted. This is due to a limitation in NTFS file system hard links.
 
 ## Hard-link migration scenario
 
-For example, a company has decided to deploy Windows 10 on all of their computers. Each employee will keep the same computer, but the operating system on each computer will be updated.
+For example, a company decides to deploy the latest supported version of Windows on all of their computers. Each employee keeps the same computer, but the operating system on each computer will be updated.
 
 1. An administrator runs the **ScanState** command-line tool on each computer, specifying the `/hardlink` command-line option. The **ScanState** tool saves the user state to a hard-link migration store on each computer, improving performance by reducing file duplication, except in certain specific instances.
 
     > [!NOTE]
+    >
     > As a best practice, we recommend that you do not create your hard-link migration store until just before you perform the migration in order to migrate the latest versions of your files. You should not use your software applications on the computer after creating the migration store until you have finished migrating your files with **LoadState**.
 
-2. On each computer, an administrator installs the company's standard operating environment (SOE), which includes Windows 10 and other applications the company currently uses.
+1. On each computer, an administrator installs the company's standard operating environment (SOE), which includes the latest supported version of Windows and other applications the company currently uses.
 
-3. An administrator runs the **LoadState** command-line tool on each computer. The **LoadState** tool restores user state back on each computer.
+1. An administrator runs the **LoadState** command-line tool on each computer. The **LoadState** tool restores user state back on each computer.
 
 > [!NOTE]
+>
 > During the update of a domain-joined computer, the profiles of users whose SID cannot be resolved will not be migrated. When using a hard-link migration store, it could cause a data loss.
 
 ## Hard-link migration store details
@@ -85,17 +89,22 @@ The `/hardlink` command-line option proceeds with creating the migration store o
 
 ### Hard-link store size estimation
 
-It isn't necessary to estimate the size of a hard-link migration store since hard-link migration store on NTFS volumes will be relatively small and require much less incremental space than other store options. Estimating the size of a migration store is only useful in scenarios where the migration store is large. The only case where the local store can be large with hard-link migrations is when non-NTFS file systems exist on the system and the non-NTFS files system contain data that needs to be migrated. Since NTFS has been the default file system format for Windows XP and newer operating systems, this situation is unusual.
+It isn't necessary to estimate the size of a hard-link migration store since a hard-link migration store on an NTFS volume is relatively small and require much less incremental space than other store options. Estimating the size of a migration store is only useful in scenarios where the migration store is large. The only case where the local store can be large with hard-link migrations is:
+
+- A non-NTFS file system exists on the system.
+- The non-NTFS files system contains data that needs to be migrated.
+
+Since NTFS is the default file system format for all currently supported versions of Windows, this situation is unusual.
 
 ### Migration store path on multiple volumes
 
-Separate hard-link migration stores are created on each NTFS volume that contain data being migrated. In this scenario, the primary migration-store location will be specified on the command line, and should be the operating-system volume. Migration stores with identical names and directory names will be created on every volume containing data being migrated. For example:
+Separate hard-link migration stores are created on each NTFS volume that contain data being migrated. In this scenario, the primary migration-store location is specified on the command line, and should be the operating-system volume. Migration stores with identical names and directory names are created on every volume containing data being migrated. For example:
 
   ```cmd
   ScanState.exe /hardlink c:\USMTMIG […]
   ```
 
-Running this command on a system that contains the operating system on the C: drive and the user data on the D: drive will generate migration stores in the following locations, assuming that both drives are NTFS:
+Running this command on a system that contains the operating system on the C: drive and the user data on the D: drive generates migration stores in the following locations, assuming that both drives are NTFS:
 
 `C:\USMTMIG\`
 
@@ -105,25 +114,26 @@ The drive you specify on the command line for the hard-link migration store is i
 
 ### Location modifications
 
-Location modifications that redirect migrated content from one volume to a different volume have an adverse impact on the performance of a hard-link migration. This impact is because the migrating data that must cross system volumes can't remain in the hard-link migration store, and must be copied across the system volumes.
+Location modifications that redirect migrated content from one volume to a different volume have an adverse effect on the performance of a hard-link migration. Performance is affected because the migrating data that must cross system volumes can't remain in the hard-link migration store. They must be copied across the system volumes.
 
 ### Migrating Encrypting File System (EFS) certificates and files
 
 To migrate Encrypting File System (EFS) files to a new installation of an operating system on the same volume of the computer, specify the `/efs:hardlink` option in the `ScanState.exe` command-line syntax.
 
-If the EFS files are being restored to a different partition, you should use the `/efs:copyraw` option instead of the `/efs:hardlink` option. Hard links can only be created for files on the same volume. Moving the files to another partition during the migration requires a copy of the files to be created on the new partition. The `/efs:copyraw` option will copy the files to the new partition in encrypted format.
+If the EFS files are being restored to a different partition, you should use the `/efs:copyraw` option instead of the `/efs:hardlink` option. Hard links can only be created for files on the same volume. Moving the files to another partition during the migration requires a copy of the files to be created on the new partition. The `/efs:copyraw` option copies the files to the new partition in encrypted format.
 
 For more information, see [Migrate EFS files and certificates](usmt-migrate-efs-files-and-certificates.md) and [Encrypted file options](usmt-scanstate-syntax.md#encrypted-file-options).
 
 ### Migrating locked files with the hard-link migration store
 
-Files that are locked by an application or the operating system are handled differently when using a hard-link migration store.
+When an application or the operating system has a lock on a file, the file is handled differently when using a hard-link migration store.
 
-Files that are locked by the operating system can't remain in place and must be copied into the hard-link migration store. As a result, selecting many operating-system files for migration significantly reduces performance during a hard-link migration. As a best practice, we recommend that you don't migrate any files out of the `\Windows` directory, which minimizes performance-related issues.
+Operating system locked files can't remain in place and must be copied into the hard-link migration store. As a result, selecting many operating-system files for migration significantly reduces performance during a hard-link migration. As a best practice, we recommend that you don't migrate any files out of the `\Windows` directory, which minimizes performance-related issues.
 
-Files that are locked by an application are treated the same in hard-link migrations as in other scenarios when the volume shadow-copy service isn't being utilized. The volume shadow-copy service can't be used with hard-link migrations. However, by modifying the new **<HardLinkStoreControl>** section in the `Config.xml` file, it's possible to enable the migration of files locked by an application.
+Application locked files are treated the same in hard-link migrations as in other scenarios when the volume shadow-copy service isn't being utilized. The volume shadow-copy service can't be used with hard-link migrations. However, by modifying the new **<HardLinkStoreControl>** section in the `Config.xml` file, it's possible to enable the migration of files locked by an application.
 
 > [!IMPORTANT]
+>
 > There are some scenarios in which modifying the **<HardLinkStoreControl>** section in the `Config.xml` file makes it more difficult to delete a hard-link migration store. In these scenarios, you must use `UsmtUtils.exe` to schedule the migration store for deletion on the next restart.
 
 ## XML elements in the Config.xml file
@@ -139,6 +149,7 @@ A new section in the `Config.xml` file allows optional configuration of some of
 | **&lt;errorHardLink&gt;** | This element defines a standard MigXML pattern that describes file paths where hard links shouldn't be created, if the file is locked for editing by another application. <br/><br/>`<errorHardLink>` [pattern] `</errorHardLink>` |
 
 > [!IMPORTANT]
+>
 > You must use the `/nocompress` option with the `/HardLink` option.
 
 The following XML sample specifies that files locked by an application under the `\Users` directory can remain in place during the migration. It also specifies that locked files that aren't located in the `\Users` directory should result in the **File in Use** error. It's important to exercise caution when specifying the paths using the **`<createhardlink>`** tag in order to minimize scenarios that make the hard-link migration store more difficult to delete.
@@ -156,4 +167,4 @@ The following XML sample specifies that files locked by an application under the
 
 ## Related articles
 
-[Plan your migration](usmt-plan-your-migration.md)
+- [Plan your migration](usmt-plan-your-migration.md).