It seems some days become worthy of a blog post, if only due to the coincidental collision of research and customer questions.  Today is one of those days.  I started off the day looking at the behavior of a Windows enrollment restriction that can be configured in Intune to block the enrollment of personal devices (those that aren’t registered with Autopilot, aren’t set up using a provisioning package, etc.).  That can be configured like so:

Once you do that, you can try to “Add a work account” to a Windows 10 device (assuming you’ve configured automatic MDM enrollment in Azure AD):

Click to “Connect”, then type in your e-mail address (UPN):

Then your password:

And you’ll see an error:

That’s one of the better MDM enrollment errors, as it gives you an error code and a reasonable text explanation.

Now let’s try a different restriction: only allowing certain Windows 10 versions.  In this case, I specified that only version 10.0.19042.0 to version 10.0.19042.0 would be accepted – basically, only a version that I wasn’t using (I was using 19041, a.k.a. Windows 10 2004).  If you go through the same process as above, you’ll see a less friendly error at the end:

Same error code, different dialog.  Go figure.  At least you can look in the event log (DeviceManagement-Enterprise-Diagnostics-Provider) to see the detailed message that Intune provided back to the client:

Very clear.  But there is one detail that’s worth calling out:  My device was running version 10.0.19041.261.  See what the event above says?  It says 10.0.19041.0.  So, that means that the patch level of the OS isn’t being provided, so it’s not possible to create an enrollment restriction that looks for a minimum patch level.  (You can use Conditional Access for things like that, post-enrollment.)

A general suggestion:  Any time you see an error code that starts with “8018” (meaning “MDM”), check that event log to see what details were provided by Intune, beyond just the error code.  The reason text is often useful.