A 200,000+ Desktop Deployment
Deploying a major software application such as Microsoft® Office 2003 or Microsoft Windows® XP Professional throughout a global enterprise can be a challenge for any IT organization. And just because Microsoft wrote the software doesn't mean internal deployment is a simple process. If you ever wanted to look inside Microsoft to catch a glimpse of how the Microsoft IT team does deployment, get out your notebook because I'm going to run you through the steps they took to deploy Office 2003 in several iterations, from the first beta release to the final version.
The Beta Deployment Cycle
The Microsoft approach to the development of reliable software includes the wide-scale deployment of pre-release applications to employee's computers—a practice known as "eating your own dog food." The feedback that the product development groups glean from this process is invaluable and helps ensure quality in the development phase. On the installation and deployment end, the dog food process provides Microsoft IT teams with valuable quality control experience.
IT/LOB Application Testing
There is always a potential for compatibility problems when deploying any new version of software, software update, or service pack. To minimize this risk, Microsoft IT maintains a central data repository containing information on every known line-of-business (LOB) application. The database is accessible via an intranet portal, so interested parties can easily generate reports detailing which technologies an application has been built with or has dependencies on.
For example, when planning the deployment of a Windows XP Professional Service Pack, Microsoft IT was able to report any applications that have dependencies on Microsoft Internet Explorer, ActiveX® controls, firewalls, and so on. Such a report can contain other pertinent information including the e-mail address of the app owner or person responsible for testing it, as well as the number of clients using it.
At each dog food deployment milestone (Beta 1, Beta 2, and so on), applications are tested for compatibility and any problems are identified and corrected before the final release. For example, when Microsoft tested Office 2003, they discovered that there were a number of apps relying on the Office XP Web Components that would require updating to the newer version.
The Microsoft IT team runs a variety of scenarios throughout the testing process. These scenarios simulate various dependencies in which new features require other applications to help them run. For example, the Cached Exchange Mode functionality of Microsoft Outlook® 2003 requires Microsoft Exchange 2003 to be running for the full functionality to be available. And because an Exchange Server migration and consolidation project and some user training were occurring at the same time as the Office 2003 deployment, the timing of the upgrades had to be planned carefully.
For more information on the Exchange server consolidation project, see the article Deploying a Worldwide Site Consolidation Solution for Exchange Server 2003
In order to validate certain feature scenarios, the Microsoft IT team must deploy custom Office 2003 settings. For example, the team deployed all Outlook 2003 e-mail clients with the Cached Exchange Mode turned on by default.
Because much more software deployment happens at Microsoft than in a typical organization, creating a painless end-user experience is paramount for the Microsoft IT team.
For this reason, the IT team does as much of the work for the user as possible. Product keys are entered automatically, End User License Agreements are accepted, and the installation user interface is reduced to only a progress bar and completion message, all to make the process less taxing on the end users.
Figure 1 Custom Maintenance Wizard
To build these customized installations, the Microsoft IT team uses the publicly available customization tools found at the Microsoft Office Web site at Office 2003 Editions Resource Kit
. The Custom Maintenance Wizard, which allows many aspects of the application to be tuned to any environment, was the primary customization tool used for the Office 2003 deployment. Figure 1
shows the intuitive interface of the Custom Maintenance Wizard.
After the installation was customized and tested, Microsoft IT deployed the Office 2003 package using Microsoft Systems Management Server (SMS) 2003. SMS provides a complete solution that includes replication of the installation package, delivery to the client desktop, and reporting to confirm the success of the deployment. SMS helped make the installation as seamless as possible. SMS can often install and update applications without the employee even being present at their computer. Users really appreciate that!
The Microsoft IT team routinely takes a phased approach to software deployment, focusing at first on a small group of clients so that the IT team can refine the deployment process and gain key feedback regarding support questions, application issues, and installation experience. The phased approach results in a more efficient and streamlined deployment to the larger group later on as the most common client questions and problems have already been addressed in the smaller trial groups.
Effective support is especially challenging during a dog food period because the app support documentation is often not complete. Phased deployment is important as it gives the support team time to build fixes and workarounds for the top support call issues before the app is widely deployed.
No deployment is complete without the ability to report on its success. Reporting speed is critical for Microsoft IT, as a given beta deployment may have a goal that must be met in a short time. For example, the Microsoft Office 2003 Beta 2 deployment goal was to reach 30,000 desktops in eight weeks, and effective reporting helped to meet and exceed this objective. The application was deployed to 7,000 more desktops than targeted in those weeks.
SMS 2003 provides reporting that allowed the Microsoft IT team to quickly determine which computers received the installation package, which ones ran it successfully, and which were not successful.
Steve Reay is a Program Manager within the Microsoft IT organization and has worked in a variety of support and deployment roles within IT at Microsoft since he joined 10 years ago.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited