Exploring Hybrid Azure AD Join with a Provisioning Package
In testing a provisioning package deployment, I found out that you can apply the PPKG to a domain-joined device so that it seemingly becomes Hybrid Azure AD Joined. Although I’m not exactly sure if the process is actually useful, it is certainly interesting, so I thought I’d write out this blog post. This is not supported since provisioning packages for Azure Active Directory Joining are meant to be used during OOBE, not on a domain joined device.
Let’s start by looking at the device itself, and running dsregcmd /status to verify that it is Domain Joined:

If we scroll further down, you can see that it fails the AD Connectivity Test, so it’s not completing the Hybrid Join process:

And in Azure AD we can verify that it is pending a Hybrid Join, but hasn’t completed it:

Great! So let’s create a provisioning package, using Windows Configuration Designer (which you can download from the Microsoft Store app):

Once that’s downloaded, we’ll create a new project:

The most important step will be going to Account Management, selecting Enroll in Azure AD, and getting a Bulk Token:

Once you have a bulk token, select Finish and then click Switch to advanced editor in the bottom left. We need to switch to the advanced editor to remove any extra settings other than the bulk token.

Here I’ll delete the DNSComputerName:

And then the HideOobe setting:

Once we only see Authority and BPRT under Azure, we’re ready to export the package:

Then we just need to copy the RunTime Provisioning Package (.ppkg) file in the exported directory to our device:

Once the PPKG is on the device, double click it to kick off the process:


Unfortunately PPKGs don’t really report any progress, but you can check under Settings > Accounts > Access work or school > Add or remove a provisioning package to see if it applied:

And we should also now see under Access work or school the ability to check Info and sync with Intune:


So what happens if we run dsregcmd /status again?

It’s reporting as Hybrid Azure AD Joined! And we know that because according to the Docs, showing both AzureAdJoined and DomainJoined qualifies the device to be Hybrid Azure AD Joined:

But… if we check Azure AD, we see that the Hybrid Azure AD Join record is actually still pending – and there’s now a new record for the Azure AD Joined device:

If we look at the device in Intune it does show up, but with no primary users since we used the provisioning package:

So what gives? Michael Niehaus has written about Hybrid Azure AD Join a ton – and he describes the process more as Azure AD registering a Domain-joined device, rather than actually Azure AD joining it (great blog post here). One of the key points he makes is that you can’t log in to a Hybrid AADJ device using Azure AD , you can only log in using AD.
If we try to log in using the Azure AD creds of a test user…


…we see that we can’t. So despite there now being a record of an Azure AD Joined device in MEM/AAD, we can confirm that this device isn’t actually Azure AD Joined.
Locally it appears like it’s Hybrid Joined, but if Azure Active Directory isn’t reporting it as such, what is it really? After letting this device sit for a few weeks, the Hybrid AAD record in AAD never updated out of pending, so we can at least say with some confidence that the PPKG didn’t really help with that process.
Comment your thoughts below! Until then, happy exploring! 🕵️‍♂️
Hi, did you ever got an answer to this? I am dealing with situation how to bulk enroll kiosk devices that are joined to local AD and basically I have two options. Use Enroll into MDM only option in settings and login with DEM account (but that actually creates yet another object in AAD and its not fully managable, IME does not install) or do this HAAD join with DEM account that will enroll device into Intune and shows up in AAD as AD joined… Either option does not seems to be good one..
Never really found an answer – the device stayed as AADJ in the portal and never updated the pending hybrid record. Unfortunately I think the best route forward for your kiosk devices is planning a migration to AADJ+MDM only. Otherwise the DEM+HAADJ puts you in an unsupported state, at least according to this Docs article.
To make it hybrid join, So before we apply the provisioning package it has to be joined to domain manually right? Then apply the provisioning package.
Correct – must be domain joined beforehand.
Hi,
Was there ever any answer to this? In a very similar scenario.
Thanks in advance
I didn’t investigate further – but the device was stuck in pending and not properly hybrid joined, never. HAADJ is supposed to register the device in AAD rather than attempt to join the device (which is what the PPKG does). So although Windows was reporting it joined to both, Azure AD had no idea what to do with the device.
It sounds like there’s a misunderstanding of what should happen with Hybrid Azure AD Join. Even once the device is registered in Azure AD, you can’t log on to Windows via Azure AD; you can only log in using Active Directory (hence you need connectivity to a domain controller).
Thanks Michael, appreciate the correction! Updated that section.