If you have attempted to deploy Microsoft Endpoint Manager (Intune), you may have run across this error in the “Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin” event log during enrollment:
Auto MDM Enroll Impersonation Failure (Unknown Win32 Error code: 0x82aa0008). It may also coincide with error Auto MDM Enroll: Device Credential (0x1), Failed (Unknown Win32 Error code: 0x80192ee2).
There are a couple of reasons why this error can crop up, so let’s dig into a few of them.
Table of Contents
- Background
- How to Fix “Auto MDM Enroll Impersonation Failure (Unknown Win32 Error code: 0x82aa0008)”
Background
Devices can enroll into Intune using either “Device Credentials” or “User Credentials”. If using the GPO enrollment method, you can choose either one. This is located under Computer Configuration > Administrative Templates > Windows Components > MDM > Enable Automatic MDM Enrollment Using Default Azure AD Credentials.
If you are using SCCM Co-Management, then this is always going to be “Device Credential” and the SCCM agent itself will facilitate the enrollment.
But what does “Auto MDM Enroll Impersonation Failure” even mean? In my experience with a large-scale deployment, this is nearly always related to the fact that there is no logged-in user during the enrollment attempt. This can be lab machines sitting at the login screen for extended periods of time, someone out on vacation, or just random workstations around the organization. Even with SCCM co-management, I had a lot of issues with getting these types of systems to enroll into Intune.
Does Intune need a logged-in user? No, it does not assuming you have met all of the requirements of Intune enrollment. The main ones are:
- Hybrid AAD Joined or Cloud AAD Joined
- The correct Azure Licensing assigned
- Co-management enrollment and/or GPO enrollment
So what is the fix?
How to Fix “Auto MDM Enroll Impersonation Failure (Unknown Win32 Error code: 0x82aa0008)”
I had this issue crop up on my co-management devices who were configured to auto-enroll into Intune. For some reason, it would just not complete this process when a logged-in user was not present. Even though it is supposed to be using “Device Credentials”, it would continue to fail.
I did the following things to fix this error:
I first configured MDM Enrollment scope in Azure AD to “All”. This is not required at all if using SCCM co-management for enrollment, but it is required using the GPO method. I turned it on regardless.
Then I enabled the GPO for automatic Intune enrollment on a single client and took a look at the scheduled task it creates (You can do this using local gpo – gpedit.msc). If you open up Task Scheduler and navigate to Microsoft\Windows\EnterpriseMgmt, you’ll see a task called “Schedule created by enrollment client for automatically enrolling in MDM from AAD using AAD device credential“.
And then if you open up the Actions tab, you will see the command it is running:
%windir%\system32\deviceenroller.exe /c /AutoEnrollMDMUsingAADDeviceCredential
Very interesting. I wonder if I can trigger this manually on a client?
In my other blog, I talk about a number of things you can do to speed up Intune enrollment with co-management. You can use a number of remote PowerShell commands and/or PSExec to help manually trigger the same process SCCM/GPO are using to enroll. So let’s give it a shot!
First, I checked the event viewer just to confirm the error by running this command:
$computername = "Desktop-12345"
Invoke-Command -ComputerName $Computername -Command {Get-WinEvent -LogName "Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin" -MaxEvents 100 |sort TimeCreated | ft -AutoSize -Wrap}The event viewer indeed shows the “Impersonation Failure” error.
Let’s go ahead and run that same command calling DeviceEnroller.exe. Ensure that you have downloaded PSExec from Microsoft and extracted PSexec.exe into C:\Temp\PSTools. This will ensure the executable is run as “SYSTEM”.
$computername = "Desktop-12345"
C:\Temp\PSTools\PsExec.exe "\\$computername" -accepteula -s c:\windows\system32\deviceenroller.exe /c /AutoEnrollMDMUsingAADDeviceCredentialAfter running the command remotely and checking Event Viewer, low and behold it worked! Enrollment complete.
NOTE: If you have the GPO set you can just remotely call the scheduled task.
And that’s how I fixed this issue in my environment. You may not see this as often if you are using the GPO method instead of Co-management as this scheduled task automatically runs and retries quite often.
