With any luck, you saw this morning’s blog post talking about Windows Autopilot for existing devices. In that blog, I talked about how this didn’t require any client-side changes to support joining devices to Active Directory (via Hybrid Azure AD Join, my least favorite feature name – more on that some other time). So why did it take so long? The original feature was designed to support Azure AD Join – that’s what was required, so that’s what was validated and released. But looking at the implementation, I couldn’t see any reason it wouldn’t work for Active Directory as well, so I tried it. And it didn’t work.
But at least it didn’t work in a way that showed promise. Windows 10 started up, saw the AutopilotConfigurationFile.json, and read the settings out of it, including the “CloudAssignedDomainJoinMethod” setting which specifies a value of 1 for Active Directory Join and 0 for Azure AD Join. The device then tried to enroll in Intune (instead of trying to do an Azure AD Join), which is needed to complete the Active Directory Join process via the Intune connector. But that enrollment failed with a typical error (80180003) with event ID 52 in the Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin (a useful place to look for any 8018xxxx enrollment error codes) that said:
MDM Enroll: Server Returned Fault/Code/Subcode/Value=(Authorization) Fault/Reason/Text=(Authorization).
So, once we got Intune to accept this type of Windows Autopilot enrollment, everything worked.
Some of you may have tried this yourselves in the past and found that the device joined Azure AD instead of Active Directory. That was because the WindowsAutopilotIntune module did not generate a JSON file that specified a “CloudAssignedDomainJoinMethod” value of 1, it always specified 0. That was changed back in May to generate the correct value for Hybrid Azure AD Join profiles, so that we could validate the expected behavior. So make sure you install the latest version of this module.
Also mentioned in the blog: You need to target a “Domain Join” profile to “All Devices” as that’s what Intune will need to use to figure out what Active Directory domain and OU the device should be joined to. Because the device doesn’t yet exist in Azure AD, there’s no way to put it into a group so that you can target policies to that group. It will end up getting all policies that target “All Devices” as well as any user-targeted policies. If it ends up in groups later (after it’s been joined to AD and synced into Azure AD), then Intune will send additional policies later.
As a reminder, you can also speed up the Windows Autopilot for existing devices process as implemented in ConfigMgr using a modified task sequence. Check out my older blog (which has been migrated to the Tech Community site) on that.
Categories: Windows Autopilot