Fix Intune Device Already Enrolled Errors 8018000A and 0x8007064C

If a Windows enrollment fails with 8018000A or 0x8007064C, the message usually sounds simple: the device is already enrolled. In practice, that can mean three different things. Another user already connected the device to work or school, the PC was previously enrolled and never cleaned up properly, or the machine was built from an image that carried old enrollment artifacts forward.

That matters because the fastest fix depends on which of those states you are actually in. If you treat every case like a tenant problem, you waste time in Intune and Microsoft Entra ID. If you treat every case like a local cleanup problem, you can miss the fact that the wrong user is still attached to the device.

Microsoft documents both errors as valid Windows Intune enrollment failures and gives a very specific cleanup path for each one. This guide turns that into a field workflow you can use during OOBE, Company Portal enrollment, or manual Access work or school troubleshooting.

What 8018000A and 0x8007064C usually mean

Microsoft’s current Windows enrollment troubleshooting guidance separates these two errors, but the root theme is the same: Windows believes management is already present.

• 8018000A: Something went wrong. The device is already enrolled.
• 0x8007064C: The machine is already enrolled.

The difference is where the duplicate state usually sits:

• 8018000A is commonly tied to a different user already connected to the device through Work Access or a previous Microsoft Entra join.
• 0x8007064C is more often tied to stale local enrollment artifacts, such as an old Intune certificate, an old OnlineManagement registry branch, or a cloned image that carried enrollment state into a new build.

That distinction gives you a better starting point:

1. Check whether another user already owns the work connection.
2. Check whether the device still has old MDM artifacts locally.
3. Check whether the device record is a reimage or clone that inherited enrollment state it should never have had.

Fast triage before you touch the device

Before you remove anything, capture enough evidence to avoid destroying the clue you need later.

Record these items in the ticket:

• Exact error code and wording.
• Whether the failure happened during OOBE, Company Portal, or Access work or school.
• Current signed-in user.
• Device serial number and hostname.
• Whether the device is a reimage, Autopilot rebuild, or cloned VM.
• Whether the device previously belonged to another user.

Then run these checks on the endpoint:

dsregcmd /status
Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.Issuer -match 'Intune|Sc_Online_Issuing|Microsoft Intune MDM Device CA' } |
  Select-Object Subject, Issuer, NotAfter
mdmdiagnosticstool.exe -area "DeviceEnrollment" -zip "C:\Users\Public\Documents\MDMDiagReport.zip"

dsregcmd /status helps confirm whether the device is already joined or registered. The certificate check helps you spot old Intune enrollment certificates. The MDM diagnostics package gives you a support artifact before you start deleting local state.

If the device is a shared support machine, pause here and verify whether the previous user intentionally enrolled it. Do not rip out enrollment artifacts from a device that is still legitimately managed for someone else.

Root cause 1: Another user is already connected to work or school

Microsoft says 8018000A commonly appears when a different user already enrolled the device in Intune or joined it to Microsoft Entra ID. On the device, Windows often surfaces a clue under:

Settings > Accounts > Access work or school

A common message is effectively: Another user on the system is already connected to a work or school account. Remove that connection and try again.

This is the cleanest variant of the problem because the fix is user ownership cleanup, not deep MDM surgery.

Fix workflow

1. Sign out of Windows.
2. Sign in with the user account that originally connected the device.
3. Go to Settings > Accounts > Access work or school.
4. Remove the existing work or school connection.
5. Sign out again.
6. Sign in with the intended user.
7. Retry Microsoft Entra join or Intune enrollment.

This happens often in real environments when:

• A tech enrolled the machine during staging and forgot to disconnect it.
• A loaner laptop was handed to a new employee without cleanup.
• A pilot device changed ownership between testing cycles.
• The user started one enrollment path, then a different admin tried another path under a different account.

If you skip the ownership check and jump straight into registry cleanup, the second user can still be blocked because the original work connection remains authoritative.

Root cause 2: Old Intune enrollment artifacts are still on the device

For 0x8007064C, Microsoft’s documented remediation focuses on local residue from a previous enrollment. The high-signal artifacts are:

• An old Intune certificate in the local computer personal store.
• The HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OnlineManagement registry tree.
• In some stubborn cases, the Windows Installer product key tied to the old client state.

This scenario is common after:

• Re-enrollment attempts that were never fully cleaned up.
• Older device management migrations.
• Bare-metal rebuilds that did not actually clear all management state.
• Reference images or captured images made from already-enrolled machines.

Microsoft’s cleanup path

Microsoft’s documented steps are very specific:

1. Open MMC.
2. Add the Certificates snap-in for the Computer account.
3. Browse to Certificates (Local Computer) > Personal > Certificates.
4. Look for the Intune certificate issued by Sc_Online_Issuing and delete it if present.
5. Delete HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OnlineManagement and all subkeys if the key exists.
6. Retry enrollment.
7. If the PC still cannot enroll, delete HKEY_CLASSES_ROOT\Installer\Products\6985F0077D3EEB44AB6849B5D7913E95 if it exists.
8. Retry enrollment again.

In practice, I recommend doing the cleanup in that same order. Do not start with the Windows Installer product key unless the primary certificate and OnlineManagement cleanup did not resolve the issue.

Practical admin workflow

Use this sequence to keep the change controlled:

1. Export evidence first

Before deleting anything, capture:

• Screenshot of Access work or school.
• dsregcmd /status output.
• Certificate thumbprint and issuer if you find an Intune cert.
• MDM diagnostics ZIP.

2. Remove stale certs

You can use MMC, which is Microsoft’s documented path, or verify by PowerShell before using the GUI.

Get-ChildItem Cert:\LocalMachine\My |
  Where-Object { $_.Issuer -match 'Sc_Online_Issuing|Microsoft Intune' } |
  Format-List Subject, Issuer, Thumbprint, NotAfter

If the certificate clearly belongs to the old enrollment, remove it through the Certificates snap-in so you can visually confirm what changed.

3. Remove old OnlineManagement state

Delete only the Microsoft-documented key for this issue:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OnlineManagement

This is the branch Microsoft calls out when the device still behaves as if it remains enrolled.

4. Retry before deeper cleanup

Do one clean retest after removing the certificate and OnlineManagement key. If the device still throws 0x8007064C, then move to the extra installer cleanup that Microsoft documents.

5. Use the installer product key only when necessary

The extra key:

HKEY_CLASSES_ROOT\Installer\Products\6985F0077D3EEB44AB6849B5D7913E95

should be treated as escalation cleanup, not first response. If your service desk standard jumps directly to deleting multiple unrelated keys, tighten the runbook. More deletion does not equal better troubleshooting.

Root cause 3: The machine was cloned or rebuilt from an already-enrolled image

Microsoft explicitly says 0x8007064C can happen when the computer has the cloned image of a machine that was already enrolled. This is a high-value clue for VDI templates, rushed refresh projects, and support teams that capture reference images from devices that touched production services.

When that happens, the new endpoint may inherit enrollment traces that belong to another identity or another physical device. Intune then sees a collision between what the local operating system believes and what the service expects.

Signs you are dealing with a clone problem

• Multiple devices begin failing after a new image rollout.
• The failure appears on freshly built endpoints before normal user activity.
• The same stale certificate issuer or registry state appears across several machines.
• The affected machines all came from the same task sequence, gold image, or VM snapshot.

What to do

1. Fix one representative device first.
2. Validate the image or deployment workflow that produced it.
3. Confirm the build process is not capturing enrolled state.
4. Rebuild additional machines only after the image issue is corrected.

If multiple devices are involved, this is no longer a single-device incident. It is an image hygiene problem. Document it that way so the packaging or deployment team owns the root cause.

Step-by-step remediation workflow for frontline engineers

If you need a repeatable runbook, use this order:

1. Identify which error you actually have

• 8018000A: start with user ownership and Access work or school.
• 0x8007064C: start with stale artifacts and clone history.

2. Check for an existing work account connection

Open:

Settings > Accounts > Access work or school

If another user is connected, remove that connection using the original user account before doing anything else.

3. Inspect for old Intune certificates

Use MMC or PowerShell to look for the old MDM certificate in the local machine personal store.

4. Remove Microsoft-documented local residue

Delete the OnlineManagement key only after you capture evidence.

5. Retest enrollment cleanly

Use one path only. Do not bounce between Company Portal, OOBE, and manual join attempts during the same retest. Mixed testing muddies the result.

6. Escalate to deeper cleanup only if the first retest fails

Use the installer product key cleanup Microsoft documents.

7. Review the cloud-side record if the device has been reused

If this was a reissued corporate laptop, check whether stale Intune or Microsoft Entra device objects should be retired or removed as part of your organization’s normal lifecycle workflow. That is not the first fix Microsoft lists for these exact errors, but it is often relevant when ownership changed several times.

Caveats that save time

Be careful with registry cleanup

Microsoft’s own article warns that incorrect registry edits can create serious problems. Back up the relevant keys before deleting them. In production, that means your runbook should specify exactly which keys are in scope, not “delete anything that looks MDM-related.”

Do not assume the cloud is the problem

These two errors often look like Intune service failures to junior technicians because enrollment never starts cleanly. In reality, Microsoft’s documented causes are mostly local state and ownership collisions.

Re-enrollment is not the same as a fresh build

A reimaged device that still carries old management artifacts is not a clean test case. If the machine was reused, verify the previous enrollment really got removed.

Shared test accounts create noise

If multiple admins take turns enrolling the same laptop under different accounts, you can recreate 8018000A easily. Use named pilot users and a documented ownership handoff.

When to escalate

Escalate beyond frontline cleanup when any of these are true:

• The same error affects multiple freshly built machines from one image.
• You removed the documented local artifacts and the failure still returns.
• dsregcmd /status shows an unexpected join state that does not match the intended deployment design.
• The device is part of Autopilot, shared device, or hybrid join workflows that require cloud and on-prem coordination.

At that point, attach the MDM diagnostics ZIP, device serial number, current join state, and the exact cleanup steps already performed. That prevents the next engineer from starting over.

The short version

For 8018000A, think wrong user already connected. For 0x8007064C, think old enrollment residue or cloned image. Microsoft’s documented fix is not broad Intune surgery. It is a controlled cleanup of the existing work account, the old Intune certificate, the OnlineManagement registry branch, and in stubborn cases the old installer product key.

If you separate those scenarios early, these incidents stop being long mystery tickets and turn into a predictable enrollment repair workflow.