Last week, I spent three days learning about the Microsoft Solution Accelerator for Business Desktop Deployment (BDD).

According to Microsoft:

“The Microsoft Solution Accelerator for Business Desktop Deployment delivers end-to-end guidance for efficient planning, building, testing, and deploying Microsoft Windows XP Professional, Windows XP Tablet PC Edition, and Office Professional 2003 Editions. It helps IT professionals realize a quick return on investment while also setting new standards for reliability, performance, security, and ease of use.”

Basically, BDD is a framework for successful Windows XP desktop deployment. A collection of guidance, sample templates, tools and scripts, wrapped around a Windows XP and Office 2003 installation source, BDD version 1 has been around for some time now, and version 2 has two variant editions:

• BDD Standard Edition is intended for medium sized organisations, enabling a highly automated (light touch) desktop deployment, requiring a LAN infrastructure with at least one server and sufficient space to store all of the working files and images (although Microsoft do recommend the use of Active Directory and Remote Installation Services) as well as either PowerQuest DeployCenter 5.5 or Symantec Ghost 8.0 and Windows PE 2004.
• BDD Enterprise Edition is intended for large enterprises, utilising Active Directory, Remote Installation Services, Microsoft SQL Server 2000 and Microsoft System Management Server (SMS) 2003 (with the Operating System Deployment Feature Pack) to deliver a zero touch deployment. To use all of the features in BDD enterprise Edition, including provisioning, Microsoft BizTalk Server 2004, Microsoft Exchange Server 2003 and Microsoft Operations Manager (MOM) Server 2005 are also required. In short, BDD Enterprise can use just about every element of the Windows Server System.

Both editions additionally rely on the Microsoft User State Migration Toolkit (USMT) 2.6, Microsoft Application Compatibility Toolkit 3.0, Microsoft Office Access 2003 Conversion Toolkit, Windows XP Professional with Service Pack 2, and Office Professional 2003 Edition Service Pack 1.

The crossover between the two BDD variants (in terms of the cost of development vs. the number of desktops) is somewhere between 500 and 2000 desktops and the BDD framework scales up to a deployment of many thousands of PCs.

I’ve been working with unattended operating system builds for many years, and the consultancy that I work for (Conchango) already has a highly automated standard operating environment (SOE) process, built around the same technologies. BDD is a formalisation of existing best practices, packaged in a manner that allows an organisation to:

• Create a software and hardware inventory to assist in deployment planning.
• Test applications for compatibility with Windows XP Professional and mitigate the compatibility issues discovered during the process.
• Set up an initial lab environment with deployment and imaging servers.
• Customise and package core and supplemental applications.
• Automate desktop image creation and deployment.
• Ensure that the desktop is hardened to improve security within the environment.
• Manage processes and technologies to produce a comprehensive and integrated deployment.

Even with BDD in place, rolling out a new standard desktop to hundreds or even thousands of computers, possibly spread across the globe, is not a trivial task and is likely to include a large team of people. In fact BDD is based around the idea of feature teams, each of which is responsible for one area of the solution.

As can be seen from the diagram above (which relates to BDD Enterprise Edition – BDD Standard Edition does not include provisioning), at the heart of BDD is the business case, and project management. Surrounding this function are the feature teams:

• Application compatibility remediation – discovering which applications are in use, which are to be migrated, and investigating application compatibility.
• Infrastructure compatibility remediation – analysing the current state of the infrastructure, to determine whether it is suitable to support the implementation of the new business desktop, then implementing new infrastructure as required. For example, does the network have sufficient bandwidth? Where are the bottlenecks? Are all of the PCs of a suitable specification to run Windows XP? How many will need to be replaced? etc.
• Computer imaging system – which technologies will be used for deployment? Will this be zero touch or light touch? How many images will there be and what is the basis for creating a separate image? (e.g. functional images, or hardware variations). Functional images can be difficult to manage because of the number of images to keep up to date and in general the number of images should be minimised (in my last company we had just two, hardware-based, images for the various PC models across Europe). Where there are specific hardware concerns, it may be more cost-effective to replace some PCs than to develop an separate image for a particular computer type.
• Core and supplemental application packaging – packaging those applications which will be included within the image (generally just Microsoft Office, Adobe Reader and some system software), and those supplemental applications that need to be deployed on a per user or per group basis.
• User state migration – to be avoided wherever possible, user state migration is problematic and time consuming – therefore expensive; however, it is very rare that a deployment will not require the transfer of files and settings.
• Securing the desktop – security should be included in every area of the design, but it is still necessary for someone to take control of the overall security for the desktop.
• Deployment process – the process of actually getting the software into PCs throughout the organisation.
• Preparing for operations – involving operations staff in the project, to ensure that the new platform is taken on board and managed well by the people who are often under-appreciated and over-utilised, and whose buy-in can ensure the success or failure of the entire project.
• Upgrading Office – ensuring that Microsoft Office functionality is unaffected by the upgrade, paying attention to file versions, macros, file locations, etc.
• Provisioning – allowing staff to help themselves – provisioning may be as simple as providing a website for users to reset their password after answering a few security questions, or it may be a process to request a new application, with full workflow throughout the approval process right up to the automatic deployment of the application to the desktop.

Of course some roles may be combined, depending on the size of the organisation. In fact the whole point about BDD is that it is designed to scale.

Fundamental to the whole process is the Microsoft Solutions Framework (MSF). MSF provides people and process guidance to help teams and organisations become more successful in delivering business-driven technology solutions to their customers. It is a deliberate and disciplined approach to technology projects based on a defined set of principles, models, disciplines, concepts, guidelines, and proven practices from Microsoft.

At the heart of MSF is the process model, which includes a five stage lifecycle for the solution. Based on phases and milestones, at each stage there are clear requirements in order to justify the ongoing cost of development. For example, there is no value in spending time, effort and money on planning the solution until the vision and scope for the project has been agreed.

The vision may be a single global desktop but the scope may impose restraints on this. In my opinion, envisioning is one of the most important areas of any desktop deployment and is also one of the most overlooked, generally because a customer can’t see the value in up-front planning and needs to be seen to deliver something to the business as soon as possible.

As the solution is deployed (and during preparation for operations), the Microsoft Operations Framework (MOF) is employed to provide operational guidance for the management of the solution. MOF is based on the UK government IT Infrastructure Library (ITIL) – the most widely accepted approach to IT Service Management in the world – and is fundamentally split into a set of models: a process model, a team model and a risk management discipline, as well as a set of service management functions.

The MOF team model organises the IT operations group into several role clusters – individuals or groups who perform related activities to accomplish a particular component of an IT service, based on industry best practices for structuring operations teams. MOF then provides additional guidance that applies collectively and individually to the role clusters.

The MOF process model assumes that the main responsibility of the IT operations groupÂ’ is managing change in the IT environment. The most effective way to deal with change throughout the lifespan of a service is to group related changes together into a package called a release, so that the changes can be planned and managed as a unit. The MOF process model describes a life cycle that can be applied to any release and the processes and activities that make up each part of that life cycle and groups similar service management functions (SMFs) into each of four quadrants relating to a specific mission of service.

The MOF risk management discipline applies proven risk management techniques to the daily problems faced by operations staff. Many models, frameworks, and processes exist for managing risks and all share similarities in how they identify and manage risk. MOF applies key principles, along with customised terminology, structured and repeatable risk analysis and evaluation process, integrated within a larger operations framework.

All of the above is just an overview – I recommend that anyone looking to manage a major desktop deployment considers using the BDD framework, and that any organisation running on a primarily Microsoft desktop and server platform takes a serious look at MSF and MOF.