Office 2007 Customisation and Deployment using BDD 2007

Posted on By Mark Wilson

Over the years, the various methods available for customising and deploying Microsoft Office have advanced considerably and so here are a few notes on customising and deploying the 2007 Microsoft Office System using the Microsoft Solution Accelerator for Business Desktop Deployment (BDD) 2007:

  • The first step is to create a network distribution point.  This is easily achieved using the BDD 2007 workbench (Distribution Share, Applications, New), with the additional advantage of integrating the Office 2007 files into the BDD distribution folder structure (e.g. D:\Distribution\Applications\Office2007).
  • The BDD workbench will also enable the application (by default) and allow the entry of additional information on the General tab.  The Dependencies tab can be used to control the order of application deployment within the BDD logic.  There is also a tab for Office Products which can be used to configure the deployment of Microsoft Office.
  • To save disk space, additional Office System components may be added to an existing distribution point.  Multiple languages may be integrated in the same manner – i.e. by adding the files to the application within BDD Workbench.
  • Office 2007 is always installed via setup.exe rather than with individual Windows Installer (.MSI) packages.
  • The Office Customization Tool (OCT) is used to create or edit Windows Installed Patch (.MSP) files to customise Office installations:
    • It may be launched from the command line using setup.exe /admin or within the BDD Workbench using the Office Customization Tool button in the application properties.  The OCT replaces the Custom Installation Wizard and Custom Maintenance Wizard tools in previous Office versions.
    • The OCT language interface will match the regional setting for the application (rather than the operating system language).
    • OCT allows the specification of multiple network sources (in case the primary is not available). By default, all necessary files are copied locally first and setup is launched from this cache – the local installation source (LIS).  If the installation is modified later then setup with use the LIS before attempting to locate network sources.
    • By default, .MSP files are saved in the Updates folder on the application distribution point.  Setup scans this location when it runs and will retrieve application settings from .MSP files.  If multiple .MSP files exist then the first one (in alphabetical order) will be used.
    • When editing .MSP files with the OCT, those areas that have changed from the defaults are highlighted in bold.
  • Microsoft Office updates and service packs can be copied to the Updates folder on the application distribution point for automatic application during installation.
  • Settings may be specified within a config.xml file (via the application properties in BDD Workbench) or using a .MSP file:
    • Sensitive values such as product keys should be stored within an .MSP file rather than as clear text in config.xml.
    • The command line to use a config.xml file is setup.exe /config applicationsubfolder\config.xml.
    • Settings in config.xml will take precedence over duplicate settings in a .MSP file.
  • Office setup writes a log file to %temp% on the destination machine.  The filename for this log will be prefixed with setupexe.
  • Microsoft Systems Management Server (SMS) 2003 can also be used to deploy Microsoft Office 2007:
    1. Create a package using the source files from the BDD distribution point.
    2. Create a program for Office 2007:
      • Within the package, create a new program and edit the properties to include the program name (e.g. Office 2007) and the appropriate command line (setup.exe /config applicationsubfolder\config.xml).
      • If the program is hidden (on the General tab) and the installation requires user input then it will never complete.  Similarly if the option to allow users to interact with this program option (on the Requirements tab) is not selected then installation will fail, unless the package has been created for silent installation.
      • If users have local administrator rights on their workstations then he program may be configured to run with user rights; however this is generally not desirable and a run mode of run with administrative rights should normally be selected.
      • The Windows Installer tab can be used to define a .MSI file that is used when clients with the package installed make updates to the Office installation (e.g. install on first use or repair).
    3. Create a distribution point (within SMS – not to be confused with the BDD distribution point) and copy the package to the distribution point.
    4. Check the distribution process using the SMS report for the distribution status of a specific package.
    5. Define a collection to receive the package based on membership rules and specific resource attributes.
    6. Create an advertisement for the package/program and schedule accordingly.
    7. If clients are taking a long time to receive an advertisement, check the schedule and also try initiating both machine and user policy actions within the systems management applet in control panel (installed by the SMS client).

BDD 2007 overview

Posted on By Mark Wilson

It’s been almost three years since I wrote a post about the Microsoft Solution Accelerator for Business Desktop Deployment (BDD) and since then it’s been updated twice – first with BDD v2.5 and now with BDD 2007 (the latest version of which is now known simply as Microsoft Deployment).

According to Microsoft:

The Solution Accelerator for Business Desktop Deployment (BDD) is best-practice guidance for desktop deployment. BDD is targeted at companies that want to reduce deployment time, effort, and cost by increasing the level of automation. It allows administrators to deploy desktops with Zero Touch and Lite Touch interaction at the target PCs. This solution also helps organizations move to a managed environment with standardized desktop images.

Effectively, BDD is a framework that brings together a variety of deployment tools with business logic in order to implement best practices.  In it’s simplest form, known as Lite Touch Installation (LTI), BDD allows administrators to create/capture operating system images, customise these and deploy them to other workstations.  This requires very little infrastructure and as such is suitable for small and mid-size business; however there is also a Zero Touch Installation (ZTI) option that integrates with Microsoft Systems Management Server (SMS) 2003 or System Center Configuration Manager (SCCM) 2007 for enterprises that have the required infrastructure in place.

Supported on Windows X, Server 2003, Server 2003 R2 and Vista, BDD can be used to deploy Windows clients, together with applications (e.g. Office 2007) and customisations.  Available in both x86 and x64 editions (with both versions supporting installation of clients on either architecture), BDD 2007 is finally looking like a product, rather than a collection of tools glued together with scripts and HTML applications.  There’s still a few strange interfaces, but the hub of BDD 2007 is the BDD Workbench – an MMC 3.0 snap-in.  Other requirements for BDD are Windows Script Host (WSH) 5.6 and it also makes use various other tools that may be downloaded from within the BDD Workbench:

  • Windows Automated Installation Kit (WAIK).
  • Application Compatibility Toolkit (ACT) 5.0.
  • User State Migration Tool (USMT) 3.0.
  • MSXML 6.0.
  • Key Management Server (KMS) (and associated management pack).
  • Volume Activation Management Tool.
  • Office Migration Planning Manager.
  • Windows Vista Hardware Assessment

Screenshot of the BDD 2007 Workbench

After installation of BDD (supplied as Windows Installer .MSI file, together with a quick start guide and deployment tools overview – both of which are worth reading), the primary folders are held in %programfiles%\BDD 2007\ and consist of:

  • \BIN – BDD Workbench console and supporting files.
  • \Documentation – documentation.
  • \Downloads – storage for components downloaded by BDD 2007.
  • \ManagementPack – BDD management pack files.
  • \Samples – sample task sequence scripts.
  • \Scripts – scripts used by the BDD Workbench.
  • \Templates – master template files used for defaults in unattended Windows installations.
  • \Temporary – temporary storage space.

Other tools (e.g. the WAIK and ACT) add their own folders to the BDD file structure.

The installation also creates a \Distribution folder on the drive with the largest amount of free space (or at a custom location supplied during installation).  This contains the following subfolders and except \Scripts and \Tools are empty at installation time:

  • \$OEM$ – files and folders to be copied to the destination computer during Windows Vista setup.
  • \Applications – any application files that are installed as part of deployment.
  • \Captures – images captured using ImageX.
  • \Control – storage of files used by the BDD execution engine.
  • \Operating Systems – any operating system files that are installed as part of deployment.
  • \Out-of-Box Drivers – driver files not delivered by default with Windows Vista.
  • \Packages – Windows Vista-compatible packages for installation with the operating system (security updates, language packs, service packs, etc.) in cabinet file (.CAB) or Windows Update (.MSU) format.
  • \Scripts – scripts used by the Lite Touch deployment engine.
  • \Tools – tools used by the deployment engine and the location of USMT source files.

Configuring BDD to deploy an operating system and applications consists of:

  1. Install BDD.
  2. Update/install additional components (e.g. WAIK, USMT) from within the BDD Workbench.
  3. Add one or more operating systems to the distribution share from within the BDD Workbench.  This could be a full set of source files, a custom image (.WIM) file (i.e. an image captured from a reference computer) or an image from a Windows Deployment Services server.  This operation can either copy the installation or move it from another location.
  4. Add any applications to the master image from within the BDD Workbench – applications can be moved/copied to the distribution share or existing locations may be referenced via a UNC path.  Specify any application settings (e.g. command line switches for a silent installation, or a working directory).
  5. Add any additional device drivers that are required within the master image, using the BDD Workbench.  The BDD tools will look for .INF files in the process of scans all subfolders in the specified directory.
  6. Add any additional packages, such as operating system updates and language packs, using the BDD Workbench.

Once the master image is established, it’s necessary to define one or more builds.  Each build has an identifier (which must not contain spaces) as well as a name and a number of associated comments.  The build defines an operating system, along with key details such as product keys and the Administrator password and, once created, the build properties can be amended to customise settings, optionally launching the Windows System Image Manager to edit the unattend.xml file that controls the Vista installation.

Finally, the deployment point must be configured:

  • Builds may be deployed using the local BDD distribution point (shared as \\%computername%\Distribution$), a separate share on the local or a remote computer, as a .ISO image for use on removable media (DVD, USB flash drive, etc.), or via SMS 2003/SCCM 2007 (which facilitates ZTI installations).  Note that SMS 2003 requires the SMS 2003 Operating System Deployment (OSD) Feature Pack whereas SCCM has OSD functionality built into the product.
  • Various options exist to control the user experience during deployment (e.g. the selection of other applications during installation).
  • It may be necessary to create/update the Windows pre-installation environment (WinPE) images that are used to connect to a deployment point.  The resulting .WIM files (found on the distribution point in a \Boot folder) can be added to a Windows Deployment Services (WDS) server as a bootable PXE image for bare-metal deployment whereas the .ISO file equivalents can be mounted in a virtual machine or booted from removable media.  During the creation of these images, tasks are logged in %temp%\DeployUpdates_x86.log.  Generic images are generic_x86.wim and generic_x86.iso.

At this stage, BDD is ready to deploy builds to workstations; however there are some additional capabilities:

  • It is possible to define a SQL Server database to store details of deployed computers.
  • Images may be captured using BDD deployment points such that there is no requirement to separately run SysPrep or ImageX.  The Windows Deployment Wizard (invoked from the Windows PE images created earlier) automatically runs both of these utilities in order to prepare and capture an image.

Now is the time to start planning for Windows Server 2008

Posted on By Mark Wilson

I recently attended a presentation at which the CA (formerly Computer Associates) Directory of Strategic Alliances, Dan Woolley, spoke about how CA is supporting Windows Server 2008.

CA is not a company that I associate with bringing products to market quickly and I understand why companies are often reticent to invest in research and development in order to support new operating system releases.  Hardware and software vendors want to see customer demand before they invest – just look at the debacle with Windows Vista driver support! There are those that blame Microsoft for a lack of device support in Windows Vista but they worked with vendors for years (literally) before product launch and even now, a full year later, many items of hardware and software have issues because they have not been updated. That’s not Microsoft’s fault but a lack or foresight from others.

It’s true that some minor releases are probably not worth the effort, but supporting a new version of Windows, or a new version of a major server product like Exchange Server or SQL Server should be a no-brainer.  Shouldn’t it?

It’s the same with 64-bit driver support (although Microsoft is partly to blame there, as their own 64-bit products seem to lag behind the 32-bit counterparts – hopefully that will change with the "Longhorn" wave of products.

Dan Woolley’s presentation outlined the way that CA views new product releases and, whilst his view was that they are ready when the customers are ready, from my perspective it felt like a company justifying why they wait to provide new product versions.

CIOs expect infrastructure to be extensible, stable, flexible and predictable

He made the point that CIOs expect infrastructure to be extensible, stable, flexible and predictable (they abhor change as the impact of change on thousands of customers, users, and servers is difficult to understand) and how they:

  • Deliver services to facilitate corporate business (so require a stable infrastructure platform).
  • Work to maximise IT investments.

That may be true but Woolley didn’t consider the cost of running on legacy systems.  Last year I was working with a major accounting firm that was desperate to move away from NT because the extended support costs were too high (let alone the security risks of running on an operating system for which no new patches are being developed).  As recently as 2005, I worked with a major retailer whose back office systems in around 2000 outlets are running on Windows NT 3.51 and whose point of sale system depends on FoxPro for MS-DOS!  Their view is that it works and that wholesale replacement of the infrastructure is expensive.  The problem was that they were struggling to obtain spare parts for legacy hardware and modern hardware didn’t support the old software.  They were literally running on borrowed time (and still are, to the best of my knowledge).

CA’s view is that, when it comes to product deployment, there are five types of organisation:

  • Innovators – investigating new products in the period before it is launched  – e.g. Microsoft’s Technology Adoption Programme (TAP) customers.
  • Early adopters – who work with new products from the moment they are launched up to around about the 9 month point.
  • General adoption – product deployment between 9 months and 4 years.
  • Late adopters – deploying products towards the end of their mainstream support (these organisations are probably running Windows 2000 and are only now looking at a move to Windows Server 2003).
  • Laggards – the type of customers that I described earlier.

Looking at the majority of that group, there are a number of deployment themes:

  • Inquiring (pre-launch).
  • Interest and testing (post-launch).
  • Budgeting (~4 months after launch)
  • Prototyping and plots (~1 year after launch)
  • Deployment (~18 months after launch)
  • Replacement/upgrade programmes (~5 years after launch – co-incidentally at the end of Microsoft’s mainstream support phase)
  • Migration (7+ years after launch – onto another platform altogether).

What is interesting though is that there are also two distinct curves for product deployment:

  • Sold licenses.
  • Deployed enterprise licenses.

This is probably because of the way that project financing works.  I know from bitter experience that it’s often better to buy what I need up front and deploy later because if I wait until the moment that I need some more licenses, the budget will not be forthcoming.  It seems that I’m not alone in this.

CA view their primary market as the customers on a general/late adoption timescale.  That sounds to me like a company trying to justify why it’s products are always late to market.  Windows Server 2008 will launch early next year and serious partners need to be there with products to work with the new operating system right from the launch – innovators expect a few problems along the way but when I’m trying to convince customers to be early adopters I don’t want to be held back by non-existent management agents, backup clients, etc.

Windows Server 2008 is built on shared code with Windows Vista so the early hiccups and device adoption should already have been ironed out

CA’s view supports the "wait for service pack 1" mentality but then Woolley closed his presentation by stating that CA builds on Microsoft platforms because they consider them to be extensible, stable, flexible and predictable and because they will allow the delivery of service to facilitate corporate business imperatives and maximise IT investments.  He stated that CA has been working with Microsoft on Windows Server 2008 architecture reviews, design previews, TAPs and logo testing but if they are truly supportive of Microsoft’s new server operating system, then why do they consider their primary market as not being ready for another year?

Once upon a time hardware led software but in today’s environment business is supported by software and the hardware is just something on which to run the software.  In today’s environment we have to consider a services model.  Microsoft’s move towards regular monthly patches supports this (they are certainly less focused on service packs with the last service pack for Windows XP – the client operating system with the largest installed base – having shipped over three years ago).

Windows Server 2008 is built on shared code with Windows Vista so the early hiccups and device adoption should already have been ironed out.  That means that Windows Server 2008 should not be viewed as "too new", "too disruptive" (it will actually ship at service pack 1 level) and, all being well, the adoption curve may be quicker than some think.