That’s the short title. The long title should really be something like this:
The first day in the life of a Hybrid Azure AD Joined device has lasting implications on the rest of the device’s life, at least from an Intune management perspective.
And with that, we have both a blog topic and the most common challenge that customers have with Windows Autopilot and user-driven Hybrid Azure AD Join deployments. You might get it to work once, but then for some reason you can’t get it to work again, you get frustrated and curse at Microsoft, and give up – for a while. Eventually, maybe you figure out that it works for new devices, so great, lets treat all devices like new devices: remove then from Azure AD, Intune, Autopilot, maybe even AD, and then re-add them to Windows Autopilot. And presto, it works again. Once. Before you have to repeat the whole process again.
I’ve talked about this basic problem in past blogs, but given that this is still the #1 question with Windows Autopilot, it’s worth digging in a little deeper. Let’s start from the beginning, with a brand new device being added to Windows Autopilot. After you do that, you’ll see that there’s a Windows Autopilot device, and an associated Azure AD device object. Because the device has not yet enrolled in Intune, there is no Intune object. Because the device has never joined Azure AD, the Azure AD device object is disabled and named using the serial number of the device.
I put the device into a group that has a Hybrid Azure AD Join profile associated with it, and that same group is used to assign the Domain Join device configuration profile that specifies what AD domain and OU the device should use when joining AD. Once the Windows Autopilot profile assignment is complete (that takes a few minutes after adding the device to the group), the device is ready to deploy.
The device will boot up and ask for Azure AD credentials. These will be used to to enroll the device into Intune. Now you’ll see the Windows Autopilot device links to an Intune object:
Notice that the device name is still the Windows default random name. If you checked the Azure AD device, you would see that it is still disabled. The name will change a little later in the process:
Intune will then generate an offline domain join blob (using the Intune Connector for Active Directory) and send that to the client PC. It will install that blob and reboot. At that point, the device will pick up the new name. Eventually Intune will see that new name.
After a period of time (up to 30 minutes), the newly-created Active Directory device will sync from AD into Azure AD. At that point you can see two devices in Azure AD for the machine, one that is Azure AD Joined and the other Hybrid Azure AD Joined.
This is the point where things get interesting: As soon as Intune sees the Hybrid Azure AD Join device object, it will start using that one for device-targeted policies. And more importantly, it will stop using the Azure AD device object for policy targeting at the same time. So remember the group that you placed that Azure AD device into, and the policies that are targeted to that device? Now they are no longer applicable. So if you were to reset, reimage, or otherwise redeploy the device from scratch, you’ll find that it will only use the policies targeted to the Hybrid Azure AD Join device object.
Want some proof? Follow the link from the Windows Autopilot device to the Intune device and see what policies are targeted to the device. Also, notice that the Windows Autopilot device still points to the Azure AD device object, not the Hybrid Azure AD device.
The most important device configuration profile for the Hybrid Azure AD Join process is the Domain Join profile. If the device being deployed does not have a Domain Join profile assigned to it, it will fail – the device will time out and eventually display an 80070774 error, indicating that it can’t contact a domain controller. That’s kind of deceptive, because it doesn’t even know what domain controller it needs to contact, because it never joined Active Directory in the first place. So how do you work around that? If you have a simple environment (like me) you can just target the Domain Join device configuration profile to “All devices” – then which device Intune uses doesn’t matter, all are in scope. If you have a more complex environment, you might have a dynamic group that you are using, maybe “All Autopilot devices.” You can modify that query to select both objects by looking for any devices with ZTDID set, as well as any devices whose name starts with your AD device naming prefix. In my case, my devices are all named starting with “AD-” so I can use a query like this:
Note that the simple editor at the top isn’t always good at editing a query that has “-any _” in it, so you might need to edit the text manually by clicking the Edit link toward the bottom right.
Either way, we need to make sure that the Domain Join profile, as well as any other device-targeted profiles, is targeted to both the original Azure AD device (for the initial deployment scenario) as well as the new Hybrid Azure AD Join device (for subsequent deployments – with a new object created each time).
Longer term, our goal is to have Azure AD merge the two device objects together – that avoids all sorts of confusion, and ensures that group-based targeting isn’t affected by the flip from the Azure AD device object to the Hybrid Azure AD device object.
Share this:
Categories: Windows Autopilot
Out of Office Hours 
and if we have multiple profiles to be used for different machines then to use the “group” tag is the way to go? Or is it “lost” after the replacement of the synced device? I cannot say this is straightforward but hey, this is in development.. I would like to go into production with autopilot hybrid so need heavy testing and deep understanding before users start having questions and problems. thanks!
LikeLiked by 1 person
The group tag will always be associated with the Azure AD device object and never with the Hybrid Azure AD device object. If you have policies that you need to follow with both objects (for the reasons described in the article), you could use different device naming prefixes and separate Domain Join profiles tied to each group tag, with a dynamic group that selects the right group tag or the right name prefix.
LikeLike
Hi Michael,
Great article !
“The group tag will always be associated with the Azure AD device object and never with the Hybrid Azure AD device object.”
> This is not what i observed, in Graph Explorer we see the “OrderID” on both objects.
I agree that setting the group tag in Autopilot only update the associated Azure AD device object. But during Autopilot the new Hybrid AAD object inherits the group tag.
I noticed that sometime a device could run into a specific issue / state. After a device wipe its Azure AD object display name is no longer updated during next oobe (as well as its activity date), and the device is well connected to its Hybrid AAD object, and working fine. It results in Autopilot to a device linked to 2 differents name for the AAD & Intune objects. Did you encounter this kind of issue ?
LikeLike
Interesting, I can see that too (with the same ZTDID applied to the AAD device and the Hybrid AAD device). That’s not the way it used to be. I’ll check on that. I have seen the names out of sync, but I’ve never checked close enough to understand why. I’ll see if I can find a pattern.
LikeLike
I did not find how to respond to your last comment Michael… i hope it would be still readable 🙂
“That’s not the way it used to be.”
We use Group Tag for One AutoPilot profile assignment & two Domain Join Configurations. Group tag is convenient in replacement of purchase order ID, as some Azure AD devices were deleted (due to a out of sync bug with the AP device & ZTID lost… during multiples & repetitive tests).
Eventually If you have a way to reinject purchase order id i’ll take it !
But i think it would be great to keep the Group Tag for all the device lifetime… i’m not a big fan of targeting device by theirs names and a ‘startswith’ !
LikeLike
Hi Michael, Indeed another great article! I’ve been following all your articles on Autopilot and White glove. They’ve been immensely helpful. For some reason though, I’m unable to post a comment on any of them. Even here, I wanted to reply to your last response to Jean but there’s no reply option next to that post. :p
I have a lot of questions specific to specific posts and would like to ask those there. Is there a way I can do that?
Question: I’m working with a customer on Autopilot with White glove. The Windows 10 build being used is 1909 or higher. We’ll soon begin our testing on their test (Lenovo) machines. We’ll be using a script to rename the machine to a particular org format (3 digit region code + serial number). Any pointers to any issues that we might encounter while doing this?
-Vishal
LikeLike
Renaming AAD-joined devices isn’t too hard. But AD-joined devices are harder – you have to do it in the context of an account that can update the AD computer object, otherwise you’l break the domain trust.
LikeLike
Hey Mike, what is the recommend approach to switch/convert an existing Hybrid Azure AD joined device to Azure AD join? Is it as simple as changing the the AD Group so that the device is now in the AD Group that is Assigned to the Azure AD joined Deployment Profile and no longer in the AD Group that is Assigned to the Hybrid Azure AD joined Deployment Profile? What interval of time does Intune re-evaluate Deployment Profiles, if it even does?
Thanks,
Calip
LikeLike
My recommendation: Reset or reimage the device. There’s no clean way to do it in place, due to various ACLs in place on the file system and in the registry, hence the need to start over to avoid remnants from the AD join interfering with ongoing proper behavior of the device.
LikeLike
Yesterday I tried converting laptop from Hybrid join to Azure AD join by just switching the group tag on Autopilot profile and reset Win10, but it ended up just to broken Hybrid join with error 80070774. The dynamic device group based on group tag didn’t update correctly. I ended up deleting the device from autopilot and re-adding the the csv. Should this work like this or should’ve I delete old objects first? Your previous comments on group tag associations may explain why this didn’t work.
LikeLike
The 80070774 error typically indicates that no Domain Join profile was targeted (one of the main topics in this blog post).
LikeLike
Appreciate your recommendation! This is what we were thinking as well.
LikeLiked by 1 person
Thank you for your articles
In the case where we have a Hybrid Azure joined device, does this allow us to deploy GPO’s and Security Groups from our on prem Domain Controller ?
I’m trying to work through a scenario where we will have Intune but still allow access to our NTFS File Servers ( Security Permissions + Drive Mapping GPO )
LikeLike
A Hybrid AAD Joined device is first and foremost joined to Active Directory, so yes, it receives GPOs and other settings from AD. It is also registered in AAD so that you get additional benefits (e.g. automatic sign-on to cloud resources).
Today, the Autopilot Hybrid AAD Join scenario needs to be performed on-prem, but we are working on ways to do that over the internet using VPN.
LikeLike
Hi Michael, Hybrid White Glove, the device will always use the default ESP screen I guess as no user is assigned.. The ESP screen that it grabs at the white glove stage then seems to be used when the user logs in despite another being targetted at the user. Any ideas if this will be fixed at some point?
LikeLike
We are working on improvements to the ESP targeting to let you target both users and devices. Right now, you can only target users (or “all users and devices” as a final catch-all).
LikeLike
Thanks Michael for replying.
LikeLike
Mike thanks for another nice thread.
we are struggling to achieve the Autopilot hybrid AD join, all the pre reqs in place and i did have one successful enrolment where device joined Azure as well as On-Prem and thats all.
now enrolment get error straight after when entered the login credentials at OOBE screen. Error 80004005 which is a server error (enrolment rejected).
some devices go back to login page after entered the login credentials (initially shows login page with company branding but once use the login creds then it goes back to standard Microsoft login page (without the company branding)
we got 1809 devices but i have tried 1903 / 1909 with no success.
LikeLike
There should be an event log entry in the Enterprise Device Management log that says why the enrollment was rejected. It could be because it hasn’t been enabled for Windows devices, that there are OS version restrictions in place, no license assigned, etc.
LikeLike
A fun read since I just migrated ~300 users to Windows 10. It took a crazy month to get the Hybrid Join setup and various apps/policies/etc configured and then the bumpy ride began and we rolled out a mix of new and re-deployed machines in a little over one month. 1903 seemed to be buggy with Autopilot and much of what you describe above, we learned as machines had issues here and there. 2 identical machines, one would work, one would fail. Anyhow since 1909 the builds seem a little better and at least White glove seems to be working now.
I have a question, when doing a reset of a machine, we began the practice of deleting the local AD computer account which of course removes the Hybrid-AD account the next time ADConnect syncs. Is there any plan to have an Intune reset of a W10 machine clean up old computer accounts in local AD? It would seem logical since the Intune Connector has the ability to create computer accounts with the blob request. Why can’t it delete local AD accounts when a computer reset is initiated. Please let me know if I’m missing something here. When resetting iPhones in Intune, there’s no cleanup to do. Resetting W10 seems to be missing that one piece. Especially using the auto-created names for computer names it’s impossible to clean up later if you don’t clean it when you reset.
LikeLike
We’re still looking at options. At present, the AD account isn’t the biggest of our concerns 🙂
LikeLike
Hello Michael, looking for advise to deploy apps and settings based on OS language using dynamic device groups. For example Office 365 with proofing tools and restricted groups. I couldn’t find an attribute in azure ad dynamic groups for device OS language?
Little bit more on the issue. Restricted groups matches the group name string to inject the users so ‘Administrators’ local group in a Win10 will be called differently when the OS language is set to non-English. Manually assigning device groups is exhausting and leads to error due to the lack of keeping up with inventory. A dynamic group based on OS language will be a saver. Do you have ideas on this one?
Thanks, Noor
LikeLike
Hi Micheal, we are struggling to achieve the Autopilot hybrid AD join on 1909 Education. On the ESP page, setup gets stuck at Joining your organizations network (working on it) and then it errors out due to exceeded time limit. My understanding is that at this step, device is waiting for AD / AAD sync for device id. So we even tried manually force syncing AAD / AD sync but that does not help either. The domain join is successful and we can see the object in AD. On ESP page when I press CTRL + ALT + Del and launch task Scheduler, I see all the task under WS-join is disabled. When I check the user device registration logs, I see that WS-join did got executed but it failed to join AAD with event id 204 as it is not able to find that object (The device object by the given id ) in ADD and after that it disables the WS-join tasks and changes the registry. One interesting thing is if we enable the Automatic-Device-Join task and run it manually, the Joining your organizations network step immediately gets completed successfully and rest of the setup goes well. We are seeing similar behavior when we test Automatic device registration GPO on existing Windows 1909 devices where task gets disabled and when we run manually it registers successfully . Any help would be appreciated. As such we do plan to open a case with Microsoft if we are able to resolve this by mid next week.
LikeLike
Sorry, I’m behind on comments. Opening a case would be a good idea, as I don’t see why this wouldn’t happen automatically. Because a lot of orgs don’t want to wait for all of this to happen, they disable user ESP (there is a custom OMA-URI policy to do this documented in one of my blogs). That would end up masking your problem, not solving it, but the user would be a little happier 🙂
LikeLike
Hello Michael, I’ve noticed an odd behavior and wanted to report it because I’m not sure if it’s only our environment or if it would affect other people as well.
We are all setup to properly do hybrid-domain join and we are using white glove to provision devices.
Everything is working well.. except that if I assign some specific policies to devices, then the white glove process will be stuck.
I have one in mind where I can always reproduce the issue.. if I assign the “Start menu” policy (from the “device restrictions” profile) to devices, the device won’t go past the “Provisioning” screen, so basically it doesn’t go to the ESP phase.
If I then assign this policy to users, well then everything is fine. I can reproduce that issues with some other specific policies (Windows Update is another one where I find strange that I couldn’t assign it to devices, otherwise it breaks the white glove process).
My issue with this is that I would need to assign some of those policies to devices instead of users so I can exclude some devices group.
I hope this make sense, we will look at opening a ticket with Microsoft as I can reproduce this issue and I don’t think this is a normal behavior.
LikeLike
Do you see any reboots as a result of those policies?
LikeLike
No reboot, basically, once I click on “Provision”, it gets stuck at the Windows Autopilot Configuration screen (like shown here: https://www.reddit.com/r/Intune/comments/f2pc4n/autopilot_white_glove_stuck_on_provisioning_device/). When I remove that specific policy (or assign it to users instead), it can go past that and show the ESP page. I’ll try to confirm one more time that I can still reproduce the issue, and I’ll make sure to download the latest 1903 build (that’s the version we are currently using in our environment). On a side note, I’m pretty sure that even though it is stuck at that first page, that it creates the object in AD, etc. but since the screen doesn’t go to the ESP phase, it never completes the white glove process. Thank you for your time.
LikeLike
I can confirm using 1903 (December edition, didn’t have time yet to try the January 2020 edition) that if I assign the “Start menu” configuration profile to the device that the white glove process doesn’t get past the “provisioning device…” screen. I can see from the Autopilot devices list that the device gets renamed and creates an associated Intune device. I’m not sure what I should be looking for at that point to troubleshoot. We manage tablets and Azure VMs and my goal would be to deploy some policies (for example the “Start” menu) to tablets and exclude VMs, but right now I can’t do that because it breaks the white glove provisioning process for our tablets deployment – so I have to assign to users which affect all devices where the user login (tablet + VM). Any help would be greatly appreciated. We will try to open a case with Microsoft but in the meanwhile I thought it could be useful to have your expertise on this as it could potentially affect many other people that will be trying hybrid domain join with white glove in the future. Thank you very much.
LikeLiked by 1 person
Hi Michael, is there a problem if reboots are included, I have a script wrapped as an intunewin application that is set to rename the computer and do some post configuration and a restart. This is set as a required app as part of the ESP and the app is assigned to a device group. I have seen the reboot causing the ESP to fail/timeout and if I remove the reboot the process completes fine.
LikeLike
Michael you are a god send. Can I ask you a quick question though in regarding “At that point you can see two devices in Azure AD for the machine, one that is Azure AD Joined and the other Hybrid Azure AD Joined”. This is not a good look in my opinion and seems really confusing. Is there any workaround, so that the device only appears once as a Hybrid device?
Right now if I go to the users view in Azure AD and assigned devices to the account who just enrolled the device via Autopilot, I don’t see the new device assigned to that user (who enrolled the machine via windows pilot). I wonder is it because there are two devices like you mentioned above? Having two devices in Azure AD and not having any enrolled device associated to the user, would mean essentially Autopilot is unusable for us. Any help is really appreciated.
LikeLike
Hi Michael, you are a godsend. Do you know when Microsoft hope to merge the Intune and Azure AD objects? Also with Hybrid join the device dies not appear in the users profile in Azure. Is this by design?
LikeLike