Freigeben über

谈一谈新版本的USMT

  • Artikel

USMT,User States Migration Toolkit??Windows 7??????,USMT???????????:

Hard-Link Migration Store: The new hard-link migration store is for use in computer-refresh scenarios only. Hard-link migration stores are stored locally on the computer that is being refreshed and can migrate user accounts, files, and settings in less time using megabytes of disk space instead of gigabytes.

Running ScanState on Offline Windows Images: You can run the ScanState command in Microsoft Windows PE. In addition, USMT now supports migration from previous installations of Windows contained in Windows.old directories. The offline directory can be a Windows directory when you run the ScanState command in Windows PE or Windows.old when you run the ScanState command in Windows .

Volume Shadow Copy Support: With the /vsc command line option, the ScanState command can now use the volume shadow copy service to capture files that are locked for editing by other applications.

New AES Encryption Options: USMT now provides support for stronger encryption algorithms in several key size options, based on support in the source computer’s operating system.

Configurable File Errors: You can use the new <ErrorControl> section in the Config.xml file to configure which file or registry read/write errors can be safely ignored by the /c command-line option and which ones might cause the migration to fail. In addition, the /genconfig option now generates a sample <ErrorControl> section that is enabled by specifying error codes and desired behaviors in the Config.xml file.

New Helper Functions: The ScanState command has two new helper functions that enable new migration scenarios:

  • MigXmlHelper.FileProperties can be used to control which files are migrated, based on properties that you specify. For example, date created, date modified, date accessed, and file size.
  • MigXmlHelper.GenerateDocPatterns can be used to find user documents on a computer automatically without your having to author extensive custom migration .xml files.

Improved Space Estimation: The ScanState command now more accurately estimates the size of the migration store as well as the additional temporary disk space required to create the migration store. This results in a reduction of migration failures due to low disk space. The ScanState command now also estimates the size of the compressed migration store.

List of Files Being Migrated: You can use the /listfiles command-line option for the ScanState command to generate a text file list of all files included in the migration.

Usmtutils.exe: This is a new tool that supplements the functionality provided by Scanstate.exe and Loadstate.exe.

Local Group Migration: You can use the new <ProfileControl> section in the Config.xml file to configure local group membership of users during the migration. For instance, you could use this to change users from being members of the local administrators group to being members of the local users group during a migration.

??,???????,??Hard-Link Migration Store???TechNet????Hard-link migration store???????:

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.

In most aspects, a hard-link migration store is identical to an uncompressed migration store. It is located where specified by the Scanstate command-line tool and you can view the contents of the store by using Windows® Explorer. Once created, it can be deleted or copied to another location without changing user state. Restoring a hard-link migration store is similar to restoring any other migration store; however, as with creating the store, the same hard-link functionality is used to keep files in-place.

As a best practice, we recommend that you delete a hard-link store as soon as possible after your migration is complete, 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.
  • Applications reading and writing to files that were migrated may orphan the files from the migration store, resulting in additional disk space being consumed.

For example, a company has decided to deploy Windows® 7 on all of their computers. Each employee will keep the same computer, but the operating system on each computer will be updated.

  1. An administrator runs the ScanState command-line tool on each computer, specifying the /hardlink command-line option. The ScanState tool saves the user state to a hard-link migration store on each computer, improving performance by reducing file duplication, except in certain specific instances.
  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.
  3. An administrator runs the LoadState command-line tool on each computer. The LoadState tool restores user state back on each computer.

This section provides details about hard-link migration stores.

Hard Disk Space

The /hardlink command-line option proceeds with creating the migration store only if there is 250 megabytes (MB) of free space on the hard disk. 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 on the size of the migration.

It is not necessary to estimate the size of a hard-link migration store. Estimating the size of a migration store is only useful in scenarios where the migration store is very large, and on NTFS volumes the hard-link migration store will require much less incremental space than other store options. The only case where the local store can be quite large is when non-NTFS file systems exist on the system and contain data being migrated. Since NTFS has been the default file system format for Windows XP and Windows Vista®, this situation is unusual.

Migration Store Path on Multiple Volumes

Separate hard-link migration stores are created on each NTFS volume that contain data being migrated. In this scenario, the primary migration-store location will be specified on the command line, and should be the operating-system volume. Migration stores with identical names and directory names will be created on every volume containing data being migrated. For example:

Scanstate /hardlink c:\USMTMIG […]

Running this command on a system that contains the operating system on the C: drive and the user data on the D: drive will generate migration stores in the following locations, assuming that both drives are NTFS:

C:\USMTMIG\

D:\USMTMIG\

The drive you specify on the command line for the hard-link migration store is important, because it defines where the master migration store should be placed. The master migration store is the location where data migrating from non-NTFS volumes is stored. This volume must have enough space to contain all of the data that comes from non-NTFS volumes. As in other scenarios, if a migration store already exists at the specified path, the /o option must be used to overwrite the existing data in the store.

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.

Files that are locked by an application or the operating system are handled differently when using a hard-link migration store.

Files that are locked by the operating system cannot remain in place and must be copied into the hard-link migration store. As a result, selecting many operating-system files for migration significantly reduces performance during a hard-link migration. As a best practice, we recommend that you do not migrate any files out of the \Windows directory, which minimizes performance-related issues.

Files that are locked by an application are treated the same in hard-link migrations as in other scenarios when the volume shadow-copy service is not being utilized. The volume shadow-copy service cannot be used in conjunction with hard-link migrations. However, by modifying the new <HardLinkStoreControl> section in the Config.xml file, it is possible to enable the migration of files locked by an application.