Cloning my Mac’s hard drive to gain some extra space

My MacBook (bought in 2008, unfortunately just before the unibody MacBook Pros were introduced) has always been running with upgraded memory and storage but it was starting to creak.  Performance is okay (it’s not earth-shattering but all I do on this machine is digital photography-related workflow) and it won’t take any more RAM than the 4GB I have installed but I was constantly battling against a full hard disk.

After a recent holiday when I was unable to archive the day’s shots and had to start filling my “spare” (read old and slow) memory cards to avoid deleting unarchived images, I decided to upgrade the disk. I did briefly consider switching to a solid state solution (until I saw the price – enough to buy a new computer), then I looked at a hybrid device, before I realised that I could swap out the 320GB Western Digital SATA HDD for a 750GB model from Seagate. The disk only cost me around £73 but next day shipping bumped it up a bit further (from Misco – other retailers were offering better pricing but had no stock). Even so, it was a worthwhile upgrade because it means all of my pictures are stored on a single disk again, rather than spread all over various media.

Of course, no image really exists until it’s in at least two places (so I do have multiple backups) but the key point is that, when I’m travelling, Lightroom can see all of my images.

I didn’t want to go through the process of reinstalling Mac OS X, Lightroom, Photoshop CS4, etc. so I decided to clone my installation between the two disks.  After giving up on a rather Heath Robinson USB to IDE/SATA cable solution that I have, I dropped another £24.99 on a docking station for SATA disk drives (an emergency purchase from PC World).

I’m used to cloning disks in Windows, using a variety of approaches with both free OS deployment tools from Microsoft and third party applications. As it happens, cloning disks in OS X is pretty straightforward too; indeed it’s how I do my backups, using a utility called Carbon Copy Cloner (some people prefer Super Duper). Using this approach I: created a new partition on the new disk (in Disk Utility), then cloned the contents of my old hard disk to the new partition (with Carbon Copy Cloner); then test boot with both drives in place (holding down the Alt/Option key to select the boot device); before finally swapping the disks over, once I knew that the copy had been successful.  Because it’s a file level copy, it took some time (just under six hours) but I have no issues with partition layouts – the software simply recreated the original file system on the partition that I specified on the new disk.  There’s more details of the cloning process in a blog post from Low End Mac but it certainly saved me a lot of time compared with a complete system rebuild.

Now all I need to do is sort out those images…

Hardware specific application targeting with MDT 2010

Guest Post
[Editor’s note: this post was originally published on Garry Martin’s blog on 28 October 2009. As Garry’s closing down his own site but the content is still valid, he asked me if I’d like to post it here and I gratefully accepted!]

I’m running a Proof of Concept (PoC) at work at the moment which is making use of Microsoft Deployment Toolkit (MDT) 2010. Whilst most of the drivers we need can be managed by using the Out-of-Box Drivers Import function, some are delivered by the OEM as .EXE or .MSI packages. Whilst we could use multiple Task Sequences to manage these, or even select the applications individually at build time, our preference was to use some sort of hardware specific targeting.


First of all, we needed to uniquely identify the hardware, and for this purpose we used the Plug and Play (PnP) Device ID, or hardware ID as it is sometimes called.

To determine the hardware IDs for a device by using Device Manager:

  1. Install the device on a test computer
  2. Open DeviceManager
  3. Find your device in the list
  4. Right-click the entry for your device, and then click Properties
  5. In the Device Properties dialog box, click the Details tab
  6. In the Property list, click Hardware Ids
  7. Under Value, make a note of the characters displayed. They are arranged with the most specific at the top to the most general at the bottom. You can select one or more items in the list, and then press CTRL+C to copy them to the clipboard.

In our case, the Sierra Wireless MC8755 Device gave us USB\VID_1199&PID_6802&REV_0001 as the most specific value and USB\VID_1199&PID_6802 as the least specific, so we made a note of these before continuing.

Next, we downloaded the Sierra Wireless MC87xx 3G Watcher .MSI package from our notebook OEM support site. Sierra Wireless have instructions for performing a silent install of the 3G Watcher package, so we used those to understand the installation command we would need to use.

So, we had a unique ID for targeting, the installation package, and the installation command line we would need to use. Now we needed to configure MDT to deploy it. First, we create a New Application.

  1. In the MDT 2010 Deployment Workbench console tree, right-click Applications, and click New Application
  2. On the Application Type page, click Next to install an application and copy its source files to the deployment share
  3. On the Details page, type the application’s name in the Application Name box, and click Next
  4. On the Source page, type the path or browse to the folder containing the application’s source files, and click Next
  5. On the Destination page, click Next to use the default name for the application in the deployment share
  6. On the Command Details page, type the command you want to use to install the application, and click Next. We used the following
    msiexec.exe /i 3GWatcher.msi /qn
  7. On the Summary page, review the application’s details, and click Next
  8. On the Confirmation page, click Finish to close the New Application Wizard.

Next we modify the Task Sequence and create our query.

  1. In the MDT 2010 Deployment Workbench console tree, click Task Sequences
  2. In the details pane, right-click the name of the Task Sequence you want to add the Application to, and then click Properties
  3. In the Task Sequence Properties dialog box, click the Task Sequence tab
  4. Expand State Restore and click on Install Applications
  5. Click the Add button, and select General, then Install Application
  6. On the Properties tab for Install Application, type the application’s name in the Name box, and click the Options tab
  7. On the Options tab, click the Add button and select If statement
  8. On the Source page, type the path or browse to the folder containing the application’s source files, and click Next
  9. In the If Statement Properties dialog box, ensure All Conditions is selected and click OK
  10. On the Options tab, click the Add button and select Query WMI

This is where we’ll now use a WMI query that will provide our Hardware Specific Application Targeting. You’ll need to modify this for your particular hardware, but we previously discovered that our least specific Device ID value was USB\VID_1199&PID_6802 so we will use this to help form our query.

  1. In the Task Sequence WMI Condition dialog box, ensure the WMI namespace is root\cimv2 and type the following in the WQI Query text box, clicking OK when finished:
    SELECT * FROM Win32_PNPEntity WHERE DeviceID LIKE '%VID_1199&PID_6802%'
  2. Click OK to exit the Task Sequences dialog box

And that’s it. When you deploy a computer using the modified Task Sequence, the WMI query will run and, if matched, install the application. If a match can’t be found, the application won’t be installed. Hardware Specific Application Targeting in a nutshell.

Installing Windows from a network server without Windows Deployment Services

I’d like to start this post with a statement:

Windows Deployment Services (WDS) is a useful role in Windows Server 2008 R2.  It’s free (to licensed Windows users), supports multitasking, and is a perfectly good method of pushing Windows images to clients…

Unfortunately that statement has a caveat:

… but it needs to be installed on an Active Directory-member computer.

For some, that’s a non-starter.  And sometimes, you just want a quick and dirty solution.

I have a small dedicated server at home to run Active Directory along with basic network services (DNS, DHCP, etc.) for my home IT.  I also run Philippe Jounin’s excellent TFTP Daemon (service edition) on it in order to support image loads on my Cisco 7940 IP Phone.

In order to rebuild the Hyper-V server that I use for infrastructure test and development, I wanted to boot across the network and install Windows Server 2008 R2 – and a few days ago I found Mark Kubacki’s post about TFTPd32 and DHCP Server – Windows Deployment Services without WDS. Perfect!  No need to install another role on my little Atom-powered server – particularly as, once this server is built, I’ll probably install WDS on it  to deploy images to my various test virtual machines!

So, this is the process – with thanks to Mark Kubacki, and to Ryan T Adams (who wrote about installing Vista without a CD Drive using TFTP – for instance, installing Windows on a netbook) who were gracious enough to blog about their experiences and give me something to build upon:

  1. Download tftpboot.exe from Ryan T Adams’ site and run it to extract the contents to a suitable hard drive location (i.e. the TFTP root folder).  Unfortunately, you probably won’t need most of this 154MB download (more on that in a moment) but it will get you started.
  2. Start tftpd32.exe (or copy the files to your TFTP root, if you are already running a TFTP service, as I was) and add tftpd32.exe (or tftpd32_svc.exe) as a Windows Firewall exception (you could just disable the firewall but I don’t recommend that approach).
  3. Either set TFTPD32 to act as a DHCP server and specify the boot file options (as Ryan describes), or configure DHCP options 066 and 067 (boot server host name and boot file name) on another DHCP server (Mark shows how to do this for the Windows DHCP Server role) using the IP address of the TFTP server and the boot file name of boot\
  4. Make sure that the TFTP Server is set to include PXE capability in the advanced TFTP options and that it’s DHCP Server capability is turned off if you are using another DHCP server.
  5. Restart the TFTP Server (or service) to pick up the configuration changes.
  6. Boot a computer (or virtual machine) from its network card, press F12 when prompted and wait for Windows PE to load, then map a drive to another machine on the network which is sharing the Windows media (I use Slysoft Virtual Clone Drive to mount an operating system ISO file and I’ve shared the virtual drive).
  7. Switch to the newly mapped drive and type setup.exe to run Windows Setup.

Unfortunately, the version of the Windows Preinstallation Environment (Windows PE) that Ryan has supplied in tftpboot.exe is a 32-bit version (of Windows PE 2.0, I think).  When I tried to use this to install Windows Server 2008 R2 (which is 64-bit only), I was greeted with the following message:

This version of Z:\setup.exe is not compatible with the version of Windows you’re running.  Check your computer’s system information to see whether you need a x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher.

I needed a 64-bit version of Windows PE.  No problem.  That’s included in the Windows Automated Installation Kit (WAIK), so I overwrote Ryan’s winpe.wim with the one from %programfiles%\Windows AIK\Tools\PETools\amd64, and restarted the computer I wanted to build.  This time Windows Setup ran with no issues and Windows Server was installed successfully.

Even though I used the TFTPD32, this method could be used to install Windows from just about any TFTP server (it could even be running on totally different operating system, I guess), or even to load another WIM file (i.e. not Windows PE) from a network boot. I’m sure if I had more time I could come up with all sorts of scenarios (boot Windows directly from the network?) but, for now, I’ll stick to using this method as a WDS replacement.

Windows 7 beta deployment tools

Those who are checking out the Windows 7 beta with a view towards automated deployments may be interested to note that a beta of the Windows Automated Installation Kit has been released for Windows 7 along with an open beta of the Microsoft Deployment Toolkit 2010.

Giving or receiving a PC as a Christmas present? Take an image of the drive first

Some quick advice for those of you about to open up new PCs bought for Christmas (for that matter, the advice is equally applicable whatever the occasion)… avoid the temptation to dive straight in and have a play. Instead, take an image of the hard drive as it arrived from the factory – yes, you can always use the manufacturer’s instructions to return the machine to a restored state but this can take a long time (as I found a few weeks back when I succumbed to temptation and had a play with my Lenovo Idea Pad S10e before imaging it!).

As I write this, I’m setting up a new Dell notebook for someone (an Inspiron 1525) and the first key I pressed (after the power button) was F2 to go into the BIOS. Here I changed a couple of settings (boot order and numlock key state), then booted again with F12 for the boot menu to use my device of choice (floppy disk drive, USB drive, or PXE network boot) to boot to my image capture software of choice (Symantec Ghost, Windows Deployment Service, you name your poison) and take an image of the entire drive (not a partition).

Following this, I can can configure the device as intended (remove the crapware, install some AV software, install an Office suite, etc.) and then take another image when I’m done.

Of course, for corporate deployments it’s normal to blow away the manufacturer’s image and install something more appropriate to the organisation’s requirements but, for home and small business users, it’s perfectly acceptable to use the factory-supplied build and this might just save you some time if you ever need to return to square one.

Using packet level drivers for MS-DOS network connectivity

One of the reasons to use Windows PE for operating system deployment is that it’s built on a modern version of Windows so, at least in theory, driver support is less of an issue than it would be using MS-DOS boot disks.

Even so, there are still times when a good old MS-DOS boot disk comes in handy and networking is a particular pain point – NDIS drivers are a pain to configure so packet-level drivers are often useful for operating system deployment tasks (but not optimised for anything more substantial). Available for many of the more common Ethernet cards, they are generally 16-bit utilities for MS-DOS and so will not work in 32-bit or 64-bit operating systems.

As this is not exactly cutting edge technology, many of the useful sites are starting to drop off the ‘net (but a surprising number remain) – here’s a few links I found that might come in handy:

A few things I found whilst drive imaging with Symantec Ghost

I need to rebuild one of my PCs before lending it to someone for a few days but before I do that I want to take an image of it. If I had the Microsoft Deployment Toolkit 2008 set up at home then that would be reasonably straightforward but I don’t, and the old drive imaging technologies will be fine for this – at least that’s what I thought until I spent half the night and a good chunk of this morning fighting with Symantec Ghost… So, here’s a few of the things that I’ve (re-)discovered about Ghost in the last few hours.

  • Using Ghost in peer-to-peer mode does require the slave and the master machines to be running the same version of Ghost – it will present a version mismatch if you try and run different versions.
  • Ghost 6.x Enterprise has a multicast option but I couldn’t get it to work (it was always greyed out for me). Symantec’s knowledge base suggests that this may be down to TCP/IP issues and I’m pretty sure that packet-level network drivers are required with the MS-DOS client (the Windows server can use the normal Windows network settings) but, even with a suitable packet driver loaded, I gave up after a few hours without success.
  • GhostCast Server uses (UDP) port 6666 for communications.
  • GhostCast Server 8.x will create a Windows Firewall exception for itself but the exception still needs to be enabled manually.
  • On a multi-homed server, there seems to be no way to select the NIC on which the GhostCast Server presents a session.
  • Multicasting also seems to need the client and server versions to match one another. 16-bit Ghost 7.x should work with an 8.x server but it wasn’t working out for me with 7.5 and 8.2 (32-bit 8.x clients were connecting to the server fine, so I knew it was working, but I didn’t want to image those machines – and I didn’t have a copy of the 7.x server).
  • Compression adds a lot of time to the imaging process.

Eventually, I got everything working with a 16-bit copy of Ghost 8.2 running on MS-DOS (to be completely accurate, it was a Windows ME startup disk created from Windows XP) communicating with a GhostCast Server 8.2 running on Windows Server 2008.

And for anyone who is wondering why I was messing about with 16-bit executables and MS-DOS (in these days of Windows PE), Toffa suggested that I should try a Windows PE disk with the 32-bit ghost client. Although that would have let me access USB-attached external storage, I didn’t have enough space on a USB drive and was storing my image on a server. Windows XP (and so PE) doesn’t natively recognise the network card on the machine I was imaging, so that would have required me to extend the Windows PE image and provide additional driver support. Somehow, using a universal network boot disk seemed like the easy option.

Windows Vista and Office 2007 deployment brain dump

This week I’m working on a Desktop Deployment Planning Services (DDPS) engagement with a customer. It’s been a while since I last looked at deployment (basically I haven’t done anything since I passed the Windows Vista and Office 2007 deployment exam) so I’m revising my notes in preparation for a workshop tomorrow.

As a supplement to my previous post on a BDD 2007 overview and Office 2007 customisation and deployment using BDD 2007, this is a rollup of just about everything I could lay my hands on about Vista and Office deployment. It’s not particularly well structured – let’s just call it a “brain dump”. If anyone has anything extra to add, please leave a comment at the end of this post:

Windows imaging technologies

  • ImageX (imagex.exe) is a command line tool for manipulating Windows Imaging Format (.WIM) files. It is built using the Windows imaging API (WIMGAPI) together with a .WIM file system filter.
  • Windows Vista images are HAL-independent and make use of single instance storage. To minimise the amount of space used by Windows Vista installation images, use imagex.exe to apply images to separate folders on a computer and then append these images to the final image.
  • Windows System Image Manager (SIM) is used to create and maintain answer files.
  • To modify an image, use imagex.exe to mount it and then apply an unattended setup answer file (unattend.xml).
  • Package Manager (pkgmgr.exe) can be used to update both image files and computers that have already had an image applied:
    • When used to update computers that have already had an update applied, pkgmgr.exe can install, configure and update features in Windows Vista (e.g. installed components, device drivers, language packs, updates). It can also be used with an unattended installation answer file for new installations.
    • When adding additional drivers to an existing Windows Vista image, use pkgmgr.exe to add the drivers from a folder.

Windows Vista deployment

  • Windows Setup (setup.exe) for Vista is now GUI-only and there is no more winnt.exe and winnt32.exe.
  • Windows installation is structured around a number of configuration passes:
    • Windows PE.
    • Offline servicing.
    • Generalise.
    • Specialise.
    • Audit system.
    • Audit user.
    • OOBE system.
  • unattend.xml is a single unattended installation answer file, replacing multiple files in previous versions of Windows – including unattend.txt, cmdlines.txt, winbom.ini, oobeinfo.ini and sysprep.inf.
  • To avoid prompting users for input during the installation of Windows Vista, create an unattended setup installation file and copy this to a USB flash drive, then ensure that the flash drive is present during Windows Vista installation.
  • unattend.xml must be renamed to autounattend.xml when used on removable media during installation and replaces winnt.sif.
  • The Out-of-Box Experience (OOBE) is now known as Windows Welcome and is controlled with oobe.xml, which includes options for Windows Welcome, ISP sign-up and the Windows Vista Welcome Center.
  • Disk repartitioning can be configured in the first pass of the Windows PE section of unattend.xml.
  • When using multiple hardware configurations, create a distribution point that includes an Out-of-Box Drivers folder.
  • Windows Deployment Services (WDS) replaces Remote Installation Services (RIS).
  • When using WDS with computers that do not have PXE capabilities, create a WDS discovery image and use this to create a bootable CD for Windows Vista installation.
  • When using WDS on a server that provides DHCP services, enable DHCP Option 60 and configure WDS to listen on port 67.
  • If the WDS Image Capture Wizard is unable to capture a reference computer image, restart the reference computer and run sysprep /generalize /oobe.
  • The Windows Automated Installation Kit (WAIK) replaces and contains updated versions of tools previously provided to OEMs (e.g. Windows PE) for use in corporate deployments.
  • The OEM Preinstallation Toolkit (OPK) is for system builders, containing the WAIK and additional OEM-specific information (e.g. OEM licensing).
  • bootsect.exe is used to enable deployment alongside earlier versions of Windows with the Windows Vista boot manager (bootmgr.exe) – it replaces fixfat.exe and fixntfs.exe (both included with Windows Vista). Microsoft knowledge base article 919529 has more details.
  • boot.ini has been replaced by the >Boot Configuration Data.
  • The System Preparation Tool (sysprep.exe) is installed by default on Windows Vista systems in %windir%\system32\sysprep and there are several changes when compared with previous versions:
    • sysprep /reseal is replaced with sysprep /generalize /oobe.
    • sysprep /factory is replaced by sysprep /audit.
    • sysprep /mini is replaced by sysprep /oobe.
    • sysprep /nosidgen is replaced by sysprep /generalize.
    • sysprep /clean and sysprep /bmsd are deprecated.
    • sysprep /activated is replaced by sysprep /generalize (together with slmgr.vbs for managing the activation status of a computer)
    • OEMs are required to run sysprep /oobe before delivery of new computers.

Customising Office 2007 installations

  • Windows Installer Patch (.MSP) files can be used to produce customised Office installations (and then called using a script).
  • Multiple installation shares can be defined within a .MSP file.

Office 2007 deployment

  • To create an Office 2007 installation share (e.g. for scripted deployment), create a shared folder on a server and copy the installation files from the source media to the root of the shared folder.
  • To slipstream Microsoft Office 2007 updates into the deployment, create a folder called updates in the Microsoft Office 2007 distribution folder and copy all updates to this folder.

User data migration:

  • The User State Migration Toolkit (USMT) v3.0 can be used with both Windows XP and Windows Vista.
  • miguser.xml can be used to ensure that USMT captures files with a particular extension during migration.
  • The USMT scanstate.exe command can be used with the /p switch to ensure that sufficient free space exists in a target folder.
  • USMT can migrate user state using a network server during an upgrade that involves repartitioning of disks.
  • If the partition table is to be left intact during a migration, use a local partition with sufficient free space for temporary storage.
  • scanstate.exe can scan a source computer, collect files and create a store without modifying the source. The default action is to compress files and store them in image file (usmt3.mig).
  • loadstate.exe will migrate files and settings from and existing store to the destination computer.
  • The scanscate.exe and loadstate.exe commands have matching command line arguments.
  • Migration XML files include rules to define what should be migrated and are specified with the /i switch:
    • Custom XML files define components to exclude and are created using scanstate /genconfig:config.xml.
    • migsys.xml is used with the /targetxp switch to migrate operating system and browser settings.
    • migapp.xml is used to migrate application settings.
    • miguser.xml is used to migrate user files, folders and filetypes.
    • If the destination computer is running Windows XP, modify miguser.xml, migapp.xml and migsys.xml
    • If the destination computer is running Windows Vista, modify miguser.xml and migapp.xml but migsys.xml is not supported – use config.xml instead.
    • migxml.xsd can write and validate xml files.
  • scanstate /p can be used to create a space estimate file called usmtsize.txt (it will also be necessary to specify /nocompress).

Office 2003-2007 interoperability


  • To add multiple language support to Office 2007 applications, install the appropriate language pack on the installation share and update config.xml.
  • To add a language pack to an existing computer, use pkgmgr.exe to apply a new unattended setup installation file that references the appropriate language pack.
  • If the Windows SIM is unable to access language pack settings in a customised Windows Vista image, generate a new catalog based on the custom image.

Further reading

Introducing the Microsoft Deployment Toolkit 2008

One of the sessions that I managed to catch at UK customer launch for Microsoft’s 2008 products last week was Julius Davies’ and Jason Stiff‘s presentation on Windows Server 2008 (and Windows Vista) deployment. I recently spent some time brushing up my deployment skills but there have been a few developments since then – not least the rebranding of the Microsoft Solution Accelerator for Business Desktop Deployment (BDD) as Microsoft Deployment.

With Windows Vista and Windows Server 2008 now sharing a common codebase, the same techniques can be applied to both client and server deployment. Conseqently, whilst still consisting of a combination of documentation and tools to provide guidance for deployment best practice, the Microsoft Deployment Toolkit (MDT) 2008 is equally applicable to Windows Vista (including SP1) and Windows Server 2008 (as well as certain downlevel operating system releases) – hence the removal of the emphasis on the business desktop.

As for its previous incarnations (I recently wrote an overview of BDD 2007), Microsoft Deployment 2008 provides for “lite touch” or “zero touch” deployment. Lite touch deployment is primarily about the creation of images for deployment from DVD, using Windows Deployment Services (WDS) or another method. Zero touch deployment relies on Microsoft System Center Configuration Manager (SCCM) to provide a management framework but both use the same core tools (Windows PE, ImageX, etc.).

As with BDD 2007, MDT 2008 includes a deployment workbench with an information center (documentation, news, and components), distribution share (operating system, applications, packages – e.g. language packs, and drivers), task sequences (with major OEMs to provide their own extensions to the XML), and deployment (deployment points and database) – now including multicast support (which even Microsoft note is overdue) using Windows Deployment Services. With the zero touch installation, MDT is used to extend the SCCM site server and provide similar concepts to the deployment workbench, including the ability to import task sequences from MDT and take them further (for example to provide role or feature-based installations).

In terms of roadmap for MDT, an update is expected in June 2008 to support System Center Configuration Manager 2007 service pack 1 as well as enhanced OEM support and further configuration elements. Further out “deployment 5” is expected to include an expanded product knowledge and cater for role based deployments using a “hydration” process for common applications.

Whilst on the subject of deployment, Garry Martin sent me a link to Dan Cunningham’s Workstation Migration Assistant – effectively a wrapper for the Microsoft User State Migration Toolkit (USMT). It looks like it could be a useful tool in the migration engineer’s arsenal – The Deployment Guys have more information on their blog.

Office 2007 Customisation and Deployment using BDD 2007

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).