Patching Office 365 with Configuration Manager 2012! or “How I learned to stop worrying and love the Click2rclient!”


Recently I was pulled into a customer engagement, where the customer had recently deployed Office 365 for their users. While they loved the benefits of O365, they couldn’t quite get their head around allowing O365 to update on its own when a user launched Office, and a new update was available.

Their goal then, was to disable the Automatic Update feature of O365 and replace it with a scheduled and targeted Update from System Center Configuration Manager. Once this was done, they could control what version of O365 was deployed across all of their systems, how and when their client machines were updated, and if necessary, rollback to previous versions of O365.

Follow along, shall we?

To do this, the first step is to disable the Automatic Update feature of O365. Load the Office 2013 Administrative Template files into Group Policy. You can find them Here: Office 2013 ADMX ADML Files and Office Customization Tool.

Following this TechNet article to use the new Group Policy Settings to customize Office 2013 Use Group Policy to enforce Office 2010 settings.

Pay particular attention to this GPO setting:

Microsoft Office 2013 (Machine)\Updates

Enable Automatic Updates


This policy setting controls whether the Office automatic updates are enabled or disabled for all Office products installed via Click-to-Run. This policy has no effect on Office products installed via Windows Installer. If you enable or do not configure this policy setting, Office periodically checks for updates. When updates are detected, Office downloads and applies them in the background. If you disable this policy setting, Office won't check for updates.


Once you have disabled O365’s ability to update itself, you’ll need to setup Configuration Manager 2012 to kick off the Office Update feature known as Click2Run.

Here’s how to do that.

Create a Collection that will contain the target machines you want to update with Click2Run.  In my lab I only have one client (Windows 8.1) that I’m going to use for this demo).  It is in a Collection of it’s own.Capture20


Next create an empty package. “But Dave, why an empty package?” you say.  Just follow me on this one….all shall become clear in due time.

Create a Package without any Source files. 


I called my package OfficeC2RClient.  I gave the Package the same version as the version of O365 I was updating.

You can find a list of all the Office 365 Versions and their Version information

 HERE: Microsoft Office 2013 Click-to-Run Virtualization

In my lab, the Package name is OfficeC2RClient (and for fun, I’m listing the Version of O365 that I want to update to with this package.  The full version number is 15.0.4631.1004 (which we will use in a minute).


Notice on the Data Source tab, I don’t point to any source files.  There is a really great reason for this. In this example we’re going to use the built in functionality of O365 to patch itself, but calling it as a command instead of distributing it as a package.



“Hey Dave!” You might say, “We could go grab the Office Click to Run executable and push it with Configuration Manager 2012. Couldn’t we?”


Yes we could make that the Source Files for our Package, distribute it across our Configuration Manager 2012 Distribution Points and push it like any other package to our client O365 machines to kick off their update.

  But we don’t really want to.   The reason for this, is that this file gets updated by 0365 itself.  Every time the file is updated, we’d have to pull it from a client source, repackage it, and redistribute to our Distribution Points….and that’s a lot of time wasted.

What we’re going to do instead is add a Program to our package that simply calls the officec2rclient.exe that already exists on each client machine.

The syntax for the Program will be "Program Files\Microsoft Office 15\ClientX64\OfficeC2RClient.exe" /update user updatetoversion=15.0.4631.1004


This is what our Program looks like.


And we’re making sure that we let it run “Whether or Not a User is Logged On.”


Now we create a Deployment for our Package/Program.


The Deployment allows us to Target our Collection that contains the Office 365 clients we want to patch.


Now add the Distribution Points (just for fun).


Nothing to see here.  Keep moving….


In my lab, I want OfficeC2RClient.exe to check for Office 365 updates once a month on the Last Friday of the Month.


The schedule looks like this:


Click on thru the Deployment Wizard and then Done!

Now on the Last Friday of every 1 months…


My Windows 8.1 client is getting its Office 365 update as Targeted and Scheduled by Configuration Manager 2012, but using the building officec2rclient.exe.  (Could we hide the above splash screen? Of course!  Using the /displaylevel variable |False you can prevent the User from seeing the splash screen interface during the update.  More details on that Here: Click-to-Run for Office 365 and its associated command-line switches

After the updates are downloaded, they get applied.


And finally checking to ensure the Version that we pushed is the Version that we got….

We pushed "Program Files\Microsoft Office 15\ClientX64\OfficeC2RClient.exe" /update user updatetoversion=15.0.4631.1004

And we got….


And that’s all folks!  Questions? Comments?


SPECIAL THANKS TO:  Alan Ross, Brian Moreland, Matt DePietro and Daniel Earnest for their background on Office 365 and support with this customer’s question!