Best Practices

Security best practices

As the authorized administrator, it is your responsibility to protect the privacy of the users and maintain security during and after the migration. In particular, consider the following issues.

• Encrypting File System (EFS). You should take extreme caution when migrating encrypted files to computers running Windows XP. This is because the end user does not need to be logged on or even present to capture the user state. By default, USMT fails if an encrypted file is found. In order for USMT to successfully migrate EFS certificates, the end user is needed both before and after the migration. For more information about EFS best practices, see article 223316 in the Microsoft Knowledge Base. For specific instructions, see How To Migrate EFS Files and Certificates.

• Encrypt the store. You should consider using /encrypt (on the ScanState command line) and /decrypt (on the LoadState command line). However, you should use extreme caution with this option because anyone that has access to the ScanState command line script will also have access to the encryption key.
• Virus scan. We recommend that you scan both the source and destination computers for viruses prior to running USMT. In addition, you should scan the destination computer image. Running an antivirus utility prior to migration will ensure that all data is virus-free.
• Maintain security of the file server and the deployment server. We recommend that you manage the security of the file and deployment servers. It is important to make sure that the file server where you save the store is secure. You will also need to secure the deployment server to ensure that the user data that is in the log files is not exposed. You should not transmit data over an Internet connection unless you have a secure connection (such as a virtual private network) because most of the data that you are migrating will be unencrypted.
• Password migration. To ensure the privacy of the end users, USMT does not migrate passwords (including those for applications such as Microsoft Outlook Express, Microsoft Internet Explorer, as well as Remote Access Service (RAS) connections and mapped network drives). It is important to make sure that the end users know their passwords. In order to ensure that all passwords are known, you should ask end users to change and record their passwords before the migration.
• Local account creation. Before you migrate local accounts, see Migrating local and domain accounts.
• Administrator security. In some organizations, it is critical to keep the user state secure from the administrator who is performing the migration. If the administrator's access to user states is a security concern for you, you can use the following precautions:
  • Have the end user perform the migration using USMT, a scripted-manual method, or the PC Migration Assistant. Under the scripted-manual method, the user must be able to restore the user state by logging on as the administrator.
  • When securing the state in the temporary store, make sure that while the root folder might allow full user access, the individual user folders only allow access for IT staff and the owner of the folder.
  • Use Internet Protocol security (IPSec) or other network security protocols to secure data as it travels over the network.
  • Use a software deployment tool that uses restricted rights.
  • The deployment engineer should not have physical access to the end-user computer. All troubleshooting and control should be performed through secure interfaces.

General best practices

• Install applications before LoadState. Though it is not always essential, it is good practice to install all applications on the destination computer before restoring the user state. This ensures that migrated settings are preserved. Specifically, if the following applications are installed on the source computer, they must be installed on the destination computer prior to running LoadState: Lotus SmartSuite, RealPlayer Basic, and Quicken 2004 Home and Business.
• Close all applications before running ScanState or LoadState. If some applications are running during ScanState or LoadState, USMT may not migrate some data. For example, if Outlook is open, USMT may not migrate .pst files. USMT will fail if it cannot migrate a file or setting unless you specify /c. When you specify /c, USMT will ignore the errors, and log an error each time it encounters a file that is in use that did not migrate.
• Log off after you run LoadState. Some settings (for example, fonts, wallpaper, and screensaver settings) will not take effect until the next time the user logs in. For this reason, you should log off after you run LoadState.
• Managed environment. To create a managed environment, you may want to move all of the end user’s documents into My Documents (%CSIDL_PERSONAL%). We recommend that you migrate files into the smallest possible number of folders on the destination computer. This will help you to clean up files on the destination computer if LoadState fails to complete.
• Chkdsk.exe. We recommend that you run Chkdsk.exe before running ScanState and LoadState. Chkdsk creates a status report for a hard disk drive and it also lists and corrects common errors. For more information about this tool, see Chkdisk at the Microsoft Web site.
• Migrate in groups. If you decide to perform the migration while users are using the network, it is best to migrate user accounts in groups. In order to minimize the impact on network performance, you should determine the size of the groups based on the size of each user account. Migrating in phases also allows you to make sure each phase is successful before starting the next phase. This also allows you to make any necessary modifications to your plan between groups.