Monday, April 27, 2015

ConfigMgr and Office365 Click-to-Run

Like many organizations we are migrating towards cloud offerings where it makes sense, and Office is no exception. With that said, we have begun transitioning from the MSI install of Office 2013 to  Click-to-run via Office 365 (O365). With my organization being global with lots of customization we had a choice to make in relation to updates. You have 3 basic ways of maintaining Office 365 Click-to-Run.
  1. Get Updates from Microsoft Office CDN
  2. Get Updates from local UNC Path
  3. Package as App-V
All of these methods are well documented. For us we choose the second Option (B) which gives some control over its Updates vs the other two. With the first option it was all in the hands on MS, we were not comfortable with that as we have had troubles with Office patches in the past. While we have experimented with App-V, I was concerned about using it for Office due to its footprint since its on every machine and in constant use, especially for Outlook and Lync. I see us changing to the first method long term, as rumors abound about Office 2016 Click-to-run changing the update process.


First part is to get the content which is covered very well so I wont really touch on it. Simply put, you call an XML against ODT to grab the content from the Office CDN. I created a simple shell script to download it at 2AM every Monday, Wednesday and Friday and email the results. Sometimes I'll manually run it such as on Patch Tuesday. One thing I don't like about ODT is it ALWAYS downloads the latest. Already got it? Here let me download that for you again. I would like it to check and not download the current version again if it already exists locally. Next version of the script will do some revision control and other ideas I have.

This content is managed on a File Server with 32-Bit and 64-Bit together. Originally these were separate but since you state the bit level via the install XML they were merged for easier management. We maintain the last 5 versions on site.


IMO we moved back 10 years with Office 365 Updates. No SUP, WSUS, MU, etc. It updates via a scheduled task that checks 3 times a week and after login. So for arguments sake, daily. Since we chose Option B we get it from a UNC path. Being global it doesn't make sense for O365 to go across the globe to some File Server so we used DFS so its "local". Reminded of FRS replication problems from my Modular Messaging days, I chose to have ConfigMgr do replication instead of DFS. Plus, we have these SCCM Servers all over with the content so I wanted to use that. In other words, DFS namespace folder points you to the closest source and SCCM servers are the Folder Targets.

Within SCCM we have a package with the following folder Structure at its root.

 Dev   - Future Use, if you have Test, you should have Dev.
 O2013 - Some systems had their MSOCache removed so the MSI O2013 content is here
 Prod  - Production
 PTG   - Patch Testing Group
 Test  - Testing

Under each folder you have the Office\Data structure. Nothing special. Currently PTG gets the updates a month before production, basically when released by MS. To gripe, I wish MS would have Feature Updates separated from Security Updates. Its rough making a client UI change. With MS releasing Skype For Business this month, it effectively has stopped us from updating O365 until we resolve Skype For Business. If they fix a zero-day next month, we'll have to choose between that and Skype For Business.

Skype For Business was released as part of the April cycle so its located under 'Test' while the Lync team tests it out and does anything they need to do before we let it loose. With how this folder structure was done, we can add more folders for testing, or O2016 release, or ...

O365 gets its alternative update path via HKLM\SOFTWARE\Microsoft\Office\15.0\ClickToRun\Configuration\UpdateURL. This points to the UNC path for the updates source. '\\\Updates\O365\Prod' for example but any Namespace root will work. Since they are all in the same place, just change 'Prod' to 'Test' or whatever. This path is set initially during install by the XML. More below on that.

For the package, there's no programs, just content. On the Data Access tab you check the boxes so it will publish have the content outside the Content Library via UNC.

This will let it behave similar to previous SCCM versions and place the content at \\SCCMServer\SMSPKGD$, whatever D is in your case. So now for DFS you add an entry for \\SCCMServer\SMSPKGD$\PACKAGEID. We also have 1E Nomad so you can use \\SERVERNAME\NomadSHR$\PACKAGEID_Cache in that case. We now have the O365 content at all DPs and end-points can pull O365 Updates.


You can do this, but since its SCCM, we have to automate the Updates path also! We used Compliance settings to set UpdateURL in the registry.

Each Compliance Setting is setup very similar with the only difference being the UpdateURL UNC Path.

Under Settings we have the following:

For Compliance Rules we have this one rule:

Under Relationships we point to a Configuration Baseline.

For the Baseline we have the configuration data set.

And the following for the deployment to a collection. It checks and mitigates daily.

This in turn points to some collections. These are pretty simple in that for Prod its limited to the All Workstations Collection as well as excludes the other O365 Update Collections (Test, PTG, etc) and for the other non Prod ones, they each point to an AD Group that we put user objects into. Since we have a few Citrix Server installs, those are handled as well.


Now that all this is setup the management is pretty easy. The Script downloads the new version, we get email its here. We then copy the version into the appropriate folder in the package and replicate it. Thats it. Clients will update O365 on their own from here. We could automate further as needed.

Side note on the folder structure. Point the UpdateURL to the root folder that 'Office\Data' will be in. The O365 update process will navigate down. Also, the (or and (or are the same file and are located in the Office\Data folder. Everything else lives under the version folder.

Office 2016 Click-to-Run Beta

The current version of O2016 Beta ODT only downloads the two main stream files for each bitlevel so you will have to manually download the following files. Be sure to change the version (16.0.3823.1010 shown below) to the version of choice. The structure and naming convention is the same as for O2013 bits of O365. You'll need to take the (or and rename to (or and put up a directory under Data.\Office\Data\16.0.3823.1010\\Office\Data\16.0.3823.1010\\Office\Data\16.0.3823.1010\\Office\Data\16.0.3823.1010\\Office\Data\16.0.3823.1010\\Office\Data\16.0.3823.1010\\Office\Data\16.0.3823.1010\\Office\Data\16.0.3823.1010\\Office\Data\\Office\Data\  


This script is provided as-is, no warranty is provided or implied.The author is NOT responsible for any damages or data loss that may occur through the use of this script.  Always test, test, test before rolling anything into a production environment.

You can find the download script along with some download XML files referenced in this post here. You will need to tweak them for your environment. Additionally, you will need to download the latest ODT from Microsoft and blat.exe for email.


No comments:

Post a Comment