ADMX Import Policy imported incorrectly in Intune

[PZan]

trafficstars

I tried searching through open and closed issues, but couldn't find any relevant history so I'm creating an issue on this one.

I might be doing something wrong, but I'm trying to make use of the ADMX Import tool to import OMA-URI based policies for Winget-AutoUpdate, sadly without success. For most of the configurable settings the actual value imported to Intune is simply <enabled /> or <disabled /> when in fact some input is expected. For example, the policy template has a "Updates at Time" setting which, when enabled, presents a dropdown and gives me a selection of hours (01:00 - 24:00). Regardless of my choice, the selection is not actually represented in the policy in Intune, and instead is just <enabled />.

Have I stumbled upon a bug here or am I doing something wrong?

I'm using the Development branch of IntuneManagement, in order to get passed Phishing resistant mfa requirements, not sure if that matters.

Thank you in advance.

[Micke-K]

Hello,

I have not tested the ADMX import in a long time. I need to figure out how I did that. It sounds like a bug though but I know there are some weird issues depending on the destination of the reg keys etc.

Can you give me the exact process you did? ADMX you were using, policy, settings etc.

Cheers!

[PZan]

Thank you for the response! Wasn't expecting such quick feedback :)

Steps to reproduce:

1. Downloaded and extract the #latest admx files from Romanitho/Winget-AutoUpdate
2. Run .\Start-IntuneManagement.ps1 via console
3. Sign in via top right corner using PassKey (selecting 'only for this app' when asked)
4. Click Views > Intune Tools
5. Load ADMX and then Load ADML
6. I configured more or less every configureable setting.
   • It seems as if the issue is specifically with the dropdown menu based settings, i.e.
     • UpdatesAtTime
     • UpdatesInterval
     • NotificationLevel
   • Other text field- or radio button based settings seems to be imported correctly
7. In the Import tab I also configure every field (Custom Profile Name, Description, ADMX Policy File Name, Ingest ADMX file ✅. The last field, "OMA-URI Name for the ADMX Ingestion", I've tried both left blank and customized.

[Micke-K]

Thank you for this!

I'll see if I can have a look at it on the weekend or so. I just arrived in Sweden for my son's graduation so it's a bit chaotic at the moment.

Cheers!

[PZan]

Thank you and no stress! Enjoy the Scandinavian "heatwave" while it lasts ;)

[Micke-K]

Hello,

Sorry for long delay. I did not touch my computer during my holiday.

Can you try the Development branch. I found an issue with the drop downs.

I did get the strings as expected for the whitelist/blacklist.

Let me know if any of the others doesn't work. Could be similar issues.

Cheers!

[PZan]

Thank you for putting in the effort! I have verified that the custom policy appears to have been imported properly, but not if it's assigning correctly on an endpoint yet. I'll keep you updated!

[PZan]

I've been traveling the last week or so, so sorry for the late response, but I'm still encountering some errors, I'm working on settings for Winget AutoUpdate and Dell Command Update

• The ADMX ingestion for both Winget AutoUpdate and Dell Command Update generates error 0x87d1fde8 (Remediation failed). I have supplied custom names to my templates, WAU_2.6.1 and CommandUpdate_5.5.0, not sure if this could be the culprit to this error, but I will try and remove special chars and see if this makes any difference.
• For Dell Command Update there's two other settings named Update Settings and Installation Deferral which also generates error 0x87d1fde8. These settings both have multiple lines inside of them, but are somewhat different from eachother where Update Settings has six different drop down menus for selecting various update settings (obviously) and Installation Deferral has four text fields where you configure various defferal settings, by entering a number between 1-99 for some rows or 1-9 for others.

Does this make sense and is there a chance you could figure out a fix?

[Micke-K]

Hello,

• Does it set the value in registry? I've seen where it shows remediation failed error in Intune but it actually set the value in the registry.
• I'll see if I can find the Dell admx and test it.

Any reason you do this via admx in the tool instead of importing the ADMX in Intune and configure the policies there? I created the ADMX Tool before Intune supported 3rd party ADMX files.

Cheers!

[PZan]

I have struggled with replacing imported templates files when they were in use, and just generally felt it was sort of half baked from MS, so I figured this method should be more reliable and the way to go! Do you have a better way to go about it?

I will check the registry after the weekend.

[Micke-K]

Hello,

I had a look at this. It looks like Dell Client Device Manager.ADMX file is depending on Dell.ADMX.

<policyNamespaces>
    <target prefix="ClientDeviceManager" namespace="Dell.Policies.ClientDeviceManager" />
    <using namespace="Dell.Policies" prefix="Dell" />
</policyNamespaces>

Dell.Policies is defined in the Dell.ADMX and it is the root category for the other ADMX files e.g. it is the Dell root folder in GPMC. It could be that Windows then can't use the Dell Client Device Manager.ADMX file since there is a reference for a missing category and therefore can't verify value. I have seen issues with other ADMX files where I had to manually update and remove references before they imported successfully.

You could try adding a Custom OMA-URI policy for the Dell.ADMX as well without any settings in it. This should, in theory, deploy the admx file to the client but not sure if it fixes the issue.

Another thing you could try is the attached ADMX/ADML. I manually updated the ADMX and removed the dependency and created the Root category in the same file. I also added the Dell string to the ADML file. I did not test it myself so test it in a test environment before trying it out in production.

Cheers!

Dell_v2.zip