Troubleshooting group policy ingestion with Intune

Microsoft EM+S and Intune
1

Intune provide capability for deploy policies that are no displayed via the GUI by ingesting and applying group policy.

This works by first installing the group policy ADMX on the machine and then applying the changes specified in ADMX.

However I’ve come across a number of issues while ingesting ADMX files and had to figure out the trobuleshooting steps.

Policy ingestion steps and the problem

Here is an example of Office ADMX ingestion and some issues I’ve run across the way.

Microsoft doc on ingestion below

First step is to download and extract the Office ADMX file
https://www.microsoft.com/en-us/download/details.aspx?id=49030

Second step is to create a custom Windows 10 profile

image
image495×682 22.1 KB

With the following configuration

image
image941×325 12.3 KB

OMA-URI: ./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/Office16/Policy/Office16Policy

Open office16.admx and copy the content into the value field.
Save and assign the policy.

After the policy assignment deployment has failed

image
image1428×299 47.7 KB

Troubleshooting steps

Intune policy pushes are recorded in the following event log
Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin

Looking at the event log I’ve noticed the following error

image
image2217×472 207 KB

Looks like there is a problem with software\policies\microsoft\vtso registry key
Quick Google search (Support Tip: Ingesting Office ADMX-Backed policies using Microsoft Intune - Microsoft Community Hub) reveals that the following keys cannot be modified in this way

  • software\policies\microsoft\vtso
  • software\policies\Microsoft

Upon finding this I’ve had to modify the value in Intune policy and remove the following keys

<policy name="L_EnableMinimizeVbaResigning" class="User" displayName="$(string.L_MinimizeVbaResigning)" explainText="$(string.L_MinimizeVbaResigningExplain)" key="software\policies\microsoft\vba\security" valueName="minimizevbaresign">
  <parentCategory ref="L_SecuritySettings" />
  <supportedOn ref="windows:SUPPORTED_Windows7" />
  <enabledValue>
    <decimal value="1" />
  </enabledValue>
  <disabledValue>
    <decimal value="0" />
  </disabledValue>
</policy>
<policy name="L_DisableVSTOLegacy1Or2" class="User" displayName="$(string.L_VSTOLegacy1Or2)" explainText="$(string.L_VSTOLegacy1Or2Explain)" key="software\policies\microsoft\vsto" valueName="vstolegacy1or2disable">
  <parentCategory ref="L_SecuritySettings" />
  <supportedOn ref="windows:SUPPORTED_Windows7" />
  <enabledValue>
    <decimal value="1" />
  </enabledValue>
  <disabledValue>
    <decimal value="0" />
  </disabledValue>
</policy>

Once this was done the ADMX has successfully installed

2

Hi,

A very nice article. Could you please provide information on disabling autoplay on windows 10 using the ADMX ingestion and OMA-URI method.

3

Instead of deploying a CSP policy you should look at applying MDM security baselines. You can disable autoplay via the baselines.

1 Like
4

Thank a lot. Will use the baseline as recommended.

5

I’m trying to ingest office16.admx for our enrolled computers too, and it doesn’t fail but gets stuck in Intune perpetually as pending status.

Exactly how many policies need to be manually trimmed off office16.admx? I see you recommend deleting L_EnableMinimizeVbaResigning but its path software\policies\microsoft\vba\security is supposed to be allowed?

I am unsure whether it’s Intune side or Windows client side that’s gone corrupt. No clear indication how to resolve/cleanse the problem.

https://social.technet.microsoft.com/Forums/en-US/c87e8844-1c3e-4494-b311-070244c6dc27/issue-with-admx-deployment?forum=microsoftintuneprod

6

Is there a reason why you’re trying to injest the office ADMX rather then use Administrative Templates?

Most of the office policy can be applied through the Administrative Templates.

I had a quick look and seems that both settings you’re trying to configure are available in the Administrative Template.

image
image1263×531 35.9 KB

image
image1456×558 39.6 KB

7

I was looking at the wrong section - Computer Configuration - did not find the AutoSave policies and thought they were incomplete so I download the .admx files as per

Only later on tracing through the office16.admx contents did I see they were user scope policies. (but subsequent assignment to device group or user group had no effect)

And now Intune and target computers appear to be in some limbo state and not able to push new/updated config profiles down. I am currently engaging with Microsoft support to fix this.

8

On a side path, I tried to define the Office app policies via Office 365 Client Configuration Service

https://config.office.com/officeSettings/officepolicies

Under the hood, I do not know if it’s the very same Intune engine puhsing the policies, but they don’t take effect either.

9

So apparently to snap the client Windows computers out of their sync coma, had to manually weed out from Registry

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

This technique of manually ingesting Office .admx files is not only no longer compatible, but outright insidiously dangerous as it can put client Windows computers out of the policy/update loop.

Trigger a manual sync with MDM and its regular communication can now proceed as before and other configuration profiles can push down again.

10

When you setup an “Administrative Template” configuration policy in Intune it installs the office ADMX files on the local machine, perhaps there is a configuration clash of the same ADMX file being installed from multiple sources

Edit: Some of the environments I have access to are deploying office ADMX successfully and devices are communicating with Intune. Can you share your configuration? It may be specific to your config or other resources that are being deployed alongside Office ADMX.

11

Intune’s inherent Office 2016 AT end up as office16v2 and office16v2~Policy~ keys in the Registry, so I don’t think they directly conflict. They can co-exist given the “namespace”, but of course, if the target Windows client has the old Office16 keys regardless of other configs and ATs, then the MDM client stack stalls and won’t respond to MDM again.

I am currently sorting this out with Microsoft to help them discover why Windows 10 is brought to its knees by such a simple action. And it was an additive action, as opposed to a reductive/destructive action.