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:

General

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.

Completed

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.

Maintenance

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.

-Kevin

1E NomadBranch Collections

I'm working on updating our 1E NomadBranch install to the latest version and thought having some collections for it would be useful. We already have many for ConfigMgr itself.

So for Nomad Activity I set up these collections as I thought they would be useful for the upgrade but also ongoing.

To start I have a parent collection called 'All Systems with 1E NomadBranch' I used this for the query.

 select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_ADD_REMOVE_PROGRAMS on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID = SMS_R_System.ResourceId inner join SMS_G_System_ADD_REMOVE_PROGRAMS_64 on SMS_G_System_ADD_REMOVE_PROGRAMS_64.ResourceID = SMS_R_System.ResourceId where SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName like "1E Nomad%" OR SMS_G_System_ADD_REMOVE_PROGRAMS_64.DisplayName like "1E Nomad%"  

I ended up using the % wildcard as version 6 is called 'NomadBranch' and version 5 is called 'Nomad Branch' (has space). This was easier then doing separate queries or other ways. Additionally Nomad has both 32-Bit and 64-Bit so we pull from SMS_G_System_ADD_REMOVE_PROGRAMS_64.DisplayName and SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName as well.

Now we break down the major versions. I'm a fan of parent/child collections so these are limited to the parent collection 'All Systems with 1E NomadBranch' above. We obtained NomadBranch at version 5.2 so I didn't do anything earlier then that. For these I ended up just looking for the version of NomadBranch.EXE.

All Systems with 1E NomadBranch 6

 select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_SoftwareFile on SMS_G_System_SoftwareFile.ResourceID = SMS_R_System.ResourceId where SMS_G_System_SoftwareFile.FileName = "NomadBranch.exe" and SMS_G_System_SoftwareFile.FileVersion like "6.%"  

All Systems with 1E NomadBranch 5

 select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_SoftwareFile on SMS_G_System_SoftwareFile.ResourceID = SMS_R_System.ResourceId where SMS_G_System_SoftwareFile.FileName = "NomadBranch.exe" and SMS_G_System_SoftwareFile.FileVersion like "5.%"  

I also wanted sub versions so I created those also. I didn't know I had any version 5 so they are getting updated forcefully. With that said, I didn't care to expand those out and focus on 6 since its the current major version. So we look for version 6.0 and 6.1. These are limited to the main version 6.

All Systems with 1E NomadBranch 6.0

 select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_SoftwareFile on SMS_G_System_SoftwareFile.ResourceID = SMS_R_System.ResourceId where SMS_G_System_SoftwareFile.FileName = "NomadBranch.exe" and SMS_G_System_SoftwareFile.FileVersion like "6.0%"  

All Systems with 1E NomadBranch 6.1

 select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_SoftwareFile on SMS_G_System_SoftwareFile.ResourceID = SMS_R_System.ResourceId where SMS_G_System_SoftwareFile.FileName = "NomadBranch.exe" and SMS_G_System_SoftwareFile.FileVersion like "6.1%"  

For all the above versions, they are the same query with the version number changed so copying makes it quicker. A like is used since version is a string vs using a full match as Nomad uses X.X.X.X version structure and we have many sub versions around.

Finally, I wanted to know who was NOT on the latest patch level. At the time of this post it is 6.1.100.181. So we use the same query but use a ≠ (not equals) instead of a like for the version. As new patches come out we just modify this query so we can target any upgrades needed.

All Systems with 1E NomadBranch 6.1 NOT Current Patch

 select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_SoftwareFile on SMS_G_System_SoftwareFile.ResourceID = SMS_R_System.ResourceId where SMS_G_System_SoftwareFile.FileName = "NomadBranch.exe" and SMS_G_System_SoftwareFile.FileVersion != "6.1.100.181"  

As a bonus I also wanted to know who had the 1E ConfigMgr Extensions installed. This is limited to a collection of who has the SCCM Console installed.

All Systems with 1E NomadBranch Admin Extensions

 select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_ADD_REMOVE_PROGRAMS on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID = SMS_R_System.ResourceId where SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName = "1E Nomad Branch Admin Extensions 2012"  

And who needs to be updated

All Systems with 1E NomadBranch Admin Extensions less then 6.1

 select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_ADD_REMOVE_PROGRAMS on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID = SMS_R_System.ResourceId where SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName = "1E Nomad Branch Admin Extensions 2012"  

-Kevin