Allow ADMX templates to be updated
As of today, there is no convenient way to update ADMX templates, once they have been initially pushed to our Win10 devices.
Example : MS offers a new ADMX file for Office2016, or Citrix company releases a new ADMX file for Receiver app.
So the custom OMA-URI we use at initial stage, is sth like "./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/Office2016/Policy/Office2016Admx".
I naively thought I could replace the existing ADMX file that I uploaded to Intune with a new one, and the backend will push the new template to clients, replacing all the nice registry structure under HKEYLOCALMACHINE\SOFTWARE\Microsoft\PolicyManager\AdmxDefault.
While the MS documentation about ADMX stuff in Policy CSP (https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-configuration-service-provider), says that majority of sub-categories support "Delete" operation, especially "Policy/ConfigOperations/ADMXInstall" section, the other small section called "Policy/ConfigOperations/ADMXInstall/AppName/Policy/UniqueID" says that Delete is NOT supported.
This key difference has been highlighted to me by the Intune support, so credits to them (ticket 118092119061205)... The end result is that when you need to update an ADMX that was already pushed to a device, with a newer version, you cannot do that because it isn't supported, and you end up with a nice error message in the Event Log.
So please support properly "Delete" operation for the ADMX templates.
Were you even able to successfully ingest the stock office16.admx schema, and subsequently configure the policies?
I've ingested other 3rd-party ADMXs and configured them easily before (e.g. Lenovo Vantage; Google Chrome), but today I naively ingested Microsoft's own supplied office16.admx and even though the target computers' Registry do show up in the AdmxDefault and AdmxInstalled keys, they appear stuck perpetually at pending status in Intune. I could not push another config profile to set the Office policies (also stuck pending).
Not only that, but it seems other config profiles of other types also cannot deploy. Was office16.admx a land mine waiting to be stepped on?
Olav Rønnestad Birkeland commented
I too thought I could update the ADMX, that would be the logical thing to allow.
Microsoft should have though of this and solved this scenario. Yet a poorly designed Intune feature IMHO.
Yep concur with this... the only workaround is to change the name of the OMA-URI from .../Office16ADMX to .../Office16ADMX2.
This will then apply new settings added to the string... however, it does not remove existing settings if they are no longer listed. Not sure what is does to existing settings that remain, which might have had GPO settings changed.
Also, what are the implications with the new Administrative Templates features which was discussed at Ignite: https://oliverkieselbach.com/2018/09/29/ignite-2018-my-wrap-up/
If I implement the Office 2016 ADMX ingestion, will the settings clash with the new feature update?
Seems very beta all of this... the only way I can truly update an ADMX policy today is to delete the keys listed under:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\AdmxDefault and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\Admxinstalled