This issue started out as a support ticket where many users were being asked to authenticate to M365 apps every time they signed into AVD. For context, this was a smaller environment with only a few Windows 11 multi-session hosts. The session hosts are also hybrid-joined and Intune enrolled. So, the first thing I usually check here is the Hybrid enrollment status. You can have issues with SSO if the devices are not properly Hybrid or Entra joined. We can see from the screenshot below that the host is in a pending state. It’s also not enrolled in Intune. So, we have two things to fix here:
If you’ve been working with Entra in hybrid-environments, you’ve probably encountered devices in the pending registration before. If not, and you want to know more about how hybrid-join works, you can visit my blog here. Back to resolving the pending status, I went through my blog on how to correct this here – HAADJ devices stuck with pending registration state – SMBtotheCloud. After resolving the registration state, I noticed shortly after, the icon for the device changed to an autopilot device. Our AVD hosts should definitely not be autopilot devices.
After checking the autopilot registrations, the device was indeed autopilot registered.
I corrected the dynamic group rule that was registering this device with autopilot, and then deleted the device’s autopilot registration. Next, I attempted to enroll the device in Intune via the scheduled task from Group Policy failed. Looking into the error, we can see a few errors. The first error makes sense, indicating the device was found as an autopilot device, but marked for deletion. Maybe I just needed to wait longer for the registration to delete on the back end. The other errors all contain the error code 0x80180005.
One of my first visits for enrollment errors I am unfamiliar with is to visit Rudy’s blog – Troubleshooting Intune MDM Enrollment errors | Azure AD (call4cloud.nl). And sure enough, we can see Error Code 80180005. Per Rudy’s blog:
So, I tried the suggestion from Rudy’s blog. However, there were no autopilot configuration files on this device. Next, I enabled the debug event logs on the host and re-ran the enrollment scheduled task. This time I got some additional events, including the one below. Again, we can see a reference to Autopilot in the error:
Looking that enrollment ID (DAD70CC2-365B-450D-A8AB-2EB23F4300CC) up in the registry, we don’t see the details of a MAM or MDM enrollment. We simply see an enrollment state of 1 and enrollment type of a. This enrollment ID exists on every other device I checked, so I am assuming it has something to do with autopilot since the event also references Autopilot.
Looking at the scheduled tasks, I can see there is no enrollment ID folder under the EnterpriseMgmt task folder. There should be a subfolder with the enrollment ID that is generated when the Intune enroll GPO hits the device and creates the enrollment task:
I attempted to delete the scheduled task and enrollment ID from the registry and then run gpupdate to see if it would properly recreate the task, but the same behavior persisted. At this point, I double checked everything and even though the device was removed from Autopilot and not showing in the autopilot registered devices list, the device still showed as an autopilot device in Entra:
If we look at the device in Graph, we can see it still shows a ZTDID for autopilot, which also supports what we were seeing in the event viewer.
After trying to remove the ZTDID with graph api, I had no luck, and at this point, it would be easier to remove the device and let it re-register. So, I tried deleting the device from Entra, but since the device was still showing as an autopilot device, I couldn’t delete it from the Entra dashboard:
I ended up with a situation where the device did not really have an Autopilot registration, but Entra thought the device was still registered. I tried deleting the device from Entra with the PowerShell graph module, and that succeeded. After waiting several minutes, the device was also removed from the Entra GUI.
Next, I ran the scheduled task to hybrid join the device, ran a delta sync in Entra connect, and then ran a Gpupdate to Intune enroll the device. This time things looked much better, and we have an enrollment ID for the scheduled task:
The device also shows successful hybrid-join and Intune enrollment in the Entra dashboard. Long story short – if you’re getting this error, make sure Entra doesn’t think the device is registered with Autopilot. And the quickest method to resolve this if you end up in the same situation is to delete the device from Entra and let it go through the process of hybrid-join and Intune enrollment.
