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!

Comments (14)
  1. Tom_Floor says:

    Very usefull, thanks!

  2. Ed (DareDevil57) says:

    thanks for sharing.

  3. art says:

    Where are the updates pulled from by the clients…a share, the cloud, etc.?

  4. alan says:

    If you don’t specify they pull from the cloud
    You can also set the share to pull from in the GPO

  5. Wilfred says:

    I think there will also be an effect in the operational side of this process. The monthly scheduling of the deployment seems to be useless from my understanding.

    Everytime Microsoft releases new updates, we still need to create SCCM packages every month since we need to change the version number in the "updatetoversion" parameter in the command.

    Also, to add up on Art’s question earlier, we still need to manually download the updates and store it in a shared location in the network before we can be able to trigger the command with the latest version number.

    Just sharing my thoughts. All inputs are welcome.

  6. DirkM says:

    I’m looking for a way to run officec2rcleint.exe and wait for it to finish before I continue with my script. start /wait… doesn’t work. Does anybody know how to call officec2rclient /update and have a script pause until the update task has been completed?

  7. Ram Karthik says:

    For desktop users, update from \server1update will work but how about laptop users ? Who needs to move into client side or different office for few months. I mean laptop users for roaming multiple branch. What will be scenario for update ?

  8. jing says:

    Thank you for this post!
    but, how do you update to the latest version if the updatetoversion parameter is specified?

  9. Wilfred: If you don’t specify "updateto" you will get the latest version. We have a Production UNC path and a Testing UNC path, so when we just run /update user then they are automatically updates to the latest version in the Production folder. Every month
    Testing is copied to Production, and a new build is download to Testing. Works fine, and fully automated.

  10. Ram Karthik says:

    I agree local UNC path accessible for desktop users. just think if a user working from home or client location then UNC path not accessible and it won’t update….even if you run through sccm you need to push entire builds approx 1GB that’s not a good
    solution. I’m seeing some limitation in Office 365 Architecture. All inputs are welcome….

  11. Error 80088-27 says:

    Each time we try this (or any other update method), we get Error Code: 30088-27. We’ve tried allowing auto updates, disabling them, ADMX/GPO, manual runs, etc… We use SCCM 2012 to push the initial application install which works great, but after that
    we’re never able to update through any method. Any ideas?

  12. Travis says:

    Sorry, above the error is 30088-27. It appears to relate to the LocalSystem account, and several sites say "just uninstall and reinstall" but that’s not solving our issue. Further, I can’t ask our users to all "Online Repair" their install since they won’t
    have admin rights. Happy to take this to email or provide diagnostics so we can move forward, if anyone’s able to assist.

Comments are closed.

Skip to main content