Troubleshooting
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.
In Part 2 and Part 3 we looked at constructing the OMA-URI path and value from scratch so that we can begin to pull any setting we want out of the ADMX.
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...
Do You Has Feature, Bro?
This is not very applicable for third-party ADMXs, however, Microsoft has a default set of Policy CSP backed settings. We looked at this back in Part 2 of this series to better understand how to construct our OMA-URI path.
If you look into some of these settings in more detail, such as "NoLogOff", you'll see that it is only applicable to Windows Enterprise edition. Which means if you try to apply this setting to Windows 10 Pro, it will fail.
Furthermore, double check your Windows version. Some settings are simply not available for certain Windows versions.
So, before you drive yourself crazy, make sure the setting you're trying to manage is supported by:
Windows Edition
User or Device scope
Windows Version
User Licensing
Make Love, Not Conflicts
Some times, your device may report back in MEM as a "conflict". This isn't an error but usually means there is another setting that is also being applied that Intune can't override. Generally, this is simply an admin error on how the settings/policies are configured.
In this case, double check your work, and make sure the policy logic works. If you recall back to the GPO days, there is an order to which policies are applied called "Link Order". Intune works similarly, but it's not as clear cut. There are some additional details on this page on which policy takes precedence.
When In Doubt - Contact Microsoft for Support
...and when nothing you've tried works, open that support call.
If you recall my "Rejected by Licensing" error from the Event Viewer example above, my PC was on Windows 10 Business, which is absolutely supported by the CSP according to the Microsoft documentation, and I had confirmed the version of Windows is supported.
After toiling and testing for 2 days, I was convinced this wasn't me (or if it was, someone smarter needed to tell me where I f'ed up), so I contacted Microsoft.
I spent nearly two months back and forth with Microsoft with all levels of engineering, and they eventually determined and filed this as bug.
While you should perform basic (and advanced troubleshooting) as the diligent admin that you are, some times, it's not you, it's them. How does the saying go? "If you could say it like Hallmark, you wouldn't need Hallmark"? In this case, if you could be Microsoft, you wouldn't need Microsoft. The support feature is there to be used. So use it when you feel you've run your course.
If your company happens to be engaged with external consultants you trust (like me, for example), you can also reach out to them. If you're not a decision maker in your organization, obviously check with the boss so you're not incurring costs they're not aware of.
That concludes our 4 part series on Intune OMA-URI! I hope you've found this useful. If you did, share with your admin friends.
If you need some additional support on Endpoint Management, we're very good at this stuff. So contact us to see if we can help support your business goals.
The content on this web site is provided for general information purposes only and does not constitute professional advice. Users of this web site are advised to seek specific technical advice by contacting SiFr or their own IT resource regarding any specific technical issues. SiFr does not warrant or guarantee the quality, accuracy or completeness of any information on this web site. The articles published on this web site are current as of their original date of publication, but should not be relied upon as accurate, timely or fit for any particular purpose.
This web site may contain links to third party web sites. Links are provided for convenience only and SiFr does not endorse the information contained in linked web sites nor guarantee its accuracy, timeliness or fitness for a particular purpose.
SiFr is a Microsoft Partner. However, we do not have an affiliate relationship with Microsoft and we do not receive any monetary benefit in commissions or otherwise for clients choosing Microsoft services. We aim to offer unbiased advice based on our own experience with the services.