Technical White Paper

Published: July 18, 2006 | Updated: January 8, 2007

Executive Summary

This white paper shares the experiences of the Microsoft Information Technology (Microsoft IT) organization in the deployment of Microsoft® Windows Vista™ Beta 2. This document describes the Microsoft IT high-level processes for deploying Windows Vista Beta 2 and the best practices learned as a result. IT professionals, especially architects, can use this white paper to help plan their own Windows Vista deployments.

Microsoft chose an "opt-in" model for client deployment that allows users to decide whether and when to upgrade and allows them to upgrade at a convenient time rather than on a specified schedule. Giving control of the installation to the user—especially allowing them to choose the time and method of installation—provides a more positive user experience. This contrasts with forced upgrades, which may occur at inconvenient times and produce unexpected results that may include data loss or system failure.

Microsoft IT facilitated the deployment with careful pre-deployment planning (including establishing clear goals shared with other organizations, such as the Windows Development organization), end-user training, extensive application compatibility testing, and a variety of deployment paths for users to choose from.

Because Microsoft IT must deploy various prerelease versions of Windows Vista (while it is still in development), some of their processes might not align with your business needs.

Note: For security reasons, the sample names of forests, domains, internal resources, and organizations used in this white paper do not represent real resource names used within Microsoft and are for illustration purposes only.

Introduction

Corporate decision-makers often request information about Microsoft employees' experiences in using Microsoft products and technologies within the company. Microsoft IT not only provides IT services for Microsoft, but it also acts as the first customer for each new release of server and business productivity software. The methods that Microsoft IT uses to deploy these technologies, and the experience that Microsoft IT gains from these deployments, often provide meaningful deployment and operational guidelines for other organizations that want to deploy Microsoft products.

Additionally, because Microsoft IT works with these Microsoft products from the prerelease versions to the release to manufacturing (RTM) versions, Microsoft IT provides the rest of Microsoft with valuable feedback about product features and functionalities. This feedback improves Microsoft products throughout the software development life cycle and helps Microsoft customers and partners successfully deploy these products and technologies.

Microsoft considers the availability and the reliability of its business desktop implementation a critical part of the day-to-day operations of the company.

Overview of the Microsoft IT Environment

Microsoft IT provides global IT services that range from server and network operations to software deployment and end-user technical support. For internal deployments, Microsoft IT has the following objectives:

• Prove operating system reliability and functionality prior to the external release.

• Update clients with minimal cost of testing and minimal impact on corporate operations.

• Serve as a first customer for Microsoft products by validating code, identifying bugs and compatibility issues, and providing reliability statistics.

Microsoft IT deployed Windows Vista into an environment characterized by a wide geographic distribution, complexity of server roles and applications, and the requirement to deploy and test pre-release versions of multiple software products concurrently.

The Microsoft IT environment spans more than 400 locations in more than 80 countries and regions. About half of the locations are in the Puget Sound region of Washington State, with the next largest presence in Japan. On average, each user employs three desktop computers in various roles that range from daily operations (e-mail, Microsoft Office applications) to testing products. The following table summarizes the large and complex Microsoft IT environment.

Table 1. Microsoft IT Environment

Microsoft IT Deployment Requirements

Because Microsoft IT is required to test pre-release versions of software, each product must be deployed many times before release, sometimes in rapid succession. Deploying multiple builds of an operating system prior to its release is especially demanding, because both the product deployed and the deployment tools are in development during most deployment phases. Based on deployment goals at multiple milestones, Microsoft IT will deploy more than 60,000 desktop computers running Windows Vista prior to RTM.

Microsoft IT will deploy the following operating systems prior to RTM:

• Beta builds. These pre-production builds enable product teams to set short-term goals for quality and functionality. Microsoft IT helps validate these builds in real-world scenarios. There may be weekly versions of a beta build between milestones; only the final beta build for the milestone is deployed.

• Releasecandidate (RC) builds. RC builds are versions that are almost ready for public release. Microsoft IT might receive several RC builds of the operating system.

• RTM builds. An RTM build is the final build that will be released to customers. After Microsoft IT receives the RTM build, it completes the software package for the installation sequencer and deploys the package as quickly and safely as possible. The goal is to completely deploy the RTM build within 60 days of its availability.

Situation

Microsoft IT provides global IT services that range from server and network operations to software deployment and end-user technical support. In addition to running a world-class IT utility, Microsoft IT participates in global software beta testing and deployment. The Windows Vista beta, with pre-RTM deployment goals in excess of 90,000 clients and relying on new and untested deployment technologies, provides an incredible opportunity to test the new operating system and its underlying deployment technologies.

Microsoft IT Objectives

Microsoft IT has the following objectives for deploying Windows Vista Beta 2:

• Maximize IT resources by moving the installation process to the user.

• Provide an installation experience comparable to Microsoft Windows® XP.

• Improve Windows Vista through pilot testing and feedback to Windows development.

• Improve Windows Vista deployment technologies through use and feedback.

• Achieve deployment goal of 30,000 clients during Beta 2.

Features Driving Adoption in Microsoft IT

There are many new features in Windows Vista. For Beta 2, Microsoft IT focused on the following technologies:

• Network Access Protection. Administrators use Network Access Protection to prevent clients that do not meet corporate security requirements from connecting to an internal network and potentially spreading malicious software (malware) to other computers on the network.

• User Account Control. User Account Control enables users to change common settings without requiring administrative rights. User Account Control prevents standard users from making potentially dangerous changes to their computers while allowing most applications to install and run normally.

• Microsoft BitLocker™ Drive Encryption. BitLocker Drive Encryption is a hardware-enabled data protection feature that encrypts the entire Windows system volume to help prevent unauthorized users from compromising the Windows file system.

New Features That Microsoft IT Used to Improve Deployment

Windows Vista has several new features that enhance the deployment experience. During the Beta 2 deployment, Microsoft IT used the following technologies:

• Image-Based Setup (IBS). IBS, based on the new Windows Imaging (WIM) file format, provides a consistent setup experience regardless of the deployment mechanism. IBS also supports unattended installation options on a per-device, per-architecture, or per-server basis.

• Multilingual User Interface. Multilingual User Interface (MUI) support enables many language support packages to be associated with a single image. Thirty-five MUI languages are available for customers of Microsoft Windows Vista Enterprise. An additional 62 languages are available as options in all versions of Windows Vista.

• Windows Deployment Services. Windows Deployment Services, the Windows Vista version of Remote Installation Services (RIS), provides a network-based installation of Windows Vista and supports all IBS, WIM, and MUI features.

Shared Goals with Windows Development

When Microsoft IT agrees to deploy a new product, it works with the development team to establish a set of shared goals. These goals are common to and agreed upon by both parties. For example, one goal is that the development team will respond to critical failures within a specified amount of time. Microsoft IT and Windows Development established a broad range of shared goals for Windows Vista.

The following shared goals are specific to Windows Vista Beta 2:

• Total installed Windows Vista-based clients (30,000):

  • Deployment mechanisms: 30 percent deployed by Windows Deployment Services

  • Time required for remote installation: equal to that of Windows XP

• Ease of management:

  • Key Management Service (KMS) servers required: two

  • IT Image computers activated through volume licensing: 100 percent

  • Windows Long Horn servers required to support Windows Vista deployment: two (for KMS)

  • Reduction in number of images to be maintained: 50 percent compared to Windows XP

  • Reduction in updates requiring restarting computer versus Windows XP: 20 percent

  • Difference in number of critical security updates versus Windows XP: Fewer

  • Reduction in computers failing to respond: 15 percent

  • Reduction in incidences of Microsoft Windows Internet Explorer® failing to respond (hang or crash): 25 percent

• Test results:

  • Tier 1 line-of-business (LOB) applications tested: 100 percent

  • Tier 1 LOB client applications that can be run in protected admin mode: 100 percent

  • Applications running without elevated rights on Windows XP versus Windows Vista: 100 percent

  • Standard client products passing compatibility testing: 100 percent

  • Standard desktop configurations tested: more than 26

  • Standard mobile computer configurations tested: more than 23

• Bug management:

  • Unique blocking bugs fixed or agreed to defer: 100 percent

• Supportability:

  • Reduction in calls for setup assistance: 50 percent

  • Reduction in operating system-related Helpdesk calls versus Windows XP: 20 percent

  • IT Showcase docs prepared: more than 4

Solution

To meet its deployment goals, Microsoft IT created a deployment project team responsible for preplanning, planning, communication and education, and deployment technologies.

The following table outlines how Microsoft IT will achieve its deployment goals.

Table 2. How Microsoft IT Will Achieve Its Windows Vista Deployment Goals

Predeployment Planning

To prepare for the deployment of Windows Vista Beta 2, Microsoft IT set internal client expectations, created an escalation plan, and trained its internal Helpdesk (tier 1 support) personnel.

Setting End-User Expectations

The Windows Vista deployment internal to Microsoft is on an opt-in basis, meaning that users have a choice to participate in the beta or wait for the RTM release. Microsoft IT also uses a client-requested deployment method for Windows Vista. To meet its deployment goals while providing this level of flexibility, Microsoft IT had to anticipate issues, measure the user experience, put feedback mechanisms in place, and iterate its communications and deployment plans.

To further increase participation in the beta, when each prerelease version of Windows Vista was released, the senior vice president of the Windows Division sent out an e-mail message to all full-time employees to request participation. Microsoft IT has found that having visible executive support is essential for successful deployments. When employees know that executives are behind decisions and changes, they are more likely to be positive and flexible. Following the e-mail message, end users received a newsletter that contained the following information:

• Product information, including what is new and what has changed

• Links to training resources

• Pre-installation information, including hardware compatibility checks and how to migrate files and settings

• Installation instructions based on which operating system the computer is currently running

• Post-installation configuration information to help users minimize downtime

• Customer support resources and instructions for reporting issues about the product

The goal of these communications was to set the users' expectations about installing and using the operating system and to get employees excited about the release.

Creating an Escalation Plan

Microsoft IT established a well-defined resolution process for diagnosing and correcting any deployment failures or issues with Windows Vista. When a user encounters an issue, it is escalated through the following groups in the specified order. Although this process is specific to Microsoft, any organization should create a similar escalation process before calling Customer Service and Support with Windows Vista questions. Helpdesk (tier 1). Users first contact Helpdesk. Helpdesk personnel are trained to test resolutions and workarounds that the product teams have developed. Before an issue is escalated past tier 1, a subject matter expert must review the issue and confirm that it should be handled by tier 2.

1. Advanced support (tier 2). This team is trained to resolve the more complex issues that require a deeper level of technical knowledge. These issues typically include configuration problems, application compatibility, driver issues, and connectivity issues. This team investigates an issue, and if a resolution is found, the team creates a support article so that others can fix the issue in the future.

   Tier 2 also determines where issues are escalated. If an error in the code causes the issue, the team escalates the issue to tier 3 for further investigation. For any issues that the operating system does not cause, the tier 2 team can engage the appropriate service or application support team to resolve the issue.

2. Windows Diagnostic and Debug Team (tier 3). The Windows Diagnostic and Debug Team (WINDDT) is the Microsoft IT diagnostic and debug support team. It investigates and debugs issues at the code level, determines the root cause, and escalates to the product group as appropriate. If needed, the team contacts the support team for the application or service that an issue is related to. For example, if the issue affects only Microsoft Office Word functionality, WINDDT contacts the Office support team.

   Note: Tier 3 is the internal Microsoft team analogous to Customer Service and Support Because Microsoft IT must provide feedback to the product group, it has a team analogous to a CSS escalation team within its organization. An organization should call CSS after issues are raised within its own advanced support team.

3. Windows Vista product group. If the WINDDT team determines that the problem is because of Windows Vista, it escalates the issue to the product team, which fixes the issue in the code.

Training Helpdesk

Helpdesk employees received extensive training to support Windows Vista. Microsoft used the following process to train these technicians:

1. Create a list of support articles and training materials. Microsoft IT compiled a list of issues and features that the technicians needed to understand in order to help users with Windows Vista. For example, Microsoft IT gathered information about how the new features work, known issues, and so on.

   Note: Helpdesk has a database of support articles that document known issues. When a user calls with an issue, if the technician cannot fix it right away, he or she searches the database to see whether the issue is documented. These articles are also available for users to search to self-diagnose the issues that Microsoft IT has encountered, which reduces the time that users spend calling Helpdesk. Each article contains information about the issue, in addition to the resolution or workaround.

2. Train the trainers. Microsoft IT used the articles and training materials to create presentations. Then, subject matter experts used the presentations to train the trainers on each feature or issue. For Beta 2, Microsoft IT trained approximately 10 trainers.

3. Train the technicians. The trainers went back to their teams and trained the phone technicians. The trainers used the presentations from step 2, and each presentation was updated if the product had changed. Approximately 58 phone technicians were trained for the Beta 2 version of Windows Vista. Each trainer was trained on the following topics:

   • What is Windows Vista

   • Installation

   • Data migration

   • Desktop Windows manager and graphics

   • Microsoft Windows Internet Explorer version 7

   • User Access Control

   • Windows collaboration

   • Microsoft Windows Media® Player

   • Connection management

   • Windows Defender

   • Networking, network diagnostics, and remote access

   • Remote assistance

   • Device manager

   • Drivers

   • Troubleshooting

   • Windows Online Help

   Note: The trainers also trained 355 desk-side technicians. These technicians provide support to employees in 291 cities worldwide where Microsoft has subsidiary offices.

4. Establish ongoing communication with the product group. Microsoft IT held daily meetings for two weeks following each release and twice-weekly meetings thereafter with each team involved in the escalation path. The goals of these meetings were:

   • To increase communication among tier 1 support, tier 2 support, and the appropriate product group about issues being seen and possible workarounds or fixes.

   • To continually evaluate the escalation process. For example, Microsoft IT evaluated whether the appropriate amount and kinds of issues were being escalated to the product group.

   • To identify a need for new support articles and any changes or additional documentation that needed to be added to the end user's product Web site (for example, installation instructions and frequently asked questions).

Communicating Project Status

Through previous experience, Microsoft IT has learned the importance of communication in large deployment projects. Deployment teams need to establish regular communication methods to convey what they plan to do and when they plan to do it. Additionally, they must communicate quickly when problems arise. To accomplish this, Microsoft IT recommends the following communication methods:

• Project Web site. Microsoft IT created a SharePoint site that contained all of the project details and documentation. The site included deployment schedules, meeting minutes, status updates, problem resolution processes, and other information related to the deployment.

• Regular status reports. Microsoft IT sent regular status reports. These e-mail messages discussed project issues, action items, and metrics related to the deployment, and provided a link to project plans.

• Weekly meetings. Microsoft IT had meetings each week to monitor the deployment across all teams. A representative attended from each team that was involved in the deployment.

• Quarterly reviews with stakeholders and executives. Microsoft IT met with stakeholders and executives approximately four times a year to communicate deployment progress and make key decisions.

• Readiness package for regional IT. Microsoft IT created an internal Web site to communicate deployment plans and information to the regional IT department. The regional IT department is in charge of data centers and branch offices that are outside the Redmond location. This site contained the information that the regional IT departments needed to deploy Windows Vista in their areas. For example, information included an e-mail template with instructions on how to customize it to the different areas, a partner contact sheet, and copies of a customizable newsletter.

Training and Education

Microsoft IT spent a lot of time creating an effective project team and educating end users. For any organization, both the project team and the users must be prepared for a deployment. When an organization is working with beta products, it must create and agree on detailed roles and responsibilities, as well as change management and escalation procedures, in order to efficiently respond to rapid change during the active deployment period.

Project Team Training

To keep the project team efficient and running smoothly, Microsoft IT did the following:

• Set deployment goals. Microsoft IT set goals for how many computers it wanted running Windows Vista for each milestone (Beta 2, RC1, and RTM).

• Include technical experts on the project team. The Microsoft IT project team consisted of both project managers and technical experts. The technical experts were vital to ensuring that the deployment was efficient. They had a deep understanding of Windows Vista and were devoted to the deployment. Because the technical experts understood the product so well, they were able to guide decisions and anticipate problems.

• Put security experts in charge of defining and fixing security issues. The security experts influenced decisions to ensure that the environment met security guidelines. Most issues were based on new features in Windows Vista that affect security (for example, BitLocker Drive Encryption, User Account Control, and Phishing Filter). These experts determined the effect that these features would have on the environment.

• Put infrastructure experts in charge of defining and fixing infrastructure issues. The infrastructure experts examined various aspects of Windows-based networking, looking for issues that would affect deployment and operation of the Windows Vista-based client. They discovered that TCP tuning, a new feature that more efficiently uses wide area network (WAN) bandwidth, performed very well in production tests but could not be implemented initially because it did not support the currently available bandwidth monitoring tools.

  Note: Microsoft IT recommends that an organization has technologists working on the deployment, at least until it begins deploying the operating system. The organization should consider hiring a contractor or someone from Microsoft if it does not have qualified and available resources. An organization that is interested in hiring a Microsoft expert should contact Microsoft Services.

• Develop a detailed deployment plan. Microsoft IT spent several months planning for the deployment before it took any action. This preparation enabled Microsoft IT to anticipate problems and create a plan that worked.

• Perform the deployment based on the plan. Microsoft IT followed its plan as much as possible, which increased efficiency. However, Microsoft IT was flexible if a problem arose that required a change.

• Communicate decisions across the project team. Microsoft IT strove to keep all team members team up to date on the project details. Project managers brought information back to the team from higher-level meetings to ensure that the decisions that they made aligned with others across the department.

End User Education

After the prerelease version of the operating system was complete, Microsoft IT continually updated a product Web site and sent regular e-mail messages to keep employees connected to the IT department.

Note: It is important for an organization to consider what users need to know in order to decrease downtime after Windows Vista is installed. The organization should provide users with the information they need to do their work, as well as information that will reduce helpdesk calls after the installation. Otherwise, users may spend a significant amount of time getting familiar with the operating system and resolving issues. Although these items are not critical to deployment, educating users will increase users' productivity and their overall satisfaction with the deployment.

Product Web Site

Microsoft IT created a Web site targeted to employees who install and use Windows Vista. The Web site contains the following tools and information:

• Product overview. This includes links to key product information and information about what has changed with the user experience of Windows Vista. It also outlines User Access Control and Network Access Protection, two features that affected users the most.

• Pre-installation information. This includes the information that end users need before installing this product. For example:

  • Hardware requirements. For users to verify that their computers meet minimum requirements to run Windows Vista, they can run the Windows Vista Upgrade Advisor. For more information about this beta product, see the Microsoft Web site.

  • Information about migrating files and settings. This includes instructions on how to use Windows Easy Transfer to migrate files and settings. For instructions on how to use this tool, see the Microsoft Web site.

  • Information about application compatibility. The Application Compatibility Toolkit is a set of tools and resources that are designed to help minimize the risks associated with deployments of Windows operating systems. Users can use this toolkit to find out whether their existing applications will be compatible with Windows Vista. For more information, see the Microsoft Web site.

• Installation instructions. Microsoft IT provides instructions on how to install Windows Vista based on the operating system that a computer is currently running. These specific instructions help users incorporate Windows Vista into the Microsoft environment.

• Post-installation information. This includes information about how to configure a computer to work in the environment. For example, information includes how to connect to the network, add users, and perform other configuration tasks.

• Frequently asked questions. Microsoft IT answers some of the anticipated common questions. The following table provides a representative list of the questions that Microsoft IT addresses:

Table 3. Frequently Asked Questions

• Troubleshooting. This includes the known issues and workarounds that end users may encounter.

  Note: For an organization to create this list, it should review the release notes and update the site with any issues that employees may encounter in its environment. The organization should also list any environment-specific issues that may not be documented in the release notes.

• Feedback. A feedback Web site outlines key deployment scenarios and experiences. Users can browse to this site to both rate the experience and provide anecdotal comments. The feedback improves the installation instructions and the customized installation image, and it adds or clarifies educational content.

• Customer support. Microsoft IT provides links to the following information:

  • Helpdesk. This includes phone numbers, times, and the types of issues for which the Helpdesk can provide assistance.

  • Online self-help. Microsoft IT created an internal resource that employees can use to research help articles to fix their problems. This includes links to Windows Vista Help and Support Center and specific articles that solve typical problems.

Newsletter

After the initial e-mail from the Windows Division senior vice president, Microsoft IT sent a newsletter in e-mail every three weeks. This newsletter included links to information that helped employees stay connected, ensure that their needs were met, and resolve any issues. The newsletter outlined any actions that users needed to take, along with deployment status, tips and tricks, and links to the same information that the product Web site contains.

Enterprise Learning Roadmap

Enterprise Learning Roadmap is a new feature of the Business Desktop Deployment solution accelerator. An organization can use Enterprise Learning Roadmap to tailor the information that it gives to end users. This Web-based tool helps the organization identify topics from Windows Vista Help and Support Center and Microsoft Office Online (http://go.microsoft.com/fwlink/?LinkId=70263) that fill the specific needs of users. The tool enables an organization to select training topics that are relevant to the current stage of its deployment. The organization can also select topics by user expertise or role. For more information about this tool, go to http://go.microsoft.com/fwlink/?LinkId=70262.

Application Compatibility Testing

The Microsoft IT approach to application compatibility testing for the Windows Vista Beta 2 release is explained in detail in "Application Compatibility Testing for Windows Vista," a Technical Case Study available on Microsoft IT Showcase.

Microsoft IT addressed the need for application compatibility testing by creating a Windows Vista LOB application compatibility testing program. The program revealed compatibility problems addressed by either the Windows Vista development team or the IT organization that owns the affected LOB applications. To set up the program, Microsoft IT took the actions described in the following sections.

Establish Goals and Objectives

Microsoft IT established the following goals and objectives for its application compatibility program:

• Ensure that the selected internal LOB applications are compatible with Windows Vista.

• For each selected LOB application, test key functionality and user scenarios.

• Minimize the impact that upgrading to Windows Vista has on users, support (Helpdesk call volume), business unit IT (BUIT) teams, and, ultimately, Microsoft customers.

• Identify LOB application compatibility issues early in the product development life cycle.

• Help ship the highest-quality Windows Vista operating system possible.

Select a Program Manager

Because Microsoft business units, their LOB applications, and the associated BUITs are widely distributed, Microsoft IT designated a single program manager to plan and coordinate the program.

This manager's tasks included soliciting commitments from senior management, BUITs, and test teams; selecting the LOB applications to be tested, scheduling the testing, and coordinating with BUITs; negotiating with the support team; and expediting testing tasks.

Develop the Program Management Plan

The program manager defined the requirements and scope of the testing, including scenarios, goals, and milestone dates. In addition, the program manager was responsible for obtaining support resources, briefing all parties involved, and compiling the feedback from participants.

Select the LOB Applications To Be Tested

To select the LOB applications, the program manager considered factors such as business criticality, user base, and technology dependencies.

Prioritize the LOB Applications To Be Tested

The program manager identified a pool of about 300 LOB applications: about 100 first-priority applications and a further 200 second-priority applications. The tier 1 applications each had at least 5,000 users or were used by executives. These applications would be tested prior to every major release milestone. Tier 2 applications had fewer users. They would be tested less frequently than tier 1 applications (they would be worked into the testing schedule as resources permitted).

Establish Communications Channels

To coordinate effort across organizational and national boundaries, the program manager established individual contact persons. Each contact covered multiple LOB applications in a given BUIT.

Create a Reporting Tool

The testing program used a Microsoft Office Excel® spreadsheet, which included the most relevant information, such as the application name, a unique application identifier, its usage status ("in production" versus "retired," for example), the responsible BUIT, contact persons, and test results. The spreadsheet also provided summaries of the number of applications in each result category (for example, "passed" and "failed") categorized for tier 1, tier 2, and all applications.

Build the Testing Environment

Testers endeavored to duplicate the actual daily-use environment as much as possible. To do this, they matched the versions of all involved software to those in production whenever possible, as well as duplicating real user actions and procedures.

Establish and Collect Measurements

Because Microsoft IT principally deployed Windows Vista Beta 2 as a voluntary download, the number of successful installations was the primary metric that Microsoft IT used to assess the success of the deployment. This information was collected by automated inventory polling of workstations corporation-wide via Microsoft Systems Management Server (SMS) and communicated via an internal Web site. This Web site, which also publicized the shared goals, was continually updated with the current status compared to those goals.

Additionally, Microsoft IT tracked the closure rate of calls to the Helpdesk by using call-tracking software. The goal was to keep the call rate to within 70 percent of the target.

Windows Vista Deployment

To meet the deployment objectives, Microsoft IT chose to deploy Windows Vista by using the following resources:

• Windows Deployment Services. Microsoft IT used Windows Deployment Services to build new client computers and to flatten and rebuild existing computers.

• Product Web site. Microsoft IT provides a Web site to a share-based installation for all available Microsoft products. Using this well-known site for installation of Windows Vista provided end users with a consistent experience while using standard processes saved project resources.

• DVD image. Remote and international teams were able to create bootable media locally from a centrally managed image that Microsoft IT provided.

Deployment Types

Microsoft IT relied on upgrades and bare-metal installation (including flatten and rebuild) to meet its Windows Vista Beta 2 deployment goals. The following are the most common deployment scenarios for Windows Vista:

• Upgrade. The new operating system is installed on the client computer's hard drive, without reformatting the drive, and with minimal impact on the existing file system.

• Forced upgrade. The new operating system is installed on the client computer's hard disk drive without user intervention or initiation. As with the upgrade scenario, the hard drive is not reformatted, and the existing file system is left intact.

• Migration. User data (files and settings) in known locations (such as directories and registries) is stored, and the client computer's hard disk drive is reformatted. The new operating system is installed, after which the user data is restored.

• Bare-metal installation. The new operating system is installed on the client computer's hard disk drive after the drive is partitioned and formatted appropriately. No user data is retained, and there is no assumption that the computer has a valid Windows operating system already installed.

• Flatten and rebuild. The hard disk drive of the client computer is reformatted, and the new operating system is installed. This scenario assumes that a valid Windows operating system is installed on the computer before the flatten and rebuild begins.

The following criteria can help an organization determine which upgrade path to us.e

Table 4. Upgrade Path Based on Current Client Configuration

Windows Deployment Services

Windows Deployment Services is the updated and redesigned version of RIS. Windows Deployment Services assists with the rapid adoption and deployment of Windows operating systems. An organization can use it to set up new computers through a network-based installation without requiring an administrator to be physically present at each computer and without requiring installation directly from CD media.

Windows Deployment Services is the feature name for a suite of components that work together to enable the deployment of Windows operating systems, particularly Windows Vista. These components fall into the following three categories:

• Server components. These components include a Preboot Execution Environment (PXE) server and trivial file transfer protocol (TFTP) server for network starting a client to load and install an operating system. Also included is a shared folder and image repository that contains startup images, installation images, and files that a booting client needs specifically for network startup.

• Client components. These components include a graphical user interface that runs within the Windows Pre-installation Environment (Windows PE) and communicates with the server components to select and install an operating system image.

• Management components. These components are a set of tools that an administrator uses to manage the server, operating system images, and client computer accounts.

Deploying Windows Deployment Services

At the time of Windows Vista Beta 2 deployment, Microsoft IT had existing RIS servers with Windows XP and Microsoft Windows Server 2003 images deployed throughout the enterprise. In addition to providing installation services for Windows Vista, Microsoft IT required all RIS deployment capabilities to be preserved on upgrade and moved to any new servers. This requirement meant that Microsoft IT could run its Windows Deployment Services implementation in mixed mode, allowing for deployment of Windows Image (WIM) and earlier image types. To meet this requirement, Microsoft IT used three deployment scenarios for Windows Deployment Services:

• New server installation. In a new server installation, Windows Deployment Services installs as an update to RIS, either as a software update to Windows Server 2003 Service Pack 1 or as part of Windows Server 2003 Service Pack 2. New servers were installed to provide extra installation resources for the Windows Vista deployment.

• Parallel migration. Microsoft IT already had many existing RIS servers. Where a new Windows Deployment Services server replaced an existing RIS server, Microsoft IT used parallel migration to get the new server in place with minimal impact to clients. The existing RIS server was left functional and in place until all aspects of Windows Deployment Services functionality were verified. After clients were successfully installing Windows Vista as well as Windows XP and Windows Server 2003, Microsoft IT took the RIS server offline.

• In-place upgrade. Many servers did not warrant replacement. Instead, Microsoft IT augmented them with an additional 50 gigabytes (GB) of disk space to accommodate additional images. In this scenario, the servers often had multiple roles installed and were often in remote offices. Upgrading these servers was a complex task that required close communication with the many server role owners as well as the regional support staff and release manager. The hardware upgrade was completed in advance of the software upgrade to reduce the number of variables if troubleshooting became necessary.

Implementing Windows Deployment Services

To preserve its investment in RIS, Microsoft IT chose to upgrade existing RIS servers to Windows Deployment Services or to build new Windows Deployment Services servers in mixed mode. Windows Deployment Services mixed mode enables deployment of WIM and earlier (RIS) image types. To implement this functionality, Microsoft IT configured Windows Deployment Services by using the OSChooser:Yes option.

Other implementation details include providing x86-based and x64-based images and allowing the clients to choose what operating system to install regardless of processor type(in the case of x64-based clients). To work around an x64-based basic input/output system (BIOS), which does not report the architecture properly, Microsoft IT also set ArchitectureDiscovery:Yes.

Specifying the Client Image

To specify the client image, Microsoft IT began with the security-enhanced volume licensing and activation feature of Windows Vista. Microsoft IT also applied configuration changes appropriate for the environment, including data collection tools and common applications. Using a volume-licensed image meant that end users did not need to enter a product key each time they installed Windows Vista. Not having to apply for a product key in advance of installing the operating system or performing product activation steps saved time and created a better user experience. The security-enhanced volume licensing solution was also available for remote installations over a virtual private network (VPN).

Changes made to the base image included turning on Windows Firewall and installing antivirus software. Image specifications that include the 2007 Microsoft Office system were also established. When the specification was complete, it was used to create a reference image.

Implementing the Client Image

Microsoft IT then built a reference computer to the established Windows Vista specifications. After the reference computer was built and reviewed for completeness, Microsoft IT created a reference image by using sysprep.exe. Microsoft IT then added the prepared image to the Windows Deployment Services server. After the image was added to the server, unattended installation files and language packs were applied, which enabled Microsoft IT to associate multiple languages to a single image.

Installing Windows Vista by Using Windows Deployment Services

After Windows Deployment Services was installed and configured, clients with PXE- capable startup ROMs could boot to a Windows Deployment Services server when a user pressed F12 at system startup. The Windows Deployment Services client would then load and present installation options, including Windows Vista, Windows XP, and Windows Server 2003. The client then selected the version to install and waited for the Windows Vista installation and setup to complete.

Alternative Deployment Methods

In addition to using Windows Deployment Services for new or rebuilt clients, Microsoft IT provided the following deployment methods.

Web-Based Installation from Product Web Servers

For upgrades and parallel installations and for computers that did not support PXE startup, Microsoft IT

provided a Web-based installation method by using its product Web servers, which are used internally as a common installation point for Microsoft products. This upgrade method enabled clients to preserve most of their configurations and application settings. Preserving existing settings during upgrade got the end-user clients back to work more quickly, making the deployment a better experience.

Installation from DVD

Microsoft IT also provided the Windows Vista Beta 2 product DVD to Microsoft employees. Like the Web-based installation method, the product DVD was used for upgrades and parallel installations. The DVD was equally useful for non-PXE clients and clients that were not connected to the corporate network.

Why Microsoft IT Chose Its Deployment Method

In many operating system deployments, the IT department delivers and installs the operating system software to the client computers in a client-request model. Microsoft IT chooses not to perform this type of deployment for client operating systems. Instead, Microsoft IT provides the self-help process for end users to install the product themselves at their discretion. Microsoft IT deploys client operating systems in this client-requested model for a variety of reasons.

Microsoft chose this deployment method partially because although it manages its computers to a very tight security baseline, it allows all employees to have full administrative rights on their computers. Employees can configure their computers as they choose in order to complete their jobs; they can install almost any application, and they may have a variety of Windows operating system versions installed. Employees need this flexibility to develop and test Microsoft products. Because Microsoft employees do not have a single standard desktop across the company, Microsoft IT must offer a self-service model rather than pushing a company-wide standard operating system.

Note: The configurations and settings that Microsoft IT controls are those that provide security or manage general productivity improvements (for example, pushing Microsoft .NET Framework version 2.0 to all computers so that end users do not have to download it themselves). Microsoft IT forces updates and default settings to client computers that help keep the network secure. Microsoft IT tries to limit the restrictions that it places on each client computer to allow employees the freedom to create and troubleshoot software as the business dictates.

In some ways, the client-requested method is easier on the user. Instead of forcing an operating system upgrade based the Microsoft IT schedule, users can choose to upgrade their computers based on their own work schedules. Although they have to install the product themselves, they can choose a time that is convenient for them. To make this method cost-effective, Microsoft IT needs to provide clear and accurate processes to ensure that even novice users can start and finish an upgrade without encountering problems.

The client-requested deployment method improves Microsoft products. The nonrestrictive environment allows Microsoft employees to test the software in all kinds of scenarios. For example, because Microsoft employees install and configure Windows Vista themselves, they find issues that might not have been found otherwise. As a result, Microsoft ships better products that have been tested by users of all types.

Although this deployment method is not possible for organizations whose users are not administrators on their computers, many of the techniques and technologies that Microsoft IT uses are completely transferable to any kind of deployment. The planning processes and best practices are not specific to a client-requested model, and most of the technologies (like image preparation and Windows Deployment Services) can be used with any deployment method.

Best Practices

Microsoft IT followed or established many best practices during the Windows Vista deployment. Microsoft IT spent months planning the deployment, testing, self-hosting, and working on desktop deployment technologies prior to making the Windows Vista Beta 2 commonly available throughout Microsoft. Below is a list of the Microsoft IT best practices for a successful Windows Vista deployment:

• Read the documentation. Before a user installs Windows Vista, he or she should read at least the following documentation on the Microsoft Web site. This content will help the user become familiar with the product and any known issues.

  • Release notes. For information about known issues with Windows Vista Beta 2, see http://go.microsoft.com/fwlink/?LinkId=66576.

  • Product overview for IT professionals. To view this content, see the Microsoft Web site.

  • Product evaluation. To view this content, see the Microsoft Web site.

• Make sure you have clear responsibilities and priorities. Clear responsibilities and aligned priorities help ensure that a project progresses efficiently. For example, make sure that a single program management team is overseeing the overall deployment plan and can drive status reporting and communication to stakeholders.

• Document all processes. In projects with a longer duration, it is important for an organization to document all of its processes. This way, if employees change positions or leave the organization, the people taking over have a clear picture of how to accomplish their jobs.

• Use information and feedback from past deployments. This may seem like common sense, but an administrator who is new to his or her position may not know that this feedback exists. An administrator can use feedback from any deployment—not just from operating system installations. For example, an administrator can use feedback if he or she deployed Windows XP Service Pack 2.

• Test critical applications prior to deployment. An administrator can use the Application Compatibility feature to find out whether your existing applications will be compatible with Windows Vista. For more information, see the Microsoft Web site.

• Deploy a Key Management Server. Using a Key Management Server to implement Volume Licensing version 2 creates a better client experience by eliminating the need to acquire a product key prior to installation and reduces license management expense.

• Be aware of disk space considerations. When planning for deployment, an administrator must take into account the required disk space for the installation. For detailed information about space requirements for Windows Vista Beta 2, see the Microsoft Web site.

Conclusion

Microsoft IT deployed Windows Vista Beta 2 into the Microsoft global environment by using client-driven installation methods based on readily available deployment technologies. Microsoft IT was able to create a compelling installation experience, based on client requests rather than scheduled or mandatory installation. Careful planning, training the deployment team, educating end users, using the latest deployment technologies, and being responsive to the client base participating in the beta program have put Microsoft IT on track to achieve all Beta 2 goals.

Any organization, regardless of its size, should complete each of the phases described in this document to create a great user experience, achieve deployment goals, and mitigate risk during Windows Vista deployment.

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 information Centre at (800) 563-9048. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information through the World Wide Web, go to:

http://www.microsoft.com

http://www.microsoft.com/technet/itshowcase