When Intune Enrollment Won't Stick: Registry Cleanup, Reimaging, and What We Learned

The Problem

We had a device that wouldn't enroll in Intune. The enrollment failure seemed straightforward at first—until we dug into the logs.

The root cause: a misspelled email address in the user's Active Directory account. Simple typo, big impact. The device had attempted enrollment multiple times and failed each time, leaving behind stale registry artifacts that wouldn't clear themselves.

What We Tried

We didn't immediately reimage. We ran through the standard recovery steps:

Kerberos key rollover. The customer had recently performed a key rollover on their Entra Connect instance, which had resolved enrollment issues for other devices. This one stayed stuck.

Registry cleanup. We ran an enrollment registry cleanup script and executed dsregcmd /forcerecovery. The device still wouldn't pick up MDM URLs. Windows showed the device status as WillNotProvision—a state that usually means the device has given up on itself.

More digging. We confirmed the email mismatch in AD, fixed it, tried again. Still nothing. At that point, the registry was too contaminated with failed enrollment attempts. The device had written down "I can't enroll" and wasn't going to change its mind.

The Decision

Reimage it.

Before that happened, we made sure to:

• Delete the device object from Active Directory
• Remove it from Entra ID
• Check Autopilot registration and clean that up too

This prevents the device from picking up the same bad state during a fresh Windows setup.

Windows Update Rings: Configuration Review

While we were in the environment, we also reviewed and updated their Windows Update deployment rings.

Ring 0 and Ring 1 configuration:

• Enabled driver updates across both rings
• Clarified deferral periods—how long to wait before forcing an update
• Set deadlines and grace periods so devices know when they have to restart
• Defined maintenance windows so updates don't surprise users mid-workday

Feature update strategy:
The customer is deploying 25H2. We recommended treating it as optional first—push it to a pilot group, catch any app compatibility issues, then move to required deployment in waves using targeted device groups. This is the safer path for line-of-business applications.

What Stuck With Us

The enrollment issue was fixable until it wasn't. Once the registry got too dirty, recovery commands hit a wall. The lesson: catch and fix enrollment problems early. A misspelled email in AD sounds minor, but the longer a device stays in a failed state, the more junk it writes to the registry.

For the reimage—make sure Autopilot is clean before you start. A fresh OS hitting dirty Autopilot registration is just going to fail again.

Where This Breaks in Production

This doesn't show up in new deployments.

It shows up in environments where:

• Devices have been enrolled, unenrolled, and re-enrolled multiple times — often across different enrollment methods (GPO-joined, Autopilot, manual Company Portal)
• Legacy management coexists alongside Intune: SCCM co-management, old GPOs, third-party agents that were never fully removed
• The environment went through a migration without a full device state cleanup

Over time, the device accumulates management state that Intune can't cleanly reconcile. Policies apply partially, compliance flips unpredictably, and re-enrollment fixes it temporarily before the same behavior returns.

If This Is Happening in Your Environment

Enrollment instability is rarely just an enrollment problem.

It's usually a sign that device management state, policy enforcement, and identity are out of alignment across the environment — and the inconsistency compounds over time.

If your devices enroll but don't behave predictably, or if you're seeing the same devices cycle through re-enrollment repeatedly, that's typically where we get brought in.

We don't rebuild from scratch — we fix and stabilize what's already there.

→ itccinc.com