Forum Discussion
Office bypassing Target Version set by Intune
Ok so I was managing my Microsoft patches through Intune. A while back Microsoft sent out this message…. https://docs.microsoft.com/en-us/DeployOffice/other/devices-updating-monthly-enterprise-chann...
manoth_msft
Microsoft
MicrosoftHi Steve,
there is more to it. For troubleshooting I would check these locations in the following order:
1) HKLM\SOFTWARE\Policies\Microsoft\cloud\office\16.0\Common\officeupdate > IgnoreGPO
If this key is 1, then the values in the same location are the winning ones, set by Servicing Profile / config.office.com.
If this key is 0, Servicing Profiles / config.office.com is not controlling updates on this box and any potentially existing values in this key are ignored.
2) If No 1 is not the winner, Office checks these locations in the following order for the winning setting:
1st Priority : GPO "UpdatePath" - HKLM\software\policies\microsoft\office\16.0\common\officeupdate!updatepath
2nd Priority : GPO "UpdateChannel" - HKLM\software\policies\microsoft\office\16.0\common\officeupdate!updatebranch
3rd Priority : "UpdateURL" or UpdatePath="\\Server\Share" HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration
*4th Priority: UnmanagedUpdateURL - HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration\UnmanagedUpdateURL
5th Priority : CDNBaseURL - HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration\CDNBaseUrl
3) If No 1 & 2 yield an update channel different from the installed one, I would check if the Microsoft 365 Apps are deployed through Intune using the native app mode and have a different update channel set. In this case Intune will detect a configuration drift (e.g. after Profiles moved the device to channel A, but the Intune app is configured to be on Channel B) and trigger the setup engine to move back to the configured channel. Check this video for an explanation of how Intune can handle the Microsoft 365 Apps: https://youtu.be/fA8lcnRXmkI
Hope this helps!
there is more to it. For troubleshooting I would check these locations in the following order:
1) HKLM\SOFTWARE\Policies\Microsoft\cloud\office\16.0\Common\officeupdate > IgnoreGPO
If this key is 1, then the values in the same location are the winning ones, set by Servicing Profile / config.office.com.
If this key is 0, Servicing Profiles / config.office.com is not controlling updates on this box and any potentially existing values in this key are ignored.
2) If No 1 is not the winner, Office checks these locations in the following order for the winning setting:
1st Priority : GPO "UpdatePath" - HKLM\software\policies\microsoft\office\16.0\common\officeupdate!updatepath
2nd Priority : GPO "UpdateChannel" - HKLM\software\policies\microsoft\office\16.0\common\officeupdate!updatebranch
3rd Priority : "UpdateURL" or UpdatePath="\\Server\Share" HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration
*4th Priority: UnmanagedUpdateURL - HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration\UnmanagedUpdateURL
5th Priority : CDNBaseURL - HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration\CDNBaseUrl
3) If No 1 & 2 yield an update channel different from the installed one, I would check if the Microsoft 365 Apps are deployed through Intune using the native app mode and have a different update channel set. In this case Intune will detect a configuration drift (e.g. after Profiles moved the device to channel A, but the Intune app is configured to be on Channel B) and trigger the setup engine to move back to the configured channel. Check this video for an explanation of how Intune can handle the Microsoft 365 Apps: https://youtu.be/fA8lcnRXmkI
Hope this helps!
This is SUPER useful information. I have been pulling my hair out for over a week with about 20 PCs that rolled back (or maybe never updated) from 2103 (?!?!) This just answered my question, seems that a super old GPO wrote a that build to the registry of these PCs. But there is no GPO doing that now so this was hard to figure out.
Quick follow up, do you know if there is a setting that sets the IgnoreGPO key? Or just push the key itself?
Quick follow up, do you know if there is a setting that sets the IgnoreGPO key? Or just push the key itself?
- manoth_msft
brenzphi If you want to offboard just a subset of devices, then I would recommend excluding those using an Entra group: https://learn.microsoft.com/en-us/microsoft-365-apps/admin-center/cloud-update#exclude-groups.
For fully disabling Cloud Update, check out https://learn.microsoft.com/en-us/microsoft-365-apps/admin-center/cloud-update#cloud-update-review-deactivation.
After excluding devices or disabling the profile, device will automatically be offboarded (ignoreGPO=0) on next check-in. Please allow at least 24h for processing.
Note: Using the Channel Change feature in Inventory will enable the cloud update profiles again, so if you go for disabling the whole profile, omit using this feature to prevent the profile from being re-enabled and onboarding devices again.
- Thanks for insides.
So how to disable Cloud Update and revert back to GPO Management aka. `IgnoreGPO = 0` ? - Martin, again this info is GREAT! But just to pick your brain a bit, I have a few PCs listed as managed in the config.office.com console but the ignoregpo key is set to 0. Any idea why this would be? We still have duplicate AD computers in our directory since we are in Hybrid, so i was thinking maybe config.office.com is adding the unused dupe computer account but the computers are actively communicating with Config.office.com. And it's only a subset of computers. I may try to update the key manually on a test machine, but I would love any insight you might have on this.
- manoth_msftThe IgnoreGPO key is set by the servicing profile based on if a device is in scope of profiles or not (see https://learn.microsoft.com/en-us/deployoffice/fieldnotes/adopt-servicing-profiles#how-a-servicing-profile-is-applied-to-a-device; the sentence "These devices will also receive commands that instruct the local Office Update Engine to ignore commands that are coming from other management solutions" is referring to IgnoreGPO being set.)
We do not recommend to set the IgnoreGPO manually. I would rather nuke the targetversion keys if those are left-overs from GPOs which are no longer applied.
