4. Collecting files and settings with ScanState
You must run
ScanState as Administrator. On Windows 2000 and XP systems, you can
simply log on and run the tool with an administrative account. On
Windows Vista systems, you will be prompted by User Authentication
Control (UAC) to allow the tool to run with this required access. Of
course, if you have a systems management solution in place to distribute
the command line, this is ideal. Using group policy, a startup script
can do the job, but keep in mind that a logon script runs in the context
of the user (which will fail unless all your users happen to be
administrators).
ScanState is a command line tool with many options (Table
1 describes each of the options individually). Following this table are
some typical examples of ScanState commands. The syntax for ScanState
is:
scanstate [StorePath] [/i:[Path\]FileName] [/o] [/v:VerbosityLevel]
[/nocompress] [/localonly] [/encrypt /key:KeyString|/keyfile:[Path\]FileName]
[/l:[Path\]FileName] [/progress:[Path\]FileName] [/r:TimesToRetry]
[/w:SecondsBeforeRetry] [/c] [/p] [/all] [/ui:[DomainName\]
UserName]|LocalUserName] [/ue:[DomainName\]UserName]|LocalUserName] [/
uel:NumberOfDays|YYYY/MM/DD|0] [/efs:abort|skip|decryptcopy|copyraw] [/
genconfig:[Path\]FileName] [/targetxp] [/config:[Path\]FileName] [/?|help]
Table 1. ScanState Command Line Parameters
| Option | Description |
|---|
| StorePath | Specifies folder where the files and settings are to be stored. |
| /i | Specifies
configuration xml file containing rules that define what state to
migrate. This is typically used more than once to specify multiples of
such files (such as MigUser.xml, MigApp.xml, MyCustom.xml). |
| /o | Overwrite any existing data in the store. If not specified ScanState will fail if the store already contains data. |
| /v | Specifies the verbosity of the output created in the ScanState log. The default is 0, but valid values range from 0 to 15. |
| /nocompress | Disables
compression (enabled by default). This may be used for troubleshooting
purposes so you can browse the contents or to use a virus scanning
program to scan the contents. |
| /localonly | Limits
migration to files stored on the local computer (regardless of the
rules specified in included xml configuration files). If this option is
not specified, data from external drives on the source computer will be
included in the collection process. |
| /encrypt | Encrypts the store with the specified key (password). The key is specified with the /key or /keyfile options. |
| /key:<KeyString> | Used
with the /encrypt option to identify a KeyString between 8 and 256
characters long. If there is a space in the KeyString value, surround
the string in double quotes. |
| /keyfile:<KeyFile> | Used
with the /encrypt option to identify a text file that contains an
encryption key (as opposed to providing the string on the command line
with the /key option). |
| /l | Specifies
the location of the ScanState log file. This can be specified as a
relative path or a full path, but cannot be the same folder as
StorePath. |
| /progress | Creates
the optional progress log. This can be specified as a relative path or a
full path, but cannot be the same folder as StorePath. |
| /r | Specifies
the number of times to retry when an error occurs. The default is three
times. This can be helpful in environments where network connectivity
is an issue. |
| /w | Specifies the number of seconds to wait between retries (see /r option). The default is 1 second. |
| /c | Causes
ScanState to continue to run even if there are nonfatal errors. Without
this option, ScanState will exit on the first error encountered. Any
such errors are ignored but will be logged in the progress log. |
| /p | Generates
a space-estimate file called usmtsize.txt that is saved to StorePath.
When this option is specified no user stat is collected. Note: You must
also specify /nocompress with this option. |
| /all | This
option explicitly migrates all of the users on the computer, which is
the default behavior unless accounts are excluded with either the /ue or
/uel options. |
| /ui:<UserID> | Migrates
only specified users. You can specify the domain and user name or a
local user name. All users are included by default, so this option is
only helpful when using the /ue or /uel options to exclude users. The
asterisk (*) wildcard is supported. For example, to migrate only the
user named NCKELLY, you could use the following options:
/ue:*\* /ui:domain\NCKELLY
|
| /ue:<UserID> | Excludes specified users from migration. You can specify the domain and user name or a local user name. |
| /uel:<NumberOfDays> | Limits migration to only users that have logged onto the source computer within the specified number of days. |
| /efs:<Setting> | Specifies how the ScanState should handle EFS encrypted files. The following settings may be specified:
/efs:abort: Fail with an error code if an EFS file is found on the source computer
/efs:skip: Ignore all EFS files
/efs:decryptcopy: Decrypt if possible before saving to store
/efs:copyraw: Copy the file in its encrypted state
EFS Certificates are migrated automatically. When migrating to
Windows Vista it is recommended that you use the /efs:copyraw option |
| /genconfig | Generates
a Config.xml file which identifies all items that would be collected.
Instead of collecting the items, it generates a file identifying each
component that would be migrated with the identifier migrate="yes" included with each item. By editing this file to reflect migrate="no" where items should be excluded, the /config option may be used to enforce these exclusions. |
| /targetxp | Optimizes
the process for situations when the destination computer will be
running Windows XP. This option is helpful when creating a store as it
will limit the contents to those items that pertain to Windows XP. This
may also be used with /genconfig to limit the contents of config.xml to
those items that pertain to Windows XP. |
| /config | Specifies
the optional Config.xml file that should be used when creating a store.
This can be specified as a relative path or a full path (if you do not
specify a path, Config.xml must be located in the current directory). |
This example collects
user data and settings (scanstate) by using the default MigUser.xml and
MigApp.xml configuration files (/i:miguser.xml /i:migapp.xml) and saves
the resulting store to \\server\share\store. It creates a verbose log
file with status messages that can be used with a debugger (/v:13) to a
file named scan.log which is created in the current directory
(/l:scan.log):
ScanState \\server\share\store /i:miguser.xml /i:migapp.xml /v:13 /l:scan.log
This next example
generates an usmtsize.txt file (/p) that provides a space-estimate based
on the collection of user data and settings (scanstate) using the
default MigUser.xml and MigApp.xml configuration files (/i:miguser.xml
/i:migapp.xml). The /nocompress option is required when generating a
space estimate file with /p. Finally, because the destination for the
store is a network location, a log file with the /l option must be
specified. In this case, the log file would be created in the current
directory and would record only default errors and warnings (as is
dictated by the default logging level of zero).
ScanState /i:miguser.xml /i:migapp.xml \\server\share\store /nocompress /p
/l:scan.log
This final example
collects user data and settings (scanstate) by using the default
MigUser.xml and MigApp.xml configuration files
(/i:miguser.xml/i:migapp.xml) and saves the resulting store to
E:\localstore. However, only those users who have logged in within the
last 45 days will have their data and settings migrated (/uel:45).
ScanState /i:migapp.xml /i:miguser.xml E:\localstore /uel:45
5. Restoring files and settings with LoadState
Although it is
not always essential, installing all applications on the destination
computer before restoring the user state is a good practice. Doing this
ensures that migrated settings are preserved; otherwise some
applications may overwrite or disregard existing settings restored by
LoadState.
LoadState is a command line tool with many options (Table 2
describes each of the options individually). Following this table are
some typical examples of LoadState commands. The syntax for LoadState
is:
loadstate StorePath [/i:[Path\]FileName] [/v:VerbosityLevel] [/nocompress]
[/decrypt /key:KeyString|/keyfile:[Path\]FileName] [/l:[Path\]FileName]
[/progress:[Path\]FileName] [/r:TimesToRetry] [/w:SecondsToWait] [/c] [/all]
[/ui:[[DomainName\]UserName]|LocalUserName] [/ue:[[DomainName\]
UserName]|LocalUserName] [/uel:NumberOfDays|YYYY/MM/DD|0] [/
md:OldDomain:NewDomain] [/mu:OldDomain\OldUserName:[NewDomain\]NewUserName]
[/lac:[Password]] [/lae] [/q] [/config:[Path\]FileName] [/?|help]
Table 2. LoadState Command Line Parameters
| Option | Description |
|---|
StorePath
| Specifies folder where the files and settings are stored. |
/i
| Specifies
configuration xml file containing rules that define what state to
migrate. This is typically used more than once to specify multiples of
such files (such as MigUser.xml, MigApp.xml, MyCustom.xml, etc.). |
/v
| Specifies the verbosity of the output created in the ScanState log. The default is 0, but valid values range from 0 to 15:
output |
/nocompress
| Specifies that the store is not compressed. |
/decrypt
| Decrypts the store with the specified key. The key is specified with the /key or /keyfile options. |
/key
| Used
with the /decrypt option to identify a KeyString between 8 and 256
characters long. If there is a space in the KeyString value, surround
the string in double quotes. |
/keyfile
| Used
with the /decrypt option to identify a text file that contains an
encryption key (as opposed to providing the string on the command line
with the /key option). |
/l
| Specifies
the location of the LoadState log file. This can be specified as a
relative path or a full path, but cannot be the same folder as
StorePath.
running LoadState from a shared network resource. |
/progress
| Creates
the optional progress log. This can be specified as a relative path or a
full path, but cannot be the same folder as StorePath. |
/r
| Specifies
the number of times to retry when an error occurs. The default is three
times. This can be helpful in environments where network connectivity
is an issue. |
/w
| Specifies the number of seconds to wait between retries (see /r option). The default is one second. |
/c
| Causes
LoadState to continue to run even if there are nonfatal errors. Without
this option, LoadState will exit on the first error encountered. Any
such errors are ignored but will be logged in the progress log. |
/all
| This
option explicitly migrates all of the users on the computer, which is
the default behavior unless accounts are excluded with either the /ue or
/uel options. |
/ui
| Migrates
only specified users. You can specify the domain and user name or a
local user name. All users are included by default, so this option is
only helpful when using the /ue or /uel options to exclude users. The
asterisk (*) wildcard is supported. For example, to migrate only the
user named NCKELLY, you could use the following options:
/ue:*\* /ui:domain\NCKELLY
|
/ue:<UserID>
| Excludes specified users from migration. You can specify the domain and user name or a local user name. |
/uel:<NumberOfDays>
| Limits migration to only users that have logged onto the source computer within the specified number of days. |
/md:<OldDomain>:<NewDomain>
/md:<LocalComputerName>:
<NewDomain>
| Specifies
a new domain for the user(s). This option may be used to change the
domain for users on a computer or to migrate a local user to a domain
account. OldDomain may contain the asterisk (*) wildcard character. |
/mu:<OldDomain\
OldUserName>:<[NewDomain\]
NewUserName>
/mu:<OldLocalUserName>:
<NewDomain\NewUserName>
| Specifies
a new user name for the specified user. If the store contains more than
one user, multiple /mu options may be specified. You cannot use
wildcard characters with this option. |
/lac:<Password>
| Specifies
that if a user account is a local account, and it does not already
exist on the destination computer, to create the account on the
destination computer as a disabled account (to enable the account, the
/lae option must be specified as well).
If /lac is not specified, any local user accounts that do not
already exist on the destination computer will not be migrated. Password
is the password for the newly created account. By default, an empty
password is used. |
/lae
| Enables the account that was created with /lac. You must specify /lac with this option. |
/q
| Allows
LoadState to run without administrative credentials. This option only
migrates the account for the user who is currently logged on. |
/config
| Specifies
the optional Config.xml file that should be used during restore. This
can be specified as a relative path or a full path (if you do not
specify a path, Config.xml must be located in the current directory). |
The following command
restores all user data and settings (LoadState) by using the default
MigUser.xml and MigApp.xml configuration files (/i:miguser.xml
/i:migapp.xml) from the specified store at \\server\share\store.
Finally, because the destination for the store is a network location, we
must also specify a log file with the /l option. In this case, the log
file would be created in the current directory and would record only
default errors and warnings (as is dictated by the default logging level
of zero).
LoadState /i:migapp.xml /i:miguser.xml \\server\share\store /c /l:load.log
This next command
will restore all user data and settings (LoadState) using the
MigUser.xml and custom.xml configuration files (/i:miguser.xml
/i:custom.xml) from the specified store at E:\localstore. This store was
encrypted using the /encrypted option, so to perform the restore, the
/decrypt option is used and the password used as a Keystring during the
ScanState phase is repeated here with LoadState (/key:NINRLS19).
LoadState /i:miguser.xml /i:custom.xml E:\Localstore /decrypt /key:NINRLS19
6. Reviewing best practices
The following are some
best practices to keep in mind when working with USMT. Arguably the most
important of these recommendations focus on security. Remember, when
performing a migration you are taking personal information, potentially
confidential information, and removing it from the environment where it
was secured. Take care with user data by encrypting it, scanning it for
viruses, and deleting the migration stores after the migration has
succeeded.
Close all applications before running ScanState or LoadState:
While Windows Easy Transfer requires it, you could run the USMT tools
with applications running, but doing so may result in a failure to
migrate the settings of those applications.
Install applications before running LoadState:
To better ensure that migrated settings are preserved, it is best to
install all applications on the destination computer before restoring
user data and settings.
Log off after running LoadState:
Some system settings will not take effect until the next time a user
logs in. To fully complete a restoral, log off of the system once
LoadState has finished running.
Consolidate restored files:
To realize a more managed environment, you can redirect the restoral of
documents to the smallest possible number of folders. For example, you
can restore all office document types to the same profile folder
(documents).
Encrypt the store:
Encrypting the store adds an element of security to the data. Use the /
encrypt and /decrypt options to better protect user data and settings.
At the same time, please keep in mind that the key (or password) is
visible in plain text so anyone that has access to the command line (or
your script that is running the command line) will also have access to
this password.
Consider password migration:
USMT does not migrate passwords (including those for applications such
as Outlook, Internet Explorer, Remote Access Service [RAS] connections,
and mapped network drives). In order to ensure that all passwords are
known, it is advisable to have end users change and record their
passwords just prior to the migration.
Perform virus scans: Scan both the source and destination computers for viruses before running USMT.
Maintain the security of the store while it is on your network:
Make certain that the file server where you save the store is secure.
It is also important to secure the deployment server so that user data
in the log files are not exposed.
Migrate in groups:
Particularly if performing the migration while users are using the
network, it is best to migrate user accounts in groups. This both
minimizes the impact on network performance and also allows you to make
sure each phase is successful before moving on to the next. Finally,
this also allows you to make any necessary modifications to your process
between groups.
