Automating for Awesome – An Always-Updated Office

2017-10-15 • 5 minutes to read

It was sometime in 2014 when I first learned about the concept of an “Image Factory”—an automated build system that generates consistent and reliable reference Windows images for one to use in future deployments. At the time, my WinPE experience was limited to ConfigMgr. I didn’t realize how valuable an Image Factory could be until I implemented one and found that I could complete a Windows deployment in a fraction of the time.

If you do not have an Image Factory, might I recommend borrowing Mikael Nystrom’s Reference Image Factory scripts. I use an Image Factory to generate fresh new Windows images on a monthly basis. My images contain only the bare-essentials (.NET 3.5, all the Visual C++ Redistributables, Silverlight), which are then updated against Windows Update/WSUS. This means when I finish imaging a machine, I’m not spending hours running Windows Update against it.

I recently upgraded our Image Factory environment to use Mr. Nystrom’s v3 scripts (compared to the older v2 scripts). During my build, I started thinking about ways to keep Office up to date. Previously I just included Office in the base image, but some business requirements changed that process. Now that Office installs during build time, I didn’t want to go back to having to run Microsoft Update against a freshly-built machine.

If keeping Office installers up to date has ever come across your list before, you’ve probably seen the VBScript provided by Microsoft that does just that. The process is pretty simple: update Office, run the script, then copy all the *.msp files into the Updates folder in your Office install.

…But what if we could automate this so you could spend that time doing other things?


This proof-of-concept solution performs the following:

  • Builds a fresh Windows environment, and installs Office
  • Updates the Office install
  • Extracts the files to a share
  • Shuts down the machine (which is eventually deleted)

We make use of the following:

MSI/Click to Run notice: This process works only with the legacy “MSI” version of Office. If you have the ability to deploy the Office Click-to-Run version, I highly recommend it. For those who haven’t achieved that level of C2R zen, read on…


Creating the task sequences and validating the Office extraction script:

  • First, we store the Extract-OfficeUpdates.wsf script in the MDT deployment share. I put mine in an “Extra” folder, located at the root of my MDT Deployment Share.
  • Open the script, and modify line 70 with the name of the server and path you want to save Office updates to. Note that if you specify “\server\path,” the script will create a new folder named after the task sequence and put it’s Office updates in there (“\server\path\OFFICE16PRO”).
  • Next, we create a new task sequence folder in MDT called “OfficeBuilds.” Then we create our task sequences for each Office product we want to keep updated.
  • In each task sequence, install your Office product:

    (I put them under a folder as this makes copying/pasting between task sequences much easier)
  • Under the “Mount Office Extraction Share,” use the ZTIConnect script as follows. Be sure that your MDT Build Account has write access to this share!
  • Under “Extract Office Updates,” run this command. You’ll see that it’s pulling directly from the MDT server so there’s no need to generate new ISOs:

At this point, you could spin up virtual machines and kick off these task sequences—you’d have Office update content in no time. We’d like to take this a step further by automating this process.


Customizing the Image Factory scripts:

If you have used Mr. Nystrom’s scripts, you know that the default behavior is a VM is created, it’s customized to your liking, it’s captured to a WIM file, then the VM is destroyed. This is almost exactly the same process we want for Office updates, except we don’t need the capture step. Here’s what I did to quickly implement a solution:

  • Edit the ImageFactoryv3.xml file to include a new element that contains the name of your OfficeBuilds task sequence folder. Name it whatever you like, just remember it and make sure it’s unique:

  • Make a copy of the main build script (I added “Office” to the end so I know it’s for building Office deployments)

  • Edit this file. We’re going to make just a few changes:

    • Search for “RefTaskSequenceFolderName”
  • Rename the two MDT:// strings so they show the name of the element you used above
    (Instead of “MDT:\Task Sequences\$($Settings.Settings.MDT.RefTaskSequenceFolderName”, mine is now “MDT:\Task Sequences\$($Settings.Settings.MDT.RefTSFolderNameOffice”)
  • * Search for “DoCapture.” You will see some if/then logic. Remove all the if/then logic and only leave the code segment that contains “NO” for DoCapture:

If all goes to plan, you’ll have an Image Factory that spins up virtual machines, installs Office, updates it, extracts the updates to a folder of your choice, then deletes the VM once it’s finished!

Important side note: Don’t run this the same time as another Image Factory script. If you run two or more at the same time, you’ll run into weirdness with your customsettings.ini file.

Good luck, and happy updating!


An immensely special thank you to Mikael Nystrom for providing his Image Factory scripts. Without them, Id have a lot less free time. I owe you a beer at the next MMS!




Improving the TPM OSD Experience

ConfigMgr + Apple DEP