mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-17 03:13:44 +00:00
CI Update
This commit is contained in:
@ -77,7 +77,7 @@ Next, you should go through the user interface and make a list of all of the ava
|
||||
**Note**
|
||||
Most applications store their settings under the user profile. That is, the settings stored in the file system are under the %**UserProfile**% directory, and the settings stored in the registry are under the **HKEY\_CURRENT\_USER** hive. For these applications you can filter the output of the file and registry monitoring tools to show activity only under these locations. This will considerably reduce the amount of output that you will need to examine.
|
||||
|
||||
|
||||
|
||||
|
||||
4. Start the monitoring tool(s), change a setting, and look for registry and file system writes that occurred when you changed the setting. Make sure the changes you make actually take effect. For example, if you are changing a setting in Microsoft Word by selecting a check box in the **Options** dialog box, the change typically will not take effect until you close the dialog box by clicking **OK**.
|
||||
|
||||
@ -86,7 +86,7 @@ Next, you should go through the user interface and make a list of all of the ava
|
||||
**Note**
|
||||
Changing an application setting invariably leads to writing to registry keys. If possible, filter the output of the file and registry monitor tool to display only writes to files and registry keys/values.
|
||||
|
||||
|
||||
|
||||
|
||||
## <a href="" id="bkmk-step3"></a>Step 3: Identify how to apply the gathered settings.
|
||||
|
||||
@ -119,12 +119,12 @@ After you have completed steps 1 through 3, you will need to create a custom mig
|
||||
**Note**
|
||||
We recommend that you create a separate .xml file instead of adding your script to the **MigApp.xml** file. This is because the **MigApp.xml** file is a very large file and it will be difficult to read and edit. In addition, if you reinstall USMT for some reason, the **MigApp.xml** file will be overwritten by the default version of the file and you will lose your customized version.
|
||||
|
||||
|
||||
|
||||
|
||||
**Important**
|
||||
Some applications store information in the user profile that should not be migrated (for example, application installation paths, the computer name, and so on). You should make sure to exclude these files and registry keys from the migration.
|
||||
|
||||
|
||||
|
||||
|
||||
Your script should do the following:
|
||||
|
||||
@ -162,9 +162,9 @@ To speed up the time it takes to collect and migrate the data, you can migrate o
|
||||
|
||||
[Log Files](usmt-log-files.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -60,7 +60,7 @@ If there is not enough local disk space, or if you are moving the user state to
|
||||
**Important**
|
||||
If possible, have users store their data within their %UserProfile%\\My Documents and %UserProfile%\\Application Data folders. This will reduce the chance of USMT missing critical user data that is located in a directory that USMT is not configured to check.
|
||||
|
||||
|
||||
|
||||
|
||||
### <a href="" id="bkmk-localonly"></a>The /localonly Command-Line Option
|
||||
|
||||
@ -71,9 +71,9 @@ You should use this option to exclude the data from removable drives and network
|
||||
|
||||
[Plan Your Migration](usmt-plan-your-migration.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -92,12 +92,12 @@ The following table defines the supported combination of online and offline oper
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
**Note**
|
||||
It is possible to run the ScanState tool while the drive remains encrypted by suspending Windows BitLocker Drive Encryption before booting into WinPE. For more information, see [this Microsoft site](https://go.microsoft.com/fwlink/p/?LinkId=190314).
|
||||
|
||||
|
||||
|
||||
|
||||
## <a href="" id="bkmk-usergroupmembership"></a>User-Group Membership and Profile Control
|
||||
|
||||
@ -159,7 +159,7 @@ An offline migration can either be enabled by using a configuration file on the
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
You can use only one of the **/offline**,**/offlineWinDir** , or **/OfflineWinOld** command-line options at a time; USMT does not support using more than one together.
|
||||
|
||||
@ -197,7 +197,7 @@ The following system environment variables are necessary in the scenarios outlin
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
## <a href="" id="bkmk-offlinexml"></a>Offline.xml Elements
|
||||
|
||||
@ -258,9 +258,9 @@ The following XML example illustrates some of the elements discussed earlier in
|
||||
|
||||
[Plan Your Migration](usmt-plan-your-migration.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -55,7 +55,7 @@ The Config.xml file is the configuration file created by the `/genconfig` option
|
||||
**Note**
|
||||
When modifying the XML elements in the Config.xml file, you should edit an element and set the **migrate** property to **no**, rather than deleting the element from the file. If you delete the element instead of setting the property, the component may still be migrated by rules in other XML files.
|
||||
|
||||
|
||||
|
||||
|
||||
## <a href="" id="bkmk-migapp"></a>Overview of the MigApp.xml file
|
||||
|
||||
@ -65,7 +65,7 @@ The MigApp.xml file installed with USMT includes instructions to migrate the set
|
||||
**Important**
|
||||
The MigApps.xml file will only detect and migrate .pst files that are linked to Microsoft Office Outlook. See the [Sample migration rules for customized versions of XML files](#bkmk-samples) section of this document for more information about migrating .pst files that are not linked to Outlook.
|
||||
|
||||
|
||||
|
||||
|
||||
## <a href="" id="bkmk-migdocs"></a>Overview of the MigDocs.xml file
|
||||
|
||||
@ -182,7 +182,7 @@ You can make a copy of the MigUser.xml file and modify it to include or exclude
|
||||
**Note**
|
||||
Each file name extension you include in the rules within the MigUser.xml file increases the amount of time needed for the ScanState tool to gather the files for the migration. If you are migrating more than three hundred file types, you may experience a slow migration. For more information about other ways to organize the migration of your data, see the [Using multiple XML files](#bkmk-multiple) section of this document.
|
||||
|
||||
|
||||
|
||||
|
||||
## <a href="" id="bkmk-multiple"></a>Using multiple XML files
|
||||
|
||||
@ -204,7 +204,7 @@ You can use multiple XML files with the ScanState and LoadState tools. Each of t
|
||||
<tr class="odd">
|
||||
<td align="left"><p>Config.xml file</p></td>
|
||||
<td align="left"><p>Operating-system components such as desktop wallpaper and background theme.</p>
|
||||
<p>You can also overload config.xml to include some application and document settings by generating the config.xml file with the other default XML files. For more information, see [Customize USMT XML Files](usmt-customize-xml-files.md) and [Config.xml File](usmt-configxml-file.md).</p></td>
|
||||
<p>You can also overload config.xml to include some application and document settings by generating the config.xml file with the other default XML files. For more information, see <a href="usmt-customize-xml-files.md" data-raw-source="[Customize USMT XML Files](usmt-customize-xml-files.md)">Customize USMT XML Files</a> and <a href="usmt-configxml-file.md" data-raw-source="[Config.xml File](usmt-configxml-file.md)">Config.xml File</a>.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>MigApps.xml file</p></td>
|
||||
@ -221,7 +221,7 @@ You can use multiple XML files with the ScanState and LoadState tools. Each of t
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
For example, you can use all of the XML migration file types for a single migration, as in the following example:
|
||||
|
||||
@ -234,7 +234,7 @@ Scanstate <store> /config:c:\myFolder\config.xml /i:migapps.xml /i:migdocs.xml /
|
||||
**Important**
|
||||
You should not use the MigUser.xml and MigDocs.xml files together in the same command. Using both XML files can result in duplication of some migrated files. This occurs when conflicting target-location instructions are given in each XML file. The target file will be stored once during the migration, but will be applied by each XML file to a different location on the destination computer.
|
||||
|
||||
|
||||
|
||||
|
||||
If your data set is unknown or if many files are stored outside of the standard user-profile folders, the MigDocs.xml is a better choice than the MigUser.xml file, because the MigDocs.xml file will gather a broader scope of data. The MigDocs.xml file migrates folders of data based on location. The MigUser.xml file migrates only the files with the specified file name extensions.
|
||||
|
||||
@ -248,7 +248,7 @@ You can use the **/genmigxml** command-line option to determine which files will
|
||||
**Note**
|
||||
If you reinstall USMT, the default migration XML files will be overwritten and any customizations you make directly to these files will be lost. Consider creating separate XML files for your custom migration rules and saving them in a secure location.
|
||||
|
||||
|
||||
|
||||
|
||||
To generate the XML migration rules file for a source computer:
|
||||
|
||||
@ -292,7 +292,7 @@ The MigDocs.xml file calls the **GenerateDocPatterns** function, which takes thr
|
||||
<td align="left"><p>ScanProgramFiles</p></td>
|
||||
<td align="left"><p>The <em>ScanProgramFiles</em> argument is valid only when the <strong>GenerateDocPatterns</strong> function is called in a system context. This argument determines whether or not to scan the Program Files directory to gather registered file name extensions for known applications.</p>
|
||||
<p>For example, when set to <strong>TRUE</strong>, the function discovers and migrates .doc files under the Microsoft Office directory, because .doc is a file name extension registered to a Microsoft Office application. The <strong>GenerateDocPatterns</strong> function generates this inclusion pattern for .doc files:</p>
|
||||
<pre class="syntax" space="preserve"><code><pattern type="File">C:\Program Files\Microsoft Office\*[*.doc]</pattern></code></pre>
|
||||
<pre class="syntax" space="preserve"><code><pattern type="File">C:\Program Files\Microsoft Office<em>[</em>.doc]</pattern></code></pre>
|
||||
<p>If a child folder of an included folder contains an installed application, ScanProgramFiles will also create an exclusion rule for the child folder. All folders under the application folder will be scanned recursively for registered file name extensions.</p></td>
|
||||
<td align="left"><p>False</p></td>
|
||||
</tr>
|
||||
@ -309,7 +309,7 @@ The MigDocs.xml file calls the **GenerateDocPatterns** function, which takes thr
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
**Usage:**
|
||||
|
||||
@ -321,9 +321,9 @@ To create include data patterns for only the system drive:
|
||||
|
||||
``` syntax
|
||||
<include filter='MigXmlHelper.IgnoreIrrelevantLinks()'>
|
||||
<objectSet>
|
||||
<script>MigXmlHelper.GenerateDocPatterns ("FALSE","TRUE","TRUE")</script>
|
||||
</objectSet>
|
||||
<objectSet>
|
||||
<script>MigXmlHelper.GenerateDocPatterns ("FALSE","TRUE","TRUE")</script>
|
||||
</objectSet>
|
||||
</include>
|
||||
```
|
||||
|
||||
@ -331,9 +331,9 @@ To create an include rule to gather files for registered extensions from the %PR
|
||||
|
||||
``` syntax
|
||||
<include filter='MigXmlHelper.IgnoreIrrelevantLinks()'>
|
||||
<objectSet>
|
||||
<script>MigXmlHelper.GenerateDocPatterns ("TRUE","TRUE","FALSE")</script>
|
||||
</objectSet>
|
||||
<objectSet>
|
||||
<script>MigXmlHelper.GenerateDocPatterns ("TRUE","TRUE","FALSE")</script>
|
||||
</objectSet>
|
||||
</include>
|
||||
```
|
||||
|
||||
@ -341,9 +341,9 @@ To create exclude data patterns:
|
||||
|
||||
``` syntax
|
||||
<exclude filter='MigXmlHelper.IgnoreIrrelevantLinks()'>
|
||||
<objectSet>
|
||||
<script>MigXmlHelper.GenerateDocPatterns ("FALSE","FALSE","FALSE")</script>
|
||||
</objectSet>
|
||||
<objectSet>
|
||||
<script>MigXmlHelper.GenerateDocPatterns ("FALSE","FALSE","FALSE")</script>
|
||||
</objectSet>
|
||||
</exclude>
|
||||
```
|
||||
|
||||
@ -402,14 +402,14 @@ The user context includes rules for data in the User Profiles directory. When ca
|
||||
**Note**
|
||||
Rules contained in a component that is assigned the user context will be run for each user profile on the computer. Files that are scanned multiple times by the MigDocs.xml files will only be copied to the migration store once; however, a large number of rules in the user context can slow down the migration. Use the system context when it is applicable.
|
||||
|
||||
|
||||
|
||||
|
||||
### <a href="" id="bkmk-samples"></a>Sample migration rules for customized versions of XML files
|
||||
|
||||
**Note**
|
||||
For best practices and requirements for customized XML files in USMT, see [Customize USMT XML Files](usmt-customize-xml-files.md) and [General Conventions](usmt-general-conventions.md).
|
||||
|
||||
|
||||
|
||||
|
||||
### <a href="" id="bkmk-exclude"></a>Exclude rules usage examples
|
||||
|
||||
@ -423,16 +423,16 @@ In the examples below, the source computer has a .txt file called "new text docu
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>Rule 1</p></td>
|
||||
<td align="left"><pre class="syntax" space="preserve"><code><pattern type="File">d:\new folder\[new text document.txt]</pattern></code></pre></td>
|
||||
<td align="left"><pre class="syntax" space="preserve"><code><pattern type="File">d:\new folder[new text document.txt]</pattern></code></pre></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>Rule 2</p></td>
|
||||
<td align="left"><pre class="syntax" space="preserve"><code><pattern type="File">d:\new folder\*[*]</pattern></code></pre></td>
|
||||
<td align="left"><pre class="syntax" space="preserve"><code><pattern type="File">d:\new folder<em>[</em>]</pattern></code></pre></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
To exclude the new text document.txt file as well as any .txt files in “new folder”, you can do the following:
|
||||
|
||||
@ -442,10 +442,10 @@ To exclude Rule 1, there needs to be an exact match of the file name. However, f
|
||||
|
||||
``` syntax
|
||||
<exclude>
|
||||
<objectSet>
|
||||
<pattern type="File">D:\Newfolder\[new text document.txt]</pattern>
|
||||
<pattern type="File">D:\New folder\*[*.txt]</pattern>
|
||||
</objectSet>
|
||||
<objectSet>
|
||||
<pattern type="File">D:\Newfolder\[new text document.txt]</pattern>
|
||||
<pattern type="File">D:\New folder\*[*.txt]</pattern>
|
||||
</objectSet>
|
||||
</exclude>
|
||||
```
|
||||
|
||||
@ -455,9 +455,9 @@ If you do not know the file name or location of the file, but you do know the fi
|
||||
|
||||
``` syntax
|
||||
<unconditionalExclude>
|
||||
<objectSet>
|
||||
<script>MigXmlHelper.GenerateDrivePatterns ("*[*.txt]", "Fixed")</script>
|
||||
</objectSet>
|
||||
<objectSet>
|
||||
<script>MigXmlHelper.GenerateDrivePatterns ("*[*.txt]", "Fixed")</script>
|
||||
</objectSet>
|
||||
</unconditionalExclude>
|
||||
```
|
||||
|
||||
@ -467,16 +467,16 @@ If you want the <UnconditionalExclude> element to apply to both the system
|
||||
|
||||
``` syntax
|
||||
<component type="Documents" context="UserandSystem">
|
||||
<displayName>MigDocExcludes</displayName>
|
||||
<role role="Data">
|
||||
<rules>
|
||||
<unconditionalExclude>
|
||||
<objectSet>
|
||||
<script>MigXmlHelper.GenerateDrivePatterns ("*[*.txt]", "Fixed")</script>
|
||||
</objectSet>
|
||||
</unconditionalExclude>
|
||||
</rules>
|
||||
</role>
|
||||
<displayName>MigDocExcludes</displayName>
|
||||
<role role="Data">
|
||||
<rules>
|
||||
<unconditionalExclude>
|
||||
<objectSet>
|
||||
<script>MigXmlHelper.GenerateDrivePatterns ("*[*.txt]", "Fixed")</script>
|
||||
</objectSet>
|
||||
</unconditionalExclude>
|
||||
</rules>
|
||||
</role>
|
||||
</component>
|
||||
```
|
||||
|
||||
@ -492,9 +492,9 @@ This rule will include .pst files that are located in the default location, but
|
||||
|
||||
``` syntax
|
||||
<include filter='MigXmlHelper.IgnoreIrrelevantLinks()'>
|
||||
<objectSet>
|
||||
<pattern type="File">%CSIDL_LOCAL_APPDATA%\Microsoft\Outlook\*[*.pst]</pattern>
|
||||
</objectSet>
|
||||
<objectSet>
|
||||
<pattern type="File">%CSIDL_LOCAL_APPDATA%\Microsoft\Outlook\*[*.pst]</pattern>
|
||||
</objectSet>
|
||||
</include>
|
||||
```
|
||||
|
||||
@ -504,9 +504,9 @@ For locations outside the user profile, such as the Program Files folder, you ca
|
||||
|
||||
``` syntax
|
||||
<include filter='MigXmlHelper.IgnoreIrrelevantLinks()'>
|
||||
<objectSet>
|
||||
<pattern type="File">%CSIDL_PROGRAM_FILES%\*[*.pst]</pattern>
|
||||
</objectSet>
|
||||
<objectSet>
|
||||
<pattern type="File">%CSIDL_PROGRAM_FILES%\*[*.pst]</pattern>
|
||||
</objectSet>
|
||||
</include>
|
||||
```
|
||||
|
||||
@ -515,7 +515,7 @@ For more examples of include rules that you can use in custom migration XML file
|
||||
**Note**
|
||||
For more information about the order of precedence for XML migration rules, see [Conflicts and Precedence](usmt-conflicts-and-precedence.md).
|
||||
|
||||
|
||||
|
||||
|
||||
## <a href="" id="bkmk-next"></a>Next steps
|
||||
|
||||
@ -531,9 +531,9 @@ You can use an XML schema (MigXML.xsd) file to validate the syntax of your custo
|
||||
|
||||
[Include Files and Settings](usmt-include-files-and-settings.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -65,7 +65,7 @@ As the authorized administrator, it is your responsibility to protect the privac
|
||||
**Important**
|
||||
If you migrate an encrypted file without also migrating the certificate, end users will not be able to access the file after the migration.
|
||||
|
||||
|
||||
|
||||
|
||||
- **Encrypt the store**
|
||||
|
||||
@ -124,7 +124,7 @@ As the authorized administrator, it is your responsibility to protect the privac
|
||||
**Note**
|
||||
The number of times a rule is processed does not affect the number of times a file is migrated. The USMT migration engine ensures that each file migrates only once.
|
||||
|
||||
|
||||
|
||||
|
||||
- **We recommend that you create a separate .xml file instead of adding your .xml code to one of the existing migration .xml files**
|
||||
|
||||
@ -139,7 +139,7 @@ As the authorized administrator, it is your responsibility to protect the privac
|
||||
**Note**
|
||||
The question mark is not valid as a wildcard character in USMT .xml files.
|
||||
|
||||
|
||||
|
||||
|
||||
## Related topics
|
||||
|
||||
@ -148,9 +148,9 @@ As the authorized administrator, it is your responsibility to protect the privac
|
||||
|
||||
[Plan Your Migration](usmt-plan-your-migration.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -28,25 +28,25 @@ One of the main considerations for planning your migration is to determine which
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[Migration Store Types Overview](migration-store-types-overview.md)</p></td>
|
||||
<td align="left"><p><a href="migration-store-types-overview.md" data-raw-source="[Migration Store Types Overview](migration-store-types-overview.md)">Migration Store Types Overview</a></p></td>
|
||||
<td align="left"><p>Choose the migration store type that works best for your needs and migration scenario.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>[Estimate Migration Store Size](usmt-estimate-migration-store-size.md)</p></td>
|
||||
<td align="left"><p>Estimate the amount of disk space needed for computers in your organization based on information about your organization's infrastructure.</p></td>
|
||||
<td align="left"><p><a href="usmt-estimate-migration-store-size.md" data-raw-source="[Estimate Migration Store Size](usmt-estimate-migration-store-size.md)">Estimate Migration Store Size</a></p></td>
|
||||
<td align="left"><p>Estimate the amount of disk space needed for computers in your organization based on information about your organization's infrastructure.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[Hard-Link Migration Store](usmt-hard-link-migration-store.md)</p></td>
|
||||
<td align="left"><p><a href="usmt-hard-link-migration-store.md" data-raw-source="[Hard-Link Migration Store](usmt-hard-link-migration-store.md)">Hard-Link Migration Store</a></p></td>
|
||||
<td align="left"><p>Learn about hard-link migration stores and the scenarios in which they are used.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>[Migration Store Encryption](usmt-migration-store-encryption.md)</p></td>
|
||||
<td align="left"><p><a href="usmt-migration-store-encryption.md" data-raw-source="[Migration Store Encryption](usmt-migration-store-encryption.md)">Migration Store Encryption</a></p></td>
|
||||
<td align="left"><p>Learn about the using migration store encryption to protect user data integrity during a migration.</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
## Related topics
|
||||
|
||||
@ -55,9 +55,9 @@ One of the main considerations for planning your migration is to determine which
|
||||
|
||||
[User State Migration Tool (USMT) How-to topics](usmt-how-to.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -28,25 +28,25 @@ The User State Migration Tool (USMT) 10.0 migrates user files and settings duri
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[ScanState Syntax](usmt-scanstate-syntax.md)</p></td>
|
||||
<td align="left"><p><a href="usmt-scanstate-syntax.md" data-raw-source="[ScanState Syntax](usmt-scanstate-syntax.md)">ScanState Syntax</a></p></td>
|
||||
<td align="left"><p>Lists the command-line options for using the ScanState tool.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>[LoadState Syntax](usmt-loadstate-syntax.md)</p></td>
|
||||
<td align="left"><p><a href="usmt-loadstate-syntax.md" data-raw-source="[LoadState Syntax](usmt-loadstate-syntax.md)">LoadState Syntax</a></p></td>
|
||||
<td align="left"><p>Lists the command-line options for using the LoadState tool.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[UsmtUtils Syntax](usmt-utilities.md)</p></td>
|
||||
<td align="left"><p><a href="usmt-utilities.md" data-raw-source="[UsmtUtils Syntax](usmt-utilities.md)">UsmtUtils Syntax</a></p></td>
|
||||
<td align="left"><p>Lists the command-line options for using the UsmtUtils tool.</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -40,31 +40,31 @@ 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.
|
||||
In most cases, the ScanState and LoadState logs indicate why a USMT migration is failing. We recommend that you use the **/v**<em>:5</em> option when testing your migration. This verbosity level can be adjusted in a production migration; however, reducing the verbosity level might make it more difficult to diagnose failures that are encountered during production migrations. You can use a verbosity level higher than 5 if you want the log files output to go to a debugger.
|
||||
|
||||
**Note**
|
||||
Running the ScanState and LoadState tools with the **/v***:5* option creates a detailed log file. Although this option makes the log file large, the extra detail can help you determine where migration errors occurred.
|
||||
**Note**
|
||||
Running the ScanState and LoadState tools with the **/v**<em>:5</em> option creates a detailed log file. Although this option makes the log file large, the extra detail can help you determine where migration errors occurred.
|
||||
|
||||
|
||||
|
||||
|
||||
- Use the **/Verify** option in the UsmtUtils tool to determine whether any files in a compressed migration store are corrupted. For more information, see [Verify the Condition of a Compressed Migration Store](verify-the-condition-of-a-compressed-migration-store.md).
|
||||
- Use the **/Verify** option in the UsmtUtils tool to determine whether any files in a compressed migration store are corrupted. For more information, see [Verify the Condition of a Compressed Migration Store](verify-the-condition-of-a-compressed-migration-store.md).
|
||||
|
||||
- Use the **/Extract** option in the UsmtUtils tool to extract files from a compressed migration store. For more information, see [Extract Files from a Compressed USMT Migration Store](usmt-extract-files-from-a-compressed-migration-store.md).
|
||||
- Use the **/Extract** option in the UsmtUtils tool to extract files from a compressed migration store. For more information, see [Extract Files from a Compressed USMT Migration Store](usmt-extract-files-from-a-compressed-migration-store.md).
|
||||
|
||||
- Create a progress log using the **/Progress** option to monitor your migration.
|
||||
- Create a progress log using the **/Progress** option to monitor your migration.
|
||||
|
||||
- For the source and destination computers, obtain operating system information, and versions of applications such as Internet Explorer and any other relevant programs. Then verify the exact steps that are needed to reproduce the problem. This information might help you to understand what is wrong and to reproduce the issue in your testing environment.
|
||||
- For the source and destination computers, obtain operating system information, and versions of applications such as Internet Explorer and any other relevant programs. Then verify the exact steps that are needed to reproduce the problem. This information might help you to understand what is wrong and to reproduce the issue in your testing environment.
|
||||
|
||||
- Log off after you run the LoadState tool. Some settings—for example, fonts, desktop backgrounds, and screen-saver settings—will not take effect until the next time the end user logs on.
|
||||
- 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.
|
||||
**Note**
|
||||
USMT will fail if it cannot migrate a file or setting unless you specify the **/c** option. When you specify the **/c** option, USMT ignores errors. However, it logs an error when it encounters a file that is in use that did not migrate.
|
||||
|
||||
|
||||
|
||||
|
||||
## <a href="" id="user"></a>User Account Problems
|
||||
|
||||
@ -330,9 +330,9 @@ You should also reboot the machine.
|
||||
|
||||
[UsmtUtils Syntax](usmt-utilities.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -30,7 +30,7 @@ For more information about using the Config.xml file with other migration files,
|
||||
**Note**
|
||||
To exclude a component from the Config.xml file, set the **migrate** value to **"no"**. Deleting the XML tag for the component from the Config.xml file will not exclude the component from your migration.
|
||||
|
||||
|
||||
|
||||
|
||||
## In This Topic
|
||||
|
||||
@ -110,7 +110,7 @@ Additionally, the order in the **<ErrorControl>** section implies priority
|
||||
**Important**
|
||||
The configurable **<ErrorControl>** rules support only the environment variables for the operating system that is running and the currently logged-on user. As a workaround, you can specify a path using the (\*) wildcard character.
|
||||
|
||||
|
||||
|
||||
|
||||
### <a href="" id="bkmk-fatal"></a><fatal>
|
||||
|
||||
@ -146,7 +146,7 @@ Syntax: `<fatal errorCode="any">`*<pattern>*`</fatal>`
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
You use the **<fatal>** element to specify that errors matching a specific pattern should cause USMT to halt the migration.
|
||||
|
||||
@ -200,14 +200,14 @@ Syntax: `<nonfatal errorCode="any">`*<pattern>*`</nonFatal>`
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
You use the **<nonFatal>** element to specify that errors matching a specific pattern should not cause USMT to halt the migration.
|
||||
|
||||
## <a href="" id="bkmk-registryerror"></a><registryError>
|
||||
|
||||
|
||||
The **<registryError>**element is not required.
|
||||
The <strong><registryError></strong>element is not required.
|
||||
|
||||
- **Number of occurrences**: Once for each component
|
||||
|
||||
@ -239,7 +239,7 @@ Syntax: `<registryError></registryError>`
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
You use the **<registryError>** element to specify that errors matching a specific pattern should not cause USMT to halt the migration.
|
||||
|
||||
@ -263,7 +263,7 @@ The **<HardLinkStoreControl>** sample code below specifies that hard links
|
||||
**Important**
|
||||
The **<ErrorControl>** section can be configured to conditionally ignore file access errors, based on the file’s location.
|
||||
|
||||
|
||||
|
||||
|
||||
``` syntax
|
||||
<Policy>
|
||||
@ -358,7 +358,7 @@ This element describes the source and destination groups for a local group membe
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
The valid and required children of **<changeGroup>** are **<include>** and **<exclude>**. Although both can be children at the same time, only one is required.
|
||||
|
||||
@ -579,9 +579,9 @@ Refer to the following sample Config.xml file for additional details about items
|
||||
|
||||
[USMT XML Reference](usmt-xml-reference.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -174,40 +174,40 @@ These examples explain how USMT deals with <include> and <exclude> r
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><ul>
|
||||
<li><p>Include rule: <pattern type="File">C:\Dir1\* [*]</pattern></p></li>
|
||||
<li><p>Exclude rule: <pattern type="File">C:\* [*.txt]</pattern></p></li>
|
||||
<li><p>Include rule: <pattern type="File">C:\Dir1* [<em>]</pattern></p></li>
|
||||
<li><p>Exclude rule: <pattern type="File">C:* [</em>.txt]</pattern></p></li>
|
||||
</ul></td>
|
||||
<td align="left"><p>Migrates all files and subfolders in Dir1 (including all .txt files in C:).</p></td>
|
||||
<td align="left"><p>The <exclude> rule does not affect the migration because the <include> rule is more specific.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><ul>
|
||||
<li><p>Include rule: <pattern type="File">C:\Dir1\* [*]</pattern></p></li>
|
||||
<li><p>Exclude rule: <pattern type="File">C:\Dir1\Dir2\* [*.txt]</pattern></p></li>
|
||||
<li><p>Include rule: <pattern type="File">C:\Dir1* [<em>]</pattern></p></li>
|
||||
<li><p>Exclude rule: <pattern type="File">C:\Dir1\Dir2* [</em>.txt]</pattern></p></li>
|
||||
</ul></td>
|
||||
<td align="left"><p>Migrates all files and subfolders in C:\Dir1, except the .txt files in C:\Dir1\Dir2 and its subfolders.</p></td>
|
||||
<td align="left"><p>Both rules are processed as intended.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><ul>
|
||||
<li><p>Include rule: <pattern type="File">C:\Dir1\* [*]</pattern></p></li>
|
||||
<li><p>Exclude rule: <pattern type="File">C:\Dir1\ * [*.txt]</pattern></p></li>
|
||||
<li><p>Include rule: <pattern type="File">C:\Dir1* [<em>]</pattern></p></li>
|
||||
<li><p>Exclude rule: <pattern type="File">C:\Dir1\ * [</em>.txt]</pattern></p></li>
|
||||
</ul></td>
|
||||
<td align="left"><p>Migrates all files and subfolders in C:\Dir1, except the .txt files in C:\Dir1 and its subfolders.</p></td>
|
||||
<td align="left"><p>Both rules are processed as intended.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><ul>
|
||||
<li><p>Include rule: <pattern type="File">C:\Dir1\Dir2\* [*.txt]</pattern></p></li>
|
||||
<li><p>Exclude rule: <pattern type="File">C:\Dir1\Dir2\* [*.txt]</pattern></p></li>
|
||||
<li><p>Include rule: <pattern type="File">C:\Dir1\Dir2* [<em>.txt]</pattern></p></li>
|
||||
<li><p>Exclude rule: <pattern type="File">C:\Dir1\Dir2* [</em>.txt]</pattern></p></li>
|
||||
</ul></td>
|
||||
<td align="left"><p>Nothing will be migrated.</p></td>
|
||||
<td align="left"><p>The rules are equally specific, so the <exclude> rule takes precedence over the <include> rule.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><ul>
|
||||
<li><p>Include rule: C:\Dir1\* [*.txt]</p></li>
|
||||
<li><p>Exclude rule: C:\Dir1\Dir2\* [*]</p></li>
|
||||
<li><p>Include rule: C:\Dir1* [<em>.txt]</p></li>
|
||||
<li><p>Exclude rule: C:\Dir1\Dir2* [</em>]</p></li>
|
||||
</ul></td>
|
||||
<td align="left"><p>Migrates the .txt files in Dir1 and the .txt files from subfolders other than Dir2.</p>
|
||||
<p>No files are migrated from Dir2 or its subfolders.</p></td>
|
||||
@ -215,8 +215,8 @@ These examples explain how USMT deals with <include> and <exclude> r
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><ul>
|
||||
<li><p>Include rule: C:\Dir1\Dir2\* [*]</p></li>
|
||||
<li><p>Exclude rule: C:\Dir1\* [*.txt]</p></li>
|
||||
<li><p>Include rule: C:\Dir1\Dir2* [<em>]</p></li>
|
||||
<li><p>Exclude rule: C:\Dir1* [</em>.txt]</p></li>
|
||||
</ul></td>
|
||||
<td align="left"><p>Migrates all files and subfolders of Dir2, except the .txt files from Dir1 and any subfolders of Dir1 (including Dir2).</p></td>
|
||||
<td align="left"><p>Both rules are processed as intended.</p></td>
|
||||
@ -224,7 +224,7 @@ These examples explain how USMT deals with <include> and <exclude> r
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
@ -243,13 +243,13 @@ These examples explain how USMT deals with <include> and <exclude> r
|
||||
<tr class="odd">
|
||||
<td align="left"><p>Component 1:</p>
|
||||
<ul>
|
||||
<li><p>Include rule: <pattern type="File">C:\Dir1\* [*]</pattern></p></li>
|
||||
<li><p>Exclude rule: <pattern type="File">C:\Dir1\Dir2\* [*.txt]</pattern></p></li>
|
||||
<li><p>Include rule: <pattern type="File">C:\Dir1* [<em>]</pattern></p></li>
|
||||
<li><p>Exclude rule: <pattern type="File">C:\Dir1\Dir2* [</em>.txt]</pattern></p></li>
|
||||
</ul>
|
||||
<p>Component 2:</p>
|
||||
<ul>
|
||||
<li><p>Include rule: <pattern type="File">C:\Dir1\Dir2\* [*.txt]</pattern></p></li>
|
||||
<li><p>Exclude rule: <pattern type="File">C:\Dir1\* [*]</pattern></p></li>
|
||||
<li><p>Include rule: <pattern type="File">C:\Dir1\Dir2* [<em>.txt]</pattern></p></li>
|
||||
<li><p>Exclude rule: <pattern type="File">C:\Dir1* [</em>]</pattern></p></li>
|
||||
</ul></td>
|
||||
<td align="left"><p>Migrates all files and subfolders of C:\Dir1\ (including C:\Dir1\Dir2).</p></td>
|
||||
<td align="left"><p>Rules that are in different components do not affect each other, except for the <unconditionalExclude> rule. Therefore, in this example, although some .txt files were excluded when Component 1 was processed, they were included when Component 2 was processed.</p></td>
|
||||
@ -257,11 +257,11 @@ These examples explain how USMT deals with <include> and <exclude> r
|
||||
<tr class="even">
|
||||
<td align="left"><p>Component 1:</p>
|
||||
<ul>
|
||||
<li><p>Include rule: C:\Dir1\Dir2\* [*]</p></li>
|
||||
<li><p>Include rule: C:\Dir1\Dir2* [<em>]</p></li>
|
||||
</ul>
|
||||
<p>Component 2:</p>
|
||||
<ul>
|
||||
<li><p>Exclude rule: C:\Dir1\* [*.txt]</p></li>
|
||||
<li><p>Exclude rule: C:\Dir1* [</em>.txt]</p></li>
|
||||
</ul></td>
|
||||
<td align="left"><p>Migrates all files and subfolders from Dir2 except the .txt files in C:\Dir1 and its subfolders.</p></td>
|
||||
<td align="left"><p>Both rules are processed as intended.</p></td>
|
||||
@ -269,11 +269,11 @@ These examples explain how USMT deals with <include> and <exclude> r
|
||||
<tr class="odd">
|
||||
<td align="left"><p>Component 1:</p>
|
||||
<ul>
|
||||
<li><p>Exclude rule: C:\Dir1\Dir2\* [*]</p></li>
|
||||
<li><p>Exclude rule: C:\Dir1\Dir2* [<em>]</p></li>
|
||||
</ul>
|
||||
<p>Component 2:</p>
|
||||
<ul>
|
||||
<li><p>Include rule: C:\Dir1\* [*.txt]</p></li>
|
||||
<li><p>Include rule: C:\Dir1* [</em>.txt]</p></li>
|
||||
</ul></td>
|
||||
<td align="left"><p>Migrates all .txt files in Dir1 and any subfolders.</p></td>
|
||||
<td align="left"><p>Component 1 does not contain an <include> rule, so the <exclude> rule is not processed.</p></td>
|
||||
@ -281,7 +281,7 @@ These examples explain how USMT deals with <include> and <exclude> r
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
### <a href="" id="regex"></a>Including and excluding registry objects
|
||||
|
||||
@ -301,7 +301,7 @@ These examples explain how USMT deals with <include> and <exclude> r
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><ul>
|
||||
<li><p>Include rule: HKLM\Software\Microsoft\Command Processor\* [*]</p></li>
|
||||
<li><p>Include rule: HKLM\Software\Microsoft\Command Processor* [<em>]</p></li>
|
||||
<li><p>Exclude Rule: HKLM\Software\Microsoft\Command Processor [DefaultColor]</p></li>
|
||||
</ul></td>
|
||||
<td align="left"><p>Migrates all keys in HKLM\Software\Microsoft\Command Processor except DefaultColor.</p></td>
|
||||
@ -310,7 +310,7 @@ These examples explain how USMT deals with <include> and <exclude> r
|
||||
<tr class="even">
|
||||
<td align="left"><ul>
|
||||
<li><p>Include rule: HKLM\Software\Microsoft\Command Processor [DefaultColor]</p></li>
|
||||
<li><p>Exclude Rule: HKLM\Software\Microsoft\Command Processor\* [*]</p></li>
|
||||
<li><p>Exclude Rule: HKLM\Software\Microsoft\Command Processor* [</em>]</p></li>
|
||||
</ul></td>
|
||||
<td align="left"><p>Migrates only DefaultColor in HKLM\Software\Microsoft\Command Processor.</p></td>
|
||||
<td align="left"><p>DefaultColor is migrated because the <include> rule is more specific than the <exclude> rule.</p></td>
|
||||
@ -326,7 +326,7 @@ These examples explain how USMT deals with <include> and <exclude> r
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
@ -346,11 +346,11 @@ These examples explain how USMT deals with <include> and <exclude> r
|
||||
<td align="left"><p>Component 1:</p>
|
||||
<ul>
|
||||
<li><p>Include rule: HKLM\Software\Microsoft\Command Processor [DefaultColor]</p></li>
|
||||
<li><p>Exclude rule: HKLM\Software\Microsoft\Command Processor\* [*]</p></li>
|
||||
<li><p>Exclude rule: HKLM\Software\Microsoft\Command Processor* [<em>]</p></li>
|
||||
</ul>
|
||||
<p>Component 2:</p>
|
||||
<ul>
|
||||
<li><p>Include rule: HKLM\Software\Microsoft\Command Processor\* [*]</p></li>
|
||||
<li><p>Include rule: HKLM\Software\Microsoft\Command Processor* [</em>]</p></li>
|
||||
<li><p>Exclude rule: HKLM\Software\Microsoft\Command Processor [DefaultColor]</p></li>
|
||||
</ul></td>
|
||||
<td align="left"><p>Migrates all the keys/values under HKLM\Software\Microsoft\Command Processor.</p></td>
|
||||
@ -359,7 +359,7 @@ These examples explain how USMT deals with <include> and <exclude> r
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
## File collisions
|
||||
|
||||
@ -415,7 +415,7 @@ For this example, the following table describes the resulting behavior if you ad
|
||||
<tr class="odd">
|
||||
<td align="left"><pre class="syntax" space="preserve"><code><merge script="MigXmlHelper.DestinationPriority()">
|
||||
<objectSet>
|
||||
<pattern type="File">c:\data\* [*]</pattern>
|
||||
<pattern type="File">c:\data* [<em>]</pattern>
|
||||
</objectSet>
|
||||
</merge></code></pre></td>
|
||||
<td align="left"><p>During ScanState, all the files will be added to the store.</p>
|
||||
@ -424,7 +424,7 @@ For this example, the following table describes the resulting behavior if you ad
|
||||
<tr class="even">
|
||||
<td align="left"><pre class="syntax" space="preserve"><code><merge script="MigXmlHelper.SourcePriority()">
|
||||
<objectSet>
|
||||
<pattern type="File">c:\data\* [*]</pattern>
|
||||
<pattern type="File">c:\data* [</em>]</pattern>
|
||||
</objectSet>
|
||||
</merge> </code></pre></td>
|
||||
<td align="left"><p>During ScanState, all the files will be added to the store.</p>
|
||||
@ -447,16 +447,16 @@ For this example, the following table describes the resulting behavior if you ad
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[USMT XML Reference](usmt-xml-reference.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -19,7 +19,7 @@ ms.topic: article
|
||||
**Note**
|
||||
Because the tables in this topic are wide, you may need to adjust the width of its window.
|
||||
|
||||
|
||||
|
||||
|
||||
## In This Topic:
|
||||
|
||||
@ -127,13 +127,13 @@ The following is a custom .xml file named CustomFile.xml that migrates My Videos
|
||||
<td align="left"><p>Filters out the shortcuts in My Videos that do not resolve on the destination computer. This has no effect on files that are not shortcuts. For example, if there is 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.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><pre class="syntax" space="preserve"><code><pattern type="File">%CSIDL_MYVIDEO%\* [*]</pattern></code></pre></td>
|
||||
<td align="left"><pre class="syntax" space="preserve"><code><pattern type="File">%CSIDL_MYVIDEO%* [*]</pattern></code></pre></td>
|
||||
<td align="left"><p>Migrates My Videos for all users.</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
``` syntax
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
@ -176,25 +176,25 @@ This table describes the behavior in the following example .xml file.
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><pre class="syntax" space="preserve"><code><pattern type="File">%ProgramFiles%\USMTTestFolder\* [USMTTestFile.txt]</pattern></code></pre></td>
|
||||
<td align="left"><pre class="syntax" space="preserve"><code><pattern type="File">%ProgramFiles%\USMTTestFolder* [USMTTestFile.txt]</pattern></code></pre></td>
|
||||
<td align="left"><p>Migrates all instances of the file Usmttestfile.txt from all sub-directories under %ProgramFiles%\USMTTestFolder.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><pre class="syntax" space="preserve"><code><pattern type="File">%ProgramFiles%\USMTDIRTestFolder\* [*]</pattern></code></pre></td>
|
||||
<td align="left"><pre class="syntax" space="preserve"><code><pattern type="File">%ProgramFiles%\USMTDIRTestFolder* [<em>]</pattern></code></pre></td>
|
||||
<td align="left"><p>Migrates the whole directory under %ProgramFiles%\USMTDIRTestFolder.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><pre class="syntax" space="preserve"><code><pattern type="Registry">HKCU\Software\USMTTESTKEY\* [MyKey]</pattern></code></pre></td>
|
||||
<td align="left"><pre class="syntax" space="preserve"><code><pattern type="Registry">HKCU\Software\USMTTESTKEY* [MyKey]</pattern></code></pre></td>
|
||||
<td align="left"><p>Migrates all instances of MyKey under HKCU\Software\USMTTESTKEY.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><pre class="syntax" space="preserve"><code><pattern type="Registry">HKLM\Software\USMTTESTKEY\* [*]</pattern></code></pre></td>
|
||||
<td align="left"><pre class="syntax" space="preserve"><code><pattern type="Registry">HKLM\Software\USMTTESTKEY* [</em>]</pattern></code></pre></td>
|
||||
<td align="left"><p>Migrates the entire registry hive under HKLM\Software\USMTTESTKEY.</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
``` syntax
|
||||
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/testfilemig">
|
||||
@ -308,9 +308,9 @@ The behavior for this custom .xml file is described within the <`displayName`
|
||||
|
||||
[Customize USMT XML Files](usmt-customize-xml-files.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -56,7 +56,7 @@ This section describes the migration .xml files that are included with USMT. Eac
|
||||
**Note**
|
||||
You can use the asterisk (\*) wildcard character in each of these files. However, you cannot use a question mark (?) as a wildcard character.
|
||||
|
||||
|
||||
|
||||
|
||||
- **The MigApp.xml file.** Specify this file with both the **ScanState** and **LoadState** commands to migrate application settings.
|
||||
|
||||
@ -67,7 +67,7 @@ You can use the asterisk (\*) wildcard character in each of these files. However
|
||||
**Note**
|
||||
Do not use the MigUser.xml and MigDocs.xml files together. For more information, see the [Identify File Types, Files, and Folders](usmt-identify-file-types-files-and-folders.md) and [USMT Best Practices](usmt-best-practices.md) topics.
|
||||
|
||||
|
||||
|
||||
|
||||
## <a href="" id="bkmk-customxmlfiles"></a>Custom .xml Files
|
||||
|
||||
@ -96,7 +96,7 @@ In addition, note the following functionality with the Config.xml file:
|
||||
**Note**
|
||||
To exclude a component from the Config.xml file, set the **migrate** value to **"no"**. Deleting the XML tag for the component from the Config.xml file will not exclude the component from your migration.
|
||||
|
||||
|
||||
|
||||
|
||||
### <a href="" id="bkmk-examples"></a>Examples
|
||||
|
||||
@ -128,9 +128,9 @@ To exclude a component from the Config.xml file, set the **migrate** value to **
|
||||
|
||||
[USMT Resources](usmt-resources.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -32,34 +32,34 @@ To reduce complexity and increase standardization, your organization should cons
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[Identify Users](usmt-identify-users.md)</p></td>
|
||||
<td align="left"><p><a href="usmt-identify-users.md" data-raw-source="[Identify Users](usmt-identify-users.md)">Identify Users</a></p></td>
|
||||
<td align="left"><p>Use command-line options to specify which users to migrate and how they should be migrated.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>[Identify Applications Settings](usmt-identify-application-settings.md)</p></td>
|
||||
<td align="left"><p><a href="usmt-identify-application-settings.md" data-raw-source="[Identify Applications Settings](usmt-identify-application-settings.md)">Identify Applications Settings</a></p></td>
|
||||
<td align="left"><p>Determine which applications you want to migrate and prepare a list of application settings to be migrated.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[Identify Operating System Settings](usmt-identify-operating-system-settings.md)</p></td>
|
||||
<td align="left"><p><a href="usmt-identify-operating-system-settings.md" data-raw-source="[Identify Operating System Settings](usmt-identify-operating-system-settings.md)">Identify Operating System Settings</a></p></td>
|
||||
<td align="left"><p>Use migration to create a new standard environment on each of the destination computers.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>[Identify File Types, Files, and Folders](usmt-identify-file-types-files-and-folders.md)</p></td>
|
||||
<td align="left"><p><a href="usmt-identify-file-types-files-and-folders.md" data-raw-source="[Identify File Types, Files, and Folders](usmt-identify-file-types-files-and-folders.md)">Identify File Types, Files, and Folders</a></p></td>
|
||||
<td align="left"><p>Determine and locate the standard, company-specified, and non-standard locations of the file types, files, folders, and settings that you want to migrate.</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[What Does USMT Migrate?](usmt-what-does-usmt-migrate.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -86,7 +86,7 @@ The ScanState tool also allows you to estimate disk space requirements based on
|
||||
**Note**
|
||||
To preserve the functionality of existing applications or scripts that require the previous behavior of USMT, the **/p** option, without specifying *<path to a file>* is still available in USMT.
|
||||
|
||||
|
||||
|
||||
|
||||
The space requirements report provides two elements, <**storeSize**> and <**temporarySpace**>. The <**temporarySpace**> value shows the disk space, in bytes, that USMT uses to operate during the migration—this does not include the minimum 250 MB needed to support USMT. The <**storeSize**> value shows the disk space, in bytes, required to host the migration store contents on both the source and destination computers. The following example shows a report generated using **/p:***<path to a file>*.
|
||||
|
||||
@ -114,7 +114,7 @@ The amount of space that is required in the store will vary, depending on the lo
|
||||
**Note**
|
||||
You can create a space-estimate file (Usmtsize.txt), by using the legacy **/p** command-line option to estimate the size of the store.
|
||||
|
||||
|
||||
|
||||
|
||||
When trying to determine how much disk space you will need, consider the following issues:
|
||||
|
||||
@ -129,9 +129,9 @@ When trying to determine how much disk space you will need, consider the followi
|
||||
|
||||
[Common Migration Scenarios](usmt-common-migration-scenarios.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -269,9 +269,9 @@ To exclude a component from the Config.xml file, set the **migrate** value to **
|
||||
- [Customize USMT XML Files](usmt-customize-xml-files.md)
|
||||
- [USMT XML Reference](usmt-xml-reference.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -61,44 +61,44 @@ Before you modify the .xml files, become familiar with the following guidelines:
|
||||
|
||||
You can use the XML helper functions in the [XML Elements Library](usmt-xml-elements-library.md) to change migration behavior. Before you use these functions in an .xml file, note the following:
|
||||
|
||||
- **All of the parameters are strings**
|
||||
- **All of the parameters are strings**
|
||||
|
||||
- **You can leave NULL parameters blank**
|
||||
- **You can leave NULL parameters blank**
|
||||
|
||||
As with parameters with a default value convention, if you have a NULL parameter at the end of a list, you can leave it out. For example, the following function:
|
||||
As with parameters with a default value convention, if you have a NULL parameter at the end of a list, you can leave it out. For example, the following function:
|
||||
|
||||
``` syntax
|
||||
SomeFunction("My String argument",NULL,NULL)
|
||||
```
|
||||
``` syntax
|
||||
SomeFunction("My String argument",NULL,NULL)
|
||||
```
|
||||
|
||||
is equivalent to:
|
||||
is equivalent to:
|
||||
|
||||
``` syntax
|
||||
SomeFunction("My String argument")
|
||||
```
|
||||
``` syntax
|
||||
SomeFunction("My String argument")
|
||||
```
|
||||
|
||||
- **The encoded location used in all the helper functions is an unambiguous string representation for the name of an object**
|
||||
- **The encoded location used in all the helper functions is an unambiguous string representation for the name of an object**
|
||||
|
||||
It is composed of the node part, optionally followed by the leaf enclosed in square brackets. This makes a clear distinction between nodes and leaves.
|
||||
It is composed of the node part, optionally followed by the leaf enclosed in square brackets. This makes a clear distinction between nodes and leaves.
|
||||
|
||||
For example, specify the file C:\\Windows\\Notepad.exe: **c:\\Windows\[Notepad.exe\]**. Similarly, specify the directory C:\\Windows\\System32 like this: **c:\\Windows\\System32**; note the absence of the \[\] characters.
|
||||
For example, specify the file C:\\Windows\\Notepad.exe: **c:\\Windows\[Notepad.exe\]**. Similarly, specify the directory C:\\Windows\\System32 like this: **c:\\Windows\\System32**; note the absence of the \[\] characters.
|
||||
|
||||
The registry is represented in a similar way. The default value of a registry key is represented as an empty \[\] construct. For example, the default value for the HKLM\\SOFTWARE\\MyKey registry key is **HKLM\\SOFTWARE\\MyKey\[\]**.
|
||||
The registry is represented in a similar way. The default value of a registry key is represented as an empty \[\] construct. For example, the default value for the HKLM\\SOFTWARE\\MyKey registry key is **HKLM\\SOFTWARE\\MyKey\[\]**.
|
||||
|
||||
- **You specify a location pattern in a way that is similar to how you specify an actual location**
|
||||
- **You specify a location pattern in a way that is similar to how you specify an actual location**
|
||||
|
||||
The exception is that both the node and leaf part accept patterns. However, a pattern from the node does not extend to the leaf.
|
||||
The exception is that both the node and leaf part accept patterns. However, a pattern from the node does not extend to the leaf.
|
||||
|
||||
For example, the pattern **c:\\Windows\\\*** will match the \\Windows directory and all subdirectories, but it will not match any of the files in those directories. To match the files as well, you must specify **c:\\Windows\\\*\[\*\]**.
|
||||
For example, the pattern **c:\\Windows\\\\*** will match the \\Windows directory and all subdirectories, but it will not match any of the files in those directories. To match the files as well, you must specify **c:\\Windows\\\*\[\*\]**.
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[USMT XML Reference](usmt-xml-reference.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -70,7 +70,7 @@ When you create a hard link, you give an existing file an additional path. For i
|
||||
**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, please see [Hard Links and Junctions](https://go.microsoft.com/fwlink/p/?LinkId=132934)
|
||||
|
||||
@ -81,7 +81,7 @@ As a best practice, we recommend that you delete the hard-link migration store a
|
||||
**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 additional disk space being consumed or problems with some applications for the following reasons:
|
||||
|
||||
@ -94,7 +94,7 @@ Keeping the hard-link migration store can result in additional disk space being
|
||||
**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.
|
||||
|
||||
|
||||
|
||||
|
||||
## <a href="" id="bkmk-scenario"></a>Hard-Link Migration Scenario
|
||||
|
||||
@ -106,7 +106,7 @@ For example, a company has decided to deploy Windows 10 on all of their compute
|
||||
**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 7 and other applications the company currently uses.
|
||||
|
||||
@ -162,7 +162,7 @@ Files that are locked by an application are treated the same in hard-link migrat
|
||||
**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.
|
||||
|
||||
|
||||
|
||||
|
||||
## <a href="" id="bkmk-xmlelementsinconfig"></a>XML Elements in the Config.xml File
|
||||
|
||||
@ -200,12 +200,12 @@ A new section in the Config.xml file allows optional configuration of some of th
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
**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 are not located in the \\Users directory should result in the **File in Use** error. It is important to exercise caution when specifying the paths using the **File in Use<createhardlink>** tag in order to minimize scenarios that make the hard-link migration store more difficult to delete.
|
||||
|
||||
@ -225,9 +225,9 @@ The following XML sample specifies that files locked by an application under the
|
||||
|
||||
[Plan Your Migration](usmt-plan-your-migration.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -25,7 +25,7 @@ USMT includes two tools that migrate settings and data: ScanState and LoadState.
|
||||
**Note**
|
||||
For more information about how USMT processes the rules and the XML files, see [Conflicts and Precedence](usmt-conflicts-and-precedence.md).
|
||||
|
||||
|
||||
|
||||
|
||||
## <a href="" id="bkmk-ssprocess"></a>The ScanState Process
|
||||
|
||||
@ -57,7 +57,7 @@ When you run the ScanState tool on the source computer, it goes through the foll
|
||||
**Note**
|
||||
From this point on, ScanState does not distinguish between components that migrate operating-system settings, those that migrate application settings, and those that migrate users’ files. ScanState processes all components in the same way.
|
||||
|
||||
|
||||
|
||||
|
||||
2. Each component that is selected in the previous step is processed further. Any profile-specific variables (such as CSIDL\_PERSONAL) are evaluated in the context of the current profile. For example, if the profile that is being processed belongs to “User1”, then CSIDL\_PERSONAL would expand to C:\\Users\\User1\\Documents, assuming that the user profiles are stored in the C:\\Users directory.
|
||||
|
||||
@ -72,7 +72,7 @@ When you run the ScanState tool on the source computer, it goes through the foll
|
||||
**Note**
|
||||
ScanState ignores some subsections such as <destinationCleanup> and <locationModify>. These sections are evaluated only on the destination computer.
|
||||
|
||||
|
||||
|
||||
|
||||
5. In the "Collecting" phase, ScanState creates a master list of the migration units by combining the lists that were created for each selected user profile.
|
||||
|
||||
@ -81,68 +81,68 @@ When you run the ScanState tool on the source computer, it goes through the foll
|
||||
**Note**
|
||||
ScanState does not modify the source computer in any way.
|
||||
|
||||
|
||||
|
||||
|
||||
## <a href="" id="bkmk-lsprocess"></a>The LoadState Process
|
||||
|
||||
|
||||
The LoadState process is very similar to the ScanState process. The ScanState tool collects migration units such as file, registry key, or registry values from the source computer and saves them to the store. Similarly, the LoadState tool collects migration units from the store and applies them to the destination computer.
|
||||
|
||||
1. ScanState parses and validates the command-line parameters, creates the ScanState.log file, and then begins logging.
|
||||
1. ScanState parses and validates the command-line parameters, creates the ScanState.log file, and then begins logging.
|
||||
|
||||
2. LoadState collects information about the migration components that need to be migrated.
|
||||
2. LoadState collects information about the migration components that need to be migrated.
|
||||
|
||||
LoadState obtains information for the application-settings components and user-data components from the migration .xml files that are specified by the LoadState command.
|
||||
LoadState obtains information for the application-settings components and user-data components from the migration .xml files that are specified by the LoadState command.
|
||||
|
||||
In Windows 7, and Windows 8, the manifest files control how the operating-system settings are migrated. You cannot modify these files. If you want to exclude certain operating-system settings, you must create and modify a Config.xml file.
|
||||
In Windows 7, and Windows 8, the manifest files control how the operating-system settings are migrated. You cannot modify these files. If you want to exclude certain operating-system settings, you must create and modify a Config.xml file.
|
||||
|
||||
3. LoadState determines which user profiles should be migrated. By default, all user profiles present on the source computer are migrated. However, you can include and exclude users using the User Options. The system profile, the "All users" profile in a source computer running Windows XP, or the Public profile in a source computer running Windows Vista, Windows 7, and Windows 8, is always migrated and you cannot exclude these profiles from the migration.
|
||||
3. LoadState determines which user profiles should be migrated. By default, all user profiles present on the source computer are migrated. However, you can include and exclude users using the User Options. The system profile, the "All users" profile in a source computer running Windows XP, or the Public profile in a source computer running Windows Vista, Windows 7, and Windows 8, is always migrated and you cannot exclude these profiles from the migration.
|
||||
|
||||
- If you are migrating local user accounts and if the accounts do not already exist on the destination computer, you must use the**/lac** command-line option. If you do not specify the **/lac** option, any local user accounts that are not already present on the destination computer, are not migrated.
|
||||
- If you are migrating local user accounts and if the accounts do not already exist on the destination computer, you must use the<strong>/lac</strong> command-line option. If you do not specify the **/lac** option, any local user accounts that are not already present on the destination computer, are not migrated.
|
||||
|
||||
- The **/md** and **/mu** options are processed to rename the user profile on the destination computer, if they have been included when the LoadState command was specified.
|
||||
- The **/md** and **/mu** options are processed to rename the user profile on the destination computer, if they have been included when the LoadState command was specified.
|
||||
|
||||
- For each user profile selected from the store, LoadState creates a corresponding user profile on the destination computer. The destination computer does not need to be connected to the domain for domain user profiles to be created. If USMT cannot determine a domain, it attempts to apply the settings to a local account. For more information, see [Identify Users](usmt-identify-users.md).
|
||||
- For each user profile selected from the store, LoadState creates a corresponding user profile on the destination computer. The destination computer does not need to be connected to the domain for domain user profiles to be created. If USMT cannot determine a domain, it attempts to apply the settings to a local account. For more information, see [Identify Users](usmt-identify-users.md).
|
||||
|
||||
4. In the "Scanning" phase, LoadState does the following for each user profile:
|
||||
4. In the "Scanning" phase, LoadState does the following for each user profile:
|
||||
|
||||
1. For each component, LoadState checks the type of the component. If the current user profile is the system profile and the component type is “System” or “UserAndSystem”, the component is selected for this user. Otherwise, the component is ignored. Alternatively, if the current user profile is not the system profile and the component type is “User” or “UserAndSystem”, the component is selected for this user. Otherwise, this component is ignored.
|
||||
1. For each component, LoadState checks the type of the component. If the current user profile is the system profile and the component type is “System” or “UserAndSystem”, the component is selected for this user. Otherwise, the component is ignored. Alternatively, if the current user profile is not the system profile and the component type is “User” or “UserAndSystem”, the component is selected for this user. Otherwise, this component is ignored.
|
||||
|
||||
**Note**
|
||||
From this point on, LoadState does not distinguish between components that migrate operating-system settings, those that migrate application settings, and those that migrate users’ files. LoadState evaluates all components in the same way.
|
||||
**Note**
|
||||
From this point on, LoadState does not distinguish between components that migrate operating-system settings, those that migrate application settings, and those that migrate users’ files. LoadState evaluates all components in the same way.
|
||||
|
||||
|
||||
|
||||
|
||||
2. Each component that is selected is processed further. Any profile-specific variables (such as CSIDL\_PERSONAL) are evaluated in the context of the current profile. For example, if the profile being processed belongs to “User1”, then CSIDL\_PERSONAL would expand to C:\\Users\\User1\\Documents (assuming that the user profiles are stored in the C:\\Users directory).
|
||||
2. Each component that is selected is processed further. Any profile-specific variables (such as CSIDL\_PERSONAL) are evaluated in the context of the current profile. For example, if the profile being processed belongs to “User1”, then CSIDL\_PERSONAL would expand to C:\\Users\\User1\\Documents (assuming that the user profiles are stored in the C:\\Users directory).
|
||||
|
||||
**Note**
|
||||
LoadState ignores the <detects> section specified in a component. At this point, all specified components are considered to be detected and are selected for migration.
|
||||
**Note**
|
||||
LoadState ignores the <detects> section specified in a component. At this point, all specified components are considered to be detected and are selected for migration.
|
||||
|
||||
|
||||
|
||||
|
||||
3. For each selected component, LoadState evaluates the <rules> sections. For each <rules> section, if the current user profile is the system profile and the context of the <rules> section is “System” or “UserAndSystem”, the rule is processed further. Otherwise, this rule is ignored. Alternatively, if the current user profile is not the system profile and the context of the <rules> section is “User” or “UserAndSystem”, the rule is processed further. Otherwise, this rule is ignored.
|
||||
3. For each selected component, LoadState evaluates the <rules> sections. For each <rules> section, if the current user profile is the system profile and the context of the <rules> section is “System” or “UserAndSystem”, the rule is processed further. Otherwise, this rule is ignored. Alternatively, if the current user profile is not the system profile and the context of the <rules> section is “User” or “UserAndSystem”, the rule is processed further. Otherwise, this rule is ignored.
|
||||
|
||||
4. LoadState creates a master list of migration units by processing the various subsections under the <rules> section. Each migration unit that is in an <include> subsection is migrated as long, as there is not a more specific rule for it in an <exclude> subsection in the same <rules> section. For more information about precedence, see [Conflicts and Precedence](usmt-conflicts-and-precedence.md).
|
||||
4. LoadState creates a master list of migration units by processing the various subsections under the <rules> section. Each migration unit that is in an <include> subsection is migrated as long, as there is not a more specific rule for it in an <exclude> subsection in the same <rules> section. For more information about precedence, see [Conflicts and Precedence](usmt-conflicts-and-precedence.md).
|
||||
|
||||
5. LoadState evaluates the destination computer-specific subsections; for example, the <destinationCleanup> and <locationModify> subsections.
|
||||
5. LoadState evaluates the destination computer-specific subsections; for example, the <destinationCleanup> and <locationModify> subsections.
|
||||
|
||||
6. If the destination computer is running Windows 7 or Windows 8 then the migunits that were collected by ScanState using downlevel manifest files are processed by LoadState using the corresponding Component Manifest for Windows 7. The downlevel manifest files are not used during LoadState.
|
||||
6. If the destination computer is running Windows 7 or Windows 8 then the migunits that were collected by ScanState using downlevel manifest files are processed by LoadState using the corresponding Component Manifest for Windows 7. The downlevel manifest files are not used during LoadState.
|
||||
|
||||
**Important**
|
||||
It is important to specify the .xml files with the LoadState command if you want LoadState to use them. Otherwise, any destination-specific rules, such as <locationModify>, in these .xml files are ignored, even if the same .xml files were provided when the ScanState command ran.
|
||||
**Important**
|
||||
It is important to specify the .xml files with the LoadState command if you want LoadState to use them. Otherwise, any destination-specific rules, such as <locationModify>, in these .xml files are ignored, even if the same .xml files were provided when the ScanState command ran.
|
||||
|
||||
|
||||
|
||||
|
||||
5. In the "Apply" phase, LoadState writes the migration units that were collected to the various locations on the destination computer. If there are conflicts and there is not a <merge> rule for the object, the default behavior for the registry is for the source to overwrite the destination. The default behavior for files is for the source to be renamed incrementally, for example, OriginalFileName(1).OriginalExtension. Some settings, such as fonts, wallpaper, and screen-saver settings, do not take effect until the next time the user logs on. For this reason, you should log off when the LoadState command actions have completed.
|
||||
5. In the "Apply" phase, LoadState writes the migration units that were collected to the various locations on the destination computer. If there are conflicts and there is not a <merge> rule for the object, the default behavior for the registry is for the source to overwrite the destination. The default behavior for files is for the source to be renamed incrementally, for example, OriginalFileName(1).OriginalExtension. Some settings, such as fonts, wallpaper, and screen-saver settings, do not take effect until the next time the user logs on. For this reason, you should log off when the LoadState command actions have completed.
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[User State Migration Tool (USMT) Command-line Syntax](usmt-command-line-syntax.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -43,16 +43,16 @@ For more information about how to change the operating-system settings that are
|
||||
|
||||
For information about the operating-system settings that USMT migrates, see [What Does USMT Migrate?](usmt-what-does-usmt-migrate.md)
|
||||
|
||||
|
||||
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[Determine What to Migrate](usmt-determine-what-to-migrate.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -32,16 +32,16 @@ It is important to carefully consider how you plan to migrate users. By default,
|
||||
|
||||
Before migrating local accounts, note the following:
|
||||
|
||||
- [You must explicitly specify that local accounts that are not on the destination computer should be migrated.](#bkmk-8) If you are migrating local accounts and the local account does not exist on the destination computer, you must use the**/lac** option when using the LoadState command. If the **/lac** option is not specified, no local user accounts will be migrated.
|
||||
- [You must explicitly specify that local accounts that are not on the destination computer should be migrated.](#bkmk-8) If you are migrating local accounts and the local account does not exist on the destination computer, you must use the<strong>/lac</strong> option when using the LoadState command. If the **/lac** option is not specified, no local user accounts will be migrated.
|
||||
|
||||
- [Consider whether to enable user accounts that are new to the destination computer.](#bkmk-8) The **/lae** option enables the account that was created with the **/lac** option. However, if you create a disabled local account by using only the **/lac** option, a local administrator must enable the account on the destination computer.
|
||||
- [Consider whether to enable user accounts that are new to the destination computer.](#bkmk-8) The **/lae** option enables the account that was created with the **/lac** option. However, if you create a disabled local account by using only the **/lac** option, a local administrator must enable the account on the destination computer.
|
||||
|
||||
- [Be careful when specifying a password for local accounts.](#bkmk-8) If you create the local account with a blank password, anyone could log on to that account on the destination computer. If you create the local account with a password, the password is available to anyone with access to the USMT command-line tools.
|
||||
- [Be careful when specifying a password for local accounts.](#bkmk-8) If you create the local account with a blank password, anyone could log on to that account on the destination computer. If you create the local account with a password, the password is available to anyone with access to the USMT command-line tools.
|
||||
|
||||
**Note**
|
||||
If there are multiple users on a computer, and you specify a password with the **/lac** option, all migrated users will have the same password.
|
||||
**Note**
|
||||
If there are multiple users on a computer, and you specify a password with the **/lac** option, all migrated users will have the same password.
|
||||
|
||||
|
||||
|
||||
|
||||
## <a href="" id="bkmk-9"></a>Migrating Domain Accounts
|
||||
|
||||
@ -58,7 +58,7 @@ USMT provides several options to migrate multiple users on a single computer. Th
|
||||
**Important**
|
||||
The **/uel** option excludes users based on the **LastModified** date of the Ntuser.dat file. The **/uel** option is not valid in offline migrations.
|
||||
|
||||
|
||||
|
||||
|
||||
- [Moving users to another domain.](#bkmk-8) You can move user accounts to another domain using the **/md** option with the LoadState command-line tool.
|
||||
|
||||
@ -69,7 +69,7 @@ USMT provides several options to migrate multiple users on a single computer. Th
|
||||
**Note**
|
||||
By default, if a user name is not specified in any of the command-line options, the user will be migrated.
|
||||
|
||||
|
||||
|
||||
|
||||
## Related topics
|
||||
|
||||
@ -80,9 +80,9 @@ USMT provides several options to migrate multiple users on a single computer. Th
|
||||
|
||||
[LoadState Syntax](usmt-loadstate-syntax.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -61,7 +61,7 @@ The **LoadState** command's syntax is:
|
||||
|
||||
loadstate *StorePath* \[/i:\[*Path*\\\]*FileName*\] \[/v:*VerbosityLevel*\] \[/nocompress\] \[/decrypt /key:*KeyString*|/keyfile:\[Path\\\]*FileName*\] \[/l:\[*Path*\\\]*FileName*\] \[/progress:\[*Path*\\\]*FileName*\] \[/r:*TimesToRetry*\] \[/w:*SecondsToWait*\] \[/c\] \[/all\] \[/ui:\[*DomainName*|*ComputerName*\\\]*UserName*\] \[/ue:\[\[*DomainName*|*ComputerName*\\\]*UserName*\] \[/uel:*NumberOfDays*|*YYYY/MM/DD*|0\] \[/md:*OldDomain*:*NewDomain*\] \[/mu:*OldDomain*\\*OldUserName*:\[*NewDomain*\\\]*NewUserName*\] \[/lac:\[*Password*\]\] \[/lae\] \[/config:\[*Path*\\\]*FileName*\] \[/?|help\]
|
||||
|
||||
For example, to decrypt the store and migrate the files and settings to a computer running Windows 7 type the following on the command line:
|
||||
For example, to decrypt the store and migrate the files and settings to a computer running Windows 7 type the following on the command line:
|
||||
|
||||
`loadstate \\server\share\migration\mystore /i:migapp.xml /i:migdocs.xml /v:13 /decrypt /key:"mykey"`
|
||||
|
||||
@ -91,28 +91,27 @@ USMT provides the following options that you can use to specify how and where th
|
||||
<p>or</p>
|
||||
<p><strong>/decrypt</strong> <strong>/key</strong>:"<em>Key String</em>"</p>
|
||||
<p>or</p>
|
||||
<p><strong>/decrypt</strong> <strong>/keyfile</strong>:[<em>Path\</em>]<em>FileName</em></p></td>
|
||||
<p><strong>/decrypt</strong> <strong>/keyfile</strong>:[<em>Path</em>]<em>FileName</em></p></td>
|
||||
<td align="left"><p>Decrypts the store with the specified key. With this option, you will need to specify the encryption key in one of the following ways:</p>
|
||||
<ul>
|
||||
<li><p><strong>/key:</strong><em>KeyString</em> specifies the encryption key. If there is a space in <em>KeyString</em>, you must surround the argument with quotation marks.</p></li>
|
||||
<li><p><strong>/keyfile:</strong><em>FilePathAndName</em> specifies a text (.txt) file that contains the encryption key</p></li>
|
||||
</ul>
|
||||
<p><em>KeyString</em> cannot exceed 256 characters.</p>
|
||||
<p><em>KeyString</em> cannot exceed 256 characters.</p>
|
||||
<p>The <strong>/key</strong> and <strong>/keyfile</strong> options cannot be used on the same command line.</p>
|
||||
<p>The <strong>/decrypt</strong> and <strong>/nocompress</strong> options cannot be used on the same command line.</p>
|
||||
<div class="alert">
|
||||
<strong>Important</strong>
|
||||
<p>Use caution with this option, because anyone who has access to the <strong>LoadState</strong> command-line script will also have access to the encryption key.</p>
|
||||
<strong>Important</strong><br/><p>Use caution with this option, because anyone who has access to the <strong>LoadState</strong> command-line script will also have access to the encryption key.</p>
|
||||
</div>
|
||||
<div>
|
||||
|
||||
|
||||
</div>
|
||||
<p>For example:</p>
|
||||
<p><code>loadstate /i:migapp.xml /i:migdocs.xml \\server\share\migration\mystore /decrypt /key:mykey</code></p></td>
|
||||
<p><code>loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /decrypt /key:mykey</code></p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p><strong>/decrypt:</strong><em>"encryption strength"</em></p></td>
|
||||
<td align="left"><p>The <strong>/decrypt</strong> option accepts a command-line parameter to define the encryption strength specified for the migration store encryption. For more information about supported encryption algorithms, see [Migration Store Encryption](usmt-migration-store-encryption.md).</p></td>
|
||||
<td align="left"><p>The <strong>/decrypt</strong> option accepts a command-line parameter to define the encryption strength specified for the migration store encryption. For more information about supported encryption algorithms, see <a href="usmt-migration-store-encryption.md" data-raw-source="[Migration Store Encryption](usmt-migration-store-encryption.md)">Migration Store Encryption</a>.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p><strong>/hardlink</strong></p></td>
|
||||
@ -122,12 +121,12 @@ USMT provides the following options that you can use to specify how and where th
|
||||
<td align="left"><p><strong>/nocompress</strong></p></td>
|
||||
<td align="left"><p>Specifies that the store is not compressed. You should only use this option in testing environments. We recommend that you use a compressed store during your actual migration. This option cannot be used with the <strong>/decrypt</strong> option.</p>
|
||||
<p>For example:</p>
|
||||
<p><code>loadstate /i:migapp.xml /i:migdocs.xml \\server\share\migration\mystore /nocompress</code></p></td>
|
||||
<p><code>loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /nocompress</code></p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
## <a href="" id="bkmk-mig"></a>Migration Rule Options
|
||||
|
||||
@ -147,16 +146,16 @@ USMT provides the following options to specify what files you want to migrate.
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><p><strong>/i</strong>:[<em>Path</em>\]<em>FileName</em></p></td>
|
||||
<td align="left"><p><strong>/i</strong>:[<em>Path</em>]<em>FileName</em></p></td>
|
||||
<td align="left"><p><strong>(include)</strong></p>
|
||||
<p>Specifies an .xml file that contains rules that define what state to migrate. You can specify this option multiple times to include all of your .xml files (MigApp.xml, MigSys.xml, MigDocs.xml and any custom .xml files that you create). <em>Path</em> can be either a relative or full path. If you do not specify the <em>Path</em> variable, then <em>FileName</em> must be located in the current directory.</p>
|
||||
<p>For more information about which files to specify, see the "XML files" section of the [Frequently Asked Questions](usmt-faq.md) topic.</p></td>
|
||||
<p>For more information about which files to specify, see the "XML files" section of the <a href="usmt-faq.md" data-raw-source="[Frequently Asked Questions](usmt-faq.md)">Frequently Asked Questions</a> topic.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p><strong>/config:</strong>[<em>Path</em>\]<em>FileName</em></p></td>
|
||||
<td align="left"><p><strong>/config:</strong>[<em>Path</em>]<em>FileName</em></p></td>
|
||||
<td align="left"><p>Specifies the Config.xml file that the <strong>LoadState</strong> command should use. You cannot specify this option more than once on the command line. <em>Path</em> can be either a relative or full path. If you do not specify the <em>Path</em> variable, then the <em>FileName</em> must be located in the current directory.</p>
|
||||
<p>This example migrates the files and settings based on the rules in the Config.xml, MigDocs.xml, and MigApp.xml files:</p>
|
||||
<p><code>loadstate \\server\share\migration\mystore /config:config.xml /i:migdocs.xml /i:migapp.xml /v:5 /l:loadstate.log</code></p></td>
|
||||
<p><code>loadstate \server\share\migration\mystore /config:config.xml /i:migdocs.xml /i:migapp.xml /v:5 /l:loadstate.log</code></p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p><strong>/auto:</strong><em>"path to script files"</em></p></td>
|
||||
@ -165,7 +164,7 @@ USMT provides the following options to specify what files you want to migrate.
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
## <a href="" id="bkmk-mon"></a>Monitoring Options
|
||||
|
||||
@ -185,7 +184,7 @@ USMT provides several command-line options that you can use to analyze problems
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><p><strong>/l:</strong>[<em>Path</em>\]<em>FileName</em></p></td>
|
||||
<td align="left"><p><strong>/l:</strong>[<em>Path</em>]<em>FileName</em></p></td>
|
||||
<td align="left"><p>Specifies the location and name of the <strong>LoadState</strong> log. You cannot store any of the log files in <em>StorePath</em>. <em>Path</em> can be either a relative or full path. If you do not specify the <em>Path</em> variable, then the log will be created in the current directory. You can specify the <strong>/v</strong> option to adjust the amount of output.</p>
|
||||
<p>If you run the <strong>LoadState</strong> command from a shared network resource, you must specify this option or USMT will fail with the error: "USMT was unable to create the log file(s)". To fix this issue, use the <strong>/l:load.log</strong> option.</p></td>
|
||||
</tr>
|
||||
@ -240,15 +239,15 @@ USMT provides several command-line options that you can use to analyze problems
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p> </p>
|
||||
<p> </p>
|
||||
<p>For example:</p>
|
||||
<p><code>loadstate \\server\share\migration\mystore /v:5 /i:migdocs.xml /i:migapp.xml</code></p></td>
|
||||
<p><code>loadstate \server\share\migration\mystore /v:5 /i:migdocs.xml /i:migapp.xml</code></p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p><strong>/progress:</strong>[<em>Path\</em>]<em>FileName</em></p></td>
|
||||
<td align="left"><p><strong>/progress:</strong>[<em>Path</em>]<em>FileName</em></p></td>
|
||||
<td align="left"><p>Creates the optional progress log. You cannot store any of the log files in <em>StorePath</em>. <em>Path</em> can be either a relative or full path. If you do not specify the <em>Path</em> variable, then <em>FileName</em> will be created in the current directory.</p>
|
||||
<p>For example:</p>
|
||||
<p><code>loadstate /i:migapp.xml /i:migdocs.xml \\server\share\migration\mystore /progress:prog.log /l:scanlog.log</code></p></td>
|
||||
<p><code>loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /progress:prog.log /l:scanlog.log</code></p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p><strong>/c</strong></p></td>
|
||||
@ -257,13 +256,13 @@ USMT provides several command-line options that you can use to analyze problems
|
||||
<tr class="odd">
|
||||
<td align="left"><p><strong>/r:</strong><em><TimesToRetry></em></p></td>
|
||||
<td align="left"><p><strong>(Retry)</strong></p>
|
||||
<p>Specifies the number of times to retry when an error occurs while migrating the user state from a server. The default is three times. This option is useful in environments where network connectivity is not reliable.</p>
|
||||
<p>Specifies the number of times to retry when an error occurs while migrating the user state from a server. The default is three times. This option is useful in environments where network connectivity is not reliable.</p>
|
||||
<p>While restoring the user state, the <strong>/r</strong> option will not recover data that is lost due to a network-hardware failure, such as a faulty or disconnected network cable, or when a virtual private network (VPN) connection fails. The retry option is intended for large, busy networks where connectivity is satisfactory, but communication latency is a problem.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p><strong>/w:</strong><em><SecondsBeforeRetry></em></p></td>
|
||||
<td align="left"><p><strong>(Wait)</strong></p>
|
||||
<p>Specifies the time to wait, in seconds, before retrying a network file operation. The default is 1 second.</p></td>
|
||||
<p>Specifies the time to wait, in seconds, before retrying a network file operation. The default is 1 second.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p><strong>/?</strong> or <strong>/help</strong></p></td>
|
||||
@ -272,7 +271,7 @@ USMT provides several command-line options that you can use to analyze problems
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
## <a href="" id="bkmk-user"></a>User Options
|
||||
|
||||
@ -297,24 +296,23 @@ By default, all users are migrated. The only way to specify which users to inclu
|
||||
<p>USMT migrates all user accounts on the computer, unless you specifically exclude an account with the <strong>/ue</strong> or <strong>/uel</strong> options. For this reason, you do not need to specify this option on the command line. However, if you choose to use the <strong>/all</strong> option, you cannot also use the <strong>/ui</strong>, <strong>/ue</strong> or <strong>/uel</strong> options.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p><strong>/ui:</strong><em>DomainName</em>\<em>UserName</em></p>
|
||||
<td align="left"><p><strong>/ui:</strong><em>DomainName</em><em>UserName</em></p>
|
||||
<p>or</p>
|
||||
<p><strong>/ui:</strong>"<em>DomainName</em>\<em>User Name</em>"</p>
|
||||
<p><strong>/ui:</strong>"<em>DomainName</em><em>User Name</em>"</p>
|
||||
<p>or</p>
|
||||
<p><strong>/ui:</strong><em>ComputerName</em>\<em>LocalUserName</em></p></td>
|
||||
<p><strong>/ui:</strong><em>ComputerName</em><em>LocalUserName</em></p></td>
|
||||
<td align="left"><p><strong>(User include)</strong></p>
|
||||
<p>Migrates the specified user. By default, all users are included in the migration. Therefore, this option is helpful only when used with the <strong>/ue</strong> option. You can specify multiple <strong>/ui</strong> options, but you cannot use the <strong>/ui</strong> option with the <strong>/all</strong> option. <em>DomainName</em> and <em>UserName</em> can contain the asterisk (*) wildcard character. When you specify a user name that contains spaces, you will need to surround it with quotations marks.</p>
|
||||
<p>Migrates the specified user. By default, all users are included in the migration. Therefore, this option is helpful only when used with the <strong>/ue</strong> option. You can specify multiple <strong>/ui</strong> options, but you cannot use the <strong>/ui</strong> option with the <strong>/all</strong> option. <em>DomainName</em> and <em>UserName</em> can contain the asterisk (<em>) wildcard character. When you specify a user name that contains spaces, you will need to surround it with quotations marks.</p>
|
||||
<p>For example:</p>
|
||||
<ul>
|
||||
<li><p>To include only User2 from the Corporate domain, type:</p>
|
||||
<p><code>/ue:*\* /ui:corporate\user2</code></p></li>
|
||||
<p><code>/ue:</em>* /ui:corporate\user2</code></p></li>
|
||||
</ul>
|
||||
<div class="alert">
|
||||
<strong>Note</strong>
|
||||
<p>If a user is specified for inclusion with the <strong>/ui</strong> option, and also is specified to be excluded with either the <strong>/ue</strong> or <strong>/uel</strong> options, the user will be included in the migration.</p>
|
||||
<strong>Note</strong><br/><p>If a user is specified for inclusion with the <strong>/ui</strong> option, and also is specified to be excluded with either the <strong>/ue</strong> or <strong>/uel</strong> options, the user will be included in the migration.</p>
|
||||
</div>
|
||||
<div>
|
||||
|
||||
|
||||
</div>
|
||||
<p>For more examples, see the descriptions of the <strong>/uel</strong>, <strong>/ue</strong>, and <strong>/ui</strong> options in this table.</p></td>
|
||||
</tr>
|
||||
@ -325,34 +323,33 @@ By default, all users are migrated. The only way to specify which users to inclu
|
||||
<p>or</p>
|
||||
<p><strong>/uel</strong>:0</p></td>
|
||||
<td align="left"><p><strong>(User exclude based on last logon)</strong></p>
|
||||
<p>Migrates only the users that logged onto the source computer within the specified time period, based on the <strong>Last Modified</strong> date of the Ntuser.dat file on the source computer. The <strong>/uel</strong> option acts as an include rule. For example, the <strong>/uel:30</strong> option migrates users who logged on, or whose user account was modified, within the last 30 days from the date when the ScanState command is run. You can specify a number of days or you can specify a date. You cannot use this option with the <strong>/all</strong> option. USMT retrieves the last logon information from the local computer, so the computer does not need to be connected to the network when you run this option. In addition, if a domain user has logged onto another computer, that logon instance is not considered by USMT.</p>
|
||||
<p>Migrates only the users that logged onto the source computer within the specified time period, based on the <strong>Last Modified</strong> date of the Ntuser.dat file on the source computer. The <strong>/uel</strong> option acts as an include rule. For example, the <strong>/uel:30</strong> option migrates users who logged on, or whose user account was modified, within the last 30 days from the date when the ScanState command is run. You can specify a number of days or you can specify a date. You cannot use this option with the <strong>/all</strong> option. USMT retrieves the last logon information from the local computer, so the computer does not need to be connected to the network when you run this option. In addition, if a domain user has logged onto another computer, that logon instance is not considered by USMT.</p>
|
||||
<div class="alert">
|
||||
<strong>Note</strong>
|
||||
<p>The <strong>/uel</strong> option is not valid in offline migrations.</p>
|
||||
<strong>Note</strong><br/><p>The <strong>/uel</strong> option is not valid in offline migrations.</p>
|
||||
</div>
|
||||
<div>
|
||||
|
||||
|
||||
</div>
|
||||
<p>Examples:</p>
|
||||
<ul>
|
||||
<li><p><code>/uel:0</code> migrates accounts that were logged on to the source computer when the <strong>ScanState</strong> command was run.</p></li>
|
||||
<li><p><code>/uel:90</code> migrates users who have logged on, or whose accounts have been otherwise modified, within the last 90 days.</p></li>
|
||||
<li><p><code>/uel:1</code> migrates users whose accounts have been modified within the last 24 hours.</p></li>
|
||||
<li><p><code>/uel:90</code> migrates users who have logged on, or whose accounts have been otherwise modified, within the last 90 days.</p></li>
|
||||
<li><p><code>/uel:1</code> migrates users whose accounts have been modified within the last 24 hours.</p></li>
|
||||
<li><p><code>/uel:2002/1/15</code> migrates users who have logged on or whose accounts have been modified since January 15, 2002.</p></li>
|
||||
</ul>
|
||||
<p>For example:</p>
|
||||
<p><code>loadstate /i:migapp.xml /i:migdocs.xml \\server\share\migration\mystore /uel:0</code></p></td>
|
||||
<p><code>loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /uel:0</code></p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p><strong>/ue</strong>:<em>DomainName</em>\<em>UserName</em></p>
|
||||
<td align="left"><p><strong>/ue</strong>:<em>DomainName</em><em>UserName</em></p>
|
||||
<p>or</p>
|
||||
<p><strong>/ue</strong>:"<em>DomainName</em>\<em>User Name</em>"</p>
|
||||
<p><strong>/ue</strong>:"<em>DomainName</em><em>User Name</em>"</p>
|
||||
<p>or</p>
|
||||
<p><strong>/ue</strong>:<em>ComputerName</em>\<em>LocalUserName</em></p></td>
|
||||
<p><strong>/ue</strong>:<em>ComputerName</em><em>LocalUserName</em></p></td>
|
||||
<td align="left"><p><strong>(User exclude)</strong></p>
|
||||
<p>Excludes the specified users from the migration. You can specify multiple <strong>/ue</strong> options but you cannot use the <strong>/ue</strong> option with the <strong>/all</strong> option. <em>DomainName</em> and <em>UserName</em> can contain the asterisk (*) wildcard character. When you specify a user name that contains spaces, you will need to surround it with quotation marks.</p>
|
||||
<p>Excludes the specified users from the migration. You can specify multiple <strong>/ue</strong> options but you cannot use the <strong>/ue</strong> option with the <strong>/all</strong> option. <em>DomainName</em> and <em>UserName</em> can contain the asterisk (<em>) wildcard character. When you specify a user name that contains spaces, you will need to surround it with quotation marks.</p>
|
||||
<p>For example:</p>
|
||||
<p><code>loadstate /i:migapp.xml /i:migdocs.xml \\server\share\migration\mystore /ue:contoso\user1</code></p>
|
||||
<p><code>loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /ue:contoso\user1</code></p>
|
||||
<p>For more examples, see the descriptions of the <strong>/uel</strong>, <strong>/ue</strong>, and <strong>/ui</strong> options in this table.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
@ -360,27 +357,26 @@ By default, all users are migrated. The only way to specify which users to inclu
|
||||
<p>or</p>
|
||||
<p><strong>/md:</strong><em>LocalComputerName:NewDomain</em></p></td>
|
||||
<td align="left"><p><strong>(move domain)</strong></p>
|
||||
<p>Specifies a new domain for the user. Use this option to change the domain for users on a computer or to migrate a local user to a domain account. <em>OldDomain</em> may contain the asterisk (*) wildcard character.</p>
|
||||
<p>Specifies a new domain for the user. Use this option to change the domain for users on a computer or to migrate a local user to a domain account. <em>OldDomain</em> may contain the asterisk (</em>) wildcard character.</p>
|
||||
<p>You can specify this option more than once. You may want to specify multiple <strong>/md</strong> options if you are consolidating users across multiple domains to a single domain. For example, you could specify the following to consolidate the users from the Corporate and FarNorth domains into the Fabrikam domain: <code>/md:corporate:fabrikam</code> and <code>/md:farnorth:fabrikam</code>.</p>
|
||||
<p>If there are conflicts between two <strong>/md</strong> commands, the first rule that you specify is applied. For example, if you specify the <code>/md:corporate:fabrikam</code> and <code>/md:corporate:farnorth</code> commands, then Corporate users would be mapped to the Fabrikam domain.</p>
|
||||
<div class="alert">
|
||||
<strong>Note</strong>
|
||||
<p>If you specify an <em>OldDomain</em> that did not exist on the source computer, the <strong>LoadState</strong> command will appear to complete successfully, without an error or warning. However, in this case, users will not be moved to <em>NewDomain</em> but will remain in their original domain. For example, if you misspell "contoso" and you specify "/md:contso:fabrikam", the users will remain in contoso on the destination computer.</p>
|
||||
<strong>Note</strong><br/><p>If you specify an <em>OldDomain</em> that did not exist on the source computer, the <strong>LoadState</strong> command will appear to complete successfully, without an error or warning. However, in this case, users will not be moved to <em>NewDomain</em> but will remain in their original domain. For example, if you misspell "contoso" and you specify "/md:contso:fabrikam", the users will remain in contoso on the destination computer.</p>
|
||||
</div>
|
||||
<div>
|
||||
|
||||
|
||||
</div>
|
||||
<p>For example:</p>
|
||||
<p><code>loadstate /i:migapp.xml /i:migdocs.xml \\server\share\migration\mystore</code></p>
|
||||
<p><code>loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore</code></p>
|
||||
<p><code> /progress:prog.log /l:load.log /md:contoso:fabrikam</code></p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p><strong>/mu:</strong><em>OldDomain</em>\<em>OldUserName</em>:[<em>NewDomain</em>\]<em>NewUserName</em></p>
|
||||
<td align="left"><p><strong>/mu:</strong><em>OldDomain</em><em>OldUserName</em>:[<em>NewDomain</em>]<em>NewUserName</em></p>
|
||||
<p>or</p>
|
||||
<p><strong>/mu:</strong><em>OldLocalUserName</em>:<em>NewDomain</em>\<em>NewUserName</em></p></td>
|
||||
<p><strong>/mu:</strong><em>OldLocalUserName</em>:<em>NewDomain</em><em>NewUserName</em></p></td>
|
||||
<td align="left"><p>Specifies a new user name for the specified user. If the store contains more than one user, you can specify multiple <strong>/mu</strong> options. You cannot use wildcard characters with this option.</p>
|
||||
<p>For example:</p>
|
||||
<p><code>loadstate /i:migapp.xml /i:migdocs.xml \\server\share\migration\mystore</code></p>
|
||||
<p><code>loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore</code></p>
|
||||
<p><code>/progress:prog.log /l:load.log /mu:contoso\user1:fabrikam\user1</code></p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
@ -390,30 +386,29 @@ By default, all users are migrated. The only way to specify which users to inclu
|
||||
<p>If the <strong>/lac</strong> option is not specified, any local user accounts that do not already exist on the destination computer will not be migrated.</p>
|
||||
<p><em>Password</em> is the password for the newly created account. An empty password is used by default.</p>
|
||||
<div class="alert">
|
||||
<strong>Caution</strong>
|
||||
<p>Use the <em>Password</em> variable with caution because it is provided in plain text and can be obtained by anyone with access to the computer that is running the <strong>LoadState</strong> command.</p>
|
||||
<strong>Caution</strong><br/><p>Use the <em>Password</em> variable with caution because it is provided in plain text and can be obtained by anyone with access to the computer that is running the <strong>LoadState</strong> command.</p>
|
||||
<p>Also, if the computer has multiple users, all migrated users will have the same password.</p>
|
||||
</div>
|
||||
<div>
|
||||
|
||||
|
||||
</div>
|
||||
<p>For example:</p>
|
||||
<p><code>loadstate /i:migapp.xml /i:migdocs.xml \\server\share\migration\mystore</code></p>
|
||||
<p>For instructions, see [Migrate User Accounts](usmt-migrate-user-accounts.md).</p></td>
|
||||
<p><code>loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore</code></p>
|
||||
<p>For instructions, see <a href="usmt-migrate-user-accounts.md" data-raw-source="[Migrate User Accounts](usmt-migrate-user-accounts.md)">Migrate User Accounts</a>.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p><strong>/lae</strong></p></td>
|
||||
<td align="left"><p><strong>(local account enable)</strong></p>
|
||||
<p>Enables the account that was created with the <strong>/lac</strong> option. You must specify the <strong>/lac</strong> option with this option.</p>
|
||||
<p>For example:</p>
|
||||
<p><code>loadstate /i:migapp.xml /i:migdocs.xml \\server\share\migration\mystore</code></p>
|
||||
<p><code>loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore</code></p>
|
||||
<p><code>/progress:prog.log /l:load.log /lac:password /lae</code></p>
|
||||
<p>For instructions, see [Migrate User Accounts](usmt-migrate-user-accounts.md).</p></td>
|
||||
<p>For instructions, see <a href="usmt-migrate-user-accounts.md" data-raw-source="[Migrate User Accounts](usmt-migrate-user-accounts.md)">Migrate User Accounts</a>.</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
### Examples for the /ui and /ue options
|
||||
|
||||
@ -445,20 +440,20 @@ The following examples apply to both the **/ui** and **/ue** options. You can re
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>Exclude all domain users.</p></td>
|
||||
<td align="left"><p><code>/ue:Domain\*</code></p></td>
|
||||
<td align="left"><p><code>/ue:Domain<em></code></p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>Exclude all local users.</p></td>
|
||||
<td align="left"><p><code>/ue:%computername%\*</code></p></td>
|
||||
<td align="left"><p><code>/ue:%computername%</em></code></p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>Exclude users in all domains named User1, User2, and so on.</p></td>
|
||||
<td align="left"><p><code>/ue:*\user*</code></p></td>
|
||||
<td align="left"><p><code>/ue:<em>\user</em></code></p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
### Using the Options Together
|
||||
|
||||
@ -466,7 +461,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.
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
@ -482,28 +477,28 @@ You can use the **/uel**, **/ue** and **/ui** options together to migrate only t
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>Include only User2 from the Fabrikam domain and exclude all other users.</p></td>
|
||||
<td align="left"><p><code>/ue:*\* /ui:fabrikam\user2</code></p></td>
|
||||
<td align="left"><p><code>/ue:<em>* /ui:fabrikam\user2</code></p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>Include only the local user named User1 and exclude all other users.</p></td>
|
||||
<td align="left"><p><code>/ue:*\* /ui:user1</code></p></td>
|
||||
<td align="left"><p><code>/ue:</em>* /ui:user1</code></p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>Include only the domain users from Contoso, except Contoso\User1.</p></td>
|
||||
<td align="left"><p>This behavior cannot be completed using a single command. Instead, to migrate this set of users, you will need to specify the following:</p>
|
||||
<ul>
|
||||
<li><p>Using the <strong>ScanState</strong> command-line tool, type: <code>/ue:*\* /ui:contoso\*</code></p></li>
|
||||
<li><p>Using the <strong>ScanState</strong> command-line tool, type: <code>/ue:<em>* /ui:contoso<em></code></p></li>
|
||||
<li><p>Using the <strong>LoadState</strong> command-line tool, type: <code>/ue:contoso\user1</code></p></li>
|
||||
</ul></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>Include only local (non-domain) users.</p></td>
|
||||
<td align="left"><p><code>/ue:*\* /ui:%computername%\*</code></p></td>
|
||||
<td align="left"><p><code>/ue:</em></em> /ui:%computername%*</code></p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
## <a href="" id="bkmk-cloi"></a>Incompatible Command-Line Options
|
||||
|
||||
@ -692,21 +687,21 @@ The following table indicates which command-line options are not compatible with
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
**Note**
|
||||
|
||||
**Note**
|
||||
You must specify either the **/key** or **/keyfile** option with the **/encrypt** option.
|
||||
|
||||
|
||||
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[XML Elements Library](usmt-xml-elements-library.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -48,22 +48,22 @@ The following table describes each command-line option related to logs, and it p
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><p><strong>/l</strong><em>[Path\]FileName</em></p></td>
|
||||
<td align="left"><p><strong>/l</strong><em>[Path]FileName</em></p></td>
|
||||
<td align="left"><p>Scanstate.log or LoadState.log</p></td>
|
||||
<td align="left"><p>Specifies the path and file name of the ScanState.log or LoadState log.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p><strong>/progress</strong><em>[Path\]FileName</em></p></td>
|
||||
<td align="left"><p><strong>/progress</strong><em>[Path]FileName</em></p></td>
|
||||
<td align="left"><p>Specifies the path and file name of the Progress log.</p></td>
|
||||
<td align="left"><p>Provides information about the status of the migration, by percentage complete.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p><strong>/v</strong><em>[VerbosityLevel]</em></p></td>
|
||||
<td align="left"><p>Not applicable</p></td>
|
||||
<td align="left"><p>See the "Monitoring Options" section in [ScanState Syntax](usmt-scanstate-syntax.md).</p></td>
|
||||
<td align="left"><p>See the "Monitoring Options" section in <a href="usmt-scanstate-syntax.md" data-raw-source="[ScanState Syntax](usmt-scanstate-syntax.md)">ScanState Syntax</a>.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p><strong>/listfiles</strong><em>[Path\]FileName</em></p></td>
|
||||
<td align="left"><p><strong>/listfiles</strong><em>[Path]FileName</em></p></td>
|
||||
<td align="left"><p>Specifies the path and file name of the Listfiles log.</p></td>
|
||||
<td align="left"><p>Provides a list of the files that were migrated.</p></td>
|
||||
</tr>
|
||||
@ -75,12 +75,12 @@ The following table describes each command-line option related to logs, and it p
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
**Note**
|
||||
You cannot store any of the log files in *StorePath*. If you do, the log will be overwritten when USMT is run.
|
||||
|
||||
|
||||
|
||||
|
||||
## <a href="" id="bkmk-scanloadstatelogs"></a>ScanState and LoadState Logs
|
||||
|
||||
@ -221,7 +221,7 @@ The remaining fields are key/value pairs as indicated in the following table.
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
## <a href="" id="bkmk-listfileslog"></a>List Files Log
|
||||
|
||||
@ -483,9 +483,9 @@ Your revised migration XML script excludes the files from migrating, as confirme
|
||||
|
||||
[LoadState Syntax](usmt-loadstate-syntax.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -26,7 +26,7 @@ Encrypting File System (EFS) certificates will be migrated automatically. Howeve
|
||||
**Note**
|
||||
The **/efs** options are not used with the LoadState command.
|
||||
|
||||
|
||||
|
||||
|
||||
Before using the ScanState tool for a migration that includes encrypted files and EFS certificates, you must ensure that all files in an encrypted folder are encrypted as well or remove the encryption attribute from folders that contain unencrypted files. If the encryption attribute has been removed from a file but not from the parent folder, the file will be encrypted during the migration using the credentials of the account used to run the LoadState tool.
|
||||
|
||||
@ -45,9 +45,9 @@ Where *<Path>* is the full path of the topmost parent directory where the
|
||||
|
||||
[Identify File Types, Files, and Folders](usmt-identify-file-types-files-and-folders.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -49,7 +49,7 @@ Links to detailed explanations of commands are available in the Related Topics s
|
||||
**Note**
|
||||
You do not have to specify the **/lae** option, which enables the account that was created with the **/lac** option. Instead, you can create a disabled local account by specifying only the **/lac** option, and then a local administrator needs to enable the account on the destination computer.
|
||||
|
||||
|
||||
|
||||
|
||||
## <a href="" id="bkmk-migratetwo"></a>To migrate two domain accounts (User1 and User2)
|
||||
Links to detailed explanations of commands are available in the Related Topics section.
|
||||
@ -86,9 +86,9 @@ Links to detailed explanations of commands are available in the Related Topics s
|
||||
|
||||
[LoadState Syntax](usmt-loadstate-syntax.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -54,21 +54,21 @@ The following table describes the command-line encryption options in USMT.
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
**Important**
|
||||
Some encryption algorithms may not be available on your systems. You can verify which algorithms are available by running the UsmtUtils command with the **/ec** option. For more information see [UsmtUtils Syntax](usmt-utilities.md)
|
||||
|
||||
|
||||
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[Plan Your Migration](usmt-plan-your-migration.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -32,38 +32,38 @@ One of the most important requirements for migrating settings and data is restor
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[Common Migration Scenarios](usmt-common-migration-scenarios.md)</p></td>
|
||||
<td align="left"><p><a href="usmt-common-migration-scenarios.md" data-raw-source="[Common Migration Scenarios](usmt-common-migration-scenarios.md)">Common Migration Scenarios</a></p></td>
|
||||
<td align="left"><p>Determine whether you will perform a refresh migration or a replace migration.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>[What Does USMT Migrate?](usmt-what-does-usmt-migrate.md)</p></td>
|
||||
<td align="left"><p><a href="usmt-what-does-usmt-migrate.md" data-raw-source="[What Does USMT Migrate?](usmt-what-does-usmt-migrate.md)">What Does USMT Migrate?</a></p></td>
|
||||
<td align="left"><p>Learn which applications, user data, and operating system components USMT migrates.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[Choose a Migration Store Type](usmt-choose-migration-store-type.md)</p></td>
|
||||
<td align="left"><p><a href="usmt-choose-migration-store-type.md" data-raw-source="[Choose a Migration Store Type](usmt-choose-migration-store-type.md)">Choose a Migration Store Type</a></p></td>
|
||||
<td align="left"><p>Choose an uncompressed, compressed, or hard-link migration store.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>[Determine What to Migrate](usmt-determine-what-to-migrate.md)</p></td>
|
||||
<td align="left"><p><a href="usmt-determine-what-to-migrate.md" data-raw-source="[Determine What to Migrate](usmt-determine-what-to-migrate.md)">Determine What to Migrate</a></p></td>
|
||||
<td align="left"><p>Identify user accounts, application settings, operating system settings, and files that you want to migrate inside your organization.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[Test Your Migration](usmt-test-your-migration.md)</p></td>
|
||||
<td align="left"><p><a href="usmt-test-your-migration.md" data-raw-source="[Test Your Migration](usmt-test-your-migration.md)">Test Your Migration</a></p></td>
|
||||
<td align="left"><p>Test your migration before you deploy Windows to all users.</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[USMT XML Reference](usmt-xml-reference.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -26,37 +26,37 @@ ms.topic: article
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[USMT Requirements](usmt-requirements.md)</p></td>
|
||||
<td align="left"><p><a href="usmt-requirements.md" data-raw-source="[USMT Requirements](usmt-requirements.md)">USMT Requirements</a></p></td>
|
||||
<td align="left"><p>Describes operating system, hardware, and software requirements, and user prerequisites.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>[USMT Best Practices](usmt-best-practices.md)</p></td>
|
||||
<td align="left"><p><a href="usmt-best-practices.md" data-raw-source="[USMT Best Practices](usmt-best-practices.md)">USMT Best Practices</a></p></td>
|
||||
<td align="left"><p>Discusses general and security-related best practices when using USMT.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[How USMT Works](usmt-how-it-works.md)</p></td>
|
||||
<td align="left"><p><a href="usmt-how-it-works.md" data-raw-source="[How USMT Works](usmt-how-it-works.md)">How USMT Works</a></p></td>
|
||||
<td align="left"><p>Learn about the processes behind the ScanState and LoadState tools.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>[Plan Your Migration](usmt-plan-your-migration.md)</p></td>
|
||||
<td align="left"><p><a href="usmt-plan-your-migration.md" data-raw-source="[Plan Your Migration](usmt-plan-your-migration.md)">Plan Your Migration</a></p></td>
|
||||
<td align="left"><p>Choose what to migrate and the best migration scenario for your enterprise.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[User State Migration Tool (USMT) Command-line Syntax](usmt-command-line-syntax.md)</p></td>
|
||||
<td align="left"><p><a href="usmt-command-line-syntax.md" data-raw-source="[User State Migration Tool (USMT) Command-line Syntax](usmt-command-line-syntax.md)">User State Migration Tool (USMT) Command-line Syntax</a></p></td>
|
||||
<td align="left"><p>Explore command-line options for the ScanState, LoadState, and UsmtUtils tools.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>[USMT XML Reference](usmt-xml-reference.md)</p></td>
|
||||
<td align="left"><p><a href="usmt-xml-reference.md" data-raw-source="[USMT XML Reference](usmt-xml-reference.md)">USMT XML Reference</a></p></td>
|
||||
<td align="left"><p>Learn about customizing a migration with XML files.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[Offline Migration Reference](offline-migration-reference.md)</p></td>
|
||||
<td align="left"><p><a href="offline-migration-reference.md" data-raw-source="[Offline Migration Reference](offline-migration-reference.md)">Offline Migration Reference</a></p></td>
|
||||
<td align="left"><p>Find requirements, best practices, and other considerations for performing a migration offline.</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
## Related topics
|
||||
|
||||
@ -67,9 +67,9 @@ ms.topic: article
|
||||
|
||||
[User State Migration Tool (USMT) Troubleshooting](usmt-troubleshooting.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -82,7 +82,7 @@ The following table lists the operating systems supported in USMT.
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
**Note**
|
||||
You can migrate a 32-bit operating system to a 64-bit operating system. However, you cannot migrate a 64-bit operating system to a 32-bit operating system.
|
||||
@ -151,9 +151,9 @@ This documentation assumes that IT professionals using USMT understand command-l
|
||||
[Estimate Migration Store Size](usmt-estimate-migration-store-size.md)<BR>
|
||||
[User State Migration Tool (USMT) Overview Topics](usmt-topics.md)<BR>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -46,7 +46,7 @@ Non-fatal Errors
|
||||
|
||||
Fatal Errors
|
||||
|
||||
As a best practice, we recommend that you set verbosity level to 5, **/v***:5*, on the **ScanState**, **LoadState**, and **USMTUtils** command lines so that the most detailed reporting is available in the respective USMT logs. You can use a higher verbosity level if you want the log files output to go to a debugger.
|
||||
As a best practice, we recommend that you set verbosity level to 5, **/v**<em>:5</em>, on the **ScanState**, **LoadState**, and **USMTUtils** command lines so that the most detailed reporting is available in the respective USMT logs. You can use a higher verbosity level if you want the log files output to go to a debugger.
|
||||
|
||||
## <a href="" id="bkmk-errormessages"></a>USMT Error Messages
|
||||
|
||||
@ -130,7 +130,7 @@ The following table lists each return code by numeric value, along with the asso
|
||||
<tr class="even">
|
||||
<td align="left"><p></p></td>
|
||||
<td align="left"><p></p></td>
|
||||
<td align="left"><p>/encrypt can't be used with /nocompress</p></td>
|
||||
<td align="left"><p>/encrypt can't be used with /nocompress</p></td>
|
||||
<td align="left"><p>Review ScanState log or LoadState log for details about command-line errors.</p></td>
|
||||
<td align="left"><p></p></td>
|
||||
</tr>
|
||||
@ -144,14 +144,14 @@ The following table lists each return code by numeric value, along with the asso
|
||||
<tr class="even">
|
||||
<td align="left"><p></p></td>
|
||||
<td align="left"><p></p></td>
|
||||
<td align="left"><p>/genconfig can't be used with most other options</p></td>
|
||||
<td align="left"><p>/genconfig can't be used with most other options</p></td>
|
||||
<td align="left"><p>Review ScanState log or LoadState log for details about command-line errors.</p></td>
|
||||
<td align="left"><p></p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p></p></td>
|
||||
<td align="left"><p></p></td>
|
||||
<td align="left"><p>/genmigxml can't be used with most other options</p></td>
|
||||
<td align="left"><p>/genmigxml can't be used with most other options</p></td>
|
||||
<td align="left"><p>Review ScanState log or LoadState log for details about command-line errors.</p></td>
|
||||
<td align="left"><p></p></td>
|
||||
</tr>
|
||||
@ -438,7 +438,7 @@ The following table lists each return code by numeric value, along with the asso
|
||||
<tr class="even">
|
||||
<td align="left"><p>27</p></td>
|
||||
<td align="left"><p>USMT_INVALID_STORE_LOCATION</p></td>
|
||||
<td align="left"><p>A store path can't be used because an existing store exists; specify /o to overwrite</p></td>
|
||||
<td align="left"><p>A store path can't be used because an existing store exists; specify /o to overwrite</p></td>
|
||||
<td align="left"><p>Specify /o to overwrite an existing intermediate or migration store.</p></td>
|
||||
<td align="left"><p>Setup and Initialization</p></td>
|
||||
</tr>
|
||||
@ -599,7 +599,7 @@ The following table lists each return code by numeric value, along with the asso
|
||||
<tr class="odd">
|
||||
<td align="left"><p></p></td>
|
||||
<td align="left"><p></p></td>
|
||||
<td align="left"><p>A store path can't be used because it contains data that could not be overwritten</p></td>
|
||||
<td align="left"><p>A store path can't be used because it contains data that could not be overwritten</p></td>
|
||||
<td align="left"><p>A migration store could not be deleted. If you are using a hardlink migration store you might have a locked file in it. You should manually delete the store, or use <strong>USMTUtils /rd</strong> command to delete the store.</p></td>
|
||||
<td align="left"><p></p></td>
|
||||
</tr>
|
||||
@ -676,7 +676,7 @@ The following table lists each return code by numeric value, along with the asso
|
||||
<tr class="even">
|
||||
<td align="left"><p>41</p></td>
|
||||
<td align="left"><p>USMT_PREFLIGHT_FILE_CREATION_FAILED</p></td>
|
||||
<td align="left"><p>Can't overwrite existing file</p></td>
|
||||
<td align="left"><p>Can't overwrite existing file</p></td>
|
||||
<td align="left"><p>The Progress log could not be created. Verify that the location is valid and that you have write access.</p></td>
|
||||
<td align="left"><p>Setup and Initialization</p></td>
|
||||
</tr>
|
||||
@ -691,7 +691,7 @@ The following table lists each return code by numeric value, along with the asso
|
||||
<td align="left"><p>42</p></td>
|
||||
<td align="left"><p>USMT_ERROR_CORRUPTED_STORE</p></td>
|
||||
<td align="left"><p>The store contains one or more corrupted files</p></td>
|
||||
<td align="left"><p>Review UsmtUtils log for details about the corrupted files. For information on how to extract the files that are not corrupted, see [Extract Files from a Compressed USMT Migration Store](usmt-extract-files-from-a-compressed-migration-store.md).</p></td>
|
||||
<td align="left"><p>Review UsmtUtils log for details about the corrupted files. For information on how to extract the files that are not corrupted, see <a href="usmt-extract-files-from-a-compressed-migration-store.md" data-raw-source="[Extract Files from a Compressed USMT Migration Store](usmt-extract-files-from-a-compressed-migration-store.md)">Extract Files from a Compressed USMT Migration Store</a>.</p></td>
|
||||
<td align="left"><p></p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
@ -767,7 +767,7 @@ The following table lists each return code by numeric value, along with the asso
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
## Related topics
|
||||
|
||||
@ -776,9 +776,9 @@ The following table lists each return code by numeric value, along with the asso
|
||||
|
||||
[Log Files](usmt-log-files.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -16,7 +16,7 @@ ms.topic: article
|
||||
# ScanState Syntax
|
||||
|
||||
|
||||
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.
|
||||
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
|
||||
|
||||
@ -122,32 +122,31 @@ To create an encrypted store using the Config.xml file and the default migration
|
||||
<li><p><strong>/key:</strong><em>KeyString</em> specifies the encryption key. If there is a space in <em>KeyString</em>, you will need to surround <em>KeyString</em> with quotation marks.</p></li>
|
||||
<li><p><strong>/keyfile:</strong><em>FilePathAndName</em> specifies a text (.txt) file that contains the encryption key.</p></li>
|
||||
</ul>
|
||||
<p>We recommend that <em>KeyString</em> be at least eight characters long, but it cannot exceed 256 characters. The <strong>/key</strong> and <strong>/keyfile</strong> options cannot be used on the same command line. The <strong>/encrypt</strong> and <strong>/nocompress</strong> options cannot be used on the same command line.</p>
|
||||
<p>We recommend that <em>KeyString</em> be at least eight characters long, but it cannot exceed 256 characters. The <strong>/key</strong> and <strong>/keyfile</strong> options cannot be used on the same command line. The <strong>/encrypt</strong> and <strong>/nocompress</strong> options cannot be used on the same command line.</p>
|
||||
<div class="alert">
|
||||
<strong>Important</strong>
|
||||
<p>You should use caution with this option, because anyone who has access to the <strong>ScanState</strong> command-line script will also have access to the encryption key.</p>
|
||||
<strong>Important</strong><br/><p>You should use caution with this option, because anyone who has access to the <strong>ScanState</strong> command-line script will also have access to the encryption key.</p>
|
||||
</div>
|
||||
<div>
|
||||
|
||||
|
||||
</div>
|
||||
<p>The following example shows the ScanState command and the <strong>/key</strong> option:</p>
|
||||
<p><code>scanstate /i:migdocs.xml /i:migapp.xml \\server\share\migration\mystore /encrypt /key:mykey</code></p></td>
|
||||
<p><code>scanstate /i:migdocs.xml /i:migapp.xml \server\share\migration\mystore /encrypt /key:mykey</code></p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p><strong>/encrypt</strong>:<em><EncryptionStrength></em></p></td>
|
||||
<td align="left"><p>The <strong>/encrypt</strong> option accepts a command-line parameter to define the encryption strength to be used for encryption of the migration store. For more information about supported encryption algorithms, see [Migration Store Encryption](usmt-migration-store-encryption.md).</p></td>
|
||||
<td align="left"><p>The <strong>/encrypt</strong> option accepts a command-line parameter to define the encryption strength to be used for encryption of the migration store. For more information about supported encryption algorithms, see <a href="usmt-migration-store-encryption.md" data-raw-source="[Migration Store Encryption](usmt-migration-store-encryption.md)">Migration Store Encryption</a>.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p><strong>/nocompress</strong></p></td>
|
||||
<td align="left"><p>Disables compression of data and saves the files to a hidden folder named "File" at <em>StorePath</em>\USMT. Compression is enabled by default. Combining the <strong>/nocompress</strong> option with the <strong>/hardlink</strong> option generates a hard-link migration store. You can use the uncompressed store to view what USMT stored, troubleshoot a problem, or run an antivirus utility against the files. You should use this option only in testing environments, because we recommend that you use a compressed store during your actual migration, unless you are combining the <strong>/nocompress</strong> option with the <strong>/hardlink</strong> option.</p>
|
||||
<p>The <strong>/nocompress</strong> and <strong>/encrypt</strong> options cannot be used together in one statement on the command line. However, if you do choose to migrate an uncompressed store, the <strong>LoadState</strong> command will migrate each file directly from the store to the correct location on the destination computer without a temporary location.</p>
|
||||
<p>For example:</p>
|
||||
<p><code>scanstate /i:migdocs.xml /i:migapp.xml \\server\share\migration\mystore /nocompress</code></p></td>
|
||||
<p><code>scanstate /i:migdocs.xml /i:migapp.xml \server\share\migration\mystore /nocompress</code></p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
## <a href="" id="run-the-scanstate-command-on-an-offline-windows-system-"></a>Run the ScanState Command on an Offline Windows System
|
||||
|
||||
@ -202,7 +201,7 @@ There are several benefits to running the **ScanState** command on an offline Wi
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
## <a href="" id="bkmk-migrationruleoptions"></a>Migration Rule Options
|
||||
|
||||
@ -222,12 +221,12 @@ USMT provides the following options to specify what files you want to migrate.
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><p><strong>/i:</strong>[<em>Path</em>\]<em>FileName</em></p></td>
|
||||
<td align="left"><p><strong>/i:</strong>[<em>Path</em>]<em>FileName</em></p></td>
|
||||
<td align="left"><p><strong>(include)</strong></p>
|
||||
<p>Specifies an .xml file that contains rules that define what user, application or system state to migrate. You can specify this option multiple times to include all of your .xml files (MigApp.xml, MigDocs.xml, and any custom .xml files that you create). <em>Path</em> can be either a relative or full path. If you do not specify the <em>Path</em> variable, then <em>FileName</em> must be located in the current directory. For more information about which files to specify, see the "XML Files" section of the [Frequently Asked Questions](usmt-faq.md) topic.</p></td>
|
||||
<p>Specifies an .xml file that contains rules that define what user, application or system state to migrate. You can specify this option multiple times to include all of your .xml files (MigApp.xml, MigDocs.xml, and any custom .xml files that you create). <em>Path</em> can be either a relative or full path. If you do not specify the <em>Path</em> variable, then <em>FileName</em> must be located in the current directory. For more information about which files to specify, see the "XML Files" section of the <a href="usmt-faq.md" data-raw-source="[Frequently Asked Questions](usmt-faq.md)">Frequently Asked Questions</a> topic.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p><strong>/genconfig:</strong>[<em>Path</em>\]<em>FileName</em></p></td>
|
||||
<td align="left"><p><strong>/genconfig:</strong>[<em>Path</em>]<em>FileName</em></p></td>
|
||||
<td align="left"><p>(Generate <strong>Config.xml</strong>)</p>
|
||||
<p>Generates the optional Config.xml file, but does not create a migration store. To ensure that this file contains every component, application and setting that can be migrated, you should create this file on a source computer that contains all the components, applications and settings that will be present on the destination computers. In addition, you should specify the other migration .xml files, using the <strong>/i</strong> option, when you specify this option.</p>
|
||||
<p>After you create this file, you will need to make use of it with the <strong>ScanState</strong> command using the <strong>/config</strong> option.</p>
|
||||
@ -239,12 +238,12 @@ USMT provides the following options to specify what files you want to migrate.
|
||||
</ul></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p><strong>/config:</strong>[<em>Path\</em>]<em>FileName</em></p></td>
|
||||
<td align="left"><p><strong>/config:</strong>[<em>Path</em>]<em>FileName</em></p></td>
|
||||
<td align="left"><p>Specifies the Config.xml file that the <strong>ScanState</strong> command should use to create the store. You cannot use this option more than once on the command line. <em>Path</em> can be either a relative or full path. If you do not specify the <em>Path</em> variable, then <em>FileName</em> must be located in the current directory.</p>
|
||||
<p>The following example creates a store using the Config.xml file, MigDocs.xml, and MigApp.xml files:</p>
|
||||
<p><code>scanstate \\server\share\migration\mystore /config:config.xml /i:migdocs.xml /i:migapp.xml /v:13 /l:scan.log</code></p>
|
||||
<p><code>scanstate \server\share\migration\mystore /config:config.xml /i:migdocs.xml /i:migapp.xml /v:13 /l:scan.log</code></p>
|
||||
<p>The following example migrates the files and settings to the destination computer using the <strong>Config.xml</strong>, <strong>MigDocs.xml</strong>, and <strong>MigApp.xml</strong> files:</p>
|
||||
<p><code>loadstate \\server\share\migration\mystore /config:config.xml /i:migdocs.xml /i:migapp.xml /v:13 /l:load.log</code></p></td>
|
||||
<p><code>loadstate \server\share\migration\mystore /config:config.xml /i:migdocs.xml /i:migapp.xml /v:13 /l:load.log</code></p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p><strong>/auto:</strong><em>path to script files</em></p></td>
|
||||
@ -256,24 +255,24 @@ USMT provides the following options to specify what files you want to migrate.
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p><strong>/targetwindows8</strong></p></td>
|
||||
<td align="left"><p>Optimizes Scanstate.exe when using USMT 10.0 to migrate a user state to Windows 8 or Windows 8.1 instead of Windows 10. You should use this command line option in the following scenarios:</p>
|
||||
<td align="left"><p>Optimizes Scanstate.exe when using USMT 10.0 to migrate a user state to Windows 8 or Windows 8.1 instead of Windows 10. You should use this command line option in the following scenarios:</p>
|
||||
<ul>
|
||||
<li><p><strong>To create a Config.xml file by using the /genconfig option.</strong> Using the <strong>/targetwindows8</strong> option optimizes the Config.xml file so that it only contains components that relate to Windows 8 or Windows 8.1.</p></li>
|
||||
<li><p><strong>To create a Config.xml file by using the /genconfig option.</strong> Using the <strong>/targetwindows8</strong> option optimizes the Config.xml file so that it only contains components that relate to Windows 8 or Windows 8.1.</p></li>
|
||||
<li><p><strong>To create a migration store.</strong> Using the <strong>/targetwindows8</strong> option ensures that the ScanState tool gathers the correct set of operating system settings. Without the <strong>/targetwindows8</strong> command-line option, some settings can be lost during the migration.</p></li>
|
||||
</ul></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p><strong>/targetwindows7</strong></p></td>
|
||||
<td align="left"><p>Optimizes Scanstate.exe when using USMT 10.0 to migrate a user state to Windows 7 instead of Windows 10. You should use this command line option in the following scenarios:</p>
|
||||
<td align="left"><p>Optimizes Scanstate.exe when using USMT 10.0 to migrate a user state to Windows 7 instead of Windows 10. You should use this command line option in the following scenarios:</p>
|
||||
<ul>
|
||||
<li><p><strong>To create a Config.xml file by using the /genconfig option.</strong> Using the <strong>/targetwindows7</strong> option optimizes the Config.xml file so that it only contains components that relate to Windows 7.</p></li>
|
||||
<li><p><strong>To create a Config.xml file by using the /genconfig option.</strong> Using the <strong>/targetwindows7</strong> option optimizes the Config.xml file so that it only contains components that relate to Windows 7.</p></li>
|
||||
<li><p><strong>To create a migration store.</strong> Using the <strong>/targetwindows7</strong> option ensures that the ScanState tool gathers the correct set of operating system settings. Without the <strong>/targetwindows7</strong> command-line option, some settings can be lost during the migration.</p></li>
|
||||
</ul></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p><strong>/localonly</strong></p></td>
|
||||
<td align="left"><p>Migrates only files that are stored on the local computer, regardless of the rules in the .xml files that you specify on the command line. You should use this option when you want to exclude the data from removable drives on the source computer, such as USB flash drives (UFDs), some external hard drives, and so on, and when there are network drives mapped on the source computer. If the <strong>/localonly</strong> option is not specified, then the <strong>ScanState</strong> command will copy files from these removable or network drives into the store.</p>
|
||||
<p>Anything that is not considered a fixed drive by the OS will be excluded by <strong>/localonly</strong>. In some cases large external hard drives are considered fixed drives. These drives can be explicitly excluded from migration by using a custom.xml file. For more information about how to exclude all files on a specific drive, see [Exclude Files and Settings](usmt-exclude-files-and-settings.md).</p>
|
||||
<p>Anything that is not considered a fixed drive by the OS will be excluded by <strong>/localonly</strong>. In some cases large external hard drives are considered fixed drives. These drives can be explicitly excluded from migration by using a custom.xml file. For more information about how to exclude all files on a specific drive, see <a href="usmt-exclude-files-and-settings.md" data-raw-source="[Exclude Files and Settings](usmt-exclude-files-and-settings.md)">Exclude Files and Settings</a>.</p>
|
||||
<p>The <strong>/localonly</strong> command-line option includes or excludes data in the migration as identified in the following table:</p>
|
||||
<table>
|
||||
<colgroup>
|
||||
@ -301,22 +300,22 @@ USMT provides the following options to specify what files you want to migrate.
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p> </p></td>
|
||||
<p> </p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
## <a href="" id="bkmk-monitoringoptions"></a>Monitoring Options
|
||||
|
||||
|
||||
USMT provides several options that you can use to analyze problems that occur during migration.
|
||||
|
||||
**Note**
|
||||
**Note**
|
||||
The ScanState log is created by default, but you can specify the name and location of the log with the **/l** option.
|
||||
|
||||
|
||||
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
@ -335,7 +334,7 @@ The ScanState log is created by default, but you can specify the name and locati
|
||||
<td align="left"><p>You can use the <strong>/listfiles</strong> command-line option with the <strong>ScanState</strong> command to generate a text file that lists all of the files included in the migration.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p><strong>/l:</strong>[<em>Path</em>\]<em>FileName</em></p></td>
|
||||
<td align="left"><p><strong>/l:</strong>[<em>Path</em>]<em>FileName</em></p></td>
|
||||
<td align="left"><p>Specifies the location and name of the ScanState log.</p>
|
||||
<p>You cannot store any of the log files in <em>StorePath</em>. <em>Path</em> can be either a relative or full path. If you do not specify the <em>Path</em> variable, then the log will be created in the current directory. You can use the <strong>/v</strong> option to adjust the amount of output.</p>
|
||||
<p>If you run the <strong>ScanState</strong> or <strong>LoadState</strong> commands from a shared network resource, you must specify this option or USMT will fail with the following error: "USMT was unable to create the log file(s)". To fix this issue, use the /<strong>l:scan.log</strong> command.</p></td>
|
||||
@ -391,16 +390,16 @@ The ScanState log is created by default, but you can specify the name and locati
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p> </p>
|
||||
<p> </p>
|
||||
<p>For example:</p>
|
||||
<p><code>scanstate \\server\share\migration\mystore /v:13 /i:migdocs.xml /i:migapp.xml</code></p>
|
||||
<p><code>scanstate \server\share\migration\mystore /v:13 /i:migdocs.xml /i:migapp.xml</code></p>
|
||||
<p></p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>/<strong>progress</strong>:[<em>Path\</em>]<em>FileName</em></p></td>
|
||||
<td align="left"><p>/<strong>progress</strong>:[<em>Path</em>]<em>FileName</em></p></td>
|
||||
<td align="left"><p>Creates the optional progress log. You cannot store any of the log files in <em>StorePath</em>. <em>Path</em> can be either a relative or full path. If you do not specify the <em>Path</em> variable, then <em>FileName</em> will be created in the current directory.</p>
|
||||
<p>For example:</p>
|
||||
<p><code>scanstate /i:migapp.xml /i:migdocs.xml \\server\share\migration\mystore /progress:prog.log /l:scanlog.log</code></p></td>
|
||||
<p><code>scanstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /progress:prog.log /l:scanlog.log</code></p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p><strong>/c</strong></p></td>
|
||||
@ -416,14 +415,14 @@ The ScanState log is created by default, but you can specify the name and locati
|
||||
<tr class="odd">
|
||||
<td align="left"><p><strong>/w:</strong><em><SecondsBeforeRetry></em></p></td>
|
||||
<td align="left"><p><strong>(Wait)</strong></p>
|
||||
<p>Specifies the time to wait, in seconds, before retrying a network file operation. The default is 1 second.</p></td>
|
||||
<p>Specifies the time to wait, in seconds, before retrying a network file operation. The default is 1 second.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p><strong>/p:</strong><em><pathToFile></em></p></td>
|
||||
<td align="left"><p>When the <strong>ScanState</strong> command runs, it will create an .xml file in the path specified. This .xml file includes improved space estimations for the migration store. The following example shows how to create this .xml file:</p>
|
||||
<p><code>Scanstate.exe C:\MigrationLocation [additional parameters]</code></p>
|
||||
<p><code>/p:"C:\MigrationStoreSize.xml"</code></p>
|
||||
<p>For more information, see [Estimate Migration Store Size](usmt-estimate-migration-store-size.md).</p>
|
||||
<p>For more information, see <a href="usmt-estimate-migration-store-size.md" data-raw-source="[Estimate Migration Store Size](usmt-estimate-migration-store-size.md)">Estimate Migration Store Size</a>.</p>
|
||||
<p>To preserve the functionality of existing applications or scripts that require the previous behavior of USMT, you can use the <strong>/p</strong> option, without specifying <em>"pathtoafile"</em>, in USMT. If you specify only the <strong>/p</strong> option, the storage space estimations are created in the same manner as with USMT3.x releases.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
@ -433,7 +432,7 @@ The ScanState log is created by default, but you can specify the name and locati
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
## <a href="" id="bkmk-useroptions"></a>User Options
|
||||
|
||||
@ -462,21 +461,20 @@ By default, all users are migrated. The only way to specify which users to inclu
|
||||
<p>or</p>
|
||||
<p>/<strong>ui</strong>:<em><ComputerName></em>\<em><LocalUserName></em></p></td>
|
||||
<td align="left"><p><strong>(User include)</strong></p>
|
||||
<p>Migrates the specified users. By default, all users are included in the migration. Therefore, this option is helpful only when used with the /<strong>ue</strong> or /<strong>uel</strong> options. You can specify multiple /<strong>ui</strong> options, but you cannot use the /<strong>ui</strong> option with the /<strong>all</strong> option. <em>DomainName</em> and <em>UserName</em> can contain the asterisk (*) wildcard character. When you specify a user name that contains spaces, you will need to surround it with quotation marks.</p>
|
||||
<p>Migrates the specified users. By default, all users are included in the migration. Therefore, this option is helpful only when used with the /<strong>ue</strong> or /<strong>uel</strong> options. You can specify multiple /<strong>ui</strong> options, but you cannot use the /<strong>ui</strong> option with the /<strong>all</strong> option. <em>DomainName</em> and <em>UserName</em> can contain the asterisk (<em>) wildcard character. When you specify a user name that contains spaces, you will need to surround it with quotation marks.</p>
|
||||
<div class="alert">
|
||||
<strong>Note</strong>
|
||||
<p>If a user is specified for inclusion with the /<strong>ui</strong> option, and also is specified to be excluded with either the /<strong>ue</strong> or /<strong>uel</strong> options, the user will be included in the migration.</p>
|
||||
<strong>Note</strong><br/><p>If a user is specified for inclusion with the /<strong>ui</strong> option, and also is specified to be excluded with either the /<strong>ue</strong> or /<strong>uel</strong> options, the user will be included in the migration.</p>
|
||||
</div>
|
||||
<div>
|
||||
|
||||
|
||||
</div>
|
||||
<p>For example:</p>
|
||||
<ul>
|
||||
<p>To include only User2 from the Fabrikam domain, type:</p>
|
||||
<p><code>/ue:*\* /ui:fabrikam\user2</code></p>
|
||||
<p>To migrate all users from the Fabrikam domain, and only the user accounts from other domains that have been active or otherwise modified in the last 30 days, type:</p>
|
||||
<p>To migrate all users from the Fabrikam domain, and only the user accounts from other domains that have been active or otherwise modified in the last 30 days, type:</p>
|
||||
<p><code>/uel:30 /ui:fabrikam\*</code></p>
|
||||
<p>In this example, a user account from the Contoso domain that was last modified 2 months ago will not be migrated.</p></li>
|
||||
<p>In this example, a user account from the Contoso domain that was last modified 2 months ago will not be migrated.</p></li>
|
||||
</ul>
|
||||
<p>For more examples, see the descriptions of the /<strong>ue</strong> and /<strong>ui</strong> options in this table.</p></td>
|
||||
</tr>
|
||||
@ -487,19 +485,18 @@ By default, all users are migrated. The only way to specify which users to inclu
|
||||
<p>or</p>
|
||||
<p><strong>/uel:0</strong></p></td>
|
||||
<td align="left"><p><strong>(User exclude based on last logon)</strong></p>
|
||||
<p>Migrates the users that logged onto the source computer within the specified time period, based on the <strong>Last Modified</strong> date of the Ntuser.dat file on the source computer. The /<strong>uel</strong> option acts as an include rule. For example, the <strong>/uel:30</strong> option migrates users who logged on, or whose account was modified, within the last 30 days from the date when the ScanState command is run.</p>
|
||||
<p>Migrates the users that logged onto the source computer within the specified time period, based on the <strong>Last Modified</strong> date of the Ntuser.dat file on the source computer. The /<strong>uel</strong> option acts as an include rule. For example, the <strong>/uel:30</strong> option migrates users who logged on, or whose account was modified, within the last 30 days from the date when the ScanState command is run.</p>
|
||||
<p>You can specify a number of days or you can specify a date. You cannot use this option with the /<strong>all</strong> option. USMT retrieves the last logon information from the local computer, so the computer does not need to be connected to the network when you run this option. In addition, if a domain user has logged onto another computer, that logon instance is not considered by USMT.</p>
|
||||
<div class="alert">
|
||||
<strong>Note</strong>
|
||||
<p>The /<strong>uel</strong> option is not valid in offline migrations.</p>
|
||||
<strong>Note</strong><br/><p>The /<strong>uel</strong> option is not valid in offline migrations.</p>
|
||||
</div>
|
||||
<div>
|
||||
|
||||
|
||||
</div>
|
||||
<ul>
|
||||
<li><p><strong>/uel:0</strong> migrates any users who are currently logged on.</p></li>
|
||||
<li><p><strong>/uel:90</strong> migrates users who have logged on, or whose accounts have been otherwise modified, within the last 90 days.</p></li>
|
||||
<li><p><strong>/uel:1</strong> migrates users whose account has been modified within the last 24 hours.</p></li>
|
||||
<li><p><strong>/uel:90</strong> migrates users who have logged on, or whose accounts have been otherwise modified, within the last 90 days.</p></li>
|
||||
<li><p><strong>/uel:1</strong> migrates users whose account has been modified within the last 24 hours.</p></li>
|
||||
<li><p><strong>/uel:2002/1/15</strong> migrates users who have logged on or been modified January 15, 2002 or afterwards.</p></li>
|
||||
</ul>
|
||||
<p>For example:</p>
|
||||
@ -511,14 +508,14 @@ By default, all users are migrated. The only way to specify which users to inclu
|
||||
<p></p>
|
||||
<p>/<strong>ue</strong>:<em><ComputerName></em>\<em><LocalUserName></em></p></td>
|
||||
<td align="left"><p><strong>(User exclude)</strong></p>
|
||||
<p>Excludes the specified users from the migration. You can specify multiple /<strong>ue</strong> options. You cannot use this option with the /<strong>all</strong> option. <em><DomainName></em> and <em><UserName></em> can contain the asterisk (*) wildcard character. When you specify a user name that contains spaces, you need to surround it with quotation marks.</p>
|
||||
<p>Excludes the specified users from the migration. You can specify multiple /<strong>ue</strong> options. You cannot use this option with the /<strong>all</strong> option. <em><DomainName></em> and <em><UserName></em> can contain the asterisk (</em>) wildcard character. When you specify a user name that contains spaces, you need to surround it with quotation marks.</p>
|
||||
<p>For example:</p>
|
||||
<p><code>scanstate /i:migdocs.xml /i:migapp.xml \\server\share\migration\mystore /ue:contoso\user1</code></p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
## How to Use /ui and /ue
|
||||
|
||||
@ -564,7 +561,7 @@ The following examples apply to both the /**ui** and /**ue** options. You can re
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
## Using the Options Together
|
||||
|
||||
@ -573,7 +570,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.
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
@ -610,7 +607,7 @@ The /**uel** option takes precedence over the /**ue** option. If a user has logg
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
## <a href="" id="bkmk-efs"></a>Encrypted File Options
|
||||
|
||||
@ -619,15 +616,15 @@ You can use the following options to migrate encrypted files. In all cases, by d
|
||||
|
||||
For more information, see [Migrate EFS Files and Certificates](usmt-migrate-efs-files-and-certificates.md).
|
||||
|
||||
**Note**
|
||||
EFS certificates will be migrated automatically when migrating to Windows 7, Windows 8 or Windows 10. Therefore, you should specify the /**efs:copyraw** option with the **ScanState** command to migrate the encrypted files
|
||||
**Note**
|
||||
EFS certificates will be migrated automatically when migrating to Windows 7, Windows 8 or Windows 10. Therefore, you should specify the /**efs:copyraw** option with the **ScanState** command to migrate the encrypted files
|
||||
|
||||
|
||||
|
||||
**Caution**
|
||||
|
||||
**Caution**
|
||||
Take caution when migrating encrypted files. If you migrate an encrypted file without also migrating the certificate, end users will not be able to access the file after the migration.
|
||||
|
||||
|
||||
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
@ -661,19 +658,18 @@ Take caution when migrating encrypted files. If you migrate an encrypted file wi
|
||||
<td align="left"><p><strong>/efs:copyraw</strong></p></td>
|
||||
<td align="left"><p>Causes the <strong>ScanState</strong> command to copy the files in the encrypted format. The files will be inaccessible on the destination computer until the EFS certificates are migrated. EFS certificates will be automatically migrated; however, by default USMT fails if an encrypted file is found, unless you specify an <strong>/efs</strong> option. Therefore you should specify the <strong>/efs:copyraw</strong> option with the <strong>ScanState</strong> command to migrate the encrypted file. Then, when you run the <strong>LoadState</strong> command, the encrypted file and the EFS certificate will be automatically migrated.</p>
|
||||
<p>For example:</p>
|
||||
<p><code>ScanState /i:migdocs.xml /i:migapp.xml \\server\share\migration\mystore /efs:copyraw</code></p>
|
||||
<p><code>ScanState /i:migdocs.xml /i:migapp.xml \server\share\migration\mystore /efs:copyraw</code></p>
|
||||
<div class="alert">
|
||||
<strong>Important</strong>
|
||||
<p>All files must be encrypted if the parent folder is encrypted. If the encryption attribute on a file inside an encrypted folder has been removed, the file will be encrypted during the migration using the credentials of the account used to run the LoadState tool. For more information, see [Migrate EFS Files and Certificates](usmt-migrate-efs-files-and-certificates.md).</p>
|
||||
<strong>Important</strong><br/><p>All files must be encrypted if the parent folder is encrypted. If the encryption attribute on a file inside an encrypted folder has been removed, the file will be encrypted during the migration using the credentials of the account used to run the LoadState tool. For more information, see <a href="usmt-migrate-efs-files-and-certificates.md" data-raw-source="[Migrate EFS Files and Certificates](usmt-migrate-efs-files-and-certificates.md)">Migrate EFS Files and Certificates</a>.</p>
|
||||
</div>
|
||||
<div>
|
||||
|
||||
|
||||
</div></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
## <a href="" id="bkmk-iclo"></a>Incompatible Command-Line Options
|
||||
|
||||
@ -855,21 +851,21 @@ The following table indicates which command-line options are not compatible with
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
**Note**
|
||||
|
||||
**Note**
|
||||
You must specify either the /**key** or /**keyfile** option with the /**encrypt** option.
|
||||
|
||||
|
||||
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[XML Elements Library](usmt-xml-elements-library.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -22,19 +22,19 @@ After you have thoroughly tested the entire migration process on a single comput
|
||||
|
||||
If your test migration encounters any errors, examine the ScanState and LoadState logs to obtain the exact User State Migration Tool (USMT) 10.0 return code and associated error messages or Windows application programming interface (API) error message. For more information about USMT return codes and error messages, see [Return Codes](usmt-return-codes.md). You can also obtain more information about a Windows API error message by typing **net helpmsg** and the error message number 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. Reducing the verbosity level might make it more difficult to diagnose failures that are encountered during production migrations. You can use a higher verbosity level if you want the log files output to go to a debugger.
|
||||
In most cases, the ScanState and LoadState logs indicate why a USMT migration is failing. We recommend that you use the **/v**<em>:5</em> option when testing your migration. This verbosity level can be adjusted in a production migration. Reducing the verbosity level might make it more difficult to diagnose failures that are encountered during production migrations. You can use a higher verbosity level if you want the log files output to go to a debugger.
|
||||
|
||||
**Note**
|
||||
Running the ScanState and LoadState tools with the **/v***:5* option creates a detailed log file. Although this option makes the log file large, it is helpful in determining where migration errors occurred.
|
||||
Running the ScanState and LoadState tools with the **/v**<em>:5</em> option creates a detailed log file. Although this option makes the log file large, it is helpful in determining where migration errors occurred.
|
||||
|
||||
|
||||
|
||||
|
||||
After you have determined that the pilot migration successfully migrated the specified files and settings, you are ready to add USMT to the server that is running Microsoft® System Center Configuration Manager (SCCM), or a non-Microsoft management technology. For more information, see [Configuration Manager](https://go.microsoft.com/fwlink/p/?LinkId=140246).
|
||||
|
||||
**Note**
|
||||
For testing purposes, you can create an uncompressed store using the **/hardlink /nocompress** option. When compression is disabled, the ScanState tool saves the files and settings to a hidden folder named "File" at *StorePath*\\USMT. You can use the uncompressed store to view what USMT has stored or to troubleshoot a problem, or you can run an antivirus utility against the files. Additionally, you can also use the **/listfiles** command-line option and the diagnostic log to list the files that were gathered and to troubleshoot problems with your migration.
|
||||
|
||||
|
||||
|
||||
|
||||
## Related topics
|
||||
|
||||
@ -43,9 +43,9 @@ For testing purposes, you can create an uncompressed store using the **/hardlink
|
||||
|
||||
[Log Files](usmt-log-files.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -28,29 +28,29 @@ The following table describes topics that address common User State Migration To
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[Common Issues](usmt-common-issues.md)</p></td>
|
||||
<td align="left"><p><a href="usmt-common-issues.md" data-raw-source="[Common Issues](usmt-common-issues.md)">Common Issues</a></p></td>
|
||||
<td align="left"><p>Find troubleshooting solutions for common problems in USMT.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>[Frequently Asked Questions](usmt-faq.md)</p></td>
|
||||
<td align="left"><p><a href="usmt-faq.md" data-raw-source="[Frequently Asked Questions](usmt-faq.md)">Frequently Asked Questions</a></p></td>
|
||||
<td align="left"><p>Find answers to questions about how to use USMT.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[Log Files](usmt-log-files.md)</p></td>
|
||||
<td align="left"><p><a href="usmt-log-files.md" data-raw-source="[Log Files](usmt-log-files.md)">Log Files</a></p></td>
|
||||
<td align="left"><p>Learn how to enable logging to help you troubleshoot issues in USMT.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>[Return Codes](usmt-return-codes.md)</p></td>
|
||||
<td align="left"><p><a href="usmt-return-codes.md" data-raw-source="[Return Codes](usmt-return-codes.md)">Return Codes</a></p></td>
|
||||
<td align="left"><p>Learn how to use return codes to identify problems in USMT.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[USMT Resources](usmt-resources.md)</p></td>
|
||||
<td align="left"><p><a href="usmt-resources.md" data-raw-source="[USMT Resources](usmt-resources.md)">USMT Resources</a></p></td>
|
||||
<td align="left"><p>Find more information and support for using USMT.</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
## Related topics
|
||||
|
||||
@ -63,9 +63,9 @@ The following table describes topics that address common User State Migration To
|
||||
|
||||
[User State Migration Toolkit (USMT) Reference](usmt-reference.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -73,17 +73,17 @@ usmtutils \[/ec | /rd *<storeDir>* | /verify *<filepath>* \[options\
|
||||
<tr class="even">
|
||||
<td align="left"><p><strong>/verify</strong></p></td>
|
||||
<td align="left"><p>Returns information on whether the compressed migration store is intact or whether it contains corrupted files or a corrupted catalog.</p>
|
||||
<p>See [Verify Options](#bkmk-verifyoptions) for syntax and options to use with <strong>/verify</strong>.</p></td>
|
||||
<p>See <a href="#bkmk-verifyoptions" data-raw-source="[Verify Options](#bkmk-verifyoptions)">Verify Options</a> for syntax and options to use with <strong>/verify</strong>.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p><strong>/extract</strong></p></td>
|
||||
<td align="left"><p>Recovers files from a compressed USMT migration store.</p>
|
||||
<p>See [Extract Options](#bkmk-extractoptions) for syntax and options to use with <strong>/extract</strong>.</p></td>
|
||||
<p>See <a href="#bkmk-extractoptions" data-raw-source="[Extract Options](#bkmk-extractoptions)">Extract Options</a> for syntax and options to use with <strong>/extract</strong>.</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
## <a href="" id="bkmk-verifyoptions"></a>Verify Options
|
||||
|
||||
@ -187,12 +187,12 @@ usmtutils /verify\[:*<reportType>*\] *<filePath>* \[/l:*<logfile&
|
||||
<li><p><strong>/key:</strong><em><KeyString></em> specifies the encryption key. If there is a space in <em><KeyString></em>, you must surround the argument with quotation marks.</p></li>
|
||||
<li><p><strong>/keyfile</strong>: <em><FileName></em> specifies the location and name of a text (.txt) file that contains the encryption key.</p></li>
|
||||
</ul>
|
||||
<p>For more information about supported encryption algorithms, see [Migration Store Encryption](usmt-migration-store-encryption.md)</p></td>
|
||||
<p>For more information about supported encryption algorithms, see <a href="usmt-migration-store-encryption.md" data-raw-source="[Migration Store Encryption](usmt-migration-store-encryption.md)">Migration Store Encryption</a></p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
Some examples of **/verify** commands:
|
||||
|
||||
@ -313,7 +313,7 @@ The syntax for **/extract** is:
|
||||
<li><p><strong>/key</strong>: <em><KeyString></em> specifies the encryption key. If there is a space in <em><KeyString></em>, you must surround the argument with quotation marks.</p></li>
|
||||
<li><p><strong>/keyfile</strong>:<em><FileName></em> specifies a text (.txt) file that contains the encryption key</p></li>
|
||||
</ul>
|
||||
<p>For more information about supported encryption algorithms, see [Migration Store Encryption](usmt-migration-store-encryption.md).</p></td>
|
||||
<p>For more information about supported encryption algorithms, see <a href="usmt-migration-store-encryption.md" data-raw-source="[Migration Store Encryption](usmt-migration-store-encryption.md)">Migration Store Encryption</a>.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p><strong>/o</strong></p></td>
|
||||
@ -322,7 +322,7 @@ The syntax for **/extract** is:
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
Some examples of **/extract** commands:
|
||||
|
||||
@ -341,9 +341,9 @@ Some examples of **/extract** commands:
|
||||
|
||||
[Return Codes](usmt-return-codes.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -83,14 +83,14 @@ This section describes the user data that USMT migrates by default, using the Mi
|
||||
**Note**
|
||||
The asterisk (\*) stands for zero or more characters.
|
||||
|
||||
|
||||
|
||||
|
||||
- **Access control lists.** USMT migrates ACLs for specified files and folders from computers running both Windows® XP and Windows Vista. For example, if you migrate a file named File1.txt that is read-only for User1 and read/write for User2, these settings will still apply on the destination computer after the migration.
|
||||
|
||||
**Important**
|
||||
To migrate ACLs, you must specify the directory to migrate in the MigUser.xml file. Using file patterns like \*.doc will not migrate a directory. The source ACL information is migrated only when you explicitly specify the directory. For example, `<pattern type="File">c:\test docs</pattern>`.
|
||||
|
||||
|
||||
|
||||
|
||||
## <a href="" id="bkmk-4"></a>Operating-system components
|
||||
|
||||
@ -152,12 +152,12 @@ The following components are migrated by default using the manifest files:
|
||||
**Important**
|
||||
This list may not be complete. There may be additional components that are migrated.
|
||||
|
||||
|
||||
|
||||
|
||||
**Note**
|
||||
Some settings, such as fonts, are not applied by the LoadState tool until after the destination computer has been restarted. For this reason, restart the destination computer after you run the LoadState tool.
|
||||
|
||||
|
||||
|
||||
|
||||
## <a href="" id="bkmk-2"></a>Supported applications
|
||||
|
||||
@ -167,12 +167,12 @@ Although it is not required for all applications, it is good practice to install
|
||||
**Note**
|
||||
The versions of installed applications must match on the source and destination computers. USMT does not support migrating the settings of an earlier version of an application to a later version, except for Microsoft Office.
|
||||
|
||||
|
||||
|
||||
|
||||
**Note**
|
||||
USMT migrates only the settings that have been used or modified by the user. If there is an application setting on the source computer that was not touched by the user, the setting may not migrate.
|
||||
|
||||
|
||||
|
||||
|
||||
When you specify the MigApp.xml file, USMT migrates the settings for the following applications:
|
||||
|
||||
@ -367,7 +367,7 @@ When you specify the MigApp.xml file, USMT migrates the settings for the followi
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
## <a href="" id="no"></a>What USMT does not migrate
|
||||
|
||||
@ -419,9 +419,9 @@ Starting in Windows 10, version 1607 the USMT does not migrate the Start menu la
|
||||
|
||||
[Plan your migration](usmt-plan-your-migration.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
File diff suppressed because it is too large
Load Diff
@ -28,49 +28,49 @@ This section contains topics that you can use to work with and to customize the
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[Understanding Migration XML Files](understanding-migration-xml-files.md)</p></td>
|
||||
<td align="left"><p><a href="understanding-migration-xml-files.md" data-raw-source="[Understanding Migration XML Files](understanding-migration-xml-files.md)">Understanding Migration XML Files</a></p></td>
|
||||
<td align="left"><p>Provides an overview of the default and custom migration XML files and includes guidelines for creating and editing a customized version of the MigDocs.xml file.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>[Config.xml File](usmt-configxml-file.md)</p></td>
|
||||
<td align="left"><p><a href="usmt-configxml-file.md" data-raw-source="[Config.xml File](usmt-configxml-file.md)">Config.xml File</a></p></td>
|
||||
<td align="left"><p>Describes the Config.xml file and policies concerning its configuration.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[Customize USMT XML Files](usmt-customize-xml-files.md)</p></td>
|
||||
<td align="left"><p><a href="usmt-customize-xml-files.md" data-raw-source="[Customize USMT XML Files](usmt-customize-xml-files.md)">Customize USMT XML Files</a></p></td>
|
||||
<td align="left"><p>Describes how to customize USMT XML files.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>[Custom XML Examples](usmt-custom-xml-examples.md)</p></td>
|
||||
<td align="left"><p><a href="usmt-custom-xml-examples.md" data-raw-source="[Custom XML Examples](usmt-custom-xml-examples.md)">Custom XML Examples</a></p></td>
|
||||
<td align="left"><p>Gives examples of XML files for various migration scenarios.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[Conflicts and Precedence](usmt-conflicts-and-precedence.md)</p></td>
|
||||
<td align="left"><p><a href="usmt-conflicts-and-precedence.md" data-raw-source="[Conflicts and Precedence](usmt-conflicts-and-precedence.md)">Conflicts and Precedence</a></p></td>
|
||||
<td align="left"><p>Describes the precedence of migration rules and how conflicts are handled.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>[General Conventions](usmt-general-conventions.md)</p></td>
|
||||
<td align="left"><p><a href="usmt-general-conventions.md" data-raw-source="[General Conventions](usmt-general-conventions.md)">General Conventions</a></p></td>
|
||||
<td align="left"><p>Describes the XML helper functions.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[XML File Requirements](xml-file-requirements.md)</p></td>
|
||||
<td align="left"><p><a href="xml-file-requirements.md" data-raw-source="[XML File Requirements](xml-file-requirements.md)">XML File Requirements</a></p></td>
|
||||
<td align="left"><p>Describes the requirements for custom XML files.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>[Recognized Environment Variables](usmt-recognized-environment-variables.md)</p></td>
|
||||
<td align="left"><p><a href="usmt-recognized-environment-variables.md" data-raw-source="[Recognized Environment Variables](usmt-recognized-environment-variables.md)">Recognized Environment Variables</a></p></td>
|
||||
<td align="left"><p>Describes environment variables recognized by USMT.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[XML Elements Library](usmt-xml-elements-library.md)</p></td>
|
||||
<td align="left"><p><a href="usmt-xml-elements-library.md" data-raw-source="[XML Elements Library](usmt-xml-elements-library.md)">XML Elements Library</a></p></td>
|
||||
<td align="left"><p>Describes the XML elements and helper functions for authoring migration XML files to use with USMT.</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
Reference in New Issue
Block a user