Welcome back folks! We will continue our deep dive of Intune ADMX backed policies by looking at how to construct OMA-URI settings from scratch.
In Part 1 of this multi-part series, we looked at what is OMA-URI, What is SyncML, and how to "ingest" a third party ADMX. If you haven't read it, I would definitely suggest you begin there.
Alright. You’ve done parts 1 through 3, hit that deploy button to your pilot groups and you get the dreaded error instead of sweet sweet success. Now what? Inevitable in any admin's career is troubleshooting.
In this part, I will go over common Intune OMA-URI troubleshooting steps that have allowed me to solve all the Intune OMA-URI problems I've encountered. Let's begin!
Delays that Cause False Negative
This is somewhat dumb, but what you see in the Endpoint Manager web console isn’t really live, per se. This isn't exactly an error but it may give you a false negative, sending you on an unnecessary troubleshooting path.
Most frequently, what happens is you've deployed a setting, you know it failed. You modify the setting and deploy again, hit the fresh button in MEM and it still shows failed. So you think your new settings aren't working.
All I can say in this regard is, if you're applying settings in fairly rapid successions, do not trust the MEM web console. If you want to know for sure, hop on the test machine you're attempting to deploy the setting to instead.
Delays That Are Just... Delays
If you're a traditional AD admin and are used to working with the fairly predictable GPOs, you'll find SyncML and Intune somewhat half-baked and infuriating. Take this policy for example:
Beyond that, machines don't immediately check-in with Intune. There are (usually) always ways of forcing it by clicking that sync button, but just be aware there are delays.
All the Typos
This is the most frequent problem of all the OMA-URI I've troubleshooted (troubleshot?). In IT we frequently joke about "user error", and for OMA-URIs, typos would be it. Frankly, I can only stare at plain text in Notepad for so long before I go cross-eyed, and I make these mistakes all the time. So much so I've complied a list! Isn't that handy?
Slashes - Pay attention to the slashes (they’re forward slashes, not back slashes)
Quote Marks - Pay attention to the quotes. They have to be the " quote and not “. This is especially important if you are copy/pasting your OMA-URI from the internet, instead of following my article and using Notepad! (*gasp* *shocked* *shame you*). The quote symbol is notorious for tripping up admins. When in doubt, Notepad is your best friend.
Letter Case - Pay attention to letter cases. The OMA-URI Path is case sensitive so be very careful.
User or Device - Make sure the scope you're apply the setting to is appropriate.
Who Needs Friend When You Have Event Viewer?
I don't know how many people actually rely on Event Viewer for troubleshooting, but personally, I find the chattiness of Windows OS particularly helpful. To me, the error message in the MEM web console is basically junk, and serves no real purpose but to say "Go check Event Viewer please."
For all Intune MDM related events, you can find it under:
Application and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider
Look for the errors and actually read the event message.
For example - "Policy is rejected by licensing". This may be meaningless before you start the Google machine, but it more or less says exactly what it needs to say, and that is "Your current license doesn't support this policy you're trying to set."
Isolate the Issue
This is not an Intune specific troubleshooting tip, but every good troubleshooter knows to isolate the issue. Is the setting you're trying to apply actually wrong? Or does the problem only impact a subset of users? Or machines?
There's nothing more infuriating or crazy making than double, triple... quintuple checking all your settings and swear you've done everything right but your test machine still errors out. Such was the case with the "Policy is rejected by licensing" error shown above...(more on that later).
When the same OMA-URI setting was deployed to a different machine, it worked just fine. Which tells me all my OMA-URI settings were correct. The error existed with that specific machine. In the case of the policy above, it seemed like the machine's Windows license didn't actually support the setting.
Which bring me to...