Planning for the Installation of Windows 7 : Designing User State Migration

If you've looked at the upgrade paths from earlier versions of Windows to Windows 7, you may have been a little surprised. There are very few upgrade choices. Some of the possible upgrade paths to versions likely to be used in the Enterprise are

• Vista Business to Windows 7 Professional, Enterprise, and Ultimate

• Vista Enterprise to Windows 7 Enterprise

• Vista Ultimate to Windows 7 Ultimate

If you're migrating other existing Windows clients, you probably won't be able to do an upgrade. This doesn't have to be as painful as it sounds. The User State Migration Toolkit has undergone significant changes and improvements and will make your job a lot easier.

USMT can be used in three types of migrations. Each one assumes that you have files and settings from a Windows XP, Windows Vista, or Windows 7 installation that you want to restore to a new installation of Windows 7.

In-place migration

An in-place migration uses the same hardware for the old and new installations of Windows. Hard drive partitions are not modified, and files and settings from the previous installation are automatically retained in the Windows.old folder.

Wipe-and-load migration

A wipe-and-load migration uses the same hardware. However, partitions on the hard drive holding the original operating system need to be modified, which will prevent the Windows.old folder from being created during the new installation. Instead, you must use USMT before the installation to save the files and settings to a migration store from the previous installation. This migration store can then be restored to the new installation of Windows 7.

Side-by-side migration

A side-by-side migration uses two computers. You can use USMT to save the files and settings to a migration store from the original computer before it's decommissioned. You can then use USMT to restore the migration store to Windows 7 on the new computer.

In this section, you'll learn where to get the USMT, how to install it, and how to use it in each of the different types of migration.

1. User State Migration Toolkit

If you used the User State Migration Toolkit (USMT) from previous operating systems, you may not have been overjoyed by the performance. I know I wasn't. However, you'll find significant improvements in the USMT on Windows 7. In addition, the time required to perform a migration has been substantially reduced.

The User State Migration Toolkit is a part of the Windows Automated Installation Kit (AIK) for Windows 7. Older versions of the AIK exist, so you need to ensure you have the version specifically designed for Windows 7.

You can use the USMT to migrate data from Windows XP, Windows Vista, or Windows 7. It supports the following migration paths:

• Windows XP to Windows Vista

• Windows XP to Windows 7

• Windows Vista to Windows 7

• Windows 7 32-bit to Windows 7 64-bit

The Windows AIK is available as a free download from Microsoft's download site (www.microsoft.com/downloads) by searching for "Windows Automated Installation Kit (AIK) for Windows 7." This download is an .iso file, so you'll need to burn it to a DVD.

Once you download the Windows AIK for Windows 7 and burn the image to a DVD, insert the DVD into your computer's drive. You can then follow the steps in Exercise 1 to install the Windows AIK, which includes the USMT.

Once the Windows AIK is installed, you'll have several program links on the Start menu within the Microsoft Windows AIK Start menu folder. These include

Deployment Tools Command Prompt

This launches a command prompt at the C:\Program Files\Windows AIK\Tools\PETools folder, which gives you access to many of the files used when creating a Windows Preinstallation Environment (Windows PE or WinPE).

Windows System Image Manager

This is used to create an unattend.txt text file that can be used to automate an installation and to open images.

Documentation

This provides links to several help files including the Unattended Windows Setup Reference, the Windows Automated Installation Kit, and the Windows PE User's Guide. Not all help files are available here. The help file for the USMT isn't accessible here even though it was installed. The USMT help file is available in the C:\Program Files\Windows AIK\Docs\CHMs folder and is named WAIK.chm.

VAMT 1.2

The VAMT 1.2 folder includes a help file for the Volume Activation Management Tool (VAMT) and a link to launch the Volume Activation Management Tool.

2. Performing In-Place Migration

When you do the installation of Windows on a computer running Windows XP, Windows Vista, or Windows 7, you can do a Custom (Advanced) installation. A message will appear similar to Figure 1.1, informing you that you can access files from the previous installation in a folder named Windows.old.

Figure 1. Windows installation notification

Now all you have to do is get the data out of the Windows.old folder and back to the original location. You can spend hours cutting, pasting, and adjusting permissions, or you can automate the process with the User State Migration Tool.

2.1. Running ScanState and LoadState

Two important files that are added to your system with USMT are ScanState and LoadState. You can use these two files from the command prompt or in batch files to automatically examine your system and restore user accounts, files, and settings in a very short time.

ScanState ScanState will collect files and settings from a previous installation or from the Windows.old folder. It will store these files and settings in a migration store.

LoadState LoadState can read the files and settings from the migration store and restore them to the current computer.

User profiles include a significant amount of data, including the desktop, document folders, Registry settings, and much more. When you use USMT for an in-place migration, it uses a hardlink migration store when the data is migrated from the Windows.old folder. This significantly reduces the time and space required to migrate all of this data. Instead of actually copying the data from one place to another on the hard drive, it just changes the links to where the data is located.

This is similar to what happens when you move a file from one location to another using drag and drop in Windows Explorer. For example, imagine a project on which you are working includes several files, so you decide to create a folder named Project and drag and drop all the files into that folder. The system doesn't create a brand-new copy of these files and then delete the originals. Instead, it just changes the file system links to these files so that they are now "located" in the Project folder.

Similarly, the hardlink migration feature in ScanState and LoadState will change the location of these files without having to copy all of the data. This can be significant if you're dealing with several GB of data.

It's fairly easy to put the ScanState and LoadState commands into a batch file that you can use to automate the migration of files and settings for multiple computers in your network. However, before automating ScanState and LoadState, it's good to know what the commands are doing.

The ScanState command is executed first. The following line shows how it may be executed to retrieve the migration data from the Windows.old folder.

ScanState.exe c:\store /v:13 /o /c /hardlink /nocompress /efs:hardlink
  /i:MigApp.xml /i:MigDocs.xml /offlineWinDir:c:\windows.old\windows

The following bullets break down the command:

• ScanState is the name of the command.

• c:\store is the location where the migration data will be stored.

• /v:13 indicates the highest level of verbosity. It will provide a significant amount of output to the log that can be viewed later. The lowest level is 0, which logs only errors and warnings.

• /o causes it to overwrite an existing migration store (if one exists).

• /c tells ScanState to continue to run even if errors are encountered.

• /hardlink is used for in-place migrations to retrieve the data from the Windows.old folder. It requires the use of the /nocompress switch.

• /nocompress specifies that data is not compressed.

• /efs:hardlink specifies that encrypted file system (EFS) files will be moved using hardlink migration. The /hardlink switch must be used for this to succeed.

• /i:MigApp.xml specifies that the MigApp.xml file (which is included in the USMT folder) will be used to identify application settings to migrate.

• /i:MigDocs.xml specifies that the MigDocs.xml file (which is included in the USMT folder) will be used to identify document types to migrate.

• /offlineWinDir:c:\windows.old\windows is used to specify the location of the files from the original installation.

After the ScanState command is executed to capture the migration data, the LoadState command is executed to restore the migration data to the current installation.

When performing in-place migrations, you can enter the LoadState command with the following switches.

LoadState.exe c:\store /v:13 /c /lac:P@ssw0rd /lae /i:MigApp.xml
  /i:MigDocs.xml /sf /hardlink /nocompress

• LoadState.exe is the command.

• c:\store is the location of the migration store created by ScanState.

• /v:13 indicates the highest level of verbosity. It will provide a significant amount of output to the log that can be viewed later. The lowest level is 0, which logs only errors and warnings.

• /c tells ScanState to continue to run even if errors are encountered.

• /lac:P@ssw0rd specifies that local accounts should be created if they don't already exist. If the /lac switch is not used, local accounts will not be migrated. The same password will be used for all migrated accounts, and if a password is not specified, the password will be empty. You should use caution if using the password in a batch file because it will be stored in clear text, and anyone with access to the batch file can read the password.

• /lae specifies that local accounts should be enabled. The /lac switch must be used to migrate the accounts. When it is used, all migrated accounts will be enabled.

• /i:MigApp.xmlspecifies that the MigApp.xml file (which is included in the USMT folder) will be used to identify application settings to migrate.

• /i:MigDocs.xml specifies that the MigDocs.xml file (which is included in the USMT folder) will be used to identify document types to migrate.

• /sf restores shell folder redirection if a user had previously used folder redirection on any of their user folders. For example, a user may have redirected the My Documents folder to be stored on a server share or on a different partition.

• /hardlink is used for in-place migrations to retrieve the data from the Windows.old folder. It requires the use of the /nocompress switch.

• /nocompress specifies that data is not compressed.

Exercise 2 will lead you through the process of creating a batch file and running it to migrate user data for in-place migrations. This assumes that the computer was running Windows XP, Windows Vista, or Windows 7 and that a clean installation of Windows 7 was then performed on the system. Data from the previous installation is stored in the Windows.old folder of the C: drive. Last, the Windows AIK for Windows 7 is also assumed to have been installed on this system.

While the previous exercise had you create a batch file with the ScanState and LoadState commands, it is possible just to execute the commands at the command prompt. However, if you have created the batch file, you can create your own portable tool that can be easily executed on any system to perform an in-place migration.

2.2. Creating a Portable USMT Batch File

If desired, you can make your batch file a little more portable. Instead of installing the Windows AIK for Windows 7 on every computer that you are migrating, you can copy the appropriate files to a USB flash drive or CD. These files consume only about 50 MB.

You can then bring your USB flash drive or CD to any computer that has had an in-place migration, run the batch file, and the migration will be done in minutes.

You'll still need to install the Windows AIK onto a Windows 7 computer. Once it's installed on any Windows 7 computer, you can use Windows Explorer to copy the USMT folder onto the portable media such as a USB flash drive.

• Browse to the C:\Program Files\Windows AIK\Tools\USMT folder.

• Right-click the USMT folder and select Copy.

• Insert a USB flash drive.

• Browse to the USB flash drive using Windows Explorer, right-click, and select Paste.

At this point, you'll have the entire contents of the USMT folder on the flash drive. This includes the USMT folder used for 64-bit systems (\USMT\amd64\) and the folder used for 32-bit systems (\USMT\x86).

Now you'll need to create a batch file that can be used on any system. The batch file used in the previous exercise can be used as a starting point, but it will need to be slightly modified.

The USMT files need to be copied to the C: drive on the system that is being migrated, so the first step in the batch file is to copy these files. This sounds simple enough, but it's impossible to tell what the letter of the USB drive will be when it's plugged in on any given system. That is, when you plug the USB into Sally's computer, the USB disk may be assigned the letter E:, but when you plug it into Joe's computer, it might be assigned the letter F:.

You can use the following If exist statement in the batch file to check to see if the USB flash drive is assigned the letter D:. It checks for the USMT folder at the root of D:. If it exists, it assumes this is the USB flash drive and copies the USMT folder from the flash drive to the Windows folder on the C: drive.

If exist D:\USMT\*.* XCopy /e /v /y C:\Windows\USMT\

The /e switch specifies that all directories should be copied—even empty ones. The /v switch is used to verify the files, and the /y switch is used to suppress prompting if any files are overwritten.

Unfortunately, this works only if the USB flash drive is assigned the letter D:. It could be assigned other letters such as E:, F:, and so on. You can add multiple lines to your batch file to check for which letter is actually assigned to the USB flash drive. Simply copy and paste the following line, changing only the letter of the drive:

If exist E:\USMT\*.* XCopy /e /v /y C:\Windows\USMT\
If exist F:\USMT\*.* XCopy /e /v /y C:\Windows\USMT\

Once you have added the extra lines, the rest of the batch file becomes a little easier. You now know your USMT files exist in the C:\Windows\USMT\x86 and the C:\Windows\USMT\AMD64 folders. You simply change to the appropriate directory and run the ScanState and LoadState commands.

For example, if you were migrating data to a 32-bit installation of Windows 7, you'd use the following batch file shown in Listing 1.

Example 1. Batch file for 32-bit data migration

If exist D:\USMT\*.* XCopy /e /v /y C:\Windows\USMT\
If exist E:\USMT\*.* XCopy /e /v /y C:\Windows\USMT\
If exist F:\USMT\*.* XCopy /e /v /y C:\Windows\USMT\
If exist G:\USMT\*.* XCopy /e /v /y C:\Windows\USMT\
If exist H:\USMT\*.* XCopy /e /v /y C:\Windows\USMT\
If exist I:\USMT\*.* XCopy /e /v /y C:\Windows\USMT\
rem
Cd "c:\Windows\USMT\x86"
ScanState.exe c:\store /v:13 /o /c /hardlink /nocompress /efs:hardlink
  /i:MigApp.xml /i:MigDocs.xml /offlineWinDir:c:\windows.old\windows
LoadState.exe c:\store /v:13 /c /lac:P@ssw0rd /lae /i:MigApp.xml
  /i:MigDocs.xml /sf /hardlink /nocompress

This batch file checks to see if the USB drive has been assigned letters D: through I:, but if you want to check for all possible drive letters just copy an If exist line, paste it, and modify the letter in the new line. You can check for all drive letters up to Z: if desired.

You could save this file as usmt32.bat.

However, if you needed to run the migration on a 64-bit system, you could replace x86 with amd64 in the change directory line and save the file as usmt64.bat.

Cd "c:\Windows\USMT\amd64"

3. Wipe-and-Load Migration vs. Side-by-Side Migration

The majority of this section has covered an in-place migration. A common scenario is where a Windows XP system has the hardware to support Windows 7. Windows 7 is installed, and the user's data and settings are then migrated from the Windows.old folder.

However, there are some scenarios where the existing system needs to be wiped clean or completely replaced. In these scenarios, you can still use the USMT commands to capture the files and settings and then later restore them, but the process is a little different. The two possible scenarios are a wipe-and-load migration or a side-by-side migration.

Wipe-and-load migration A wipe-and-load migration uses the same hardware but removes all data on the partitions. A simple example would be a system that has multiple partitions that aren't needed in Windows 7, so the drive is reconfigured as a single partition. Repartitioning the disk will result in the loss of all the data, so before this is done ScanState is run to capture all the files and settings. The ScanState data can be stored on a server, as shown in Figure 1.2, stored on an external USB drive, or even stored on a USB flash drive if the user doesn't have much data. After Windows 7 is installed, LoadState is executed to restore these settings from the server (or the external USB or flash drive). Figure 2 shows a wipe-and-load migration.

Figure 2. Wipe-and-load migration

Side-by-side migration In a side-by-side migration, a user has an older computer system that will be replaced. ScanState is run on the older system, and this older system is then decommissioned. The ScanState data can be stored on a server, as shown in Figure 2, stored on an external USB drive, or stored on a USB flash drive if the user doesn't have much data. A newer system with Windows 7 is provided, and LoadState is executed on it to restore the files and settings. Figure 3 shows a side-by-side migration.

Figure 3. Side-by-side migration

In both scenarios, the process is similar:

When ScanState is run for wipe-and-load and side-by-side migrations, the /offlineWinDir:c:\windows.old\windows switch is omitted. Instead of capturing the files and settings from the Windows.old folder, ScanState will retrieve the migration data from the actual system. In addition, instead of storing the results in the C:\Store folder, you could map a Universal Naming Convention (UNC) path to a share on a server or connect an external USB drive.

As an example, imagine that you have connected an external USB drive, and it is assigned the letter G:. The following ScanState command could be used:

ScanState.exe g:\store /v:13 /o /c /hardlink /nocompress /efs:hardlink
  /i:MigApp.xml /i:MigDocs.xml

The captured files and settings can be restored to the Windows 7 operating system with the following command. The only thing that will change is the letter of the drive where the \store folder is stored. For example, it may be G: on the original installation that had multiple partitions, but the external drive may be E: on a system that has Windows installed with only a single partition and a single DVD drive.

LoadState.exe e:\store /v:13 /c /lac:P@ssw0rd /lae /i:MigApp.xml
  /i:MigDocs.xml /sf /hardlink /nocompress

4. Determining Which User Data and Settings to Preserve

When running ScanState, you have some choices for which data and settings to preserve. The easiest choice is to accept the defaults. If your environment is typical and doesn't include any critical one-of-a-kind applications, this choice will meet most, if not all, of your needs. You can modify the defaults with the following files:

MigDocs.xml

This file includes rules used to find user documents on a computer. Some of the common file types identified in this document are .accdb, .ch3, .csv, .dif, .doc*, .dot*, .dqy, .iqy, .mcw, .mdb*, .mpp, .one*, .oqy, .or6, .pot*, .ppa, .pps*, .ppt*, .pre, .pst, .pub, .qdf, .qel, .qph, .qsd, .rqy, .rtf, .scd, .sh3, .slk, .txt, .vl*, .vsd, .wk*, .wpd, .wps, .wq1, .wri, .xl*, .xla, .xlb, and .xls*.

MigApps.xml

This file includes the rules used to migrate application settings. It will migrate many common applications published by Apple, Google, IBM, Intuit, Microsoft, and others.

MigUser.xml

This file includes rules that can be used to identify different elements of user profiles to include or exclude from the migration. By default, all users are migrated. This file is not used to specify which users to migrate.

Config.xml

The Config.xml file is optional and is created using the /genconfig switch with ScanState. It can be used specifically to exclude certain components or operating system settings from the migration.

The User State Migration Tool (USMT) 4.0 User's Guide includes the article "What Does USMT Migrate?" which includes all the details of exactly what is migrated by default. This user guide is in the form of a help file named USMT.chm located in the C:\Program Files\Windows AIK\Docs\CHMs folder when the Windows AIK is installed.

5. Local vs. Remote Storage Considerations

When creating the migration store, you can use ScanState to store it locally or remotely. Locally means you're storing the migration store on a removable USB drive or on an internal drive for a side-by-side migration. Remotely means you're storing the migration data in a shared folder on a server in your network.

Storing data on a network share can be very convenient, but it can also result in a significantly slower migration process. A migration store can hold a large amount of data. With the size of files and the abundance of hard drive space, it would be easy for a user to accumulate 10 GB of data or more. If you're saving this to a network share over a 10Mbps or even a 100Mbps network connection, you'll be waiting awhile.

Not only will you be waiting, but users on the network may also find themselves waiting longer than normal. You should consider how storing the data on network shares affects the rest of the network. If the network is already busy and you begin moving gigabytes of storage over it, things may slow to a crawl and users will start complaining.

If your network infrastructure is reliably running with GB network interface cards, routers, and switches, you will probably be able to use network storage without any problem.

6. Securing Migrated Data

The amount of data included in a migration store can be considerable and, depending on the user's job responsibilities, the data can be sensitive. Any migration stores with sensitive data should be protected until they are used to restore the user's files and settings. They should be destroyed after the user's files and settings have been restored.

Sensitive data contained in the migration store could include the following:

• Classified information such as secret data

• Company secrets such as financial data, future product details, or plans for mergers

• Personally identifiable information (PII) on customers and employees, including names, addresses, phone numbers, social security numbers, and credit card information

At the very least, migration stores should be treated with the same level of protection as the original data. For example, if a user has secret data on her system, the migration store obtained from this system should be treated with the same level of protection used to protect the source data.

This becomes especially important when storing the data on external USB drives. Because these drives are highly portable, it's possible for an administrator to migrate secret data to an external USB drive and then use this migration store to restore the files and settings on a new computer. If the administrator stops there, the USB drive will still hold the secret data. If an educated user later comes across this USB drive and sees the migration store, he could run the LoadState command and restore all the data to his computer.

Destruction of the migration store can take several different forms depending on the type of data used. Some programs will erase the data and overwrite random patterns of 1s and 0s to ensure there isn't any data remaining on the drive that can be recovered.

7. Testing Designed Strategy

Once you've identified what strategy you'll use to migrate the user's data (in-place migration, wipe-and-load migration, or side-by-side migration), you should do some testing.

Except for the wipe-and-load migration, you'll have the original data that can be used to try to save the migration data over and over again. The in-place migration retains the original files and settings in the Windows.old folder, so if you're not happy with the results of either ScanState or LoadState, you can simply rerun the commands. Similarly, as long as you keep the original computer in a side-by-side migration, you can rerun both of the commands. However, you have only one chance to run ScanState with a wipe-and-load migration.

After testing and determining the best method, it's worth your time to document the procedure in a batch file that can easily be run without your having to struggle to remember the exact commands and the specific switches.