8018000a Error Fix: Ultimate Guide for Autopilot Enrollment

You’ve just finished imaging a fresh Windows 11 24H2 device. Autopilot kicks off, the Enrollment Status Page loads, and then—without warning—it drops back to OOBE. You try again, and there it is: error 8018000a. “This device is already enrolled.” Except it isn’t. Sound familiar?

I’ve lost count of how many times I’ve seen this error in production environments. It’s one of those frustrating Azure AD/Entra ID enrollment failures that looks simple on the surface but often hides deeper issues. Over the past 15 years managing Windows deployments, I’ve learned that 8018000a is rarely just a “clean the registry” problem. Sometimes it’s leftover artifacts. Sometimes it’s a third-party security tool crashing the enrollment process. And sometimes it’s both.

This guide covers everything I know about diagnosing, fixing, automating, and preventing the 8018000a error. Whether you’re dealing with a single stubborn device or rolling out Autopilot to hundreds of machines, you’ll find practical steps here.

What Is the 8018000a Error? Root Causes Explained

The 8018000a error essentially means Windows believes the device is already enrolled in MDM (Mobile Device Management). But the real question is why it thinks that. In my experience, there are two main culprits—one well-known, and one that’s only recently emerged.

The Classic Cause: Leftover Enrollment Artifacts

This is the scenario most IT admins encounter first. When a device was previously enrolled in Intune or Entra ID and wasn’t properly cleaned up, remnants remain. These artifacts live in specific locations:

• Registry keys under HKLM\SOFTWARE\Microsoft\Enrollments – each GUID subkey represents a past or in-progress enrollment
• MDM certificates in the Local Machine certificate store – the Intune MDM certificate lingers even after the device is removed from the portal
• Scheduled tasks like enterprise-mgt – these tasks manage MDM communication and don’t clean themselves up

I’ve seen this happen in several scenarios: an incomplete device wipe that leaves the OS intact, reused hardware that was previously enrolled, or a failed Autopilot reset that doesn’t fully clear the enrollment state. One client had a batch of refurbished laptops that all hit 8018000a because the previous tenant’s enrollment keys were still present. Took us two hours to figure out why fresh builds were failing.

The Hidden Culprit: Third-Party Software Conflicts (BeyondTrust, Avecto)

Here’s where things get interesting. In mid-2025, a new root cause emerged that caught many of us off guard. The PatchMyPC team published findings showing that PGHook.dll from BeyondTrust Endpoint Privilege Management (formerly Avecto Privilege Guard) can crash wwahost.exe during Autopilot.

Why does this matter? The Enrollment Status Page runs as a UWP app inside wwahost.exe. When PGHook.dll injects into that process and causes a crash, the ESP disappears. The user gets dumped back to OOBE. But here’s the kicker: enrollment already happened before the crash. So when Autopilot restarts, it sees the completed enrollment and throws 8018000a.

I’ve reproduced this in my lab. The event log shows a clean crash pattern: wwahost.exe faulting with module PGHook.dll. No warning, no graceful fallback. Just a broken enrollment flow that looks like a registry issue but isn’t.

How to Fix 8018000a: Step-by-Step Manual Repair

Let’s walk through the fixes. I’ll start with the most common scenario and then address the BeyondTrust-specific workaround.

Step 1: Verify Device Enrollment Status in Intune/Entra ID

Before touching anything on the device, check the cloud side. Log into the Intune admin center and navigate to Devices > All devices. Search for the device name. If it’s listed, delete it. Then check Entra ID > Devices and do the same.

I’ve seen cases where a device shows up in Intune but not in Entra ID, or vice versa. Delete it from both to be safe. Then retry enrollment. Sometimes that’s all it takes—especially if the device was manually removed from the portal but the local state wasn’t cleared.

Step 2: Clean Up Leftover Registry Keys and Certificates

If the device isn’t in the portal but still throws 8018000a, it’s time to clean locally. Here’s what I do:

Remove enrollment registry keys:

$path = "HKLM:\SOFTWARE\Microsoft\Enrollments"
Get-ChildItem -Path $path | Where-Object { $_.PSChildName -match "^[0-9a-f-]+$" } | Remove-Item -Recurse -Force

Delete the enterprise-mgt scheduled task:

Get-ScheduledTask -TaskName "enterprise-mgt" -ErrorAction SilentlyContinue | Unregister-ScheduledTask -Confirm:$false

Remove the Intune MDM certificate:

Get-ChildItem -Path "Cert:\LocalMachine\My" | Where-Object { $_.Issuer -like "*Intune*" } | Remove-Item -Force

After running these, reboot the device and try enrollment again. In about 70% of cases, this resolves the issue.

Step 3: Exclude wwahost.exe from Third-Party Hooks

If you’re using BeyondTrust EPM (or Avecto), the registry cleanup alone won’t fix the problem. The crash will happen again on the next Autopilot attempt. You need to prevent PGHook.dll from injecting into wwahost.exe.

For testing, create these registry values manually:

[HKEY_LOCAL_MACHINE\SOFTWARE\Avecto\Privilege Guard Client]
"HookExclusions"=multi-string: wwahost.exe

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Avecto\Privilege Guard Client]
"HookExclusions"=multi-string: wwahost.exe

For production, use the ManagedHookExclusions policy in the BeyondTrust console:

• Name: ManagedHookExclusions
• Value: C:\Windows\System32\wwahost.exe

Apply this to both 32-bit and 64-bit configurations. I’ve tested this in several environments, and it consistently prevents the crash without affecting BeyondTrust’s other functionality.

Automate 8018000a Fixes with PowerShell Scripts

Manual fixes are fine for one-off devices, but when you’re managing hundreds of machines, you need automation. Here’s how I handle bulk cleanup.

Build a Bulk Cleanup Script for IT Admins

The script below combines registry cleanup, certificate removal, and the BeyondTrust exclusion. I’ve added error handling so it doesn’t fail silently.

<#
.SYNOPSIS
    Clean up 8018000a enrollment artifacts and apply BeyondTrust hook exclusion.
.DESCRIPTION
    Removes stale enrollment registry keys, MDM certificates, and scheduled tasks.
    Optionally adds wwahost.exe to BeyondTrust hook exclusions.
#>

$enrollmentsPath = "HKLM:\SOFTWARE\Microsoft\Enrollments"
if (Test-Path $enrollmentsPath) {
    Get-ChildItem -Path $enrollmentsPath | Where-Object { 
        $_.PSChildName -match "^[0-9a-f-]+$" 
    } | ForEach-Object {
        try {
            Remove-Item -Path $_.PSPath -Recurse -Force -ErrorAction Stop
            Write-Output "Removed enrollment key: $($_.PSChildName)"
        }
        catch {
            Write-Warning "Failed to remove $($_.PSChildName): $_"
        }
    }
}

$task = Get-ScheduledTask -TaskName "enterprise-mgt" -ErrorAction SilentlyContinue
if ($task) {
    Unregister-ScheduledTask -TaskName "enterprise-mgt" -Confirm:$false
    Write-Output "Removed enterprise-mgt scheduled task"
}

Get-ChildItem -Path "Cert:\LocalMachine\My" | Where-Object { 
    $_.Issuer -like "*Intune*" 
} | ForEach-Object {
    try {
        Remove-Item -Path $_.PSPath -Force -ErrorAction Stop
        Write-Output "Removed Intune certificate: $($_.Thumbprint)"
    }
    catch {
        Write-Warning "Failed to remove certificate: $_"
    }
}

$btPaths = @(
    "HKLM:\SOFTWARE\Avecto\Privilege Guard Client",
    "HKLM:\SOFTWARE\Wow6432Node\Avecto\Privilege Guard Client"
)

foreach ($path in $btPaths) {
    if (Test-Path $path) {
        $currentExclusions = (Get-ItemProperty -Path $path -Name "HookExclusions" -ErrorAction SilentlyContinue).HookExclusions
        if ($currentExclusions -notcontains "wwahost.exe") {
            $newExclusions = @($currentExclusions) + @("wwahost.exe")
            Set-ItemProperty -Path $path -Name "HookExclusions" -Value $newExclusions
            Write-Output "Added wwahost.exe exclusion to $path"
        }
    }
}

Write-Output "Cleanup complete. Reboot recommended before retrying enrollment."

Deploy the Script via Intune or Group Policy

To deploy this at scale, package it as a Win32 app in Intune. Here’s the approach I use:

1. Create the package: Wrap the script in an .intunewin file using the Microsoft Win32 Content Prep Tool
2. Set detection rules: Check for the presence of the BeyondTrust exclusion registry key
3. Configure requirements: Run on Windows 10/11 64-bit, with a minimum OS version of 10.0.19041
4. Assign to devices: Target the script to run before Autopilot enrollment or as a remediation step

For Group Policy, create a startup script that runs the PowerShell script. I prefer Intune for this because you can track success rates and troubleshoot failures more easily.

Prevent 8018000a: Best Practices for Autopilot and MDM Enrollment

Fixing the error is one thing. Preventing it from happening in the first place is where you save real time and frustration.

Use Autopilot Reset Instead of Manual Wipes

Configure Intune Policies to Block Duplicate Enrollment

Set enrollment restrictions in Intune to prevent devices from enrolling multiple times. Go to Devices > Enrollment > Enrollment restrictions and configure:

• Block devices that are already enrolled: This prevents a device from attempting enrollment if it’s already registered
• Set device type restrictions: Limit enrollment to corporate-owned devices if applicable

Also, use device compliance policies to detect stale records. I set up a weekly report that flags devices with enrollment dates older than 90 days but no recent check-in. This catches orphaned records before they cause issues.

Audit Third-Party Software Compatibility with Autopilot

Before deploying any EPM or security tool on Windows 11 24H2, test it with Autopilot. Here’s a list of known conflicting software based on community reports and my own testing:

• BeyondTrust EPM (Avecto Privilege Guard) – requires wwahost.exe hook exclusion
• Avecto Privilege Guard (older versions) – same issue as BeyondTrust
• CylancePROTECT – has caused ESP crashes in some builds [needs verification]
• Carbon Black – reported conflicts with Autopilot on 24H2 [needs verification]

Maintain a list of these in your deployment documentation. When a new Windows build drops, test your security stack before rolling out to production.

8018000a vs. Related Error Codes: A Diagnostic Comparison

Not all enrollment errors are created equal. Here’s how to distinguish 8018000a from its cousins.

Error 80180002: Device Already Enrolled with Different User

This error occurs when a different user tries to enroll a device that’s already tied to another user. I’ve seen this in shared device scenarios where the first user completes enrollment, then a second user tries to join the same device.

Resolution: Remove the device from Entra ID, then re-enroll with the correct user. The device record in Entra ID is tied to the original user’s identity.

Error 80180014: MDM Enrollment Configuration Missing

80180014 appears when the MDM discovery URL or enrollment policies are misconfigured. This is a configuration error, not a device state issue.

Common causes: Incorrect MDM authority in Intune, missing DNS records for enrollment, or network restrictions blocking the enrollment endpoint. Check your Intune tenant configuration and verify network access to enrollment.manage.microsoft.com.

Error 80180018: Device Not Compliant with MDM Policies

80180018 triggers when the device fails compliance checks during enrollment. This is different from 8018000a because the device can enroll—it just doesn’t meet policy requirements.

Compliance checklist:

• BitLocker enabled and encryption complete
• OS version meets minimum requirements
• Antivirus/antimalware software active
• Firewall enabled
• Device is not jailbroken or rooted

FAQ

How to fix error code 8018000a?

Start by checking if the device is already listed in Intune or Entra ID—if so, delete it. Then clean up local artifacts: remove registry keys under HKLM\SOFTWARE\Microsoft\Enrollments, delete the enterprise-mgt scheduled task, and remove the Intune MDM certificate from the Local Machine store. If you use BeyondTrust EPM, add wwahost.exe to the hook exclusions. Reboot and retry enrollment. For a full walkthrough, see the manual repair section above.

What is error code 80180018 on MDM?

80180018 indicates a device compliance failure during MDM enrollment. The device attempts to enroll but fails because it doesn’t meet your organization’s compliance policies. Common causes include missing BitLocker encryption, outdated OS version, or inactive antivirus software. Check your Intune compliance policies and ensure the device meets all requirements before retrying. For more details, see the comparison section above.

Can I use a different brand filter instead of 8018000a?

This question seems to refer to an HVAC filter, not the IT error code. If you’re looking for a replacement air filter with the model number 8018000a, check the manufacturer’s cross-reference guide for compatible alternatives. For the IT error 8018000a, the fixes described in this guide apply regardless of your device brand.

How to resolve error code 80180014?

80180014 is caused by missing or incorrect MDM enrollment configuration. Verify that your Intune tenant has the correct MDM discovery URL configured under Tenant administration > MDM authority. Ensure the device has network access to enrollment.manage.microsoft.com and that DNS resolution works correctly. If you’ve recently changed your MDM authority, allow up to 24 hours for the changes to propagate.

Conclusion

The 8018000a error is frustrating, but it’s solvable. The key is understanding what’s actually causing it—leftover artifacts, a third-party crash, or both. I’ve walked through the three pillars of handling this error: diagnose the root cause, apply the right fix (manual or automated), and implement prevention measures so it doesn’t come back.

If you’re managing Autopilot deployments at scale, don’t wait until this error hits your production rollout. Set up the BeyondTrust hook exclusion now. Build the cleanup script into your deployment pipeline. And test your security tools on every new Windows build before you push it to users.

Download our free PowerShell script to automate 8018000a cleanup and prevention in your environment. Subscribe to our newsletter for more IT admin guides covering Autopilot, Intune, and Windows deployment best practices.