Troubleshooting Office 365 ProPlus patching through System Center Configuration Manager
Published Sep 20 2018 06:38 AM 4,962 Views

First published on TechNet on Mar 23, 2017
Hello, Dave Guenthner back again with a discussion about Office 365 ProPlus. In February of 2016 I wrote a blog entry about how enterprise customers can service\patch Office 365 ProPlus with System Center Configuration Manager (ConfigMgr) I’ve spoken to many customers about this feature but only recently have customers upgraded from ConfigMgr 2007 and 2012 R2 to ConfigMgr Current Branch to use feature in production. The intention of the blog is talk about how to troubleshoot this feature using a recent case as reference. Basic documentation and requirements are posted here on TechNet . The reality is, each of us learns more when things don’t work than when they do. My case started with the following question… “ Hey Microsoft, we’re not seeing any updates for Office 365 ProPlus in Software Center ?” Checklist for SCCM: 1. Verify Office 365 Client product is selected from Products within Software Update Point Component Properties 2. Synchronize updates, verify Office 365 Client Updates exist within Software Updates node. 3. Create Automatic Deployment Rule (ADR) to download and deploy updates to collection of machines. In my case, customer has clients on First Release for Deferred and Deferred. Since updates for First Release channels can occur at any time, ADR is perfect to automate process of keeping updates current. (*Assume you know how to create ADR) Search criteria (example below) will constrain download only to two channels appropriate for this customer. Run ADR and verify content has been downloaded and distributed to deployment points. Important to note, customers should have ~10% of clients on a validation channel such as First Release Deferred and ~90% on Deferred Channel. In this way, ADR is automating download of content but SysAdmin is controlling schedule of deployment. 4. Verify Software Update Group created is deployed to desired collection. In example, ADR is deployed to All Desktop and Server Clients. Checklist for Client: 1. Install a N-1 version of Office 365 Client. By intentionally installing one month old version we can be confident updates will be applicable. As of this writing, N-1 for deferred channel is 6965.2117 and latest version is 7369.2118. Install Office 365 Client using Office Deployment Tool using sample unattend. (Assume you know how to install Office 365 Client) 2. System Center Configuration Manager references CDNBaseUrl to understand which channel is in scope for Office 365 Client. In this case, the GUID below is “Deferred Channel”, since our ADR included this channel we’re in good shape. You can use the RIOScan tool located here to provide a simple summary report to tell you what is installed and how its configured. HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration "CDNBaseUrl"= 3. System Center Configuration Manager in its applicability check requires Office COM interface to be enabled to help broker communication between Office and ConfigMgr. Typically, customers have already deployed some Office 365 Clients and want to turn this functionality on. The Software Updates client setting show below is used to enable this: Alternatively, this can be accomplished via domain policy using Office 2016 ADMX file. You can verify GPO is working by validating existence of following key. When service Microsoft Office Click-to-Run starts it will check for this value and register class to enable COM interface. HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\office\16.0\common\officeupdate "officemgmtcom"=dword:00000001 4. From control panel, launch Configuration Manager Properties applet and select Software Updates Deployment Evaluation Cycle, click Run Now. Hey Microsoft, we checked and double checked all steps and still nothing is happening ?” 5. Verify COM interface is registered. It should be, if you enabled it via one of the methods above. You can do this by verifying existence of following registry key on the client. [HKEY_CLASSES_ROOT\CLSID\{B7F1785F-D69B-46F1-92FC-D2DE9C994F13}\InProcServer32] @="C:\\Program Files\\Common Files\\Microsoft Shared\\ClickToRun\\OfficeC2RCom.dll" “ Hey Microsoft, this key doesn’t exist! ?” This is the break we were looking for. We know if OfficeMgmtCOM is present, Microsoft Office Click-to-Run service will register .dll and enable COM interface. This is not happening in customer environment. Why? Using Process Monitor from Sysinternals site we can take a trace of restarting Microsoft Office Click-to-Run service and stop trace once service has started. One of the features I like is called count occurrences. I immediately saw a smaller number of Access Denied entries relating to registration of .dll in question. Double clicking on the occurrence count will automatically open trace filtering to operation, in our case show all Access Denied. With this information, we could see McAfee DLP Agent or fcag.exe and with this evidence, make case to disable McAfee Access Protection and restart Office Click-to-Run service. The COM interface key was created and Software Update Deployment Scan finally showed update as applicable in Software Center. Security software and filter drivers are intrusive by design. In this case, customer can follow-up with this vendor and make appropriate tuning change. By taking 3 rd party security software out of the picture, we allowed the COM interface to succeed and Configuration Manager to deem client in scope and advertise update. Summary I hope this blog provides a helpful checklist to accelerate and potentially resolve any native patching activities with SCCM and Office 365 ProPlus. Dave Guenthner     SEO Key words: C2R, Click-To-Run, Click2Run, Office, SCCM, patch, patching, OfficeMgmtCOM, native, Office 365 Client Update, Office 365 ProPlus

Version history
Last update:
‎Feb 20 2020 07:29 AM
Updated by: