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