Enrolling Devices in Intune

Chapter 2:

Enrolling Devices in Intune

Using MDM Autoenrollment for Windows 10 Hybrid Devices
So if you’re not quite at the stage where you want to put all your eggs in the Azure basket, you’re probably like the majority in that you want to be able to control your devices using Intune, but you still need / want them to be domain joined for various reasons.

To that end then you need to implement MDM enrolment. Luckily Windows 10 from build 1703 has the ability to Autoenroll in Intune so long as it’s given the right nudges.

Since 1607 Windows 10 devices are automatically joined to an Azure AD that’s linked to your on-premise AD, so that natural progression for that is to allow the automatic enrolment of those devices into intune.

The following Microsoft article gives the relevant information pertaining to this;

https://docs.microsoft.com/en-gb/azure/active-directory/device-management-hybrid-azuread-joined-devices-setup

This Microsoft article gives the required chapter and verse on how to create a GPO for MDM auto enrolment;
https://docs.microsoft.com/en-us/windows/client-management/mdm/enroll-a-windows-10-device-automatically-using-group-policy

If you don’t have the facilities to configure this or you just don’t want to you can enrol windows 10 devices manually. The following Microsoft article provides the relevant information on doing this;

https://docs.microsoft.com/en-us/intune-user-help/enroll-your-w10-phone-or-w10-pc-windows

Having trouble with Hybrid Joined Devices not Auto Enrolling in Intune?

So I’ve had a least two so far (and we’ve by no means done a complete roll out) of machines that are domain and azure joined i.e. hybrid joined. They appear in Azure as such and to all intents and purposes there’s no reason why they’re not auto-enrolling and yet it seems they’re not.

Checking the scheduled task (under Microsoft, Windows, Enterprise Mgmt) shows the task that should be doing the enrolment has failed, with an error code that even uncle Google doesn’t seem to recognise, namely 0x80070088 (though there have been others).

Checking under the specific event log for this process (Application & Sevices Logs, Microsoft, Windows, DeviceManagement-Enterprise-Diagnostics-Provider, Admin) shows the same error code being generated everytime the script tries to run.

When I check the detail of this error I see the following "explanation"

Auto MDM Enroll: Failed (The system tried to delete the JOIN of a drive that is not joined.)

Doing some digging and some lateral Google searching I get a hint of an explanation that basically even though Azure thinks the device is joined the reality is that it isn’t….

This is because the machine was previously Azure joined / Intune enrolled since we’re testing lots of functionality. The Error message is simply telling me that the Delete process of the device hasn’t completed yet in Azure.

You can either wait for it to finish sorting itself out or, on advice from our friends at Microsoft, remove the machine from both the on-premise domain and manually deleted it from Azure (if it is still there).

It’s worth mentioning that even if you remove a machine from the on-premise domain the computer record doesn’t get removed immediately, it still exists as a disabled object which when AD sync kicks in replicates that over to Azure as a disabled object, so it’s important to make sure you tidy up your AD too.

Now it’s time to re-join the on-premise domain, but first I’m going to remove the old auto-enrolment scheduled task just so I have crossed all my T’s and dotted all my I’s.

So I setup the machine, joined it to the domain and logged in with my fc.spare user account as opposed to my admin account. I did a GUPDATE /Force to drag the MDM enrolment policy down and rebooted the machine again logging back in with the fc.spare user account.

I can see the machine is already in Azure, so now I just have to wait for it to appear in Intune.
How long I have to wait for is anyone’s guess, on current form it’ll be about an hour before the enrolment successfully completes. Before that it’ll fail in it’s attempts on multiple occasions before finally giving in and enrolling the device.

What is an “unknown Win32 Error code: 0x8018002b”? Is this an example of AI? Did the machine make it up? If so why doesn’t it know what it means?

This is something that Microsoft should do a bit of work on I think.

It’s really difficult to understand why this is such an “analogue” process. The process itself is like this clearly by design since the scheduled task set up to initiate enrolment is designed to run every 5 minutes until it’s successful, indicating, to me at the very least, that they know it will fail and that being the case you’d have thought they’d know why and that being the case they’d have done something to fix it!

Finally after what seems like an eternity (well it’s about an hour actually), we start getting some successes in the log….

And finally an entry in Intune…. Note though there’s no user principal name, so it isn’t completely enrolled yet…

And now it is….

So it would seem that sometimes the auto enrolment process for domain joined machines can be a bit tortuous but this is apparently by design. There may be perfectly sensible reasons for this but I don’t know what they are at the moment… I’ll update when / if I ever find out.