Introduction

Servicing O365 via Config Manager has been supported since early 2016 with the release of 1602.  However Microsoft recommend using the CDN or an on-premise file share to deliver O365 updates, with Config Manager their third choice recommendation.  I expect this is because using SCCM is by far the most complex update delivery mechanism but there are benefits too.  For example Automatic Deployment Rules have been around since SCCM 2012 R2 and have been further enhanced way back in the 1511 release (2015) to include benefits such as the ability to create multiple deployment schedules.

The ability to automate our patching strategy for O365 is very appealing and worth further investigation – to this end I have been investigating the best way to move to SCCM to service our fleet of O365 installations.

Automatic Deployment Rules

It took a while for me to understand ADRs and to feel comfortable with them.  My initial reaction was to stay well away believing that using them would surely result in an automated  catastrophe.

The truth is however that once you understand the process they actually provide a huge benefit to you and your organization.

Schedule

This will vary on your location – not everyone experiences patch Tuesday in the same way so I’m just going to say that you should configure the ADR schedule to coincide as closely as possible with the O365 Update release schedule.

Additional Deployments

This is a huge bonus since Config Manger 1602 and can be used to create additional deployments instead of multiple ADRs.  One use case is to target a pre-pilot collection with O365 updates and also a pilot collection using the same ADR.

ADRs Cannot be Fully Automated for O365 Updates…yet

One ‘gotcha’ to call out early however is that you cannot fully automate the deployment of O365 updates using an ADR.  Lets take a look at a simple evaluation query below:

As you can see  I have tried my best to filter out all past SAC updates and obtain and deploy only the most recent update (which would be 1902 at the time of writing). However the ADR will still grab updates for 1808 (and when I began to write this post back in the summer it also pulled in 1803 too)– both updates have not been superseded, expired and are released within the “1 month past” timeframe.  In short all of the available updates are still valid because of the support overlap Microsoft provides for each SAC release.

The result is that if we have 0365 version 1803 (as I did during my testing, and 1803 was still in support) installed on a client it will request the SAC update for 1803, 1808 and finally 1902.  I’m sure that the majority of your computers are on a recent O365 release but there are always exceptions and devices that have been left behind.

In my organisation we would definitely have clients that attempted to install 3 updates for O365 in a given month based on the ADR criteria above.  In my experience, and this is based on about 10 tests rather than any official documentation I have read, the device tended to do the following:

1. Reports to Config Manger that updates for 1803, 1808 and 1902 are required
2. All three updates are downloaded
3. Device skips installation of 1803
4. Device installs 1808
5. 1902 Installation is attempted at roughly the same time and fails
6. On subsequent Software Evaluation Cycle the 1902 update is installed

The user experience in this case is not great…and when considering we can essentially jump from 1803 to 1902 in one update  is a scenario we should avoid.

The only solution I found to this problem is to be very specific with the “Title” criteria. Of course this means that when Microsoft release the next “version” of O365 we will need to adjust our ADR filter slightly…resulting in a solution that is not fully automated

So in my final ADR the criteria included two lines for the ‘Title’ criteria, and I will obviously need to adjust the version number when new feature updates are released:

• -Targeted
• Semi-annual Channel Version 1902

User Notifications

The most contentious area I believe is user notifications.  It took some time to figure out what made update notifications behave differently – it turns out the advertisement start time and deadline times have the largest impact.  Thankfully Microsoft recognised that there was a general lack of clear information on this topic and a blog post was written to de-mystify the process and expectations.  The blog can be viewed here  (scroll down for the section relevant to SCCM)

I reference the “BusBar” (aka “BizBar”) below so for clarity here’s a screenshot of what that looks like:

Let’s now walk through a few scenarios and note the resulting differences:

Scenario 1 – Configuration

This scenario had the following configuration set:

1. Reboots were suppressed via SCCM
2. An Office application was left open during the update process.
3. Advertisement start time was set to a past date/time
4. Deadline set to a future time

Scenario 1 – Results

1. The advertisement start time is honoured and therefore Office update is downloaded and the majority is installed (or “staged”) before the deadline is reached
2. The update cannot finalise as some files are in use
3. The user is notified via the “BusBar” (also referred to as the “BizBar” in the article above) when any Office application is launched post staging
4. If the user clicks “Update now” – Office apps are closed and the update completes.  However rebooting without clicking on “update now” does not finalise the update.  Because SCCM reboots were suppressed there is little to force the user to finalise the update

Scenario 2  – Configuration

This scenario had the following configuration set:

1. Reboots were suppressed via SCCM
2. No Office applications were open during the update process.
3. Advertisement start time was set to a past date/time
4. Deadline set to a future time

Scenario 2 – Results

1. The update is downloaded and staged as per Scenario 1
2. The update is able to finalise as no files are locked
3. The user receives no notification that an update has taken place

Scenario 3  – Configuration

This scenario had the following configuration set:

1. Reboots were suppressed via SCCM
2. An Office application was left open during the update process.
3. Advertisement start time was set for a future date/time
4. Deadline set to a future date/time

Scenario 3 – Results

1. The update is downloaded and staged as per Scenario 1
2. “BusBar” appears when the user opens an Office application post staging
3. A reboot ‘request’ is shown to the user but not enforced
4. If the user reboots the update is finalised
5. However there is no mechanism to force a reboot to finalise the update

Scenario 4  – Configuration

This scenario had the following configuration set:

1. Reboots were suppressed via SCCM
2. An Office application was left open during the update process.
3. Advertisement start time was set in the future
4. Deadline set for a future time

Scenario 4 – Results

1. The update is downloaded and staged as per Scenario 1
2. “BusBar” appears if the user opens an Office application post staging
3. The Click To Run Service presents the user with the following notification:

   

4. If the user leaves or postpones the update, when there is 1 minute remaining of the deadline the following notification is displayed via the Click to Run Service:

   

5. Once the final minute has elapsed Office apps are closed, the Office update it finalised and once this is complete any Office applications that were closed as part of the update process are re-opened

Final test scenario