Windows 7 : Migrating User State Data - Planning User State Migration Using USMT

9/6/2012 1:37:19 AM
Thoughtful planning is a critical factor in the success of any user state migration project. By identifying the scope of the migration, you can plan storage space requirements, labor, and development time required to successfully implement the migration solution. This section describes user state migration planning topics such as using subject matter experts (SMEs), identifying and prioritizing user state data, storing user state data, and testing the effort.


The team responsible for planning and developing user state migration must work hand-in-hand with the team responsible for application deployment. Both teams will share a lab environment, application portfolio, SMEs, and so on.



Doug Davis, Lead Architect

Management Operations & Deployment, Microsoft Consulting Services

The main thing I have found about user state migration is that very few companies actually know which files they need to migrate. Even fewer have an idea about settings. The largest concern is, of course, lost data—the settings matter less.

Customers who use IntelliMirror features such as folder redirection and offline folders are the easiest to deal with; however, these customers are the minority. There are really only two ways to get user data and files. Asking the client which files they use never works and just drags out the process. You're left with another way that drives user feedback: to do full backups on your proof-of-concept and pilot groups and run standard USMT without any custom settings. When users ask for files to be recovered from the backup, you add them to the custom settings to be retained.

The second way takes a little bit longer and is what I call intern-ware: If you have an intern, you can give him or her this busy work. Figure out which applications are critical to you, search the registry for "open with," and cross-reference the file extensions to the program.

1. Choosing Subject Matter Experts

Although IT professionals in small organizations probably know each application and the settings used in the computing environment, this is highly unlikely to be the case in large organizations that potentially have thousands of applications. In large organizations, you should use SMEs to help in the planning, development, and stabilizing processes. SMEs, though not necessarily experts, are the users who are most familiar with the applications and data to migrate, and they're usually stakeholders in seeing that the process is properly performed.

Use SMEs to assist with several key tasks:

  • Locating application source media, such as CDs or DVDs

  • Identifying document storage locations for each application

  • Identifying application configuration data and settings to migrate

  • Selecting the operating system preferences to migrate

  • Consulting on file relocations that will be performed as part of the migration

2. Identifying User State Data

User state data can consist of many elements: settings that customize the user experience, application data created by the user, e-mail and messaging settings and data, and even personal data. The following sections describe examples of user state data.

2.1. Operating System Settings

The following list describes many of the operating system files and settings that you will want to migrate. (USMT migrates most of these by default.)

  • Appearance settings Examples include desktop background, colors, sounds, and screensaver settings.

  • User interface settings Examples include mouse pointers, whether double-clicking a folder opens it in a new window or in the same window, and whether users must click or double-click an item to open it.

  • Windows Internet Explorer settings Examples include home pages, favorites, cookies, security settings, and proxy settings.

  • Mail settings Examples include mail server settings, signature files, and contact lists.

2.2. Application Data and Settings

You will find application data in a number of locations. As you inventory the applications in your environment, consider the following potential locations for application settings and data storage:

  • The Program Files folder Many applications still store settings and data directly in the Applications folder within Program Files. As you plan the migration, consider whether or not you can safely redirect the application data to a different location. This will assist with future attempts to allow use of the application by standard (non-administrator) users.

  • A specific folder on the local disk Many applications define a data storage location on the local disk for storage of application settings and data. This location is often the root of the system drive.

  • The user's profile folder Many applications store data in user profile folders. Search the Documents And Settings folder (in Windows XP) or the Users folder (in Windows Vista and Windows 7) for application settings and data files.

2.3. Users' Documents

Users will store data in a variety of locations. The following strategies will help you locate users' documents:

  • Search user profile folders The Desktop and My Documents folders are only two of many locations where you will find user data in the user profile folders. Ideally, however, these two folders are the primary location of users' documents.

  • Interview users and SMEs Survey users and interview SMEs to determine common storage locations for documents. An intranet Web site, possibly based on Windows SharePoint Services, is an ideal data-collection tool.

  • Scan a sample of disks Search the local disks for common document file extensions such as .doc and .xls. Although you can't scan every disk in the organization, you can scan a representative sample to give you an idea of where you'll find documents.

  • Search Recent Documents Scan the Recent folder in users' profiles to determine the locations most frequently used to store data. This can expose some of the less intuitive storage locations. Search a representative sample of users in the organization.



Doug Davis, Lead Architect

Management Operations & Deployment, Microsoft Consulting Services

Application Compatibility Toolkit 4.0 (ACT 4.0) always grabbed the registered file extensions in the log files but never posted them to the database. In my review of the functional specification of ACT 5.0, I asked to have that log data posted to the database even if it wasn't exposed in the graphical user interface (GUI).

With a little work using SQL Server, you should be able to use ACT to find out which applications you are migrating and then sort the file extensions you need for USMT in a more logical fashion. For example, you can extract the file extensions that are a high priority from the ACT database for applications in the portfolio and then focus on migrating those applications first.

3. Prioritizing Migration Tasks

As you compile your user state migration requirements, prioritize them according to their impact on the organization. It's important to the success of this project to concentrate first on mission-critical data and later on preferences such as desktop wallpaper or screensaver settings. Prioritizing requirements helps the development personnel to prioritize their work. SMEs are a valuable source of input when prioritizing the migration requirements.

4. Choosing a Data Store Location

USMT stores user state in a data store. USMT can create the data store in a variety of locations and media during migration. By default, USMT creates a store file that contains compressed user data. It can also encrypt the data store to protect the data during the transition to the new operating system. As you prepare for user state migration, you must determine the best location for the USMT data store.

Consider the following when locating the USMT data store:

  • Hard-link migration reduces storage requirements During a hard-link migration, USMT maps how a collection of bits on the hard disk is wired into the file system. It allows you to remove the old operating system and install Windows 7 without requiring you to create copies of the original files. After installing Windows 7, USMT restores the original file links. Hard-link migration uses significantly less disk space and takes considerably less time, but you can perform a hard-link migration only in the Refresh Computer scenario.

  • USMT cannot store multiple operations in the same file USMT operations can collect data from more than one user but cannot store more than one operation in a single store file. In a high-volume migration, you can either locate the data store locally (which is only possible because the Windows 7 imaging process is nondestructive) or locate each data store on the network (possibly organized by computer name). Note that MDT 2010 handles the data store location automatically and provides choices for customizing it.

  • User state data can use significant space When creating your migration plan, you can run the ScanState component of USMT with the /p:<path to a file> command-line option to create a size estimate. If you're locating the data store on a server, rather than locally, run this command on a representative sample of computers in the environment to calculate the storage required.

  • The USMT data store must be accessible to both the source and target systems When writing to or reading from the data store, USMT must have access to that data store. Locate the file somewhere that will be available to both computers. MDT 2010 handles this issue somewhat transparently. If you're locating the data store locally, access is not an issue.

4.1. Local Data Stores

You can locate the USMT data store on the local disk in the Refresh Computer scenario.  ImageX and Windows Setup are nondestructive, which means that they can install the operating system without destroying the data on the disk. This optimizes the speed of the migration process because network speeds and removable media speeds are factored out of the process. MDT 2010 provides the option to use local data stores.

A better option is using a hard-link migration store, which enables you to perform an in-place migration in which USMT maintains all user state on the local computer while you remove the old operating system and install the new operating system. Therefore, hard-link migration is suitable only for the Refresh Computer scenario. Using a hard-link migration store drastically improves migration performance and significantly reduces hard-disk utilization, reduces deployment costs, and enables entirely new migration scenarios.

4.2. Remote Data Stores

In the Replace Computer (side-by-side) and New Computer scenarios, you can put the USMT data store on a network server. In these scenarios, putting the data store on the network is necessary because the local data store will not be available in the postinstallation phase.

4.3. Removable Storage

You can also put USMT store files on removable media during the migration process. You can use flash disks and portable hard disks to simplify this process. Because this step adds interaction to the process, it is recommended only in bench deployments or in scenarios in which you've already factored interaction into the deployment process.

5. Automating USMT

The full power of the USMT is realized when you automate migration. Through the use of scripting techniques—or tools such as MDT 2010 and Microsoft System Center Configuration Manager 2007—you can automate the migration of large numbers of systems. The following list describes each option:

  • Scripting You can execute USMT with a variety of scripting tools, including Windows PowerShell, VBScript, and batch script files. By including the appropriate command-line options, you can automate the migration process to collect and restore user state data. End users can then execute these scripts to migrate their own data.

  • Microsoft Deployment Toolkit MDT 2010 fully enables user state migration as part of the LTI and ZTI deployment processes. You can customize the location of the data stores and customize the migration .xml files to include or exclude user state as defined by your requirements (although this is often not necessary with USMT 4.0). Using the default migration .xml files with MDT 2010 is an extremely simple, straightforward process. Thus, the only real effort is in creating custom migration .xml files for USMT, if necessary.

  • Configuration Manager Configuration Manager can be used as is or with MDT 2010 to automate user state migration as part of operating system deployment. For more information about using USMT with Configuration Manager alone, see the System Center Configuration Manager 2007 documentation.

6. Testing User State Migration

After you set up the USMT migration .xml files and infrastructure, you should conduct a test pass to ensure that the solution works as planned. Test modularly: start with migration files first, followed by command-line options and automation. As you create the project plan, define testable criteria. With a test plan already established, you will be prepared to begin testing as soon as the development is complete.

6.1. Creating a Lab Environment

Establish a test lab with equipment and settings similar to systems in production in your organization. The goal is to test each scenario you will see in the production environment. Duplicate your production environment in as much detail as possible. Set up migration servers and data stores, configure source and target client systems, and prepare and place control files in the appropriate locations. Finally, execute the test and measure the results. The team responsible for user state migration should share a lab environment with the team responsible for application deployment.

6.2. Choosing Sample Data

If possible, conduct the migration tests on actual production data. You can copy this data from production systems as you prepare for the testing. For example, you can create images of SME computers for testing purposes. Testing on production data helps ensure that you expose the migration infrastructure to all scenarios that will be seen in the production environment.

Be sure to choose the following types of production data:

  • Operating system settings You should test desktop and appearance settings. Users can nominate elements for testing, or you can select a sample based on the results of user surveys. Test user profile settings and user preference settings to ensure that they are properly migrated. Identify a set of user settings that you can test.

  • Application data and settings Include application data such as configuration files and data files in your test plan. Test application registry settings and initialization files to ensure that they are properly migrated. Work with developers and SMEs to identify a representative sample of these configuration settings to test.

  • Users' documents Choose a representative sample of user data. Include sources such as My Documents and any custom data folders found in your environment.

6.3. Running the Test

Run the USMT test using the migration .xml files and procedures that you have developed for the production environment. The goal is to simulate the production migration with as much detail as possible. Be sure to use any scripts and processes designed to automate the USMT process.

6.4. Validating the Test Results
Following the migration test, verify all user state elements that have been defined for testing. View each setting and test each migrated application. Open the e-mail client and operate applications to ensure that user customizations still exist in the new system. Identify any errors and list any items that failed to migrate. Investigate these elements to ensure that you properly configured the control files for the migration. If necessary, retest to verify that problems have been resolved.
  •  Windows Server 2003 : Backing Up Data
  •  Windows Server 2003 : Selecting a Backup Medium, Developing a Backup Strategy
  •  Ivy Bridge Laptop Attacks The Market
  •  Lenovo Introduced Two AMD Trinity Chipped Laptops In Japan
  •  Lenovo Upgrades A Mass Of Laptops With Ivy Bridge Chips
  •  Windows Vista : The Wired Ethernet Network - Add PCs
  •  Windows Vista : The Wired Ethernet Network - Personalize Your Network
  •  Windows Vista : The Wired Ethernet Network - Connect the Hardware
  •  Understanding the Windows 7 Deployment Life Cycle : Placing an MDT Deployment in the MOF Life Cycle
  •  Understanding the Windows 7 Deployment Life Cycle : Scaling the Deployment Process
  •  Windows Server 2008 and Windows Vista : GPO Replication (part 2) - Client-Side Extensions
  •  Windows Server 2008 and Windows Vista : GPO Replication (part 1) - Group Policy Template and SYSVOL Replication, Active Directory Replication
  •  14-inch Sony Vaio E 2012 Review
  •  Acer 11.6-inch TravelMate B113
  •  Asus Laptop For Students
  •  Asus Zenbook Prime UX31A Review
  •  HP Has Released 3 New Ultra Books
  •  HP Pavilion M6-1045dx
  •  2 More Ivy Bridge Chipped Laptops From Fujitsu
  •  The World's Smallest Desktop Lenovo Q180
    Most View
    Crucial Adrenaline 50GB - Undeniably A Fine Drive
    Buying Advice: DSLR
    Using Your PC to Stream Videos to Your Android Device
    Huawei Ascend G600 - I Wonder Why 600?
    Get A Faster, Safer PC (Part 2) - Clean a PC and keyboard, Prevent PC hacks
    Switching To A Stand-Up Desk (Part 2)
    Synchronizing Mobile Data - Using Merge Replication (part 2) - Programming for Merge Replication
    OData with SQL Azure - Enabling OData on an Azure Database
    Windows Home Server Installation and Configuration
    Creating Link-Worthy Content and Link Marketing : Further Refining How Search Engines Judge Links
    Top 10
    ASP.NET 4 in VB 2010 : The Data Controls - Sorting and Paging the GridView
    Microsoft Content Management Server Development : A Date-Time Picker Placeholder Control (part 2)
    Microsoft Content Management Server Development : A Date-Time Picker Placeholder Control (part 1)
    Microsoft Content Management Server Development : Building SharePoint Web Parts - Configuring the Web Part, Debugging the Web Part
    Windows Server 2008 R2 networking : Planning and Deploying DNS (part 4) - Monitoring and troubleshooting DNS
    Windows Server 2008 R2 networking : Planning and Deploying DNS (part 3) - Setting up DNS zones
    Windows Server 2008 R2 networking : Planning and Deploying DNS (part 2) - Installing the DNS Server role, Configuring DNS Servers
    Windows Server 2008 R2 networking : Planning and Deploying DNS (part 1) - Designing a DNS infrastructure
    Windows Server 2008 R2 networking : Routing and Remote Access
    ADO.NET Programming : Microsoft SQL Server (part 4) - Working with Typed Data Sets