Deploying Windows 7 by Using System Center Configuration Manager 2007
Technical Case Study
Published: August 2010
Microsoft was one of the first enterprise organizations to deploy the Windows® 7 operating system on a large scale by using the Operating System Deployment (OSD) feature in Microsoft® System Center Configuration Manager 2007. Microsoft Information Technology (Microsoft IT) used System Center Configuration Manager, OSD, the latest version of the User State Migration Tool (USMT), and a customizable XML-based OSD wizard to provide a seamless migration for users who are upgrading from earlier operating systems.
Products & Technologies
Microsoft IT wanted to increase user satisfaction and reduce overall support costs associated with deploying Windows 7 to hundreds of thousands of client computers at Microsoft.
Major enhancements to System Center Configuration Manager 2007 and the User State Migration Tool (USMT) provide the foundation for the solution. The solution uses an XML-based Operating System Deployment (OSD) wizard that provides an intuitive end-user experience. USMT 4.0 migrates the user state and data, and the OSD feature uses a task sequencer to automate the deployment process.
By October 2009, Microsoft IT was already managing more than 150,000 client computers running Windows 7. Early adopters upgraded many of these computers to Windows 7 beginning with beta releases of the product. But like most enterprise IT organizations, Microsoft IT provides desktop services that require a robust solution for standardized deployments of desktop operating systems.
This technical case study provides an overview of how Microsoft IT planned, designed, and deployed Windows 7 by using System Center Configuration Manager 2007 and taking advantage of the OSD feature. This paper is intended for technical decision makers who are considering an upgrade to Windows 7, and IT professionals who design and manage deployments of client operating-system images for large enterprises. OSD provides enterprise-scale deployment services for operating systems and includes new, user-friendly options to install Windows 7 on client computers and devices. OSD can be configured for a user-initiated (“pull”) installation or an unattended, silent (“push”) installation for computers connected to a local area network (LAN).
OSD includes a task sequence that provides further flexibility for customizing a solution for operating system deployment to meet the specific needs of various organizations. Among other features, the OSD task sequence allows for conditional execution in a synchronous method and supports the inclusion of stand-alone executables within the task sequence. The solution that Microsoft IT developed to deploy both pre-RTM (release to manufacturing) and RTM versions of Windows 7 includes a custom user interface built on the OSD task sequence. This custom interface enhances the end-user experience and enables Microsoft IT to tailor the deployment service for the operating system by including important features, such as:
Prerequisite checks on the client device to confirm wired power, LAN connection, adequate random access memory (RAM), dual-boot detection, and minimum requirements for free disk space.
Options to migrate user data, network share settings, and printer settings to the new operating system.
Post-installation confirmation and results summary.
The solution enables Microsoft IT to better manage and meet user expectations while reducing support overhead.
Beyond this initial solution for the first deployment wave of Windows 7, Microsoft IT has developed a beta solution that the Solution Accelerators team is now engineering further and integrating into the Microsoft Deployment Toolkit (MDT) 2010 Update 1 release. MDT provides additional options for customers who are deploying operating systems, including:
An OSD tool that enables IT administrators to make changes to the wizard by using a graphical user interface.
Additional prerequisite checks on the client device to scan computers for all preexisting applications so that the applications can all be reinstalled as part of the operating system deployment.
Microsoft has hundreds of thousands of managed and unmanaged client computers on its network. The Redmond location alone has more than 100,000 client computers. Before Windows 7 and System Center Configuration Manager OSD, Microsoft IT offered a user-initiated service for operating system deployment that required a certain amount of technical ability. For example, users needed to manage much of their own data migration and application installations.
Although Microsoft has a great number of technically savvy users, many users were not comfortable with the experience that the solution provided. User satisfaction was low, particularly for the population of nontechnical users, and the solution was time-consuming for all users. As a result, many activities related to installation of an operating system required a substantial amount of operations support.
For the Windows 7 deployment, two of Microsoft IT's primary goals were to increase user satisfaction and reduce overall support costs. Microsoft IT also wanted to supplement and enhance what was primarily a user-initiated solution with a solution that provided both an IT-initiated and managed deployment capability and user-initiated deployments.
The first step that Microsoft IT took in creating the new service was to assess the requirements and scenarios needed to accomplish a wide distribution of a new operating system like Windows 7. Microsoft IT expended a great deal of effort to understand the current environment and to minimize any risks that could result in large increases in support calls, especially for enterprise networks like the Microsoft network.
For Microsoft IT, the primary focus areas in designing a service for operating system deployment are hard disk configurations, encryption technologies, end-user applications, end-user data, and hardware device drivers.
Microsoft client computers have a wide array of hard disk configurations, including systems that have single partitions, multiple partitions, and even multiple operating systems in dual-boot or multi-boot configurations. Microsoft IT had to consider all of the combinations or partitions when designing the solution. The installation process needed to identify specific configurations and proceed accordingly.
A large number of the client computers at Microsoft were running the Windows Vista® operating system, and many business groups use the BitLocker® Drive Encryption technology that Windows Vista introduced. BitLocker encrypts and helps protect the system partition in case of theft or loss and is especially important for mobile users. The solution had to take into account BitLocker encryption scenarios.
Preservation and migration of user data posed a significant challenge and risk that Microsoft IT had to carefully address. Windows 7 introduces version 4.0 of the User State Migration Tool. USMT 4.0 simplifies the gathering and restoring of user data. Unlike previous versions, USMT 4.0 can work outside the full operating system. When a solution is gathering a user’s state, working within the full operating system poses challenges because files are often in use or locked. Applications such as antivirus applications can also cause failures during attempts to back up data.
The data-gathering process for USMT 4.0 works in the Windows Preinstallation (Windows PE) environment, which reduces the number of running services, applications in use, and most of the activities where user data might be in use. The ability to capture a user’s state from Windows PE (also called offline backup) in a solution for operating system deployment simplifies the preservation and migration of user data.
After Microsoft IT understood the requirements of the various scenarios, it began designing the solution and deployment plan for Windows 7 based on the new capabilities of System Center Configuration Manager OSD and USMT 4.0.
The previous solution relied on Distributed File System (DFS) Replication for image replication and distribution. OSD, however, uses the replication capabilities of the extensive System Center Configuration Manager site topology and distribution point (DP) servers to make the operating system images available to client computers. Whereas replication of images through DFS Replication could take up to 20 days to finish across the Microsoft global network, System Center Configuration Manager replication finishes in 72 hours or less. The optimized use of a single task sequence that can support multiple base images significantly reduces the disk space required for content storage on the DPs.
The local System Center Configuration Manager infrastructure that Microsoft operates in Redmond consists of a primary System Center Configuration Manager server and 18 DPs. Each DP has the capacity to support about 50 simultaneous installations.
OSD Wizard and User Interface
Microsoft has a large population of technical users. Many users at Microsoft have administrative rights to their computers and require a large degree of flexibility in configuring their computers. Because of this requirement, Microsoft needed a robust user-experience solution that would collect as much environmental data as possible from end users before installing a new operating system.
Although OSD has many out-of-the-box features, it is primarily used by IT administrators to deploy standardized image configurations. To support additional requirements, OSD includes a customizable task sequence that Microsoft IT extended by creating a wizard that gathers end-user input to dynamically customize a particular installation of an operating system. The OSD wizard is an XML-based application that enables the customization of the user experience and addresses requirements for user data migration by using USMT 4.0 and an automated deployment process based on the System Center Configuration Manager task-sequence capability.
The main purpose of the OSD wizard is to validate that a computer is ready for Windows 7 installation. The wizard gathers information from the user and the client computer to dynamically configure the appropriate OSD task-sequence variables that will be used to perform the actual Windows 7 installation.
Note: The OSD wizard that Microsoft IT developed is now called the User-Driven Installation (UDI) deployment method. It has been updated for general availability and integrated into the MDT 2010 Update 1 release, and is available for download at http://blogs.technet.com/msdeployment/default.aspx or http://technet.microsoft.com/en-us/solutionaccelerators/dd407791.aspx.
The OSD wizard has two components, an executable file and a configuration file. The executable file, OSDSetupWizard.exe, is the self-contained user experience tool that Microsoft IT developed. A key feature of the wizard is that it is designed to be highly configurable to make it useful in as many scenarios as possible. This is accomplished through the use of an XML configuration file. For complex environments like the one at Microsoft, multiple configuration files can be used to support multiple scenarios.
For example, deployments at Microsoft that require support for both Run Advertised Programs (RAP) and Preboot Execution Environment (PXE) installation methods entail the use of a single executable file and OSD task sequence. However, the wizard performs differently based on the environment in which it runs (RAP or PXE). It applies different configuration files based on the environment. The result is one OSD task sequence that applies to all scenarios.
The user interface for the wizard consists of eight pages. Administrators can configure each page in one of three states: enabled, disabled, or silent. If a page is enabled, it appears to the end user; if a page is disabled, it does not appear. The silent configuration is a special case where the page does not appear unless a sequence variable for an OSD task is null. This configuration is used in cases where the wizard cannot obtain the variable input. If the variable is null, the page prompts the end user to provide the input to allow the wizard to continue.
The wizard allows the user to provide certain types of information while locking other types of information. For example, many enterprises allow end users to provide their own computer name yet do not allow end users to select their Active Directory® domain or organizational unit. The OSD wizard adapts easily to allow the display of information on a wizard page without allowing a user to alter the content of specific input, such as a domain or organizational unit. This input-locking functionality is very helpful and is available for all of the fields in each page in a configuration file.
Beyond disabling of pages and locking of specific information on pages, some pages have attributes that change internal behavior of the wizard. The wizard includes functionality to automatically check Active Directory Domain Services (AD DS) to determine whether a computer name is already in use, and to determine whether the user account is valid and whether the end user has the rights to the computer name. At Microsoft, if the computer name exists and the user does not have rights to that computer name, the user cannot continue until the user enters a name that he or she has rights to use or a new name that is not already in use. This particular situation was a primary cause of installation failure with previous operating system deployments at Microsoft. For the pages where additional attributes like this exist, values are available to disable or enable these features without recompiling the wizard.
The Welcome page of the wizard allows for appropriate branding. To brand the wizard to match a specific environment, an administrator can create a bitmap image of 630 × 100 pixels, add the image to the OSD package, and place the bitmap file name in the header attribute of the configuration file.
The OSD wizard has several built-in preflight checks that administrators can enable or disable in the configuration file. The first is a power check to confirm that a computer is running on alternating current (AC) power instead of battery power. If the wizard detects that the computer is not plugged in, the preflight check returns an error that asks the user to plug in the AC adapter.
The second built-in preflight check is the wireless network check. OSD is a bandwidth-intensive process and runs best when a computer is connected to an Ethernet network, and wireless networking capability is not available on the client computer during parts of the deployment process. When the wizard detects that a computer is not connected to an Ethernet network, it returns an error until the connection is in place.
In addition, there are preflight checks that confirm that the computer has adequate RAM and disk space. Another preflight check confirms the existence of a dual-boot configuration.
Each time a script or executable file runs, a return code is sent to the wizard. The wizard returns Success, Warning, or Error based on the configuration, as shown in Figure 1. When the wizard returns Success or Warning, the end user can continue through the remainder of the wizard. When the wizard returns Error, the user cannot continue. After the user addresses potential problems, he or she can retry each preflight check.
Figure 1. OSD wizard preflight checks
The preflight checks are extensible and support any executable file or Windows Script Host script, such as Microsoft Visual Basic® scripts. In fact, one of the most important features of the wizard is the ability to run custom preflight checks before the installation of Windows 7. For example, if an application is known to be incompatible with Windows 7, an administrator can create a preflight check script to check for the existence of the application before proceeding with the installation.
Based on the results of the preflight checks, the administrator can configure the wizard to terminate the process or allow the user to continue with a warning about failed preflight checks and resulting impacts. There is no limit to the number of preflight checks, as long as they can run and finish in less than five minutes. If they take longer than five minutes, the wizard stops running the script. For the preflight checks that the tool provides, the user receives exit messages that aid in remediating any problems indicated as warnings or errors.
An administrator can modify, remove, or add to the preflight checks—for example, the return codes and text descriptions—by using a graphical designer included with UDI that modifies the XML in the configuration file.
Installation of Applications
Two approaches exist for installing applications as part of a Windows 7 deployment. Administrators can include applications as part of the Windows Imaging (WIM) image in the base operating system, or they can install the applications after the WIM image as individual OSD task-sequence steps. Administrators often include the applications in the WIM image for applications that are not widely used and are not updated frequently. This approach has two primary drawbacks:
The increase in the size of the WIM image adversely affects download times.
The image requires more maintenance because a new WIM image must be created and System Center Configuration Manager packages must be updated whenever an application is updated in System Center Configuration Manager.
As an alternative to including applications in the WIM image, OSD can integrate with the Software Distribution feature in System Center Configuration Manager to enable end users to select the applications that they want to install as part of the OSD process and dynamically add those applications to the task sequence. As shown in Figure 2, the applications are listed in a tree view, as defined in the wizard configuration file. For example, an administrator can define an application group by business unit, location, or application type, and then define all the applications for that group and the selection defaults. The administrator can then easily change or add applications that are available in the System Center Configuration Manager database.
Figure 2. Application selection in the OSD wizard
The primary purpose of the wizard is to enable end users to affect the final outcome of their Windows 7 image. However, for environments where the end user is not expected to provide much input, administrators can hard-code the bulk of the task sequence and configure the wizard to display a minimal amount of information.
Migration of User Data and Settings Through USMT 4.0
When an OSD installation wipes clean the volume where Windows 7 will be installed, the user state must be captured accurately every time OSD is used. Otherwise, a risk of data loss exists.
USMT 4.0 includes a base set of configuration files that can be customized for specific environments to capture the state of a user’s computer, including data and settings. These configuration files, MigApp.xml and MigDocs.xml, satisfy the data migration requirements for most scenarios.
After USMT has gathered all the information that it needs about a user’s data, it must store this data while the migration occurs. In previous versions, USMT copied and stored the data on an external device or location such as an external hard disk drive, DVD, or file share. But considering that the typical Microsoft employee stores approximately 1 gigabyte (GB) of data, and considering the high number of users, the space required for copying that data would be significant. This volume of data leads to a variety of concerns, including spikes in network traffic, potential overload of server infrastructure, and the cost of storage for a one-time upgrade.
Further complicating the situation is the fact that accurately predicting the volume of data and timing of migrations is not practical, leading to an unscientific process that might produce unpredictable and unsatisfactory results. Also, the amount of time required to copy large amounts of data to a temporary location and then copy it back to the original location greatly extends the amount of time to perform an operating system upgrade.
To solve these problems, USMT 4.0 introduces support for a feature called hard links, which facilitates the local storage of user data on the user’s computer. USMT uses hard links to store pointers to the physical files so that the system can be backed up and restored without the need to physically move the files on the disk. This ability significantly reduces the amount of time to migrate to Windows 7. The only requirement for using hard links is that the user’s computer must have at least 250 megabytes (MB) of free disk space. Microsoft IT uses the hard-link capabilities of USMT 4.0 as a key part of the OSD deployment solution.
Before using the new solution to deploy Windows 7 enterprise wide, Microsoft IT piloted the solution in two phases that targeted Redmond-based users. The goal for the first phase was to verify the functionality and usability of the OSD wizard, and to obtain baseline measurements on execution time and utilization load on the System Center Configuration Manager infrastructure. Microsoft IT limited this pilot to 500 users. After a successful first-phase pilot, Microsoft IT successfully reached the goal for the second phase—10,000 Windows 7 deployments with very few installation failures after computers passed the preflight checks.
Microsoft IT created “Work Smart” guides that provided detailed, step-by-step instructions on how to use the OSD wizard for Windows 7 installations. These instructions enabled users to quickly become familiar and comfortable with the new service. Microsoft IT extensively trained support staff and support channels on the installation process before rollout of the pilots. Microsoft IT also created and continuously updated self-service troubleshooting guides, along with an e-mail alias for user feedback on the deployment experience.
An important feature of the OSD solution is the ability to push a deployment to specific computers. However, for the pilot phases, Microsoft IT chose to encourage user-initiated deployments by using the software update pop-up notifications in System Center Configuration Manager. Users can click an option in the pop-up notification to begin the OSD wizard. Microsoft IT plans to identify push deployment scenarios for specific user populations in the enterprise.
Enhancements to the OSD Wizard After the Pilot Phase
Several features were added to the OSD wizard after the pilot phase of the Windows 7 deployment. MDT 2010 Update 1 incorporates these and other enhancements, making Microsoft IT's customized solution plus additional enhancements available to all Microsoft customers. The new features include:
Dependency mapping and exclusions for applications. For example, Microsoft Office Live Meeting requires Microsoft Office to be installed, so selecting Live Meeting will automatically select Microsoft Office as well. The wizard is honors these rules and orders the installation such that no application will fail because of dependencies. For applications that are not supported for a particular set of users, administrators can exclude them from the selection list by using an exclude rule. For example, when an end user selects Microsoft Office 2007, the OSD wizard automatically disallows the selection of Microsoft Office 2010. When users select applications included in either dependency or exclusion rules, the wizard notifies them of the rule and asks whether to continue or remove the application.
Required installation of specific applications. This is useful for ensuring that applications such as key security tools are installed automatically and without any option for user override.
Ability to prevent applications from being installed on unsupported hardware. For example, the wizard can prevent users from installing 64-bit applications on 32-bit computers.
OSD user interface tool for administrative use now called UDI. Previously, an administrator had to make changes to the OSD wizard by editing the XML code. This new tool enables administrators to make changes to the wizard by using a graphical user interface.
Ability to scan computers for all preexisting applications so that the applications can all be reinstalled as part of the operating system deployment. This preflight check determines the existing application configuration, identifying the applications based on product ID, System Center Configuration Manager package ID, or program name.
Improvements to the dual-boot preflight check. The earlier method yielded a high number of false positives, mainly because of the existence of original equipment manufacturer (OEM) partitions on some computers.
During the deployment of the OSD-based solution, Microsoft IT identified best practices to help improve user satisfaction and installation success rates and to reduce support incidents. These best practices include:
Manage user expectations. Microsoft IT provided communications such as detailed user guides and self-service training and support content. Pop-up notifications in System Center Configuration Manager are a highly effective and efficient method to make end users aware of upgrades and to start the upgrade process.
Estimate and prepare for anticipated support needs. A pilot deployment is a good way to gauge the expected impact on support organizations. An organization should also thoroughly train support personnel.
Decide early on how to handle dual-boot scenarios. Most of the failed installations for Microsoft were actually failures to pass the preflight check because of dual-boot detection. Some organizations may find that many dual-boot configurations are no longer in use or required.
Include a summary results page. The summary results page informs the end user about what the OSD wizard has accomplished. It also provides valuable detail to support personnel if any issues occur during the deployment.
Take advantage of the reporting capabilities of System Center Configuration Manager to proactively drive problem management. System Center Configuration Manager provides a variety of reports that administrators can use to identify frequent deployment issues that they should address.
Baseline the System Center Configuration Manager infrastructure to determine the capacity for concurrent deployments and plan a phased rollout accordingly. The capacity of the System Center Configuration Manager DP servers and the number of simultaneous deployments can significantly affect the time required to deploy an operating system to a computer.
Use the System Center Configuration Manager catalog to bundle drivers that require a restart. Adding drivers to the System Center Configuration Manager catalog installs the drivers as part of the operating system setup. This technique minimizes the number of restarts required during installation of the operating system.
Microsoft has realized significant benefits from the new solution:
Users can start using Windows 7 quickly. The average installation time is just over 2 hours, including migration of all user data and settings and reinstallation of productivity applications.
The new process greatly increases user satisfaction, according to feedback gathered during the pilot phase. The process starts with a System Center Configuration Manager pop-up notification. When the user clicks the installation option in the pop-up notification, the OSD wizard starts and provides intuitive options and meaningful status throughout the installation process. It finishes with summary information so that the user knows what the wizard accomplished.
Support calls for user-driven operating system deployments have significantly decreased from previous methods of operating system deployment because the end-to-end and intuitive installation process provides high success rates. Reduced support calls reduce support costs associated with operating system deployments.
Microsoft IT wanted to increase user satisfaction and reduce overall support costs associated with deploying Windows 7 to more than 100,000 client computers at Microsoft. Major enhancements to Systems Center Configuration Manager and the User State Migration Tool provided the foundation for the solution.
The solution includes an XML-based OSD wizard that provides an intuitive end-user experience. USMT 4.0 migrates the user state and data, and the OSD feature uses a task sequencer to automate the deployment process. OSD then uses the existing System Center Configuration Manager infrastructure to make Windows 7 deployments available to users.
Users who take advantage of the solution can start using Windows 7 quickly with their previous configuration settings and data preserved. The average installation time is just over 2 hours, including migration of all user data and settings, and reinstallation of productivity applications.
Microsoft IT has reduced support costs for operating system deployments by creating a solution that is built on Microsoft technologies and that provides an intuitive, end-to-end user experience with high success rates for deployment.
Based on this successful deployment experience, Microsoft IT and the Solution Accelerators team integrated the OSD wizard, now known as UDI, into MDT 2010 Update 1. Customers can take advantage of the benefits of System Center Configuration Manager, OSD, USMT, and MDT 2010 Update 1 in similar deployments.
For More Information
For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada Order Centre at (800) 933-4750. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information via the World Wide Web, go to:
© 2010 Microsoft Corporation. All rights reserved.
This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY. Microsoft, Active Directory, BitLocker, Visual Basic, Windows, and Windows Vista are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.