The Microsoft Office Click-to-Run Service is responsible for registering and unregistering Office COM application during service startup. * 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 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. The policy registry key on the client had also been set HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\office\16.0\common\officeupdate OfficeMgmtCOM = 1 GPO Setting: Computer Configuration\Administrative Templates\Microsoft Office 2016 (Machine)\Updates – Office 365 Client Management / Management of Microsoft 365 Apps for enterprise 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 * This will set the following registry key on the client HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\Configuration OfficeMgmtCOM = True We did this by setting the OfficeMgmtCOM value to True. When we installed Office 365 initially, we specified in our Config XML that we wanted Configuration Manager to handle the Office updates.
Q: How were our clients getting the GPOOfficeMgmtCOM set to 1 ? If you have not already used CMPivot, go and read the docs here How? Office365ProPlusConfigurations | where ( GPOOfficeMgmtCOM = '1' ) Queue CMPivot – To get an idea of the client configurations to look for anomalies, we used CMPivot. 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. Read more about co-management capabilities here We checked the clients CoManagementHandler.log and could see they were receiving the correct co-management capabilities.Ĭapability 211 indicates the following workloads have been moved to Intune:. We started by checking the co-management capabilities were correct. 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.
AUTOMATICALLY UPDATE MICROSOFT OFFICE INSTALL
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. 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 Previously, O365 had been deployed by Configuration Manager and updates were also being managed by Configuration Manager. In the following environment, the workload had been moved to Intune for specific clients only.
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. 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.
0 kommentar(er)
