Aug 11 2022 02:54 PM
This is the status where I am having problems joining the device to Hybrid Autopilot domain. Not sure whether this is a connectivity issue between the laptop to the INTUNE connector? I can ping the domain controller from Intune connector and no problem.
Aug 15 2022 10:48 PM
Aug 16 2022 06:38 AM
@Harm_Veenstra No luck that URL was opened up and still cannot complete the process of registering the device. I think the last option is to open up the servers to the internet. Not sure how risky it is going to be. I need to do this to get past this hurdle. I see that there are some red alerts in Wireshark from the capture.
Aug 16 2022 06:59 AM
Aug 17 2022 05:37 AM
Aug 17 2022 05:46 AM
Aug 17 2022 05:56 AM - edited Aug 17 2022 06:01 AM
So, it failed again at Step 6. The connection to the Internet is wide open between the Intune connector and the Internet. Looks like same thing, and probably it is not getting what it should get from the domain controller. Is there any article what kind of ports should be opened between Domain controller and Intune connector or any specific rules, as our environment is very restricted.
Here’s a description of those numbered steps:
The device will send its hardware hash to the Windows Autopilot services.
If the device is registered with Windows Autopilot and has an Autopilot profile assigned to it, the profile details will be provided to the device. In the Hybrid Azure AD Join case, the profile would tell the device what Azure AD tenant the device is associated with and that the device needs to be joined to Active Directory, but it does not specify the Active Directory domain details.
The user will be prompted for their Azure Active Directory credentials (or if using white glove, the device will perform TPM attestation) to get an Azure AD token; that token will be used to enroll the device in Intune. Intune will be notified as part of the enrollment process that it needs to get the device joined to Active Directory.
Intune will look for a Domain Join device configuration profile assigned to the device (via the groups that device is part of). Assuming it finds one, it will create a request for the Offline Domain Join connector (officially named the “Intune Connector for Active Directory”). If it doesn’t find one, steps #5 and #6 will never happen, and the device will time out waiting for an ODJ blob that will never come.
The ODJ connector picks up the ODJ request from the Intune service (it polls Intune looking for requests). If it finds a request, it will attempt to create an Active Directory object in the specified domain and OU using the naming prefix specified (all from that Domain Join profile). If that succeeds, it will upload the resulting ODJ blob representing that computer account to the Intune service.
When the device performs its next MDM sync (usually every 3 minutes, possibly even more frequently), it will receive that ODJ blob from Intune and apply it to the device. If the “skip connectivity check” setting is specified in the Autopilot profile, the device will immediately reboot to complete the domain join process. If the “skip connectivity check” setting is not specified, or if the device doesn’t meet the requirement for that setting, the device will first try to ping a domain controller for the domain (to ensure connectivity) before rebooting. If that ping test never succeeds, this step will time out and you’ll never get to step #7.
Finally, the user needs to sign into the device using Active Directory credentials, which need to be validated by an Active Directory domain controller, hence connectivity is required at this point; VPN connectivity can be used. See this post for more details on that.
So what can possibly go wrong? There are a few points of failure in this process:
There is no Domain Join profile targeted to the device.
The ODJ connector can’t create the ODJ blob for the device. - Yes
The device can’t establish connectivity. - Yes
The user can’t sign in.
User ESP times out after the user signs in.
Strangely, I routinely see people run into one of these issues and then someone else will say “I’m seeing the exact same problem.” And more often than not, that’s not at all true. Being able to recognize the differences in these different failures is a key troubleshooting skill. You should be able to answer the following questions:
Did the ODJ connector process a request and upload a blob for the device? No
Did the device receive and apply the ODJ blob? - No
Did the device try to check connectivity?
If using a VPN connection off the corporate network, can it connect so the user can sign in?
Can the Hybrid Azure AD Join process complete so the user can get an Azure AD user token, needed to talk to Intune and other Azure AD-based services?
Aug 17 2022 06:04 AM
Aug 17 2022 06:06 AM
Aug 17 2022 06:14 AM
Aug 17 2022 06:17 AM
I think here is the problem. I see error Event ID 304 and 204 on user device registration event logs. Based on this it says that the device has to be on the internal network or on a VPN. These devices are not internal or in VPN, they are on independent users wireless network.
So, I am wondering whether there is a rule that should be in place for these devices to communicate to the domain controller? I see all the other things happening fine and the device is domain joined.
Step 4: Check for possible causes and resolutions
Pre-check phase
Possible reasons for failure:
The device has no line of sight to the domain controller.
The device must be on the organization's internal network or on a virtual private network with a network line of sight to an on-premises Active Directory domain controller.
Aug 17 2022 06:21 AM
Aug 17 2022 06:21 AM
Aug 17 2022 06:22 AM
Aug 17 2022 06:33 AM
Aug 17 2022 06:38 AM
Aug 17 2022 06:42 AM
Aug 17 2022 06:46 AM
Aug 17 2022 07:01 AM
Aug 17 2022 07:03 AM
Aug 24 2022 04:44 AM