mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-20 21:03:42 +00:00
Acrolinx score enhancement
This commit is contained in:
Siddarth Mandalika
@ -168,14 +168,14 @@ The default MigUser.xml file does not migrate the following:
|
||||
|
||||
- ACLS for files in folders outside the user profile.
|
||||
|
||||
You can make a copy of the MigUser.xml file and modify it to include or exclude standard user-profile folders and file name extensions. If you know all of the extensions for the files you want to migrate from the source computer, use the MigUser.xml file to move all of your relevant data, regardless of the location of the files. However, this may result in a migration that contains more files than intended. For example, if you choose to migrate all .jpg files, you may migrate image files such as thumbnails and logos from legacy applications that are installed on the source computer.
|
||||
You can make a copy of the MigUser.xml file and modify it to include or exclude standard user-profile folders and file name extensions. If you know all of the extensions for the files you want to migrate from the source computer, use the MigUser.xml file to move all of your relevant data, regardless of the location of the files. However, this provision may result in a migration that contains more files than intended. For example, if you choose to migrate all .jpg files, you may migrate image files such as thumbnails and logos from legacy applications that are installed on the source computer.
|
||||
|
||||
> [!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 300 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
|
||||
|
||||
You can use multiple XML files with the ScanState and LoadState tools. Each of the default XML files included with or generated by USMT is configured for a specific component of the migration. You can also use custom XML files to supplement these default files with additional migration rules.
|
||||
You can use multiple XML files with the ScanState and LoadState tools. Each of the default XML files included with or generated by USMT is configured for a specific component of the migration. You can also use custom XML files to supplement these default files with more migration rules.
|
||||
|
||||
|XML migration file|Modifies the following components:|
|
||||
|--- |--- |
|
||||
|
||||
@ -24,7 +24,7 @@ The disk space requirements for a migration are dependent on the size of the mig
|
||||
|
||||
- [Hard Disk Space Requirements](#bkmk-spacereqs). Describes the disk space requirements for the migration store and other considerations on the source and destination computers.
|
||||
|
||||
- [Calculate Disk Space Requirements Using the ScanState Tool](#bkmk-calcdiskspace). Describes how to use the ScanState tool to determine how big the migration store will be on a particular computer.
|
||||
- [Calculate Disk Space Requirements Using the ScanState Tool](#bkmk-calcdiskspace). Describes how to use the ScanState tool to determine how large the migration store will be on a particular computer.
|
||||
|
||||
- [Estimate Migration Store Size](#bkmk-estmigstoresize). Describes how to estimate the average size of migration stores for the computers in your organization, based on your infrastructure.
|
||||
|
||||
@ -35,13 +35,13 @@ The disk space requirements for a migration are dependent on the size of the mig
|
||||
|
||||
- **Source Computer.** The source computer needs enough available space for the following:
|
||||
|
||||
- [E250 megabytes (MB) minimum of hard disk space.](#bkmk-estmigstoresize) Space is needed to support the User State Migration Tool (USMT) 10.0 operations, for example, growth in the page file. Provided that every volume involved in the migration is formatted as NTFS, 250 MB should be enough space to ensure success for almost every hard-link migration, regardless of the size of the migration. The USMT tools will not create the migration store if 250 MB of disk space is not available.
|
||||
- [E250 megabytes (MB) minimum of hard disk space.](#bkmk-estmigstoresize) Space is needed to support the User State Migration Tool (USMT) 10.0 operations, for example, growth in the page file. If every volume involved in the migration is formatted as NTFS, 250 MB should be enough space to ensure success for almost every hard-link migration, regardless of the size of the migration. The USMT tools will not create the migration store if 250 MB of disk space is not available.
|
||||
|
||||
- [Temporary space for USMT to run.](#bkmk-estmigstoresize) Additional disk space for the USMT tools to operate is required. This does not include the minimum 250 MB needed to create the migration store. The amount of temporary space required can be calculated using the ScanState tool.
|
||||
- [Temporary space for USMT to run.](#bkmk-estmigstoresize) Extra disk space for the USMT tools to operate is required. This does not include the minimum 250 MB needed to create the migration store. The amount of temporary space required can be calculated using the ScanState tool.
|
||||
|
||||
- [Hard-link migration store.](#bkmk-estmigstoresize) It is not necessary to estimate the size of a hard-link migration store. The only case where the hard-link store can be quite large is when non-NTFS file systems exist on the system and contain data being migrated.
|
||||
- [Hard-link migration store.](#bkmk-estmigstoresize) It is not necessary to estimate the size of a hard-link migration store. The only case where the hard-link store can be large is when non-NTFS file systems exist on the system and contain data being migrated.
|
||||
|
||||
- [Destination computer.](#bkmk-estmigstoresize) The destination computer needs enough available space for the following:
|
||||
- [Destination computer.](#bkmk-estmigstoresize) The destination computer needs enough available space for the following components:
|
||||
|
||||
- [Operating system.](#bkmk-estmigstoresize)
|
||||
|
||||
@ -49,12 +49,12 @@ The disk space requirements for a migration are dependent on the size of the mig
|
||||
|
||||
- [Data being migrated.](#bkmk-estmigstoresize) It is important to consider that in addition to the files being migrated, registry information will also require hard disk space for storage.
|
||||
|
||||
- [Temporary space for USMT to run.](#bkmk-estmigstoresize) Additional disk space for the USMT tools to operate is required. The amount of temporary space required can be calculated using the ScanState tool.
|
||||
- [Temporary space for USMT to run.](#bkmk-estmigstoresize) Extra disk space for the USMT tools to operate is required. The amount of temporary space required can be calculated using the ScanState tool.
|
||||
|
||||
## <a href="" id="bkmk-calcdiskspace"></a>Calculate Disk Space Requirements using the ScanState Tool
|
||||
|
||||
|
||||
You can use the ScanState tool to calculate the disk space requirements for a particular compressed or uncompressed migration. It is not necessary to estimate the migration store size for a hard-link migration since this method does not create a separate migration store. The ScanState tool provides disk space requirements for the state of the computer at the time the tool is run. The state of the computer may change during day to day use so it is recommended that you use the calculations as an estimate when planning your migration.
|
||||
You can use the ScanState tool to calculate the disk space requirements for a particular compressed or uncompressed migration. It is not necessary to estimate the migration store size for a hard-link migration since this method does not create a separate migration store. The ScanState tool provides disk space requirements for the state of the computer at the time the tool is run. The state of the computer may change during day-to-day use so it is recommended that you use the calculations as an estimate when planning your migration.
|
||||
|
||||
**To run the ScanState tool on the source computer with USMT installed,**
|
||||
|
||||
@ -82,7 +82,7 @@ You can use the ScanState tool to calculate the disk space requirements for a pa
|
||||
|
||||
The migration store will not be created by running this command, but `StorePath` is a required parameter.
|
||||
|
||||
The ScanState tool also allows you to estimate disk space requirements based on a customized migration. For example, you might not want to migrate the My Documents folder to the destination computer. You can specify this in a configuration file when you run the ScanState tool. For more information, see [Customize USMT XML Files](usmt-customize-xml-files.md).
|
||||
The ScanState tool also allows you to estimate disk space requirements based on a customized migration. For example, you might not want to migrate the My Documents folder to the destination computer. You can specify this condition in a configuration file when you run the ScanState tool. For more information, see [Customize USMT XML Files](usmt-customize-xml-files.md).
|
||||
|
||||
**Note**
|
||||
To preserve the functionality of existing applications or scripts that require the previous behavior of USMT, the **/p** option, without specifying *<path to a file>* is still available in USMT.
|
||||
@ -108,7 +108,7 @@ Additionally, USMT performs a compliance check for a required minimum of 250 MB
|
||||
## <a href="" id="bkmk-estmigstoresize"></a>Estimate Migration Store Size
|
||||
|
||||
|
||||
Determine how much space you will need to store the migrated data. You should base your calculations on the volume of e-mail, personal documents, and system settings for each user. The best way to estimate these is to survey several computers to arrive at an average for the size of the store that you will need.
|
||||
Determine how much space you will need to store the migrated data. You should base your calculations on the volume of e-mail, personal documents, and system settings for each user. The best way to estimate the required space is to survey several computers to arrive at an average for the size of the store that you will need.
|
||||
|
||||
The amount of space that is required in the store will vary, depending on the local storage strategies your organization uses. For example, one key element that determines the size of migration data sets is e-mail storage. If e-mail is stored centrally, data sets will be smaller. If e-mail is stored locally, such as offline-storage files, data sets will be larger. Mobile users will typically have larger data sets than workstation users. You should perform tests and inventory the network to determine the average data set size in your organization.
|
||||
|
||||
@ -123,7 +123,7 @@ When trying to determine how much disk space you will need, consider the followi
|
||||
|
||||
- **User documents**: Frequently, all of a user's documents fit into less than 50 MB of space, depending on the types of files involved. This estimate assumes typical office work, such as word-processing documents and spreadsheets. This estimate can vary substantially based on the types of documents that your organization uses. For example, an architectural firm that predominantly uses computer-aided design (CAD) files needs much more space than a law firm that primarily uses word-processing documents. You do not need to migrate the documents that users store on file servers through mechanisms such as Folder Redirection, as long as users will have access to these locations after the migration.
|
||||
|
||||
- **User system settings** Five megabytes is usually adequate space to save the registry settings. This requirement can fluctuate, however, based on the number of applications that have been installed. It is rare, however, for the user-specific portion of the registry to exceed 5 MB.
|
||||
- **User system settings** Five megabytes is adequate space to save the registry settings. This requirement can fluctuate, however, based on the number of applications that have been installed. It is rare, however, for the user-specific portion of the registry to exceed 5 MB.
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
@ -16,7 +16,7 @@ ms.topic: article
|
||||
|
||||
# Hard-Link Migration Store
|
||||
|
||||
A *hard-link migration store* enables you to perform an in-place migration where all user state is maintained on the computer while the old operating system is removed and the new operating system is installed; this is why it is best suited for the computer-refresh scenario. Use of a hard-link migration store for a computer-refresh scenario drastically improves migration performance and significantly reduces hard-disk utilization, reduces deployment costs, and enables entirely new migration scenarios.
|
||||
A *hard-link migration store* enables you to perform an in-place migration where all user state is maintained on the computer while the old operating system is removed and the new operating system is installed; this functionality is what makes *hard-link migration store* best suited for the computer-refresh scenario. Use of a hard-link migration store for a computer-refresh scenario drastically improves migration performance and significantly reduces hard-disk utilization, reduces deployment costs, and enables entirely new migration scenarios.
|
||||
|
||||
## In this topic
|
||||
|
||||
@ -50,7 +50,7 @@ You can use a hard-link migration store when your planned migration meets both o
|
||||
|
||||
- You are upgrading the operating system on the same volume of the computer.
|
||||
|
||||
You cannot use a hard-link migration store if your planned migration includes any of the following:
|
||||
You cannot use a hard-link migration store if your planned migration includes any of the following tasks:
|
||||
|
||||
- You are migrating data from one computer to a second computer.
|
||||
|
||||
@ -62,7 +62,7 @@ You cannot use a hard-link migration store if your planned migration includes an
|
||||
|
||||
The hard-link migration store is created using the command-line option, **/hardlink**, and is equivalent to other migration-store types. However, it differs in that hard links are utilized to keep files stored on the source computer during the migration. Keeping the files in place on the source computer eliminates the redundant work of duplicating files. It also enables the performance benefits and reduction in disk utilization that define this scenario.
|
||||
|
||||
When you create a hard link, you give an existing file an additional path. For instance, you could create a hard link to c:\\file1.txt called c:\\hard link\\myFile.txt. These are two paths to the same file. If you open c:\\file1.txt, make changes, and save the file, you will see those changes when you open c:\\hard link\\myFile.txt. If you delete c:\\file1.txt, the file still exists on your computer as c:\\hardlink\\myFile.txt. You must delete both references to the file in order to delete the file.
|
||||
When you create a hard link, you give an existing file one more path. For instance, you could create a hard link to c:\\file1.txt called c:\\hard link\\myFile.txt. These two paths relate to the same file. If you open c:\\file1.txt, make changes, and save the file, you will see those changes when you open c:\\hard link\\myFile.txt. If you delete c:\\file1.txt, the file still exists on your computer as c:\\hardlink\\myFile.txt. You must delete both references to the file in order to delete the file.
|
||||
|
||||
> [!NOTE]
|
||||
> A hard link can only be created for a file on the same volume. If you copy a hard-link migration store to another drive or external device, the files, and not the links, are copied, as in a non-compressed migration-store scenario.
|
||||
@ -76,11 +76,11 @@ 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:
|
||||
Keeping the hard-link migration store can result in extra disk space being consumed or problems with some applications for the following reasons:
|
||||
|
||||
- Applications reporting file-system statistics, for example, space used and free space, might incorrectly report these statistics while the hard-link migration store is present. The file may be reported twice because of the two paths that reference that file.
|
||||
|
||||
- A hard link may lose its connection to the original file. Some applications save changes to a file by creating a temporary file and then renaming the original to a backup filename. The path that was not used to open the file in this application will continue to refer to the unmodified file. The unmodified file that is not in use is taking up additional disk space. You should create the hard-link migration store just before you perform the migration, and not use applications once the store is created, in order to make sure you are migrating the latest versions of all files.
|
||||
- A hard link may lose its connection to the original file. Some applications save changes to a file by creating a temporary file and then renaming the original to a backup filename. The path that was not used to open the file in this application will continue to refer to the unmodified file. The unmodified file that is not in use is taking up more disk space. You should create the hard-link migration store just before you perform the migration, and not use applications once the store is created, in order to make sure you are migrating the latest versions of all files.
|
||||
|
||||
- Editing the file by using different paths simultaneously may result in data corruption.
|
||||
|
||||
@ -131,7 +131,7 @@ The drive you specify on the command line for the hard-link migration store is i
|
||||
|
||||
### <a href="" id="bkmk-locationmodify"></a>Location Modifications
|
||||
|
||||
Location modifications that redirect migrated content from one volume to a different volume have an adverse impact on the performance of a hard-link migration. This is because the migrating data that must cross system volumes cannot remain in the hard-link migration store, and must be copied across the system volumes.
|
||||
Location modifications that redirect migrated content from one volume to a different volume have an adverse impact on the performance of a hard-link migration. This impact is because the migrating data that must cross system volumes cannot remain in the hard-link migration store, and must be copied across the system volumes.
|
||||
|
||||
### <a href="" id="bkmk-efs"></a>Migrating Encrypting File System (EFS) Certificates and Files
|
||||
|
||||
|
||||
@ -17,27 +17,27 @@ ms.topic: article
|
||||
# Identify Operating System Settings
|
||||
|
||||
|
||||
When planning for your migration, you should identify which operating system settings you want to migrate and to what extent you want to create a new standard environment on each of the computers. User State Migration Tool (USMT) 10.0 enables you to migrate select settings and keep the default values for all others. The operating system settings include the following:
|
||||
When planning for your migration, you should identify which operating system settings you want to migrate and to what extent you want to create a new standard environment on each of the computers. User State Migration Tool (USMT) 10.0 enables you to migrate select settings and keep the default values for all others. The operating system settings include the following parameters:
|
||||
|
||||
- **Apperance.**
|
||||
- **Appearance.**
|
||||
|
||||
This includes items such as wallpaper, colors, sounds, and the location of the taskbar.
|
||||
The appearance factor includes items such as wallpaper, colors, sounds, and the location of the taskbar.
|
||||
|
||||
- **Action.**
|
||||
|
||||
This includes items such as the key-repeat rate, whether double-clicking a folder opens it in a new window or the same window, and whether you need to single-click or double-click an item to open it.
|
||||
The action factor includes items such as the key-repeat rate, whether double-clicking a folder opens it in a new window or the same window, and whether you need to single-click or double-click an item to open it.
|
||||
|
||||
- **Internet.**
|
||||
|
||||
These are the settings that let you connect to the Internet and control how your browser operates. This includes items such as your home page URL, favorites, bookmarks, cookies, security settings, dial-up connections, and proxy settings.
|
||||
The Internet factor includes the settings that let you connect to the Internet and control how your browser operates. The settings include items such as your home page URL, favorites, bookmarks, cookies, security settings, dial-up connections, and proxy settings.
|
||||
|
||||
- **Mail.**
|
||||
|
||||
This includes the information that you need to connect to your mail server, your signature file, views, mail rules, local mail, and contacts.
|
||||
The mail factor includes the information that you need to connect to your mail server, your signature file, views, mail rules, local mail, and contacts.
|
||||
|
||||
To help you decide which settings to migrate, you should consider any previous migration experiences as well as the results of any surveys and tests that you have conducted. You should also consider the number of help-desk calls related to operating-system settings that you have had in the past, and are able to handle in the future. Also decide how much of the new operating-system functionality you want to take advantage of.
|
||||
To help you decide which settings to migrate, you should consider any previous migration experiences and the results of any surveys and tests that you have conducted. You should also consider the number of help-desk calls related to operating-system settings that you have had in the past, and are able to handle in the future. Also decide how much of the new operating-system functionality you want to take advantage of.
|
||||
|
||||
You should migrate any settings that users need to get their jobs done, those that make the work environment comfortable, and those that will reduce help-desk calls after the migration. Although it is easy to dismiss migrating user preferences, you should consider that users can spend a significant amount of time restoring items such as wallpaper, screen savers, and other customizable user-interface features. Most users do not remember how these settings were applied. Although these items are not critical to migration success, migrating these items increases user productivity and overall satisfaction of the migration process.
|
||||
You should migrate any settings that users need to get their jobs done, those settings that make the work environment comfortable, and those settings that will reduce help-desk calls after the migration. Although it is easy to dismiss migrating user preferences, you should consider the factor of users spending a significant amount of time restoring items such as wallpaper, screen savers, and other customizable user-interface features. Most users do not remember how these settings were applied. Although these items are not critical to migration success, migrating these items increases user productivity and overall satisfaction of the migration process.
|
||||
|
||||
**Note**
|
||||
For more information about how to change the operating-system settings that are migrated, see [User State Migration Tool (USMT) How-to topics](usmt-how-to.md).
|
||||
|
||||
@ -48,7 +48,7 @@ Before you run the **ScanState** command, note the following:
|
||||
|
||||
- Unless otherwise noted, you can use each option only once when running a tool on the command line.
|
||||
|
||||
- You can gather domain accounts without the source computer having domain controller access. This functionality is available without any additional configuration.
|
||||
- You can gather domain accounts without the source computer having domain controller access. This functionality is available without any extra configuration.
|
||||
|
||||
- The [Incompatible Command-Line Options](#bkmk-iclo) table lists which options you can use together and which command-line options are incompatible.
|
||||
|
||||
@ -142,7 +142,7 @@ USMT provides several options that you can use to analyze problems that occur du
|
||||
| **/l:**[*Path*]*FileName* | Specifies the location and name of the ScanState log. <br/><br/>You cannot store any of the log files in *StorePath*. *Path* can be either a relative or full path. If you do not specify the *Path* variable, then the log will be created in the current directory. You can use the **/v** option to adjust the amount of output. <br/><br/>If you run the **ScanState** or **LoadState** 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 /**l: scan.log** command. |
|
||||
| **/v:***<VerbosityLevel>* | **(Verbosity)**<br/><br/>Enables verbose output in the ScanState log file. The default value is 0. <br/><br/>You can set the *VerbosityLevel* to one of the following levels: <ul><li>**0** - Only the default errors and warnings are enabled.</li><li>**1** - Enables verbose output.</li><li>**4** - Enables error and status output.</li><li>**5** - Enables verbose and status output.</li><li>**8** - Enables error output to a debugger.</li><li>**9** - Enables verbose output to a debugger.</li><li>**12** - Enables error and status output to a debugger.</li><li>**13** - Enables verbose, status, and debugger output.</li></ul> <br/>For example: <br/>`scanstate \server\share\migration\mystore /v:13 /i:migdocs.xml /i:migapp.xml`|
|
||||
| /**progress**:[*Path*]*FileName* | Creates the optional progress log. You cannot store any of the log files in *StorePath*. *Path* can be either a relative or full path. If you do not specify the *Path* variable, then *FileName* will be created in the current directory.<br/><br/>For example: <br/>`scanstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /progress:prog.log /l:scanlog.log` |
|
||||
| **/c** | When this option is specified, the **ScanState** command will continue to run, even if non-fatal errors occur. Any files or settings that cause an error are logged in the progress log. For example, if there is a large file that will not fit in the store, the **ScanState** command will log an error and continue with the migration. In addition, if a file is open or in use by an application, USMT may not be able to migrate the file and will log an error. Without the **/c** option, the **ScanState** command will exit on the first error.<br/><br/>You can use the new <**ErrorControl**> section in the Config.xml file to specify which file or registry read/write errors can be safely ignored and which might cause the migration to fail. This enables the /**c** command-line option to safely skip all input/output (I/O) errors in your environment. In addition, the /**genconfig** option now generates a sample <**ErrorControl**> section that is enabled by specifying error messages and desired behaviors in the Config.xml file. |
|
||||
| **/c** | When this option is specified, the **ScanState** command will continue to run, even if non-fatal errors occur. Any files or settings that cause an error are logged in the progress log. For example, if there is a large file that will not fit in the store, the **ScanState** command will log an error and continue with the migration. In addition, if a file is open or in use by an application, USMT may not be able to migrate the file and will log an error. Without the **/c** option, the **ScanState** command will exit on the first error.<br/><br/>You can use the new <**ErrorControl**> section in the Config.xml file to specify which file or registry read/write errors can be safely ignored and which might cause the migration to fail. This advantage in the Config.xml file enables the /**c** command-line option to safely skip all input/output (I/O) errors in your environment. In addition, the /**genconfig** option now generates a sample <**ErrorControl**> section that is enabled by specifying error messages and desired behaviors in the Config.xml file. |
|
||||
| **/r:***<TimesToRetry>* | **(Retry)**<br/><br/>Specifies the number of times to retry when an error occurs while saving the user state to a server. The default is three times. This option is useful in environments where network connectivity is not reliable.<br/><br/>While storing the user state, the **/r** option will not be able to recover data that is lost due to a network-hardware failure, such as a faulty or disconnected network cable, or when a virtual private network (VPN) connection fails. The retry option is intended for large, busy networks where connectivity is satisfactory, but communication latency is a problem. |
|
||||
| **/w:***<SecondsBeforeRetry>* | **(Wait)**<br/><br/>Specifies the time to wait, in seconds, before retrying a network file operation. The default is 1 second. |
|
||||
| **/p:***<pathToFile>* | When the **ScanState** 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:<br/>`Scanstate.exe C:\MigrationLocation [additional parameters]`<br/>`/p:"C:\MigrationStoreSize.xml"`<br/><br/>For more information, see [Estimate Migration Store Size](usmt-estimate-migration-store-size.md).<br/><br/>To preserve the functionality of existing applications or scripts that require the previous behavior of USMT, you can use the **/p** option, without specifying *"pathtoafile"*, in USMT. If you specify only the **/p** option, the storage space estimations are created in the same manner as with USMT3.x releases. |
|
||||
@ -156,7 +156,7 @@ By default, all users are migrated. The only way to specify which users to inclu
|
||||
|-----|-----|
|
||||
| /**all** | Migrates all of the users on the computer. <br/><br/>USMT migrates all user accounts on the computer, unless you specifically exclude an account with either the /**ue** or /**uel** options. For this reason, you do not need to specify this option on the command line. However, if you choose to specify the /**all** option, you cannot also use the /**ui**, /**ue** or /**uel** options. |
|
||||
| /**ui**:*<DomainName>*\*<UserName>*<br/>or<br/>/**ui**:*<ComputerName>*\*<LocalUserName>* | **(User include)** <br/><br/>Migrates the specified users. By default, all users are included in the migration. Therefore, this option is helpful only when used with the /**ue** or /**uel** options. You can specify multiple /**ui** options, but you cannot use the /**ui** option with the /**all** option. *DomainName* and *UserName* 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. <div class="alert">**Note**<br/>If a user is specified for inclusion with the /**ui** option, and also is specified to be excluded with either the /**ue** or /**uel** options, the user will be included in the migration.</div><br/>For example:<br/><ul><li>To include only User2 from the Fabrikam domain, type:<br/>`/ue:*\* /ui:fabrikam\user2`</li><li>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:<br/>`/uel:30 /ui:fabrikam\*`<br/>In this example, a user account from the Contoso domain that was last modified two months ago will not be migrated.</li></ul><br/>For more examples, see the descriptions of the /**ue** and /**ui** options in this table. |
|
||||
| /**uel**:*<NumberOfDays>*<br/>or<br/>/**uel**:*<YYYY/MM/DD>*<br/>or<br/>**/uel:0** | **(User exclude based on last logon)**<br/><br/>Migrates the users that logged on to the source computer within the specified time period, based on the **Last Modified** date of the Ntuser.dat file on the source computer. The /**uel** option acts as an include rule. For example, the **/uel:30** option migrates users who logged on, or whose account was modified, within the last 30 days from the date when the ScanState command is run.<br/><br/>You can specify a number of days or you can specify a date. You cannot use this option with the /**all** option. USMT retrieves the last logon information from the local computer, so the computer does not need to be connected to the network when you run this option. In addition, if a domain user has logged on to another computer, that logon instance is not considered by USMT. <div class="alert">**Note**<br/>The /**uel** option is not valid in offline migrations.</div><ul><li>**/uel:0** migrates any users who are currently logged on.</li><li>**/uel:90** migrates users who have logged on, or whose accounts have been otherwise modified, within the last 90 days.</li><li>**/uel:1** migrates users whose account has been modified within the last 24 hours.</li><li>**/uel:2002/1/15** migrates users who have logged on or been modified January 15, 2002 or afterwards.</li></ul> <br/>For example: <br/>`scanstate /i:migapp.xml /i:migdocs.xml \\server\share\migration\mystore /uel:0` |
|
||||
| /**uel**:*<NumberOfDays>*<br/>or<br/>/**uel**:*<YYYY/MM/DD>*<br/>or<br/>**/uel:0** | **(User exclude based on last logon)**<br/><br/>Migrates the users that logged on to the source computer within the specified time period, based on the **Last Modified** date of the Ntuser.dat file on the source computer. The /**uel** option acts as an include rule. For example, the **/uel:30** option migrates users who logged on, or whose account was modified, within the last 30 days from the date when the ScanState command is run.<br/><br/>You can specify the number of days or you can specify a date. You cannot use this option with the /**all** option. USMT retrieves the last logon information from the local computer, so the computer does not need to be connected to the network when you run this option. In addition, if a domain user has signed in to another computer, that sign-in instance is not considered by USMT. <div class="alert">**Note**<br/>The /**uel** option is not valid in offline migrations.</div><ul><li>**/uel:0** migrates any users who are currently logged on.</li><li>**/uel:90** migrates users who have logged on, or whose accounts have been otherwise modified, within the last 90 days.</li><li>**/uel:1** migrates users whose account has been modified within the last 24 hours.</li><li>**/uel:2002/1/15** migrates users who have logged on or been modified January 15, 2002 or afterwards.</li></ul> <br/>For example: <br/>`scanstate /i:migapp.xml /i:migdocs.xml \\server\share\migration\mystore /uel:0` |
|
||||
| /**ue**:*<DomainName>*\*<UserName>*<br/>-or-<br/><br/>/**ue**:*<ComputerName>*\*<LocalUserName>* | **(User exclude)**<br/><br/>Excludes the specified users from the migration. You can specify multiple /**ue** options. You cannot use this option with the /**all** option. *<DomainName>* and *<UserName>* can contain the asterisk (</em>) wildcard character. When you specify a user name that contains spaces, you need to surround it with quotation marks.<br/><br/>For example:<br/>`scanstate /i:migdocs.xml /i:migapp.xml \\server\share\migration\mystore /ue:contoso\user1` |
|
||||
|
||||
## How to Use /ui and /ue
|
||||
@ -184,7 +184,7 @@ The /**uel** option takes precedence over the /**ue** option. If a user has logg
|
||||
|--- |--- |
|
||||
|Include only User2 from the Fabrikam domain and exclude all other users.|`/ue:*\* /ui:fabrikam\user2`|
|
||||
|Include only the local user named User1 and exclude all other users.|`/ue:*\* /ui:user1`|
|
||||
|Include only the domain users from Contoso, except Contoso\User1.|This behavior cannot be completed using a single command. Instead, to migrate this set of users, you will need to specify the following: <ul><li>On the **ScanState** command line, type: `/ue:*\* /ui:contoso\*`</li><li>On the **LoadState** command line, type: `/ue:contoso\user1`</li></ul>|
|
||||
|Include only the domain users from Contoso, except Contoso\User1.|This behavior cannot be completed using a single command. Instead, to migrate this set of users, you will need to specify the following commands: <ul><li>On the **ScanState** command line, type: `/ue:*\* /ui:contoso\*`</li><li>On the **LoadState** command line, type: `/ue:contoso\user1`</li></ul>|
|
||||
|Include only local (non-domain) users.|`/ue:*\* /ui:%computername%\*`|
|
||||
|
||||
## <a href="" id="bkmk-efs"></a>Encrypted File Options
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
title: XML File Requirements (Windows 10)
|
||||
description: Learn about the XML file requirements for creating custom .xml files, like the file must be in UTF-8 and have a unique migration urlid.
|
||||
description: Learn about the XML file requirements for creating custom .xml files, like the file must be in UTF-8 and have a unique migration URL ID.
|
||||
ms.assetid: 4b567b50-c50a-4a4f-8684-151fe3f8275f
|
||||
ms.reviewer:
|
||||
manager: laurawi
|
||||
@ -19,20 +19,20 @@ ms.topic: article
|
||||
|
||||
When creating custom .xml files, note the following requirements:
|
||||
|
||||
- **The file must be in Unicode Transformation Format-8 (UTF-8).** You must save the file in this format, and you must specify the following syntax at the beginning of each .xml file:
|
||||
- **The file must be in Unicode Transformation Format-8 (UTF-8).** Save the file in this format, and you must specify the following syntax at the beginning of each .xml file:
|
||||
|
||||
``` xml
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
```
|
||||
|
||||
- **The file must have a unique migration urlid**. The urlid of each file that you specify on the command line must be different. If two migration .xml files have the same urlid, the second .xml file that is specified on the command line will not be processed. This is because USMT uses the urlid to define the components within the file. For example, you must specify the following syntax at the beginning of each file:
|
||||
- **The file must have a unique migration URL ID**. The URL ID of each file that you specify on the command line must be different. If two migration .xml files have the same URL ID, the second .xml file that is specified on the command line will not be processed. This is because USMT uses the URL ID to define the components within the file. For example, you must specify the following syntax at the beginning of each file:
|
||||
|
||||
``` xml
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/<CustomFileName>">
|
||||
```
|
||||
|
||||
- **Each component in the file must have a display name in order for it to appear in the Config.xml file.** This is because the Config.xml file defines the components by the display name and the migration urlid. For example, specify the following syntax:
|
||||
- **Each component in the file must have a display name in order for it to appear in the Config.xml file.** This condition is because the Config.xml file defines the components by the display name and the migration URL ID. For example, specify the following syntax:
|
||||
|
||||
``` xml
|
||||
<displayName>My Application</displayName>
|
||||
|
||||
Reference in New Issue
Block a user