Windows 7

Your Windows 7 Deployment Guide

Chris Adams

Depending on the size of your enterprise, the complexity of deploying Windows 7 ranges from fairly simple to insanely complex. For Microsoft's own deployments, the task has been falling closer to the latter description. However, using System

Center, Configuration Manager 2007's Operating System Deployment (OSD) feature and the soon-to-be-released Service Pack 2 (SP2) can greatly simplify the process. No matter where your enterprise falls on the complexity spectrum, you can use the Microsoft blueprint to move your enterprise to Windows 7 sooner rather than later.

This article describes how the Microsoft team approached deploying Windows 7 to our own enterprise. It covers how we developed our Windows 7 deployment solution and how you can apply these same tools to simplify your

Understanding Enterprise Desktop Deployment Scenarios

The first step, of course, is assessing the requirements and scenarios needed to accomplish a wide distribution of a new OS. Unlike applications that are delivered to the desktop, operating systems pose a significant risk to users' productivity and data. Thus, you often spend a great deal of time trying to ascertain the current state of affairs and attempting to minimize risks while finding the sweet spot. That's especially the case at Microsoft, where the target is 280,000-plus desktops.

Figure 1: Enterprise Desktop Disk Configuration Scenarios

When developing an enterprise desktop solution, the primary focus areas are hard-disk configurations, encryption technologies, applications and user data. (While drivers for hardware devices also play a big role in deployment, they're beyond the scope of this discussion. However, the solution we developed to simplify drivers for Microsoft's own hardware is outlined in this TechNet blog post: tinyurl.com/kog748.)

The desktop configuration, whether involving single or multiple disks, is important when deploying Windows 7 using Configuration Manager. The challenge is understanding whether you're deploying Windows 7 only to new machines or via a migration process where an OS already exists. As shown in Figure 1, we had to develop a solution for Microsoft that works with a single disk with a number of partitions or with complex multi-boot and multi-disk configurations.

Many desktops at Microsoft are running Windows Vista, and some business groups are required to use the BitLocker encryption technology introduced with Vista. BitLocker encrypts and protects the system partition in case of theft or loss. When trying to upgrade the OS that's running on an encrypted drive, the task sequence must disable or suspend the encryption. Most mobile environments require encryption, so any solutions developed for them must take encryption scenarios into account.

One absolute, non-negotiable fact in every enterprise is that users have data that can't be lost during migration. For Windows users, Microsoft provides the User State Migration Toolkit (USMT), which is designed to simplify the gathering and restoring of users' data. Windows 7 introduces the next generation of USMT (version 4.0), which offers vast improvements over its predecessor. The primary differences between USMT 3.0 and version 4.0 are the focus of the last part of our scenarios: selecting the right process for gathering the user state and the method for saving that state.

Unlike previous iterations, USMT 4.0 works outside the full operating system. When gathering a user's state for restoration after the upgrade, the full OS poses some challenges because files are often in use or locked; also, other applications, such as anti-virus solutions, can cause failures during attempts to back up their data. The new version's data-gathering process works outside the full OS in environments such as Windows Pre-Execution (PE), greatly reducing the number of running services, applications in use and other scenarios involving open user data. The ability to load a user's state from Windows PE (via offline backup) works nicely with the Configuration Manager OSD task sequence that runs in Windows PE, streamlining the process of backing up the user's data.

After USMT has gathered the necessary user data, it needs somewhere to "store" this data during the migration. Microsoft had numerous choices for where to store its users' data, but that same range of options may not be within many other enterprises' IT budgets. For example, let's assume that the typical Microsoft user state was around 1GB. Options for storing this data for later retrieval included external hard disks, file servers and optical drives such as DVDs. For enterprises using Configuration Manager 2007, the State Migration Point role allows for storing the data on a remote server while the migration takes place, but that still has limitations.

The key reason that an "external" device isn't cost-effective is that it requires you to have physical storage space equal to your users' state. Thus, at Microsoft, we would have needed 280TB space free and available to support our user base. That approach only works if you can accurately gauge the amount of user data. Otherwise, it's a non-scientific process that's likely to produce unpredictable and unsatisfactory results.

The last option is using the machines where the migration is to take place. This may seem like the most logical and cost-effective approach, but it's often a technical challenge. It requires that users' machines have a large amount of free space available for backing up their data; it also involves copying users' data from one place on disk to another. As most IT veterans have learned, it takes awhile to move or copy any file onto a hard disk -- which, in turn, causes deployments to simply take too long. A deployment that takes away a user's productivity for a day (or days) simply isn't feasible -- and it represents a risk that you don't want to take.

USMT 4.0 introduces support for hard links, a feature that wasn't available in previous versions. Hard-link migration allows users' data to get stored locally on the same computer efficiently, requiring little time and disk space.

The only requirement for using hard links is that the user's computer must have 250MB of free space available. Hard-links support offers the ability to back up and restore without moving the physical files on disk. Instead, USMT stores only the pointers to the physical files and uses these pointers at restore time, significantly reducing the amount of time required for Windows 7 migration. (For more information on hard-links, see this TechNet article: tinyurl.com/m76dxv.)

Having an understanding of the various scenarios will help you build an action plan to tackle them when migrating to Windows 7.

Building Your OS Task Sequence for Windows 7

Once you understand the requirements and scenarios, implementing the solution is a straightforward task. The steps for building your solution fall into three primary categories:

1. End-user experience
2. Building the Windows 7 task sequence
3. User-state migration

Microsoft IT developed a solution, code-named "Modena," that enables the ability to support the first category by using a powerful OSD wizard, the second category through an exported task sequence and the third with state-migration scripts. This next section will outline how to use the Modena OSD tools, which include the OSD wizard, an exported task sequence and scripts.

Using the OSD Wizard

Configuration Manager's OSD is designed for IT administrators. For that reason, OSD doesn't offer a built-in wizard, which means that most enterprises must develop their own. In short, there's no out-of-box functionality for gathering end-user input using Configuration Manager -- a challenge that Microsoft itself faced.

Microsoft is a user-driven enterprise; all users operate as administrators.

Many frown on Microsoft IT decisions that affect their ability to use all of an OS's features. As a result, Microsoft had to develop a highly robust user experience that obtains as much data as possible from users without overwhelming them or impeding their ability to work.

The Modena OSD wizard bridged the gap at Microsoft and is available to your enterprise. (For information on obtaining OSD tools, see our blog at blogs.technet.com/osd.)

The Modena OSD wizard has two components: the executable and a configuration file. The executable, OSDSetupWizard.exe, is the self-contained user experience written by Microsoft. It's designed to validate that a computer is ready for the Windows 7 migration and also to gather end-user input. The wizard's final role is taking a user's input and setting OSD task-sequence variables.

A key aspect of the wizard is that it's designed to work much like plug-and-play so that it's useful in as many scenarios as possible. It accomplishes that goal through its configuration file. In fact, in complex environments such as Microsoft, the same executable can be used with various different configuration files by using the switch /xml:{osdconffilename.xml}.

For example, in deployments at Microsoft where support for both Run Advertised Programs (RAP) and Preboot Execution Environments (PXE) are required, the same task sequence is used, but the wizard performs differently, using two different configuration files based on the environment it's running (RAP or PXE). This creates a one-size-fits-all deployment package yet allows for various configurations supporting that single package.

To introduce the OSD wizard, let's start by looking at the available end-user screens (also called pages). Eight pages are available as part of the OSD wizard. We use the term "available" loosely because each page has one of three states: enabled, disabled and silent. If enabled, the page is shown to the end user; if disabled, the page isn't displayed.

Silent is a special case in which the page isn't displayed unless an OSD task-sequence variable is null. If that's the case, the page will prompt the user to provide the input allowing the wizard to continue. (For more information on the OSD wizard's enabled, disabled and silent features, see the TechNet blog post at blogs.technet.com/osd.) In some situations, end-user input is required on a specific page, but other data aren't.

For example, many enterprises allow end users to provide their own machine names, but don't allow them to select their Active Directory (AD) domains or organizational units. The OSD wizard adapts easily, allowing you to display a wizard page, but not allowing users to change the content of a specific input such as domain and organizational unit. This helpful locking functionality is available across most pages in the configuration file.

Beyond disabling and locking, some pages have additional attributes that change the wizard's internal behavior. Wizard functionality can automatically check AD to see whether a computer name is already in use or whether a user's credentials are valid. For pages where additional attributes exist, you can use values to enable or disable these features without re-compiling the wizard.

Each of the OSD wizard's eight pages is named for the function it's supposed to provide: Welcome, Pre-Flight, Computer, Network, Language, Volume, Application and Summary. Let's explore the key functionality that some of these pages provide and discuss how you can use them.

You can uniquely brand your wizard so that it matches your enterprise's typical IT branding. You can also easily accomplish branding through the configuration file by placing the bitmap name in the header attribute. To re-brand the wizard to match your environment, simply create a bitmap image with the size 630x100, add the image to your OSD package and edit the configuration file. (For more information on branding, see the TechNetblog post at tinyurl.com/r7jdve.)

Among the OSD Wizard's most powerful features is the ability to snap in your own pre-flight checks that execute prior to the migration to Windows 7. For example, let's say that your company has a human-resources application that isn't compatible with Windows 7. To minimize impact on user productivity, you create a script and add your OSD wizard pre-flight check on whether this application is installed. Based on the result of that check, you allow the users in question to continue the migration or warn them about the incompatible applications.

The OSD Wizard currently has two built-in pre-flights that you can enable or disable via the configuration file. These particular pre-flights are included because they're applicable in most enterprises. The first pre-flight is a power check that's performed in the full OS (for example, when the user migrates using RAP or Add\Remove programs) and returns an error notification if the users aren't running on AC. If the pre-flight detects that the user isn't plugged in, it will return an error notification asking the user to plug in an AC adaptor. After doing so, the user can click Retry Pre-Flight Checks and proceed, if no other errors occur.

The second built-in pre-flight is the wireless check. OSD is a bandwidth-intensive process and runs best when plugged into an Ethernet adaptor (for example, 802.3 wired connections). When the wireless pre-flight detects that a user isn't plugged in, it returns an error notification until the user establishes a wired connection to the network.

However, the pre-flight isn't constrained to the built-in checks. It supports any executable or Windows Scripting Host scripts, such as Visual Basic scripts. There's no limit to the number of pre-flight checks as long as they can execute and complete in less than five minutes (if they take longer, the OSD Wizard stops executing the script).

Figure 2 OSD Wizard

Every time a script or executable is executed, a code is returned to the OSD Wizard process. Based on the wizard's configuration, it will return a Success, Warning or Error status notification (see Figure 2). When a Success or Warning notification is returned, the user can continue through the rest of the wizard. But when an Error notification is returned, the user will be blocked from continuing. The acceptable codes returned from your pre-flight script, or from the built-in scripts, are configurable in the osdconf.xml and don't require changes to the wizard's executable. Beyond that, the text description of the error is also configurable.
There are two approaches for delivering applications as part of your Windows 7 deployment: as part of the base Windows 7 Windows Installation Image (WIM) or as individual task-sequence steps. Including the applications in the Windows 7 WIM image is often used for applications that most end users require, but that aren't updated often. This approach has two primary deficiencies. First, the image size increases, which often affects the times for downloading to clients; in addition, there's the administration of the image. Each time the applications are updated, the WIM image will require you to create a new installation image and update the appropriate Configuration Manager packages associated with the base image.

Figure 3 OSD Wizard Application Selection

For those reasons, the Modena tools integrate nicely with the Configuration Manager 2007 Install Software application feature to provide end users with the ability to select the applications they'd like to install as part of the OSD process. (For more information, see the TechNet article at tinyurl.com/pdfp5s.) As shown in Figure 3, the applications are listed in a tree-like view, based solely on your design in the OSD Wizard configuration file. For example, you can define the application group by business unit, location or application type, then define all the applications for that group and the default selection. This makes it possible to easily change or add applications, with the only requirement being that the application is packaged and available in the Configuration Manager 2007 database.

Again, the wizard's primary purpose is providing users with the ability to affect the final outcome of their Windows 7 image. For environments where users aren't expected to have much input, the wizard can be configured to ask for only minimal information; the remainder is hard-coded in the task sequence by administrators.

Losing Data: Not an Option

USMT 4.0 includes a base set of configuration files capable of capturing many enterprises' user states. These configuration files, MigApp.xml and MigDocs.xml, cover most scenarios to capture your users' data. (For more information on configuration files, see the TechNet article at tinyurl.com/okfgw4.)
OSD will clean the volume where Windows 7 is being installed. For that reason, it's extremely important that user states are captured properly and accurately every time that OSD is used. In short, data loss is simply not an option.

The best practice -- also used here at Microsoft -- is creating a safe location via a task sequence step that's your target folder for your user's state. Then, using the OSD built-in task sequence variable called OSDStateStorePath, you can exclude this directory from the volume clean done by the Apply OS step in the task sequence. (To learn how to accomplish and fully use this functionality, see the TechNet blog post at blogs.technet.com/osd.)

Building Your Task Sequence for Windows 7 Deployment

The Modena OSD tools include an exported copy of the OSD task sequence used at Microsoft. The exported task sequence is broken down into several groups, starting at the root, with "children" named Master Group and Failover. The Master Group has children associated with each major step used in the Windows 7 deployment. The children (see Figure 4) each have error conditions that return the error to the Master Group, which will then forward to a specialized step called Failover.

Breaking the task sequence into these steps makes the logging, reporting and error-handling processes much easier. As with any such undertaking, errors will occur no matter how much time you spend in preparation -- which is the reason for the Failover Group. This group is designed to gather all the pertinent log files necessary to troubleshoot a failed installation and place them in the OSD safe folder.

To implement some fault tolerance in your task sequence, start at the root level and create the two child groups, Master Group and Failover. Another best practice is having the Master Group include all the working steps required in your deployment and using it as the group designated to continue on error. Each child group -- in Microsoft's case, the five nested groups for the Master Group, shown in Figure 4 -- are needed to continue the task sequence and are set to fail on error.

Figure 4 Task Sequence Grouping

Another best practice is to set any child groups that are non-catastrophic to the deployment to continue on error. The OSD task sequence engine always determines actions to take in case of error by looking to its parent group to see whether it should continue. Because of this behavior, you should define whether each step should halt on error or continue. If a step isn't set to continue on error, the task sequence will go to its parent group to determine what action to execute next. In the design in Figure 4, the Master Group is set to continue on error so that it will execute the Failover Group that is its peer.

For example, let's say that a group is created to capture user state. Because of the importance of the steps in this group, the design for each one ensures, in case of error, deployment doesn't continue further, possibly deleting the volume (assuming that that's the next step in your task sequence). In such a case, the task- sequence engine determines whether the executing step is set to continue on error; if not, it will revert to the step's parent group to determine what action to take next. The Backup State parent group whose continue on error is unchecked will revert to its parent, who in this design is the Master Group.

The purpose of the Failover Group, as mentioned, is to ensure that we capture all the data necessary to troubleshoot in case of failures. This group needs to be set up as a peer to the Master Group to have the Master Group refer to it upon errors (see Figure 4). The Failover Group is never run unless there is a catastrophic failure during deployment. For that reason, it's the last step in the task sequence and is always run unless setup succeeds.

The state of the deployment is based on the value stored in the _SMSTSLastActionSucceeded variable. That's how the task sequence engine is used to transverse the task-sequence "tree" until it ultimately reaches completion -- in this case, meaning that the Failover Group steps are executed, gather all logs and necessary data and then fail. (For more on designing this, read the TechNetblog post at blogs.technet.com/osd.)

Providing User Status Using Bitmaps and BGInfo.exe

At Microsoft, it's important to let users know where in the migration process they are in OSD. By default, all client-based status is communicated through the Configuration Manager OSD features. While these status messages work well for some enterprises, there are other creative methods for communicating to users about the larger steps making up the migration.

The first step is understanding what the larger steps are that accompany the migration process. For example, these steps could be Partition Drive, Install Windows and Last Install applications. The primary reason for doing this is that these steps provide users with a high-level definition of overall progress -- and users enjoy this type of information.

The five main steps used at Microsoft are Backup State, Install Windows, Set Up Windows, Install Applications and Restore State. Users receive communications through the use of static bitmaps that are dynamically rendered using the TechNet Sysinternals tool BGInfo.exe. (You can download BGInfo.exe at tinyurl.com/2nbxmd, but it's included in the Modena OSD tools.) This tool allows the loading of a static bitmap when called, and it will allow you to set the bitmap that reflects the migration's current location.

Modena includes five bitmaps, one for each step, and the images that communicate the status are set through the task sequence. For example, in the task-sequence group Install OS, BGInfo.exe is called to load the bitmap representing this step (see Figure 5).

Figure 5 Displaying Status

The Modena OSD tool provides the framework for deploying this in your enterprise and only requires that you replace the bitmaps. To do this, locate the scripts folder, open BG directory and replace each bitmap image with your updated version. This will inform your end users about the five primary steps used to deploy Windows 7. This is a nice way to keep users in the loop without requiring them to read detailed steps provided by the OSD task-sequence engine.

Putting It All Together

Windows 7 is available to businesses now, but due to the complexity involved, many enterprises haven't yet started their upgrade projects. At Microsoft, this process began nearly a year ago; we've almost mastered it, yet it's never completely refined.

Windows 7 provides your end users maximum productivity and performance. Ultimately, the only barrier is getting the deployment ready. Microsoft offers System Center Configuration Manager 2007 users the Modena OSD tools to decrease deployment preparation time and complexity. Whether your enterprise needs high interaction with its end users or relies on "minimal touch," you can streamline your Windows 7 project using the same process that we used at Microsoft.

Chris Adams (chrad@microsoft.com) is a senior lead program manager in Microsoft's Management and Services Division. He focuses on System Center Configuration Manager and System CenterVirtual Machine Manager.*