You have a computer named Computer1 that runs Windows Vista and a computer named Computer2 that runs Windows 7. You plan to migrate all user profiles and data files from Computer1 to Computer2 by using the User State Migration Tool (USMT). Before performing the migration, you need to determine how much disk space will be required to store the migration data. What should you do?

Introduction / Context:
The User State Migration Tool (USMT) is used to migrate user profiles, files, and settings between Windows installations. Before you perform a migration, especially on systems with limited disk space, it is helpful to know how large the migration store will be. USMT provides a way to estimate this size without actually creating a full compressed store. This question tests your knowledge of the correct command and parameters to use.

Given Data / Assumptions:

• Computer1 runs Windows Vista and is the source computer.
• Computer2 runs Windows 7 and is the destination computer.
• You plan to use USMT to move user profiles and data from Computer1 to Computer2.
• You need to estimate the amount of disk space required to store the migration data before performing the full migration.

Concept / Approach:
USMT consists mainly of two commands: Scanstate and Loadstate. Scanstate runs on the source computer to collect user state data into a migration store. Loadstate runs on the destination computer to apply that data. Scanstate includes a /p (estimate-only) parameter that calculates how much space the store would require without actually creating the entire store. Running this command with /nocompress ensures that the size estimate corresponds to an uncompressed store location such as c:\\store, which is useful for planning.

Step-by-Step Solution:
1. Identify the proper tool for gathering user data from the source computer; this is Scanstate, not Loadstate. 2. Recognize that the size estimation must happen on the source (Computer1), where the user profiles currently reside. 3. Recall that the /p switch with Scanstate instructs USMT to estimate the space requirements instead of actually writing out the entire store. 4. The /nocompress switch ensures that the estimate reflects an uncompressed migration store located at a specified path such as c:\\store. 5. Therefore, running Scanstate c:\\store /nocompress /p on Computer1 is the correct way to estimate the required disk space.

Verification / Alternative check:
USMT documentation clearly states that Loadstate is used only on the destination system to restore data; it does not perform analysis of the source or estimate store size. The /p parameter is attached to Scanstate, not to Loadstate. When you run Scanstate with /p on the source, the tool analyzes the user profiles and reports an estimated size without writing the full migration store.

Why Other Options Are Wrong:
Option a uses Loadstate on Computer1, which is incorrect because Loadstate restores data rather than collecting it, and it does not compute the estimate. Option c also incorrectly uses Loadstate and runs it on the destination, which is not how you size the migration store. Option d attempts to run Scanstate from Computer2 against a network share, but the data to be analyzed resides physically on Computer1; the correct approach is to run Scanstate directly on the source machine.

Common Pitfalls:
One common error is confusing Scanstate and Loadstate because their names are similar. Another mistake is trying to estimate store size on the destination computer, where the user profiles do not yet exist. Finally, some administrators forget to use the /p switch and inadvertently create a full migration store when they only intended to estimate space, which can temporarily consume a large amount of disk space.

Final Answer:
You should run Scanstate c:\\store /nocompress /p on Computer1 to estimate how much disk space the migration store will require.