Automating the Migration from Windows XP to Windows 7 End-to-End

  • Article

Applies To: Windows XP

This is the fifth and final part of the series about deployment and all of the subtasks you need to perform. Admittedly, I set out to write this on one page, and I think with small font and a decent-sized plotter, you may just be able to get this to print onto a single page, but most people won’t. For the astute readers out there, you might be thinking two things, “I just read several pages of what is essentially intro content?” or “Wait, Jeremy, you forgot all about drivers!”

To the first question, I was on the team that originally wrote the ominous “1500 pages of desktop deployment guidance” back in the Business Desktop Deployment (BDD) 2.0 and 2.5 days. We’ve “streamlined” that down to a couple hundred pages, but in doing so, we left out most of the content about project management, business cases, Microsoft Solutions Framework, and so on. The result is the often-requested, “click-here, do this” guidance, but if you crave the all-up project management best practices content, we’ve posted archived versions of MDT and BDD releases:

If you’re one of those guys who refuses to use stuff branded as Windows XP SP2 or Windows Vista because it doesn’t look current, the archives may not be for you. If you want sample project plans and project templates for deploying an operating system and you are alright replacing an occasional “Vista” with a “7,” then you’ll be able to get value. Here’s a secret: the full set of processes for deploying Windows XP is roughly the same as for deploying Windows 7. Sure the tools have gotten better and cover more areas and scenarios and the operating system is more flexible for imaging and offline servicing, but the overall process is basically the same it has been for years.

Remember the “BDD Wheel?”

All of this still applies today to whatever operating system you are deploying. Even though I have the source files for this image that we built using Microsoft Office Visio® in 2003, fundamentally, I could use that original graphic today with Windows 7. That is why I’ve covered most of these areas in the first four sections.

Automating the End-to-End Migration Process

I will answer the driver question as I go into the process automation. To be honest, I want to downplay drivers a bit, because if you’ve installed Windows 7 (or even Windows Vista), you’ll know that in-box driver coverage is in a whole new league compared to Windows XP on current hardware. The important items like mass storage and network drivers are pretty well-covered, as are most other driver categories. You will need to ensure that display drivers are included in your process and that any other OEM-specific applets you want to keep are there, and we’ll cover that in a minute.

Relatively soon, you’ll need to think about the Windows activation method that you’ll be using for Windows 7. Windows XP activation usually entailed that you bake a key into your unattend process. You can still do that with the revised unattend.xml by using Windows System Image Manager and a Multiple Activation Key (MAK), or you can set up a Key Management Service (KMS). I recommend KMS, because we don’t need to worry about managing keys in the build process. When the system is online and can reach the KMS server, it activates automatically—no keys to manage or potential key leaks during the deployment itself.

Read more about this in the following guidance: Volume Activation

I was using “fun” a bit sarcastically in previous sections, but automating processes is truly the fun part of deployment for me. Whether you are using Microsoft Deployment Toolkit 2010 or System Center Configuration Manager 2007 SP2 to build your deployment task sequences, you basically need to add the same ingredients to your build:

  1. An operating system

  2. Applications

  3. Drivers

  4. Packages

Here is what that looks like in the MDT 2010 Deployment Workbench:

I actually like my sequence of ingredients better, because the operating system is the only “required” piece of the four I listed. If you have a thick image with applications, and you only want to use the task sequence to capture and reapply the user state and maybe pull Microsoft software updates from your update server or Windows Update, you can get by with only the operating system image. For a thin image, you can get by with importing a set of flat Windows 7 retail source files.

The next step we take is to add our packaged applications. We need the application source files and the silent install commands. We can also set up application dependencies. For example, if Microsoft Office Communicator is dependent on Microsoft Office 2007, by choosing to install Communicator, we’ll automatically preclude that by the entire Office package.

Like everything else in the Deployment Workbench, you right-click the item, select “New Application” and follow the wizards. When you’re done, you’ll have something that looks like the following screenshot:

As you can see from the “CommandLine” field, install command lines vary dramatically depending on the application you’re installing. Now is also the time where you want to check for drivers that were shipped as application installer packages and you’ll be treating them as applications in this case.

Now you can add “normal” drivers with .inf extensions to the “Out-of-Box Drivers” menu. Drivers will be installed automatically by default based on their Plug and Play (PnP) IDs, or if you want total control, you can group them by hardware make and model using Selection Profiles in MDT 2010. After you’ve imported drivers into the Deployment Workbench, it will look something like this:

If you are using a straight Windows Deployment Services environment with Windows Server 2008 R2, we can also use the driver store in Windows Deployment Services to keep drivers centrally on our deployment server and have them install based on PnP IDs. Likewise, System Center Configuration Manager has a great driver store to control how drivers are installed. The last step you can take for driver installation is to opt through the deployment task sequence to pull from Windows Update for updates and drivers. Chances are, between these approaches and an optional call to Windows Update, that even untested devices will successfully install with most (if not all) drivers ready to go.

The last ingredient we’ll add to our build are packages. Packages can be Cabinet (.cab) or Microsoft Update (.msu) files. There is a mechanism to do this in the Deployment Workbench and in Configuration Manager. When we detect language packs in MDT, we’ll even expose them as optional packages (as opposed to installing everything that qualifies for our operating system). After you’ve added packages, you’ll see something like this with varying package types:

At this point, we have all of our ingredients. MDT 2010 and Configuration Manager also have vital components like USMT and Windows PE to migrate user files and give us an installation environment for laying down the Windows 7 image. If you want to customize Windows PE, you can do that by using MDT 2010, however, MDT will automatically create the custom Windows PE environment for you as part of the standard build process. I introduced task sequences as the glue that combines all of the migration processes together, and I listed the core steps in the last section. Making all of this easier is the fact that the standard client and server task sequences in MDT and Configuration Manager will do essentially everything they need to do, and in many cases, you won’t need to create any custom tasks. Here is what the task sequence looks like and everything it does:

Among all of the steps, there are a couple of “Inject Drivers” steps that allow you to either rely on the PnP ID mechanism by default or choose a selection profile from the drop-down list as seen previously. After you’ve created the task sequence and everything else is done, you can start testing. Now you can use a file server, Windows Deployment Services, or standalone media to deliver your Windows 7 builds. This will perform all the steps I listed in the last section, and you’re on your way to migrating Windows XP computers to Windows 7 in a highly automated way.

Tricks for More Automation

Before I finish this article, I want to cover one last idea. When you get everything working by using MDT 2010, the first thing you’ll probably want to do is remove some of the Lite Touch Deployment wizard screens like I’ve done in following video: Windows 7 Deployment Tools Part 4.

Here is the trick. You can modify a file called “customsettings.ini” in your MDT 2010 distribution share. The file in located in the …Deploy\Control folder. By using this file, you can eliminate one, many, or all of the wizard screens by prepopulating the fields that you would otherwise have to fill in, or you can skip screens and use the defaults in other cases. A completely automated customsettings.ini file looks like the following screenshot:

I’ve also added mandatory applications to control which applications are part of this build. By using a similar customsettings.ini file with the standard client refresh task sequence, you will automate all migration steps.

With that, you have the basis to start automating migration from Windows XP to Windows 7. In less than 20 pages, I have covered a lot of ground, and I’ve been pointing along the way for more guidance per task. If you’ve gotten value out of this series, I would encourage you to: