Datasheet

Designing User State Migration 23
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 pro-
tect 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.
Testing Designed Strategy
Once you’ve identified what strategy you’ll use to migrate the user’s data (in-place migra-
tion, 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 remem-
ber the exact commands and the specific switches.
597095c01.indd 23 6/2/10 4:12:58 PM