none
Issue with ADMX deployment RRS feed

  • Question

  • Hello,

    I have a created a device configuration package that ingests the office16.admx file and applies some user class settings that:

    • Disable autosave for word/excel/powerpoint
    • Disables the file types popup

    When I deploy these to a fresh test VM they apply without issue, though the status remains 'pending' in InTune. When I attempt to add or change a setting in this configuration profile the changes are not pushed out. Attempts to send another config profile with a different ADMX ingestion have no effect.

    If I revert the test VM and target both packages to the system, both will apply without issue. It seems like it takes whatever configuration is applied initially and then no more.

    Are there any documents available which dictate best practices for ADMX ingestion & deployments? Does it matter if..

    • the ADMX ingestion is in the same configuration profile as the OMA-URI settings?
    • ./Device and ./User settings are deployed in the same configuration profile?
    • deployments target users or devices (DDG)
    • an active deployment has 'pending' - will this block subsequent profiles being applied until it receives a status from the device?

    I have read through just about every article I can find, gone through the debug logs etc but cannot find what the issue is.

    TL;DR: If I have 5 profiles and apply all 5 to my fresh test VM, settings of all 5 will apply. If I revert and ensure on profiles 1 & 2 have been assigned they will apply. Assigning profiles 3, 4 & 5 to the same VM will result in nothing happening.

    Please help :)

    Dan

    Thursday, May 16, 2019 5:59 AM

Answers

All replies

  • just putting this out there as a possible alternative:

    https://docs.microsoft.com/en-us/deployoffice/overview-office-cloud-policy-service


    Carl Barrett | Web: carlbarrett.uk | Twitter: @CarlBarrett

    • Marked as answer by _-Dan-_ Thursday, May 16, 2019 9:10 AM
    Thursday, May 16, 2019 7:50 AM
  • Hi Carl,

    Big fan, thanks for your reply. That looks excellent and I will look at that asap.

    In typical fashion about an hour after I posted this I found the culprit. Deploying the office16.admx file causes every other deployment to stall. Note that it doesn't fail, I can see the reg settings populate etc but any subsequent profile or setting gets blocked somehow.

    I have removed the vsto section, and I did add a policy to disable the File Types popup. I'll do a bit more testing out of curiosity to see at what point it breaks but wow, super happy to be closer to an answer.

    I have a full procmon trace and debug event logs that I'll check out, if I can find the exact thing I'll post back.

    Thanks again for that suggestion, I wish I had known about that a week ago.

    Cheers,

    Dan

    Thursday, May 16, 2019 8:09 AM
  • Did a bit more testing, ingesting the office16.admx file breaks something (perhaps just in my environment, I don't know). No more profiles can be rolled out after the office16.admx file has been ingested (by all accounts, successfully).


    Thursday, May 16, 2019 9:10 AM
  • I am attempting this very same activity and cannot seem to apply the AutoSave default (to off). The test VMs get the admx installed but stuck in pending. Also not clear if the custom OMA-URI AT configu profile applies or not; user still appear to have AutoSave on by default on new documents.

    ./User/Vendor/MSFT/Policy/Config/Office16~Policy~L_MicrosoftOfficeSystem~L_AutoSave/L-autoSaveDefaultOffExcel
    ./User/Vendor/MSFT/Policy/Config/Office16~Policy~L_MicrosoftOfficeSystem~L_AutoSave/L-autoSaveDefaultOffPowerPoint
    ./User/Vendor/MSFT/Policy/Config/Office16~Policy~L_MicrosoftOfficeSystem~L_AutoSave/L-autoSaveDefaultOffWord

    Is it totally necessary to use the alternative Office 365 Client Configuration Service?


    The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral


    • Edited by icelava Thursday, June 4, 2020 7:33 PM
    Thursday, June 4, 2020 9:59 AM
  • Did a bit more testing, ingesting the office16.admx file breaks something (perhaps just in my environment, I don't know). No more profiles can be rolled out after the office16.admx file has been ingested (by all accounts, successfully).

    Does that mean office16.admx completely corrupts Intune's control over enrolled devices? Forever not being able to determine if any other type of new configuration profile succeeds or fails?

    That seems to be the very case with our affected computers; Intune cannot push any new/updated config profiles to them anymore. This is absolutely, insidiously, messed up. Working with Microsoft tech support to resolve this.


    The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral


    • Edited by icelava Monday, June 8, 2020 8:43 AM update
    Thursday, June 4, 2020 10:02 AM

  • That seems to be the very case with our affected computers; Intune cannot push any new/updated config profiles to them anymore. This is absolutely, insidiously, messed up. Working with Microsoft tech support to resolve this.

    While Intune tech support does not want to take ownership of the problem - because the documentation, while linking and recommending the "offending" Office ADMX-ingestion article, still is not their problem if we choose to follow those essentially "3rd-party" instructions - I went about manual cleansing of the Registry to see if I could break the affected Windows computers out of their MDM coma.

    Thankfully, it appears that removing the follow keys, and subsequently triggering a manual sync with MDM will get Windows to "snap out of it".

    • Every HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\AdmxDefault\<PROVIDER ID>\Office16~Poilcy~ key
    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\AdmxInstalled\<PROVIDER ID>\Office16


    The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral

    Monday, June 8, 2020 4:43 PM
  • I am attempting this very same activity and cannot seem to apply the AutoSave default (to off). The test VMs get the admx installed but stuck in pending. Also not clear if the custom OMA-URI AT configu profile applies or not; user still appear to have AutoSave on by default on new documents.

    ./User/Vendor/MSFT/Policy/Config/Office16~Policy~L_MicrosoftOfficeSystem~L_AutoSave/L-autoSaveDefaultOffExcel
    ./User/Vendor/MSFT/Policy/Config/Office16~Policy~L_MicrosoftOfficeSystem~L_AutoSave/L-autoSaveDefaultOffPowerPoint
    ./User/Vendor/MSFT/Policy/Config/Office16~Policy~L_MicrosoftOfficeSystem~L_AutoSave/L-autoSaveDefaultOffWord

    Is it totally necessary to use the alternative Office 365 Client Configuration Service?

    As mentioned in above separate comment, configuring Office the raw ADMX-ingestion and OMA-URI way is no longer compatible with existing versions of Windows (or maybe also Office). In fact, it is downright dangerous and must be avoided as it can jolly well perpetual Windows into a state of MDM-sync limbo. Since the ATs are now build into Intune, use the AT configuration profile type instead.

    The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral


    • Edited by icelava Monday, June 8, 2020 4:47 PM
    Monday, June 8, 2020 4:46 PM