How do updates work in this new paradigm?
In my recent experience with deploying Office 365 Pro Plus, the methodology for deploying updates is still somewhat mystifying for most administrators – diagrams like this one don’t really help us to understand exactly how we want to (or should) apply updates:
I mean, in theory it explains it, but in my experience it’s just gets more confusing trying to understand which updates should be applied, when they should be applied, and how they should be applied.
Let’s break it down:
Individual updates are no longer available for Office 365 Pro Plus – this means you cannot use Windows Updates, WSUS, or SCCM to apply updates the way you used to in the past. (source)
Every month a new build is released – this means that you now update from one build to the next, not applying updates based off the build you installed 6 months ago.
Update Channels – here is where find things get the muddiest… partially, I believe, because Microsoft decided to use a similar yet different naming scheme for Windows 10 update / servicing channels.
- Each build is in mainstream support for 1 year – this is as long as you can defer your updates / builds before needing to upgrade to remain supportable and current.
Channels, how do they work?
Let’s talk about what these channels are and what they mean to you as you try to figure out how you’re going to manage Office Pro Plus going forward. First off – bookmark this site, and keep an eye on it to know what Channel, Version, Build, and Release Date is current: https://technet.microsoft.com/en-us/library/mt592918.aspx
This is a screenshot of the most recent update (January 2017) – but check the site for the most recent version.
Here’s how the channels break down:
Current Channel (CC) – this is the channel you’ll be on by default if you log into the portal and click the helpful button that wants you to install Office Pro Plus. The defaults for this channel are to receive a new build from Microsoft on a monthly basis, automatically. You can still control where these updates come from if you want to (more on that later), but this is the channel for early adopters, small companies that like being on the cutting edge, and are willing to put up with frequent changes.
First Release for Deferred Channel (FRfDC) – think about this as being your pilot / testing channel. If you are not just sticking with the Current Channel for your business (and most aren’t), the First Release for Deferred channel will be your power users, IT teams, and whomever you’ve identified as being a good tester in your organization.
- Deferred Channel (DC) – this is where most businesses are going to put their users, and this is indeed a good idea. The deferred channel has a nice steady pace of updates (every four months), and these updates will have gone through all the testing of Current Channel users, then First Release for Deferred users before they finally make their way down to the Deferred Channel users. This means that you have about 8 months of folks testing new updates along those various channels before you push them out to your users, allowing for a much smoother update process, with much less chances of changes breaking things in your org.
Basically, the update flow looks like this – using today’s Deferred Release (Version 1605) as a reference:
June 6th, 2016: Version 1605 was released to the Current Channel (CC)
June 14th, 2016: FRfDC gets the first Version 1605 build
- The FRfDC then gets monthly builds of version 1605 until October 11th, when Version 1609 is released to both the CC and the FRfDC.
Throughout these four months, the Current Channel has received Versions 1606, 1607, 1608, and 1609 with various iterations of builds throughout. Every quarter, all these updates get rolled into a single release and pushed out to both channels, and then CC starts to iterate again for another quarter.
- January 10th, 2017: Version 1605 is now released to the Deferred Channel (DC) – CC is already on Version 1611, and FRfDC has started using Version 1609
The big takeaway here is that if you stick with the DC for your broader user base, you’ll be deploying updates that were first released around 8 months ago – giving lots of time for these updates to be tested, bugs reported and squashed, and feedback given to Microsoft on features and changes. This channel gives you the safest, slowest update path possible, while still ensuring that your Office installations are being kept up to date.
Don’t forget that security updates are still being applied monthly, so it’s not like your 8 months behind on security, just on features and changes.
All good? Let’s move on to the how of things…
How do I actually manage this?
Glad you asked! One of the biggest changes that admins often miss is that Office Updates no longer roll out with Windows Updates. This means Windows Update, WSUS, and SCCM cannot be used to update and manage Office the way they used to.
There are three ways that admins can apply updates for Office 365 ProPlus:
As I mentioned above, if you’re already agile enough to be on the Current Channel, you’ll probably want to just leave these settings to default, and let users apply updates automatically from Microsoft servers as new builds are pushed out. If this is you, congratulations! You’re helping to test updates and make sure they’re all good before they get released to the masses in the DC 😉
This option is where you go if you want to still keep people updating automatically, but you want a little more control over the version they’re getting – the TechNet links below layout the process of how you can automate this if desired, and basically bridges the gap between convenience and control in your environment. This option will also allow you to maintain a steady cadence of updates, as you only need to configure your installs to update from a specific location, and then download whichever version you want into that updates folder.
This final option gives you the greatest amount of fine grained control – Office Updates are disabled entirely, and users will only get the versions that you deploy to them. Use this methodology if rigid change control is required, or if you want to make sure that everyone (except your pilot/test users of course) is holding to the same version, and helps to keep your environment standardized.
More information (and full details) available here: https://technet.microsoft.com/en-us/library/dn761707.aspx
It’s important to note that updates do not require local admin rights as they run under the system context, so if you’re trying to prevent users from running updates, just removing local admin privileges won’t stop these updates from applying. This also means that it’s a lot easier to manage these updates going forward, as you won’t have to go around type in an admin password in order for users to get their updates.
Given the nature of these channels (multiple release stages), it’s important that you implement a solid testing methodology in your environment. Designate a number of flexible and competent users, and put them on the FRfDC so that you know what updates are coming in your environment before they get pushed out to mission critical systems. This will allow you to defer updates if you need more testing / development time, or give you more time to prep your users for feature changes that will impact their day to day life. Once you’re comfortable that the updates are not going to cause problems in your environment, move them into the Deferred Channel and let them be released to the rest of your users.
Here’s some additional reading resources for extra credit: