Monday, March 27, 2017

Office 365 Click-to-Run Updates via ConfigMgr ADR

I have shared in the past how I am deploying Office 365 Click-to-Run (C2R) updates via ConfigMgr and DFS namespaces. Works fine, however now that C2R 2016 has settled into ConfigMgr handling updates, Iam transitioning to that.

Following the proverbial 80/20 rule, the majority of my fleet receives the Deferred Channel for Office365 Click-to-run 2016 same as most companies have chosen. For the other 20 percent they will have a mix of the remaining channels. We have decided that these other channels will be opt in for those proactive users wanting features quicker then the Deferred Channel cadence provides as well as provide SME (Subject Matter Experts) early access for testing their plug-ins etc.

The main parts of the past articles are still in place. We use AD Groups to house the users that get these other channels which is referenced by an SCCM collection for advertisements.

While we do patches on a monthly cycle, there are many times these other Office channel updates will be released outside of that, especially around First Release for Current and Current channels so we have chosen to use ADRs to automate their release so we can be nearly hands off.

First thing is to setup the ADR by navigating to \Software Library\Overview\Software Updates\Automatic Deployment Rules. Prajwal Desai covers a step by step ADR creation so I will only point out C2R specifics here:


On the general tab. I chose to save to an existing Software Update Group (SUG). This way you have just one SUG and one package per Channel. Note that if YOU create a SUG, it will create another one on its first run and use the one it created subsequently.

Deployment Settings

Software Updates

For this tab I chose the following properties to pivot off of.

  • Date Released or Revisited = 'Last 1 month'
  • Product = 'Office 365 Client'
  • Title = 'Office 365 Client Update - First Release for Current Channel'

Definitely select the Preview tab so you make sure you are getting the results you expected. In this example below, this is the last month as the rule calls out. It pulls back 6 entries, which are 3 versions with both arches. As I have both 32-bit and 64-bit I do not need to split those at this time, however I may split the arches out down the road to keep packages smaller as 64-Bit C2R has a very small footprint so I can keep it closer to the core since its not in use that much compared to 32-Bit C2R.

Evaluation Schedule

Check for updates after the SUP synchronizes.

Deployment Package

I use an existing package so each channel stays in one easy to manage SUG and package. This does mean that the package will update on its own instead of controlled by admins. Each office release is a little over 1GB in size, double for both arches.

On a related note, I use 1E Nomad for (client package) replication, the first release packages are only on my two main DPs in the main site with the Current Channel being at all DPs and clients pull from them. First release channels are on a few clients at this point and are not expected to grow past a few hundred. I see no need to have these files hosted at every site via Nomad since I may not have clients with these Channels there. So the faster channel clients do pull the content slowly across the wire. As they grow we can move them out more or bring them back in from a distribution standpoint.


Once done I have 3 rules setup for the automatic updates for the bleeding edge folks.

The Software Groups are nice and clean also. I have the 3 ADRs and the one manual for Deferred Channel that is created on our monthly cycle.


Depending on how you have your SUP supercedence set up you may have to do some maintenance and clean out old updates from the SUG so they are removed from the package by ConfigMgr. Our process is to do it when we do our monthly patch workflow however the supercedence can remove them on its own.


No comments:

Post a Comment