O365 updates via SCCM

Geo BE 96 Reputation points


We are upgrading our O365 build from 1902 to 2002 but some SCCM clients doesn't see any O365 update.

Here is our configuration:
SCCM Current branch 2006
O365 1902 semi-annual channel installed in task sequence (OfficeMgmtCOM to true in the XML)
O365 2002 semi-annual channel updates pushed with software updates
O365 management activated in the client settings
No GPO to manage O365 updates
No co-management
All our computers are staged with the same TS.

The first thing I noticed was that these clients were displayed as unmanaged in the O365 client management dashboard of SCCM altough the value of OfficeMgmtCom in the database and in the registry are correct.
I also noticed that the clients seeing the updates didn't have the key "officeupdate" in the registry (HKLM\SOFTWARE\Policies\Microsoft\office\16.0\common\officeupdate).
The clients NOT seeing the updates did have the value of OfficeMgmtCom equal to 1 in the registry.

On the other hand, in the SCCM database (v_GS_OFFICE365PROPLUSCONFIGUR), I noticed that the clients had this values:

  • working clients: GPOOfficeMgmtCOM0 equal to NULL, OfficeMgmt equal to "true" and CCMManaged0 equal to "UpdateNotify Object"
  • not working clients: GPOOfficeMgmtCOM0 equals to 1, OfficeMgmt equal to "true" and CCMMAnaged0 equal to NULL

When I changed the wmi value of CCMManaged0 of a non working (and unmanaged) device from NULL to "UpdateNotify Object", this computer appears as managed in the O365 client management dashboard after the hardware inventory but still no update available...

When I look in the UpdateDeployment.log of a non working client, I see these lines:
CEvalO365ManagementTask::Execute() UpdatesDeploymentAgent 09-12-20 16:22:00 7512 (0x1D58)
OnO365ManageOptionChange - Turning on to enable CCM to manage O365 client updates. UpdatesDeploymentAgent 09-12-20 16:22:00 7512 (0x1D58)
SwitchO365Management - bIsManagedByCCM = [false], bIsTurnOn = [true], need to switch. UpdatesDeploymentAgent 09-12-20 16:22:00 7512 (0x1D58)
Turning on to enable CCM to manage O365 updates... UpdatesDeploymentAgent 09-12-20 16:22:00 7512 (0x1D58)
Stopped the service 'ClickToRunSvc' successfully UpdatesDeploymentAgent 09-12-20 16:22:00 7512 (0x1D58)
EvaluateO365Management - SwitchO365Management (on) returned with 0x0 UpdatesDeploymentAgent 09-12-20 16:22:10 7512 (0x1D58)

The only difference with a working client is this:
bIsManagedByCCM = [false]
A working client has the value true and doesn't need to restart the service ClickToRunSvc, but I didn't find anything about this bIsManagedBySCCM and where this value come from...

When I run a compliance reporting of the update on the non working computer, the update is marked as not required.

The registry keys of AudienceId, CDNBaseURL and UpdateChannel are correct for the semi-annual channel.

What I have already tried without success:

  • Delete the computer in SCCM, coming back with the AD Discovery
  • Uninstall and reinstall of the client
  • Uninstall and reinstall of Office365
  • O365 repair
  • Wmi repair
  • the more strange: when I re-stage the computer (advertised TS as we are in confinement, no F12), the problem is still present!

Could someone help us with all that? I didn't know what more to look for...

Thanks a lot!

Microsoft Configuration Manager Updates
Microsoft Configuration Manager Updates
Microsoft Configuration Manager: An integrated solution for for managing large groups of personal computers and servers.Updates: Broadly released fixes addressing specific issue(s) or related bug(s). Updates may also include new or modified features (i.e. changing default behavior).
960 questions
Microsoft Configuration Manager
{count} votes

Accepted answer
  1. Geo BE 96 Reputation points

    Thanks @Amandayou-MSFT !

    We had another computer with another problem: the download of update failed because of class not registered...

    When I searched for this problem on internet, they talk about the com application OfficeC2RCom.

    Thus I looked on the computer without any update if the OfficeC2RCom application was correct.

    First, when I try to open the component service>COM+ Applications, it says that it could not communicate with the Microsoft Distributed Transaction Coordinator.
    I further looked at this problem and it seems that some people have this problem with some driver. In my case (on the Dell Latitude 5500), I uninstall the WIFI adapter and his driver. Then I could open the Com+ Applications in the component services...
    (This also explain why the problem was always present when I re-stage the computer.)

    I find that in the OfficeC2RCom application, the components "UpdateNotify.Object.1" and "UpdateNotify.Object.2" where not present and the classID HKEY_CLASSES_ROOT\CLSID{B7F1785F-D69B-46F1-92FC-D2DE9C994F13} was not present in the registry.

    After some research, I found this site who explained the problem and give a really small script to repair the OfficeC2RCom application.

    And miraculously, after applying this script, rebooting the computer, launching an Hardware Inventory and a Software Update Inventory Cycle, the update was available in software center!!!
    For info, the value of bIsManagedByCCM in the UpdatesDeployment.log was turned to true after that!

    So, in summary, this is what I did:

    • I had a problem to open the COM+ Applications in the component services => I found that this was caused by the WIFI driver of the computer, so I uninstalled it
    • When I could open the Com+ Applications, I saw that the two UpdateNotify.Object components were not present => I found this site and apply the script

    Finally, it was very easy when you find where the problem comes from...

    I hope this will help a lot of people!! Now I have to investigate if all our Dell Latitude 5500 have the same problem!!

3 additional answers

Sort by: Most helpful
  1. Amandayou-MSFT 11,046 Reputation points

    Hi @Geo BE

    When I run a compliance reporting of the update on the non working computer, the update is marked as not required.

    -->We could check if the update is required again by UpdatesStore.log. UpdateStore.log would record updates as missing if they are required. If it is not required or has been installed by client, there is no record in this log.


    Besides, what is the update is required by clients which not work in the compliance reporting, we could try to install the update to check if there is still something wrong with client. If installed, the client is ok so that we could exclude the possibility that there is a problem with the client.

    If the response is helpful, please click "Accept Answer" and upvote it.
    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

    0 comments No comments

  2. Geo BE 96 Reputation points

    Hi @Amandayou-MSFT ,

    Thank you for your response.

    Effectively, there is nothing about the O365 updates in the UpdateStore.log.

    The problem only affects the O365 updates. I deployed the updates of O365 1902, 1908 and 2002 and they are all marked as not required. The windows updates and the application deployment work perfectly...

    That's why I thought it was a problem with the channel, but everything seems to be good...

    Do you know something about this "bIsManagedByCCM = [false]" entry in the UpdateDeployment.log? I didn't find any documentation about that.


    0 comments No comments

  3. Geo BE 96 Reputation points


    I looked at the software update reporting "Software Updates - A Compliance > Compliance 5 - Specific computer" for a working computer and a non-working computer.
    I put the screenshots of the results:

    Working computer

    Non-working computer

    As you can see, the channel is not the same and the non working computer only show outdated updates... And there is no required Office 365 Client updates for the non working computer

    It's the same TS, the same packages, the same GPO, the same clients settings between this 2 computers... I really don't understand...