Event banner
Event details
Jason_Sandys
Microsoft
MicrosoftHi Levin. Can you expand what you mean by "Gateway"? Are you referring to Azure AD Connect? Have you also set up the Intune Connector for AD? Are you also deploying a VPN client during Autopilot so that the device can connect to your on-prem AD (assuming the device is no on-prem)? Finally, can you also expand on what you mean by "Option to start over"?
Also, just to call it out here, we strongly recommend avoiding this approach. Autopilot works best with Entra Joined (aka Azure AD joined) and we strongly recommend not using hybrid join with Autopilot for a variety of reasons. Cloud value is best realized with Entra joined and this aligns with all of our engineering investment and direction while also avoiding the many shortfalls of hybrid join with Autopilot. This recommendation is detailed at https://learn.microsoft.com/en-us/mem/solutions/cloud-native-endpoints/azure-ad-joined-hybrid-azure-ad-joined#which-option-is-right-for-your-organization
We have set up Azure AD Connect and the Intune Connector for AD on the same Windows Server. The synchronisation between AD and Azure AD works and the Intune Connector shows up in the Intune Endpoint Management Console. It shows as Aktive and working. We have successfully testet an Autopilot profile wit AAD only. But we can't get the Hybrid join working. When the enrolment gets to the point to join the local AD it fails and the only Option it lets us choose is to reset the Device again.
As of right now we are highly dependent on local AD management. That`s why we need our devices as hybrid. Also we would like to use Autopilot to simplify the process of resetting old devices and setting up new ones.
- Jason_SandysHave you reviewed the event log for the AD Connector? This should be under Microsoft\Intune\ODJConnectorService in the event viewer? Also, how exactly are you determining that the join is failing? As for being heavily dependent on AD management, what exactly does that mean? Moving Entra joined devices does not mean completely getting rid of your on-prem AD. It does involve transitioning to Entra ID and Intune for some things for sure and it's not an all or nothing proposition for sure, however, this is the best short-term and long-term path that we strongly recommend for all new device provisioning as this avoids a lot of "wasted" work and effort on something that we know is problematic at best and ultimately just prolongs an organization's commitment to a solution that is only meant as an interim step anyway.
- I haven't viewed the logs yet. I definitely will do that. As for how we are determining that the join had failed, ist that we get an error. Also, we can't get to a Desktop on the Device itself. Right now, some Software depends on local management and all permissions for the devices are set by local AD groups so I guess we would need to move most of them to Entra ID to transition to Entra ID joined. So, we hoped that using Autopilot with hybrid join would work. If I understand you right, I think the best solution for long term would be If I set up a Entra ID joined device and test what I need to transition to Entra ID to get everything to work. So, we could still manage our Servers and Users locally and have the Client Devices managed in Entra ID.
- Hi Levin, we have the same setup in our environment where our AP provisioned devices still join AD on-prem - look away Jason :-) It sounds like you've got the correct connectors in place and they are up and running. We have a config profile assigned to an EntraID 'All Autopilot Devices' group that states the domain to join, the OU to drop the device into and even the prefix for the hostname. The EntraID group has a dynamic query of (device.devicePhysicalIds -any _ -contains "[ZTDId]") - which is basically anything that's been imported into Autopilot and assigned an ID. It almost sounds like the devices haven't sight of the domain during the provisioning process. We slip a machine split tunnel VPN in as part of the process which enables line of sight to our DC's and therefore allows the domain join process to take place. The log that Jason mentioned above would certainly give some more clues I would have thought. Hope this helps
