XP to Windows 7 Migration with Microsoft Deployment Toolkit 2010

Solutions Plus:

PROBLEM: You need to migrate several Windows XP machines to Windows 7.

SOLUTION: Use Microsoft Deployment Toolkit 2010

WHAT YOU NEED: Microsoft Deployment Toolkit 2010, Windows Automated Installation Kit for Windows 7

SOLUTION STEPS:f

1. Install MDT

2. Create a Deployment Share

3. Import Your OS

4. Create a task sequence

5. Update the deployment share

6. Deploy Your First Image

DIFFICULTY: Two out of five

By now, you've probably heard that there isn't a direct upgrade path from Windows XP to Windows 7. When installing Windows 7 on a machine that previously housed XP, you can choose to wipe the hard drive clean and install a fresh copy of Windows 7, or you can perform a migration. Migrating allows you to install Windows 7 while maintaining your users' settings and data. Applications that are installed on the XP machine won't be migrated—you'll have to redeploy them using Group Policy or Configuration Manager.

While migrating one or two machines is no big deal, migrating 20 or 20,000 XP machines can be a real pain. This article is designed to help ease that pain by showing you how to set up a repeatable migration solution so every migration you perform is identical to the last, other than the user settings and data that were stored locally on the XP machines. Microsoft's free deployment tool, Microsoft Deployment Toolkit 2010 (MDT 2010), provides friendly wizards that walk you through scenario-based questions. Then, under the hood, based on the answers you gave the MDT wizards, MDT does all the hard work for you.

MDT isn't a new tool—it used to be called Solution Accelerator Business Desktop Deployment Tool (BDD). Since then, it's had a lot of the kinks worked out. If you found it difficult to use earlier versions of MDT or BDD, I think it's safe to say you'll be pleased with this version. It's definitely worth another look.

In this article, I'll give you step-by-step instructions to install the MDT, create a deployment share, import an OS, create a task sequence for migrating XP SP2 and SP3 to Windows 7, and finally walk you through the migration process. (This process is also known as a refresh scenario, because you're refreshing the same piece of hardware with a new OS.)

Step 1: Install MDT

Installing MDT 2010 doesn't require a big beefy machine. MDT requires a 1.4GHz processor, 2GB of RAM, a Gigabit NIC if you'll be deploying multiple machines concurrently, enough hard drive space to store you images (I suggest at least 20 GB to get started), and RAID if you want to provide fault tolerance for your images.

MDT requires the Windows Automated Installation Kit for Windows 7 (WAIK 2.0). It doesn't matter whether you install MDT or WAIK first, but MDT won't be able to deploy anything until WAIK is installed. WAIK requires Microsoft XML Core Services (MSXML) 6.0 and .Net Framework 2.0 or later if installing MDT on older OSs (newer OSs such as Windows Server 2008 & Server 2008 R2 have MSXML 6.0 and .Net Framework built-in). Don't worry, both MSXML 6.0 and .Net 2.0 are included in the WAIK download.

Before I get started, there are some terms you should be familiar with. Installing MDT on Windows 7 or Windows Vista SP1 creates a technician machine. Installing MDT on a server OS (Windows Server 2008 R2, Windows Server 2008, or Windows Server 2003 SP2) creates a deployment server. I recommend installing the MDT on a server OS (latest and greatest is the best) so you get all the bells and whistles that the server OS brings to the table, such as easy integration with Windows Deployment Service (WDS). The OSs that MDT 2010 supports for deployment are Windows 7, Windows Server 2008 (Including all SPs and R2), Windows Vista (SP1 or later), Windows Server 2003 R2, and Windows XP SP2 and later. The target machine is the machine to which you're deploying the new OS. In this article, your XP workstations are the target machines.

Once you've installed MDT, you'll use the Deployment Workbench (DW) snap-in, shown in Figure 1, to do all your work. You'll find the DW under Start, All Programs, Microsoft Deployment Toolkit, Deployment Workbench.

Figure 1

Step 2: Create a Deployment Share

A deployment share is the shared folder your target machines connect to during the deployment process, so you'll need to be sure your machines have network connectivity and permissions to the deployment share (you can have as many deployment shares as you choose). Create a deployment share within the DW by right-clicking the Deployment Shares node and choosing New Deployment Share. The New Deployment Share Wizard opens to the Path page. Follow these steps to create your new DS:

On the Path page, click the Browse… button and navigate to the folder in which you'd like the new deployment share to be created, or type the path. No need to create the folder first—MDT is smart enough to create it for you. I recommend creating your deployment share on a volume other than the system volume. Another hard drive would be even better. My deployment share will be created in the F:\DeploymentShare folder. Click Next.
On the Share page, type the name you'd like for the shared folder name. Accepting the default will name the deployment share's shared folder DeploymentShare$. (The $ at the end of the share name makes this a hidden share, so the folder name won't show up on browse lists.) Click Next.
On the Descriptive Name page, you can give your shared folder a description. The description can be seen from a browse list if you removed the $ from the shared folder name in step two or when you list the shares on a deployment server. An easy way to list the shares on the deployment server is to open a command prompt and type net share—your description will be in the Remark field. After you input your deployment share description, click Next.
Next is the Allow Image Capture page, which by default is configured to ask if an image should be captured of the target machine before installing Windows 7. Accepting the default setting will cause the deployment wizard to ask you whether an image should be created of the target machine and, if so, where the image (a .wim file) should be stored. This is helpful if you need to roll back the target machine to its original image. Accept the default setting and click Next.
By default, the Allow Admin Password page is set not to ask users to set the local administrator password during the deployment. This setting, if left at the default, will assign the target machine's local administrator account a blank password. That's not the whole story, however—there are other ways to provide the local administrator password. In my example, I'll provide it in a task sequence I'll create later in this article. Accept the default setting and click Next.
The Allow Product Key page allows you to choose whether you want to be prompted for a product key during the deployment process. Enterprise clients won't need to worry about product keys, because theirs is baked into the OS files. For non-enterprise clients, I recommend accepting the defaults on this page and typing the product key into your task sequence (like with the local administrator password, as I mentioned in step five). Clicking Next takes you to the Summary page.
The Summary page displays the choices you've made in the New Deployment Share Wizard. Clicking Next on the Summary page begins creating the deployment share. The steps run to create a deployment share are displayed in the Progress page that appears rather quickly then disappears, leaving you at the Confirmation page.
There a two buttons on the Confirmation page that are new to MDT 2010, Save Output and View Script. Clicking the Save Output… button lets you store the output, which is exactly what you see on the confirmation page. The View Script button shows the PowerShell commands that were run to create the deployment share. You can copy and paste commands to create your own PowerShell scripts.

Once the New Deployment Share Wizard has completed successfully, your new deployment share will appear in the DW under the Deployment Shares node, as shown in Figure 2. When you expand your new deployment share, you'll see six nodes: Applications, Operating Systems, Out-of-Box Drivers, Packages, Task Sequences and Advanced Configuration. I'll show you two of these nodes: Operating Systems and Task Sequences, with the Operating Systems node first.

Figure 2

Step 3: Import Your OS

Before you can deploy an OS, you'll need to import one into the DW. No matter which OS you import, the steps are all the same. To import an OS, right-click the Operating Systems node and choose Import Operating System. The Import Operating System Wizard opens to the OS Type page.

On the OS Type page, select Full set of source files. You can add custom image (.wim) files that you've created and WDS OS images later. Click Next.
On the Sources page, click the Browse button to navigate to your full set of source files. You can use either the root of a Windows 7 DVD or a folder where you've copied the entire Windows 7 DVD.
The Destination page prompts you for the name of the folder in which you'd like to store this OS. The folder will be created in your deployment share's OS folder. In my case, it's F:\DeploymentShare\Operating Systems. Don't look for this folder in the deployment workbench, you won't find it there. You can find it using Windows Explorer and navigating to the deployment share you created in the previous section. Click Next.
The Summary page displays the details of the Import Operating System Wizard, just as the New Deployment Share Wizard did. After reviewing your choices and making any necessary changes, click Next.
The Progress page appears. When the OS is imported, the Confirmation page appears. Importing image files can take a while, depending on the size of the image and speed of your server. Click Finish on the Confirmation page and your newly imported OS will be displayed in the deployment workbench under the Operating Systems node.

At this point, I have to mention one of my favorite new features in MDT 2010. I can now organize my OSs by creating folders to store them in. For example, you could create a folder under the Operating Systems node by right-clicking Operating Systems and choosing New Folder. Give the folder a name (such as Win 7 or XP), click Next twice, then Finish. Then you can move the OSs you've imported from one folder to another by cutting and pasting. You can create similar folder structures for your applications, drivers, and packages to keep things more organized, as shown in Figure 3. You can import applications, drivers, and packages in much the same way that you imported the OS, but with different options.

Figure 3

Step 4: Create a task sequence

The task sequence is where things start to get interesting. A task sequence contains a list of tasks to be performed during the migration and the order in which they will run. To create a task sequence, right-click the Task Sequence node and choose New Task Sequence. This launches the New Task Sequence Wizard.

On the General Settings page, fill in the Task sequence ID, Task sequence name and Comments. For example, my Task sequence ID is W7x64 and my Task sequence name is Windows 7 64-bit. The comments field is a great way to document information about the task sequence (such as when it was created, why it was created, and what will be deployed using this task sequence). Clicking Next takes you to the Select Template page.
The Select Template page lists the built-in templates. Choose Standard Client Task Sequence from the drop down box and click Next.
Select the OS (Windows 7) you'd like this task sequence to deploy on the Select OS page and click Next.
On the Specify a product key page, input a product key if needed (if you choose to not specify a product key at this time, you'll be prompted to enter one during deployment) and click Next.
The OS Settings page provides fields for Full name, Organization, and Internet Explorer home page, all of which are required fields. Fill these guys in and click Next.
Provide a password to be used for the target machine's local administrator account on the Admin Password page. Remember that when I created the deployment share, I left the Allow Admin Password page at the default, not to prompt for a local administrator password (step six in the Create a Deployment Share section). If you choose not to specify an administrator password at this time, once the migration is complete, the Windows 7 local administrator password will be blank. Input a password and click Next.
The Summary page gives you the opportunity to review your choices. When everything looks good, click Next. The Progress page appears and displays the steps being run to create the task sequence. When finished creating the task sequence, the Progress page disappears and the Confirmation page appears.
On the Confirmation page, click Finish.

Step 5: Update the deployment share

Updating your deployment share is when the gears of the MDT start to turn. When you update your deployment share, the tools needed by the MDT are copied into your deployment share. Quite a few other things occur too, but they are outside the scope of this article. Follow these steps to update your deployment share:

From within the deployment workbench, expand the Deployment Shares node. Right-click your deployment share name and choose Update Deployment Share from the menu.
The Update Deployment Share Wizard launches and displays the Options page, shown in Figure 4. There are two options to choose from: Optimize the boot image updating process and Completely regenerate the boot images. The first time you update the deployment share, it doesn't matter which option you select, because either option will do the same thing. Accept the default option and click Next.

Figure 4
In the Summary page, review your selections (make any changes) and click Next. The Progress page appears and shows you the steps performed to update the deployment share. When the deployment share is updated successfully, the Confirmation page appears. Click Finish on the Confirmation page to complete the Update Deployment Share Wizard.

Now you're ready to migrate your very first XP machine to Windows 7. Make sure that your target machine has networking functionality and can connect to the MDT deployment server's deployment share.

Step 6: Deploy Your First Image

To migrate your XP target machine to Windows 7, you'll need to begin by booting the machine into XP and logging into your domain. Then you'll need to connect to the deployment server and run LiteTouch.vbs to kick off the migration. Follow these steps:

On the XP target machine, click the Start button and then Run. Type the Universal Naming Convention (UNC) path to a script named LiteTouch.vbs stored in your deployment share's scripts folder. My deployment server's name is 2010Server and my deployment share is DeploymentShare$, so my UNC path is \\2010Server\DeploymentShare$\Scripts\LiteTouch.vbs
When LiteTouch.vbs launches, the Windows Deployment Wizard begins, as shown in Figure 5.

Figure 5

There are two options on this page, but only one is selectable: Refresh this computer. The Upgrade this computer option isn't selectable because there's no upgrade path from XP to Windows 7, only migration. Accept the default selection and click Next.
The current name of the XP machine appears on the Configure the computer name page. You can accept the existing name or provide a new name. Click Next.
The Join the computer to a domain or workgroup page allows you to input credentials for joining the new Windows 7 machine to your domain or a workgroup. You can even specify the Active Directory organizational unit (OU) where you'd to like to create the new computer object, but you'll have to use the distinguished name. For example, if my domain is named deploy.com and I want the new computer object to be created in the Workstations OU (which I've previously created), my distinguished name would look like this:
OU=Workstations,DC=Deploy,DC=com
After making your selection to join a domain or workgroup, click Next.
There are three selections on the Specify where to save your data and settings page—Automatically determine the location, Specify a location and Do not save data and settings. The Automatically determine the location setting has a sub-setting, Allow data and settings to be stored locally when possible. If both are selected, the User State Migration Tool (USMT) Scanstate utility will run utilizing the new USMT v4 hard link option. The hard link option identifies user's settings and data stored locally and stores information about them (such as where they reside on the local hard drive) in the C:\MININT\StateStore\USMT folder. The actual files and settings are left completely intact while the XP OS files that surround the settings and data are replaced with Windows 7. In a refresh scenario, this is possible because the hard drive never gets formatted. (There's no way to use hard links and format the system drive—the hard link data would be stored first, and then the process of formatting the hard drive would wipe out the data.)
Choosing Specify a location requires that you provide a UNC path for where you'd like to store the user's settings and data. Storing the user's settings and data on a network location creates network traffic and the need for storage space. Storing the user's settings and data locally using USMT hard links cuts down on both network traffic and the amount of storage space needed. I'll store mine on the deployment server in the shared USMT folder (you'll have to create and share the USMT folder first). I also want each computer to create a folder within the USMT folder based on its computer name (I'll use the %ComputerName% variable). My target machine is named XPTIStaff, so my UNC path is \\2010Server\USMT\%ComputerName%.The third option Do not save data and settings will do just that—save nothing.
The Specify where to save a complete computer backup page gives you the opportunity to create a .wim image of the XP machine before replacing the OS with Windows 7. You have the same options as the last page: Automatically determine the location (if there's room, the .wim image will be stored locally and not overwritten when the new OS is deployed); Do not back up the existing computer; or Specify a location with an UNC path of where you'd like to store the .wim image file. For example, I have a folder shared as Backups on my deployment server, so I typed the following UNC path:
\\2010Server\Backups
On the Language and other Preferences page, fill in settings such as language, time and currency format, then click Next.
Select your Time Zone and click Next.
Choose any applications you'd like to install on the Select one or more applications to install page. You need to add applications to the deployment workbench before they'll appear on this list. Click Next.
The Specify the Bitlocker configuration page lets you choose whether to enable BitLocker on the target machine. If you choose to enable BitLocker, you can also specify where to store the BitLocker encryption key. Accept the default setting, Do Not Enable BitLocker for this computer, and click Next.
The Ready to Begin page is the last page in the deployment wizard. Clicking Details… shows your selections. After reviewing your settings (make changes by clicking the blue circle with the back arrow in the bottom left corner) click Begin and let it rip. The deployment begins and displays the Installation Progress bar that shows each stage of the installation.

Under the hood, USMT runs Scanstate and stores the user's settings and data in the path you provided. Then the XP target machine reboots into a custom MDT Windows Pre Installation Environment (WinPE). This custom MDT WinPE contains the scripts needed to deploy Windows 7. After Windows 7 is installed, USMT runs again and this time performs a loadstate command that will migrate the users' data and settings from the \\2010Server\USMT\ITStaff folder. If the migration completed successfully, you'll see a screen telling you so.

The MDT is capable of much more than just migrating XP SP2 and later machines to Windows 7 while maintaining your users' settings and data. But for now, I hope these steps will help ease the migration pain.