So this is the fifth and final part of the series about deployment and all of the subtasks you need to do. Admittedly, I set out to do this in 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 now in MDT 2010, but in doing so, left out most of the content around project management, business case, 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 builds of MDT and BDD releases.

If you’re one of those guys that 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 do want sample project plans and project templates for deploying an OS and are ok replacing an occasional “Vista” with a “7”, then you’ll be able to get value. Here’s a secret, the all-up set of processes for deploying Windows XP is roughly the same as deploying Windows 7. Sure the tools have gotten better and cover more areas/scenarios and the OS is more flexible for imaging and offline servicing, but the all-up process is basically the same it has been for years.

Remember the “BDD Wheel?”

All of this still applies today to whatever OS you are deploying. Even though I have the source files for this image that we built in 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 my last four blogs.

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. The important stuff 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 any other OEM-specific applets you want to keep are there, and we’ll cover that in a minute.

One thing you’ll need to think about relatively soon is the Windows activation method that you’ll be using for Windows 7. Windows XP activation usually entailed you baking a key into your unattend process. You can still do that now with the revised unattend.xml using Windows System Image Manager and a Multiple Activation Key (MAK) or you can set up a Key Management Service (KMS). I recommend KMS, since we don’t need to worry about managing keys in the build process. Once 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 on this in Volume Activation guidance.

I was using “fun” a bit sarcastically in previous blogs, but this is truly the fun part of deployment for me – automating things. 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, since the operating system is the only “required” piece of the four I listed. If you do have a thick image with applications and just want to use the task sequence to capture and re-apply user state and maybe hit 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 just importing a set of flat Windows 7 retail source files.

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

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

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 in the “Out-of-Box Drivers” area. Drivers will be installed automatically based on their PnP IDs by default or if you want total control, you can group them using Selection Profiles in MDT 2010. Once you’ve imported drivers into the Deployment Workbench, it will look something like this:

I want to note here as well that 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 as well to control how drivers are installed. The last thing you can do for driver installation is opt via the deployment task sequence to hit 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 ConfigMgr and when we detect language packs in MDT, we’ll even expose them as optional packages (as opposed to installing everything that qualifies for our OS). Once 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 ConfigMgr 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 using MDT 2010 as well, but MDT will automatically create the custom Windows PE environment for you as part of the standard build process. I introduced task sequences as the thing that combines all of the migration processes together and even listed the core steps in the last blog. The great thing is that the standard client and server task sequences in the box in MDT and ConfigMgr 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 above. 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 out in the last blog and you’re far along on your way to start migrating Windows XP machines to Windows 7 in a highly automated way.

Last Thing

Before I finish this series, I just want to cover one last thing. Once you get everything working 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.

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. Using this file, you can eliminate one, many or all of the wizard screens by pre-populating the fields that you would otherwise have to fill in or skip screens and use the defaults in other cases. A completely automated customsettings.ini file looks like this:

I’ve also added mandatory applications to control which applications are part of this build. Using a 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 subscribe to the Deployment Guys Blog and keep checking back to the Springboard Series on TechNet for the latest content.

Thanks again for reading and get automating,

Jeremy Chapman

Windows Deployment