Resolving Persistent Errors in Custom MEM Configuration Profiles

Introduction

Recently on a Windows 10 MEM (you know, Intune) engagement, I needed to rename self-enrolled non-auto pilot devices in-line with the company naming standards. This can be done a bunch of different ways, but where possible you want to do this natively using a built in Intune Windows 10 configuration or a custom setting using an OMA-URI. Device renames for Windows 10 are only available during Autopilot setup natively in Intune, but after reading the handy dandy Configuration Service Provider Reference, I found the setting could be deployed using the ./Device/Vendor/MSFT/Accounts/Domain/ComputerName OMA-URI., so that's what I used. And that's when my eye started to twitch.

But, that works. Right?

It sure does! I created a custom configuration profile assigned to the appropriate group with the following OMA-URI settings

If we take a glance at the computer itself, we can see the configuration has successfully deployed - 

OK, so why is your eye twitching?

Seemingly more apt questions might be "Why are you using headings as questions?" Or "Why are you having this conversation with yourself?", but I'll ignore the underside of that iceberg for now. The reason my eye twitching was a big fat ERROR in the Intune console at the configuration profile, which you can see below. One of those helpful "there was an error" kind of errors. Now, when you are deploying a nice green fields Intune environment like I was in this instance, having a persistent error splattered on your console just feels dirty, so it had to be fixed. Sadly, the fix was also eye-twitch inducing.

How did you fix it?

I kind of didn't. I can't fix that particular issue, because it is an underlying issue with how Intune deals with CSP's that don't have a "Get" function. When perusing the CSP reference, every single OMA-URI is going to give you a list of supported operations which will be some or all of Add, Get, Replace or Delete. The OMA-URI we're concerned with here supports only the "Add" operation. What this means for Intune is that it can shove my config out into the void, but never read it back into the console to confirm something useful happened on the client-side, so helpfully, we get an error instead.

So now what?

Well, I just told you I didn't fix it and it couldn't be fixed, but actually I kind of did and it kind of can. I fixed it by not using a custom configuration, and instead, I wrote and deployed a simple PowerShell script which did the rename for me. Sure, this is kind of the same thing, but at least now I don't get errors in the console. At the time this was really the only option I had available to me, so it was the best approach. If my eye no longer twitched at this point, it's because I had closed it with gaffer tape.

Then Windows 10 2004 fixed it!

And at last, I think we've arrived at the only point I've been trying to make: It's now natively fixed in Windows 10 2004. If you (but really, I) in the future face this problem, we can now fix it natively. Rather than deploying the custom config I mentioned above, We can now deploy this guy:

And now we have native configuration profiles, no errors in the console, and the eye twitching has almost completely ceased! There is, of course, the requirement that the devices you deploy to are all 2004, which may not be the case in the short term for your environment, but if you, like me, do not like looking at ugly errors or ugly workarounds, the answer for this particular issue lies in 2004.

There are of course many other CSP's you could deploy via Intune which would cause the same problem for the same reason so it would be a nice addition to the console to choose to suppress errors for OMA-URI's that do not support Get operations. Or perhaps for the data on those nodes to be fed back to Intune another way, but sadly that's not the case at present. In any case, I hope this blog helps someone out there understand why they might be getting a similar persistent error in Intune. So at least you too can understand why your eye is twitching.