Techy Stuff

Hybrid Azure AD Join with Auto-enrolment into Intune for MDM

Recently there have been a number of new and interesting challenges that I am sure a lot of us in the IT sector have been faced with, mainly due to the COVID-19 epidemic.

We had a plan in place over the next 12 months to move 150 of our hard wired workstations over to laptops. The idea was to ensure they would be provisioned into Intune and Azure AD so that we would be able to retain some level of control even when those devices go offsite.

Usually, we would be able to implement a solution like this a little slower, ensuring we would go down the usual routes of planning, testing, piloting and receiving feedback before fully releasing a change like this. This project was immediately brought forward though, and instead of having months, we now have a matter of weeks to implement Intune so that it is functional.

Now, I love Azure, but at the time of writing, I am certainly no expert, and with the rate of which Microsoft change functionality, it meant that most of the documentation I was reading did not match what I saw on my screen. Even though this article may help a few people, I very much expect it to be out of date in about 3 hours time, but here goes anyway…

So a little perspective for my setup. I already use some Azure services, O365 for Email, and I have Azure AD Connect setup using the pass-through auth method. So users are already synchronising to the cloud without a problem.

Great! So, my next step was to look into Azure Active Directory, and under Devices I noticed that all of my on-prem devices were listed with the Join Type as Hybrid Azure AD Joined, and their Registered status was simply set to Pending.

I did a bit of testing, spooled up a few VMs and tried to get some new devices added to Azure AD, there was a mixture of success and fails here but in the end, after hours of testing and tinkering and after a few small, large brandy’s, here is what I did.

Configure Hybrid Azure Active Directory Join in Azure AD Connect

I ended up following this article to begin with from Microsoft.

Basically going through this process seems to cause Azure AD Connect to create some new entries in the Configuration partition of AD. After you finish the steps above, you can actually go check this by opening ADSI Edit and navigation to: Configuration > Services > Device Registration Configuration
You should actually see your tenant ID in here. I believe this essentially tells the client which tenant it needs to contact in order to register successfully with Azure.

Check over Initial Intune and Azure AD Configuration

I then followed step 1, 2 and 3 from the below link:

The above basically takes you through the steps to ensure your Azure AD and Intune are configured correctly to allow computers to join.

Configure some Group Policies

You’ll then need to connect to your on-prem Group Policy Management window. I suggest making a test OU here and ensuring you scope this to some test machines before rolling this out fully. Regardless, do the following:

Navigate to: Computer Configuration > Policies > Administrative Templates > Windows Components > MDM

Set Disable MDM Enrollment to Disabled. In true Microsoft fashion, disabling it, enables it. By default it is enabled anyway, but I seemed to have more look by specifically disabling this policy.

Set Enable Automatic MDM Enrollment using default Azure AD Credentials to Enabled and make sure the drop down is set to User Credential. If you don’t see the drop down, you may need to download the latest ADMX Templates from Microsoft which at the time of writing appear to be 1909.

Test it…

And now lets actually try and make this work…

I started by spooling up a Windows 10 (Version 2004) VM – Enterprise edition, and setting it up manually as a standalone device until I reached the desktop. I did not domain it or anything else at this stage. (Usually we use WDS/MDT for deployment in our environment, but since this was just a test, I just installed from a Win10 ISO.)

From the desktop, the first thing I did was manually add the device to the on-prem domain.

Once the computer appeared in AD, I then moved the computer object to an OU that was scoped to receive the GPO’s that we setup above. I ran gpupdate /force on the machine and restarted it just for good measure.

So far… so good…

So next, I went onto my server that runs Azure AD Connect, and I ran a Delta Sync to force Azure AD to update a little quicker. If you don’t want to do this, you can run this yourself from your Azure AD Connect server by opening a powershell window and just typing
Start-ADSyncSyncCycle -PolicyType Delta
Give it a minute to run and then continue.

Head over to Azure and go to: Azure AD Connect > Devices. From here you should be able to lookup your device. Success! Mine was listed and looked similar to this:

You can see it has added. The Join type is Hybrid Azure AD Joined which is what I would have expected, and now it is just a case of getting it into Intune for MDM.

Back to the VM, I signed in using my Azure AD creds, making sure that my user has permission to add devices to Azure AD, Intune, and also that it has the correct licensing which includes MDM assigned to it.

After your first login, not much seems to change, but check Azure after a few mins and the Registered field changes from “Pending” to a date/time.

From here, there are a few interesting things happening and places to note. The first being the Event Viewer.

So open Event Viewer and go to: Application and Service Logs > Microsoft > Windows > User Device Registration > Admin
In here you will see quite a lot of information, hopefully mostly informational. But you’ll be able to see how it is registering itself and the actions this is performing.

I believe the reason it registers itself is because as soon as the VM is joined to AD, a scheduled Task enables itself and runs in an attempt to attempt to register in Azure AD. The task always exists I believe, but it is disabled until the device becomes domain joined. For those who are interested, the scheduled task is here:
Task Scheduler Library > Microsoft > Windows > Workplace Join
I’ve highlighted it in the below image. It seems to trigger at the point of any logon to the system.

I then gave the device another reboot, signed back in as the same user and this time the activity field had been populated too.

This is where my configuration may differ very slightly from yours. I then received a popup telling me that my configuration had changed, it asked me to login again.

I logged in, approving my sign in via my phone since I have MFA enabled, and then everything seemed to return to normal.

It was only after I did the above that it appeared to do something with Intune. You can confirm this again with some more Scheduled tasks that are created by navigation to:
Task Scheduler Library > Microsoft > Windows > Enterprise Mgmt > [random numbers]
You will see in here it seems to create a task that enrols the device for you.

I’m not entirely sure what the random numbers are, I thought it may be the Azure tenant ID, or the device ID in Azure perhaps, but it isn’t, but I have blanked it out anyway just in case.

I then returned to Azure AD one more time, found the device, and under MDM, it now shows as managed by Intune.

And that is it… My device is in Azure AD, and managed by Intune. This seems so straight forward, when it works…

I confirmed MDM was working by setting up a few basic policies for desktop and login backgrounds, playing with some blob storage too in order to store the images, and it works.

Troubleshooting and Problems

I would like to express that getting this up to actual function correctly has taken probably a day or two worth of digging, trialing and testing. I hit a number if problems before managing to get this to work. Existing policies preventing this from working, firewall and proxy issues, misconfigured MDM settings and more! The above in the end seemed to work for me, and I hope that perhaps it will help others.

I’ve tried to include some of the possible place that you can go for troubleshooting above, the main places being ADSI Edit, Task Scheduled and Event Viewer, all of which should hopefully give some good information to assist you in resolving any problems you may face during the setup.

I am certainly no expert, I’m not saying my method is fully correct, but it seems to work for me, we’re still literally at the beginning of the road here for Intune, and there is much more for me to get my head around.

So my next step is policies, restrictions, conditional access, BYOD, and of course Autopilot configuration. Bring it on! 🙂

I hope this helped…

The cloud is wonderful when it works. I hope that this helped a few people at least try to work with Azure. I’m certainly no expert, I’m still a baby when it comes to cloud, but I believe sharing experiences like this are important in the hope that it may save a few people a few hours tinkering and hitting dead ends before finding a method that works. So thank you for reading, have a wonderful day! 🙂