I’ve gone and written another small script for you to consume! I call it FixMyADMX and it will try to fix some common errors in ADMX/ADML files you might find lying around. To achieve this, it will scan your ADMX and ADML and repair things like comboBoxes.
GitHub to FixMyADMX
Why Martin, why are you touching legacy?
Sometimes you have to dig through the mud to find the diamonds. I ran into this problem with some of my clients and there wasn’t really a good solution other than digging into the XML that is ADMX and ADML and figuring out why some things weren’t working as intended. Some information I could find on Rudy Ooms blog, so I suggest you read that as well. I also have to mention Adam Gross work on the Citrix.admx and his talk between him and me about this topic – really appreciate it! My script doesn’t solve all of the problems mentioned in Rudy’s blog, as they look like edge cases at the moment.
And honorable mention goes to Citrix. Citrix, can you please fix your policy files now? I even wrote a script for you to do it automatically! No excuse left! If you read on, you’ll even learn why your policy isn’t working with Intune.
<comboBox> element is not supported
As the official documentation states: “Currently, the combo box setting type isn’t supported”. Short reminder, a <comboBox> is basically a <textBox> element but with suggestions that show up when you click on the text field. That’s all, the script will just replace the elements from a combo box to a text box. Yes, you will lose the suggestions. No, it doesn’t make sense to use the <defaultvalue> because it can’t be assumed, that a suggestions is a default.
Schrödingers explainText and why it can’t be missing from the ADMX
I had to dig a little for this one, and it’s probably what drove most people crazy trying to import the latest Citrix files as well. The official documentation for a policy element (I couldn’t find a more recent version of this) claims that the explain attribute is not required. However, Intune will give you an error that reads ‘Object Reference not set to an instance of an object’ if it’s missing. FixMyADMX attempts to fix this by adding the attribute and the required string to the ADML. A default string (see screenshot above) is used instead.
Everybody needs windows.admx – or do they
This is not a problem that can be blamed on any one vendor; looking around, I found many examples of this problem that is not one. You know how you’re wasting that one slot with the “windows.admx” so you can upload all those other GPO files? As it turns out, most of the time that is not necessary. On top of each .admx you can define namespaces, which is close to importing things from other files. This gives you the ability to call other definitions (for example) and you would do this by adding “windows:”. ADMX files having this is probably a relic from the past, or because they all started out using the same example from Microsoft. More likely this was added, back when everybody wanted to have a parentCategory (see next paragraph).
TL;DR: If your ADMX file doesn’t contain the words “Windows:”, you don’t need windows.admx in Intune. This script will safely remove the unused namespace.
Fixing real windows: references
You might be here because I’m actually telling you to visit this blog if you find a legitimate use of the “Windows:” reference (it’s actually one of the log entries). Or you’re just interested in what’s going on, so here goes. First, open your ADMX file and search for all “windows:” references. Once you have a list, come back here and I’ll list a few examples and how to fix them. Depending on the feedback, I may include these fixes in future versions of FixMyADMX.
If you have something like <parentCategory ref="windows:System"/> (example from the LAPS.admx). This would tell the policy engine to put “LAPS” under “System” and that’s exactly where it shows up.
You can fix this by changing the parent category to something else. However, it needs to exist (see screenshot for a fixed example)
The second most common usage is <supportedOn ref="windows:SUPPORTED_Windows_10_0_NOSERVER"/>, which is used as a way to describe the supportability of a setting to different operating systems.
You can fix this by adding a <supportedOn> list below the <resources> element. You can then use those as a ref in the supportedOn element of each policy element. The displayName attribute must refer to an existing string in the ADML. You can use the Add-explainText function to get an example of how to add a string using PowerShell. See screenshot for an example.
In very rare cases you might see <reference ref="windows:SUPPORTED_Windows7To2k"/> used (e.g. inetres.admx). I have only ever seen this used in one file so far. They basically use it in a <definitions> list in a <definition> element to be used as a template.
I haven’t tested how to fix this yet. However, it might not be fixable, unless you also define the reference which imho doesn’t make sense.
Conclusion
I really hope you enjoy FixMyADMX and that it will save you some time. I firmly believe that it can help you understand what might be blocking you right now. It can also shed some light on ADMX created by admins. I’ve opened a thread on the “explainText” topic – a link will be added as soon as I’m done writing. explainText ist a required attribute of <policy> · Issue #4094 · MicrosoftDocs/memdocs (github.com)