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.
Note:
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.
|
Planning
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.
|
USMT and ACT
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.
