Office 365 updates stop working when workloads are switched to Intune

The following post will highlight a scenario where Office 365 Updates stop working for clients that have the Office C2R Apps workload moved to Intune. This was a “Think and write it down blog” so my apologies for the structure (or lack of it) – I hope you can still follow my train of thought.


In the following environment, the workload had been moved to Intune for specific clients only. We call this a “Pilot” workload.

Previously, O365 had been deployed by Configuration Manager and updates were also being managed by Configuration Manager. When an Office 365 deployment was created using the Configuration Manger wizard, a Global condition was set on the client Intune O365 ProPlus management = False
This means that once a client has been added to the Office C2R Apps co-management pilot group, they can no longer install office from the Software Centre.


We assumed, by moving the workload to Intune, that as well as Office installations being blocked from Configuration manager our clients would automatically start getting their updates from the CDN – but we soon noticed that some clients were not receiving Office updates. We started by checking the co-management capabilities were correct. We checked the clients CoManagementHandler.log and could see they were receiving the correct co-management capabilities.

Capability 211 indicates the following workloads have been moved to Intune:-

  • Client Apps
  • Office Click-to-Run Apps
  • Windows Updates Policies
  • Compliance Policies

Read more about co-management capabilities here

So at this point, we still assumed that the clients *should* be getting their updates from the CDN because we had moved the Office C2R Apps workload to Intune.
Queue CMPivot – To get an idea of the client configurations to look for anomalies, we used CMPivot. We started with a simple query:-

For the clients that were not receiving updates, we notice the GPOOfficeMgmtCOM was set to 1 *

If you have not already used CMPivot, go and read the docs here


Q: How were our clients getting the GPOOfficeMgmtCOM set to 1 ?
A: Couple of Reasons

When we installed Office 365 initially, we specified in our Config XML that we wanted Configuration Manager to handle the Office updates. We did this by setting the OfficeMgmtCOM value to True.

This will set the following registry key on the client HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\Configuration OfficeMgmtCOM = True


This registry key can also be set (and overridden) by Group Policy – the GPO value will win over any value set in the Config XML during your Office installation *

GPO Setting: Computer Configuration\Administrative Templates\Microsoft Office 2016 (Machine)\Updates – Office 365 Client Management / Management of Microsoft 365 Apps for enterprise

  • Enabled = 1 (Decimal)
  • Disabled = 0 (Decimal)

The policy registry key on the client had also been set HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\office\16.0\common\officeupdate OfficeMgmtCOM = 1

The Configuration Manager Client Setting Enable management of the Office 365 Client Agent, if set to Yes, will also set the same registry key to 1 and this also overrides any value specified in the config XML during Office installation.

* If you repair Microsoft Office 365, the registry key will revert back to 1 if you installed Office 365 with OfficeMgmtCOM = True specified in the Config XML (But it will get over-written if your GPO or Client Settings are disabling that option remember)

The Microsoft Office Click-to-Run Service is responsible for registering and unregistering Office COM application during service startup. Change domain policy or Configuration Manager client settings require explicit Disable selection for Office COM to be successfully deregistered and restore default configuration. Toggling Management of Microsoft 365 Apps for enterprise via Group Policy or Client Settings for Configuration Manager from Enabled to Not Configured is not sufficient.

How do we address this?

In our case, the registry key set during Office 365 installation was preventing Office from getting its updates from the CDN. What compounded the issue was a legacy GPO had tattooed the GPO registry key too that enables the OfficeMgmtCOM. The Office Click 2 Run Service must disable the OfficeMgmtCOM to allow updates to come from the CDN – this is accomplished via the GPO setting (or re-installation of Office with the OfficeMgmtCOM set to False). We have options:-

  1. Push a new Office 365 Config XML to the client where OfficeMgmtCOM is False
  2. Set the GPO to Disable Office 365 Client Management / Management of Microsoft 365 Apps for enterprise
  3. Change/Remove the value from Intune
  4. Assign Office 365 Apps to Windows 10 Devices from Intune
  5. Change the Configuration Manager Client Setting Enable management of the Office 365 Client Agent, for the C2R Co-management workload, to No

Whichever of the above solutions we choose, it is imperative that your GPO or Client Settings are not going to undo your efforts.

We are moving workloads to Intune so want the solution to come from Intune.

We are going to use Option 3 (to show off a new preview feature in Intune). In our environment the clients also have the Client Apps workload moved to Intune so we can now leverage the new Endpoint Analytics Proactive Remediation feature (Preview). We will set the same key that GPO would set to disable OfficeMgmtCOM as this overrides the setting laid down during installation for OfficeMgmtCOM from the config XML

When the GPO or Client Setting is used to disable OfficeMgmtCOM, the COM+ Application is un-registered

Endpoint Analytics Proactive Remediation

Think of it like your traditional CI in Configuration Manager. You can run scripts on a schedule, from Intune, to remediate clients. Its pretty cool stuff! This feature leverages the Intune Management Extension Agent and requires your Client Apps workload to be moved to Intune too. Read more here

We will use one script to remove the registry setting that is preventing our clients from getting Office updates from the Content Delivery Network (CDN) and another for our detection method. The scripts are below:-

Remediation Script

Detection Script

TIP It’s worth pointing out that once this registry setting is changed, the update will not be picked up until the Microsoft Office Click-to-Run Service is restarted. You could modify your remediation script to restart the Service after it changes the registry value ๐Ÿ™‚ (There is also a predefined Proactive Remediation Script in your Tenant that you can use to restart the Office C2R Service if it has stopped – very useful).

1 . Visit > Reports > Endpoint Analytics (Preview)

2 . Under Reports, click Proactive remediations

3 . Click Create Script Package

4 . Enter a Name Disable OfficeMgmtCOM

5 . Click Next

6 . In the Detection Script box, copy and paste in your PowerShell code for the detection logic and in the Remediation Script box copy and paste in your code for the remediation script

7 . Click Next

8 . Assign the Custom Script to your Co-Management Pilot Group for Office Click-to-Run Apps (Remember: Proactive Remediations will only work for co-management clients that also have the workload for Client Apps moved to Intune) . You can adjust the Schedule if you want the remediation check to occur more or less than Once Daily.

9 . Click Next and then Create

10 . Wait for (or force) a Policy Sync on your clients

11 . Monitor the IntuneManagementExtension.log in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs


Moving the co-management workload for Office Click-2-Run Apps did not guarantee that updates automatically came from the CDN for our clients. Some of the clients had the OfficeMgmtCOM registry value set to 0 and others had it set to 1.

Update 05/08/2020

Ensuring that your devices, which are scoped for the Co-Management Click 2 Run Apps workload, do not have any GPO or Client Settings that enable Office MgmtCOM is very important – this is where I suspect others will run into issues. In the blog I used Proactive Remediation to set the registry value to 0 to unregister the Office MgmtCOM app. I have also now created a higher priority Client Setting in ConfigMgr that has Enable management of the Office 365 Client Agent set to No for the clients scoped for the Co-Management Click 2 Run Apps workload – call it a belt and braces approach.

Thanks to Jake @TripleSixSeven for being a listening ear and sounding board #CommunityWin

Manage Office 365 Updates with Configuration Manager

Assign Office 365 Apps to Windows 10 Devices from Intune

Co-Management of Office Click-to-Run apps Workload

Rate this post

5 thoughts on “Office 365 updates stop working when workloads are switched to Intune”

  1. Pingback: Microsoft Edge stops receiving updates after the Windows Update workload is moved to Intune

  2. Hi Ben

    Is it possible to install Office365 Apps from Configuration Manager v2002 during OSD and then install the updates from intune? or is it more of a case of one or the other?


    1. Hi Richard,

      You can deploy anything from a Task Sequence ๐Ÿ™‚

      Once the ConfigMgr client “lights up” after OSD it will move any workloads that have been configured to Intune. So yes this is possible (although strictly speaking Intune doesn’t manage O365 updates – updates are downloaded from the CDN at an interval based on your update channel). Just be sure you don’t enable the OfficeMgmt COM when installing Office otherwise it will only look to ConfigMgr as an update source.

  3. Hi Ben,
    Excellent blog. Completely follow your train of thought on Edge and Office updates.
    One question though, might be silly but im goin to ask it anyways.
    With COnfig Manager, we were able to run tests on office/edge patches in prior and then push them to production.
    This approach above seems like a direct release. Is there a way we can control the office/edge updates, like we do so with WuFB rings ?

    1. Hey, thanks for the feedback.

      You cannot control Edge updates with Update Rings in Intune. You can still deploy Edge Beta for updates every 6 weeks, Dev for updates every Week or Canary for updates daily.
      If you want strict control and release cycles via Intune you could always disable Edge updates and push a new Win32app using versions from here

      You could always use a 3rd party product like PatchMyPC. Even if you move the Updates workload to Intune your clients can still receive 3rd party updates. PatchMyPC includes Edge in their update catalog.

      Hope that helps

Leave a Comment

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.


This site uses Akismet to reduce spam. Learn how your comment data is processed.