Windows Autopilot Hybrid Azure AD Join troubleshooting is new to most of us. I thought of sharing my experience of troubleshooting issues related to Hybrid Domain Join scenarios with Windows Autopilot.
[ Related Post – Windows Autopilot Hybrid Domain Join Step by Step Implementation Guide]
Table of Contents
Introduction –Windows Autopilot Hybrid Azure AD Join
In a previous post (Windows Autopilot Hybrid Domain Join Step by Step Implementation Guide), we discussed Windows Autopilot Hybrid Azure AD Join Architecture and how to configure.
Windows Autopilot Hybrid Azure AD Join scenario includes many puzzles like.
- Active Directory
- AAD Connect
It’s essential to understand the workflow for troubleshooting Hybrid Windows Autopilot deployment. In this post, let’s discuss some common issues and critical troubleshooting areas of Windows Autopilot Hybrid Azure AD Join scenario.
Multiple Computer Records
Based on Windows Autopilot deployment stage, you will see computer record changes in the Intune console. You will also observe multiple records created for the same computer. This information helps to correlate in which stage autopilot deployment is getting failed. Let’s see some of the events.
Initially, when Windows autopilot computer starts communicating with Intune cloud service, a temp record gets created. As shown below the temp record will be in format.
If you don’t see this temp record created, then its most likely perquisites are not configured correctly. This issue should be because of any of the following reason.
- EMS license assignment not done.
- User doesn’t have permission for MDM Enrollment.
- Internet connectivity or proxy on your Windows 10 client
After some time, the temp record gets updated to the current name of the computer. Please note the computer has not yet applied the offline domain join blob.
After a few minutes, Windows 10 machine gets offline domain join blob from Intune. After offline domain join (in Windows Autopilot Hybrid Azure AD Join scenario), computer record in Intune console gets updated as per the defined Computer naming template. You may also observe multiple records for the same computer in the Intune console.
First computer record gets created as part of Intune communication. The second record is created by AAD connect synced the new computer object from AD.
If you don’t see the record with proper computer naming template, then it states some issue. Most of the time issue lies within the Offline domain join blob deployment workflow. You may also encounter below error.
confirm you are using the correct sign-in information and that your organisation use this feature.you can try to do this again or contact your system administrator with the error code 80070774
Server Side Troubleshooting
Let’s discuss common Offline domain join deployment (in Windows Autopilot Hybrid Azure AD Join scenario) issues and where to troubleshoot. Troubleshooting can be done from the server and client side. Let’s talk about each one of them.
- Server side
- Client side
Intune AD connector connection health
Navigate to below path, to confirm the Intune AD connector connection health. Check whether your connector status is showing as Online and latest sync time updated.
If you see any error as shown below, then it indicates that your connector is not communicating with Intune.
Intune AD Connector Not Appearing
You have installed the console, and it got installed successfully. It gave the option to log in with ‘Global Admin’ credentials. You tried to log in with the credentials, and it just does nothing. It just shows the page of Microsoft and account status shows ‘Signed In.’
When you can’t see Intune Active Directory (AD) connector in the console, then it might be due to IE Enhanced Security. IE Enhanced Security Configuration is enabled by default on Windows Server 2016 or later. This security setting may block the website displayed correctly during the Intune AD connector sign in.
Chetan Sharma (in Intune professional Facebook Group) discusses a similar issue. To fix this issue, you might have to turn off IE Enhanced Security mode temporarily. You can turn on after successful Intune AD connector enrollment.
Intune ODJ connector service
If Intune ODJ Connector status shows offline, then verify connector service. As shown below, you need to make sure Intune ODJ connector service is “running” on your server.
For each imported autopilot serial number there will be corresponding Intune record created when autopilot deployment start, a new record for that computer appears in Intune console.
You can navigate to below path to find an association between hardware serial number and corresponding computer record. I usually use this in troubleshooting to check the associated Azure device id, Intune device name, Autopilot profile assignment, and enrollment status.
Let’s go through some of the events to track the communication between Intune, connector and Domain controller. Activities related to Intune ODJ connector service logged in the Event Viewer. Launch the event viewer.
Navigate to event log at “Application and Services Logs –> ODJ Connector Service.”
Below Event ID 30120 state Intune AD connector can download policy to generate Offline domain join blob.
"RequestIds":"[ d302cfe6-b60f-4d56-9f3a-2abbd89c6882 ]",
"DeviceIds":"[ 59c1b762-1852-46e0-9ebe-439aab2d17f0 ]",
"DomainNames":"[ XXXXXXXX.com ]",
"ComputerNameStaticPrefixes":"[ HYBD ]",
"ComputerNameSuffixCounts":"[ 11 ]",
Below Event ID 30130 state Intune connector service can successfully create an offline domain join blob. You can also see the computer name generated.
If auditing enabled, you could see below event in domain controller. New computer object got created using the connector server (SERVER$) permission. So make sure Intune Connector Server have enough right as explained in the first post.
A computer account was created.
Security ID: Domain\XXXX$
Account Name: SERVER$
Account Domain: Domain
Logon ID: 0x11ADCC4
New Computer Account:
Security ID: Domain\HYBDCGGLNWOWNRC$
Account Name: HYBDCGGLNWOWNRC$
Account Domain: Domain
SAM Account Name: HYBDCGGLNWOWNRC$
Display Name: -
User Principal Name: -
Home Directory: -
Home Drive: -
Script Path: -
Profile Path: -
User Workstations: -
Password Last Set: 4/20/2019 12:57:35 PM
Primary Group ID: 515
Old UAC Value: 0x0
New UAC Value: 0x80
User Account Control:
'Workstation Trust Account' - Enabled
User Parameters: -
SID History: -
DNS Host Name: HYBDcggLnwOWnRC.XXXXXX.com
Service Principal Names:
After successful offline Domain Join blob creation, Intune Active Directory connector uploads the blob to Intune. Below Event ID 30140 state connector service can upload Offline blob to Intune. Intune connector acts as a mediator between Intune and Domain controller.
Source: ODJ Connector Service Source
Date: 4/20/2019 12:57:41 PM
Event ID: 30140
"RequestIds":"[ d302cfe6-b60f-4d56-9f3a-2abbd89c6882 ]",
"DeviceIds":"[ 59c1b762-1852-46e0-9ebe-439aab2d17f0 ]",
"DeviceNames":"[ HYBDcggLnwOWnRC ]",
"BlobDataLengths":"[ 2807 ]",
"BlobEncrypted":"[ True ]",
If you see any errors during offline blob upload, then make sure there are no firewall or proxy blocking communication between connector and Intune service. If you have a proxy in your environment, then you need to make sure its configured as mentioned in pre-req.
Client side Troubleshooting
I have explained the basics of Autopilot troubleshooting in one of my previous post. For more details refer here.
Launch the event viewer and navigate to below path. You will be able to find some useful information logged in Diagnostics provider logs for troubleshooting.
Error 1 – 80070774 –Something Went Wrong
"Confirm you are using the correct sign-in information and that your organization uses this feature.you can try to do this again or contact system administrator with error code 80070774."
The above error is a result of time out during offline domain join blob deployment workflow. As basic troubleshooting, you need to verify whether connector server is healthy and active as explained earlier.
Also, you need to verify whether you can ping your domain controller and connector server from the client. After offline domain join computer requires a reboot. But the machine will not reboot until it can establish communication with the Domain controller.
NOTE! – Another possibility for this error is when the computer name “prefix” not configured correctly.
Error 2 – 80180005
"There was an error communicating with server.you can try to do this again or contact your system administrator with the error code 80180005."
There can be many reasons for the above error. In most cases, this occurs if the computer name prefix is not configured correctly. In previews Post 1 we configured computer naming template.
Make sure you don’t use any variables in the computer naming template. Unsupported computer name will result in error code “80180005” or “80070774” . In the computer naming template use simple prefix such as HYBD, ABC
Windows Autopilot Error 3 – Please wait while we setup your device
During Windows Autopilot Azure AD Join profile deployment, its reasonable that computer take bit more time on below screen. But if there are any issues, the computer will get stuck at below screen and finally timeout with an error.
In this scenario, press Shift + F10 to get command prompt support. Then try if you can ping the DC and internet URLs from the machine.
The other reason for the timeout error is when the OU path is not set correctly. Please make sure you configure the Domain Join profile correctly as explained in the previous post.
Note: You should set the organization unit in the correct format as shown in the below example.
Domain Join Logs
Check the netsetup.log to check whether computer received offline domain join blob from Intune or not. You can navigate to below location and analyze the log while troubleshooting.
Netsetup.log records Domain join events before and after applying offline domain join blob
After few minutes , offline domain join blob gets applied successfully.
03/19/2019 02:34:15:003 -----------------------------------------------------------------
03/19/2019 02:34:15:003 NetpDoDomainJoin
03/19/2019 02:34:15:018 NetpDoDomainJoin: using new computer names
03/19/2019 02:34:15:018 NetpDoDomainJoin: NetpGetNewMachineName returned 0x0
03/19/2019 02:34:15:018 NetpMachineValidToJoin: 'WIN-JHKTEC2GLIL'
03/19/2019 02:34:15:018 NetpMachineValidToJoin: status: 0x0
03/19/2019 02:34:15:018 NetpJoinWorkgroup: joining computer 'WIN-JHKTEC2GLIL' to workgroup 'WORKGROUP'
03/19/2019 02:34:15:018 NetpValidateName: checking to see if 'WORKGROUP' is valid as type 2 name
03/19/2019 02:34:17:174 NetpCheckNetBiosNameNotInUse for 'WORKGROUP' [ Workgroup as MACHINE] returned 0x0
03/19/2019 02:34:17:174 NetpValidateName: name 'WORKGROUP' is valid for type 2
03/19/2019 02:34:19:643 NetpJoinWorkgroup: status: 0x0
03/19/2019 02:34:19:643 NetpDoDomainJoin: status: 0x0
04/21/2019 08:50:40:808 -----------------------------------------------------------------
04/21/2019 08:50:40:808 NetpRequestProvisioningPackageInstall:
04/21/2019 08:50:40:808 cbPackageBinData: 983
04/21/2019 08:50:40:808 JoinOptions: 0x0
04/21/2019 08:50:40:808 ProvisionOptions: 0x40000000
04/21/2019 08:50:40:808 lpWindowsPath: C:\Windows
04/21/2019 08:50:40:808 NetpRequestProvisioningPackageInstall: Found ODJ blob format: 1.
04/21/2019 08:50:40:808 NetpSetPrivileges: Setting backup/restore privileges.
04/21/2019 08:50:40:982 NetpProvGetWindowsImageState: IMAGE_STATE_COMPLETE.
04/21/2019 08:50:40:982 NetpAddPartCollectionToRegistry.
04/21/2019 08:50:40:982 NetpProvGetTargetProductVersion: Target product version: 10.0.18343.1
04/21/2019 08:50:41:152 NetpAddPartCollectionToRegistry: delete OP state key status: 0x2.
04/21/2019 08:50:41:152 NetpConvertBlobToJoinState: Translating provisioning data to internal format
04/21/2019 08:50:41:152 NetpConvertBlobToJoinState: Selecting version 1
04/21/2019 08:50:41:152 NetpConvertBlobToJoinState: exiting: 0x0
04/21/2019 08:50:41:168 NetpAddPartCollectionToRegistry: Successfully initiated provisioning package installation: 1/1 part(s) installed.
04/21/2019 08:50:41:168 NetpAddPartCollectionToRegistry: status: 0x0.
04/21/2019 08:50:41:168 NetpOpenRegistry: status: 0x0.
04/21/2019 08:50:41:168 NetpSetPrivileges: status: 0x0.
04/21/2019 08:50:41:168 NetpRequestProvisioningPackageInstall: status: 0x0.
04/21/2019 08:54:12:726 -----------------------------------------------------------------
04/21/2019 08:54:12:726 NetpProvCheckOfflineLsaPolicyUpdate
04/21/2019 08:54:12:726 NetpMachineValidToJoinPhase3: 'HYBD6T03Oyzzs8P'
04/21/2019 08:54:12:741 NetpMachineValidToJoinPhase3: status: 0x0
04/21/2019 08:54:12:741 NetpProvCheckOfflineLsaPolicyUpdate: status: 0x0
04/21/2019 08:54:20:164 -----------------------------------------------------------------
04/21/2019 08:54:20:164 NetpProvContinueProvisioningPackageInstall:
04/21/2019 08:54:20:164 Context: 1
04/21/2019 08:54:20:164 NetpProvGetWindowsImageState: IMAGE_STATE_COMPLETE.
04/21/2019 08:54:21:227 NetpCreatePartListFromRegistry: status: 0x0.
04/21/2019 08:54:21:227 NetpCompleteOfflineDomainJoin
04/21/2019 08:54:21:227 fBootTimeCaller: TRUE
04/21/2019 08:54:21:227 fSetLocalGroups: FALSE
04/21/2019 08:54:21:321 NetpJoinDomainLocal: NetpHandleJoinedStateInfo returned: 0x0
04/21/2019 08:54:21:652 NetpJoinDomainLocal: NetpManageMachineSecret returned: 0x0.
04/21/2019 08:54:22:074 NetpJoinDomainLocal: status of setting LSA pri. domain: 0x0
04/21/2019 08:54:22:074 NetpJoinDomainLocal: Updating W32TimeConfig
04/21/2019 08:54:22:324 NetpCompleteOfflineDomainJoin: status: 0x0
04/21/2019 08:54:22:324 NetpProvContinueProvisioningPackageInstall: status: 0x0.
04/21/2019 08:54:22:921 -----------------------------------------------------------------
04/21/2019 08:54:22:921 NetpProvContinueProvisioningPackageInstall:
04/21/2019 08:54:22:921 Context: 2
04/21/2019 08:54:22:921 NetpProvGetWindowsImageState: IMAGE_STATE_COMPLETE.
04/21/2019 08:54:22:921 NetpCreatePartListFromRegistry: status: 0x0.
04/21/2019 08:54:22:921 NetpCompleteOfflineDomainJoin
04/21/2019 08:54:22:921 fBootTimeCaller: TRUE
04/21/2019 08:54:22:921 fSetLocalGroups: TRUE
04/21/2019 08:54:22:937 NetpManageLocalGroupsForJoin: Adding groups for new domain, removing groups from old domain, if any.
04/21/2019 08:54:24:234 NetpManageLocalGroupsForJoin: status of modifying groups related to domain 'XXX' to local groups: 0x0
04/21/2019 08:54:24:234 NetpManageLocalGroupsForJoin: INFO: No old domain groups to process.
04/21/2019 08:54:24:234 NetpCompleteOfflineDomainJoin: NetpManageLocalGroupsForJoin returned code: 0x0.
04/21/2019 08:54:24:234 NetpCompleteOfflineDomainJoin: status: 0x0
04/21/2019 08:54:24:234 NetpProvContinueProvisioningPackageInstall: Provisioning package installation completed successfully.
04/21/2019 08:54:24:234 NetpProvContinueProvisioningPackageInstall: delete OP state key status: 0x0.
04/21/2019 08:54:24:234 NetpProvContinueProvisioningPackageInstall: status: 0x0.
After applying the offline domain join blob then the computer will go for restart. At this point, Windows 10 computer should have AD connectivity after computer restart user can log in with Domain credentials.
Enrollment Status Page (ESP)
After user signs in there will be enrollment status screen whenever the Intune enrollment status page (ESP) is configured for your tenant.
Make sure you configured below CSP to skip the user policy during ESP screen.
- OMA-URI: ./Vendor/MSFT/DMClient/Provider/MS DM Server/FirstSyncStatus/SkipUserStatusPage
- Data type: Boolean
- Value: True
If the CSP policy is not configured you may get error as shown below.
NOTE! – Why CSP configuration is required to skip the user policy during ESP screen?
As we know during Autopilot deployment computer is first joined to AD Domain. The machine is still not yet marked as Hybrid Azure AD joined. AAD connect is responsible for the computer object in AD to synch to Azure AD.
It usually takes at least 30 min for the AAD connect to process the computer object and sync to Azure AD. Because of this delay, you may encounter timeout error within Enrollment status page. Intune will not deploy any user targeted policies until the computer object is synced to Azure and authenticated.
At the point, the workaround is to skip user targeted policies during Enrollment status page. However, Intune will start deploying User policies once the computer receives user token(typically 30 min). It is recommended to go through Michael Niehaus blog for more details.
All credits to Michael Niehaus and Sandys (presented during MMS). Also, thank you Daniel Ratliff for sharing this information in Twitter.
- 8007 Window Autopilot Errors are Win32 Errors (Network or some other related errors).
- 0x800705B4 = timeout
- 0x80070774 = domain controller not found
- 801C Windows Autopilot Errors are Azure AD Join / Device Registration related issues.
- 0x801C0003 = Device Authorization error (not authorized to join Azure AD, exceeded device limit).
- 8018 Windows Autopilot errors are MDM Enrollment related issues.
- 0x80180003 = authorization (user not authorized to enroll).
- 0x80180005 = Server error (enrollment rejected, scenario not enabled, etc.).
- 0x80180014 = Device not supported (enrollment restrictions rules).
- 0x80180018 = No user license (Azure AD premium or Intune licenses are NOT assigned).
- 8000 Windows Autopilot errors are mostly due to Windows related Errors.
- 0x80004005 = Generic error (fail).
- 1. Beginners Guide Setup Windows Autopilot Deployment
- 2. Dynamically Deploy Security Policies and Apps to Windows Autopilot Devices
- 3. Where is Autopilot Assign Profile Button in Intune Portal
- 4. Windows Autopilot End to End Process Guide
- 5. Repurpose/Reprovision Existing Devices to Windows Autopilot
- 6. Windows AutoPilot Profile AAD Dynamic Device Groups.
- 7. Windows Autopilot License Requirements