Recovering from a bad Intune deployment without making it worse

Stop the spread, unwind the damage, verify it took. A failure-mode-to-action playbook for when a config profile, app push, or CA policy goes sideways.

The first move when an Intune policy goes wrong is almost always to stop the spread, not to undo the damage. Remove the assignment, add an exclude filter, or pause the rollout before you start triaging. Undo can wait five minutes. Another thousand devices checking in cannot.

Intune has no undo button. What it has is roughly a dozen levers you can pull in sequence, and the job is matching the right one to what actually broke. Pull the wrong lever and you turn a config profile mistake into a fleet-wide reimage.

The first five minutes

Before you diagnose anything, contain it.

Find the policy or app in the admin center and either remove the group assignment or add an exclude assignment filter. Filters evaluate at check-in and stop future delivery without touching what’s already been applied. Reporting takes up to 30 minutes to catch up, so trust the configuration view, not the dashboard counts. (Create assignment filters)
Open Tenant administration > Audit logs. Logs are retained for two years and cannot be deleted, so you have time to read carefully, but you want to know now who changed what and when. (Use audit logs to track and monitor events)
Force a sync on the affected devices. Without it, the Windows MDM client follows its own schedule: every 3 minutes for 15 minutes after enrollment, every 15 minutes for 2 hours, then every 8 hours. Eight hours is a long time to wait for a remediation to land. Bulk sync handles up to 100 devices at a time from Devices > Bulk device actions; for anything larger, hit the Graph endpoint POST /deviceManagement/managedDevices/{id}/syncDevice in a loop. (Remote Device Action: Sync, When does a Windows client sync with Intune?)

Containment first. Diagnosis second. Recovery third.

The tattooing trap

Removing the assignment is the obvious first move and the wrong one for tattooed settings.

Microsoft’s own troubleshooting docs say the quiet part out loud: “Some CSPs remove the setting, and some CSPs keep the setting, also called tattooing.” There is no master list of which CSPs tattoo and which revert. (Troubleshoot device configuration profiles)

What is documented:

USB blocking policies tattoo. Removing the assignment does not unblock the ports.
Firewall rules revert. Removing the profile deletes the rules. Watch for the inverse problem: you removed the policy and now the firewall is wide open.
VPN, Wi-Fi, certificate, and email profiles are removed when the assignment goes. That is documented behavior, not a bug, and it is the most common way a “rollback” leaves users without network access. (Patch My PC — Intune policy tattooing)

For tattooed settings the recovery is not “remove the policy.” It is “push a new policy with the correct value to overwrite what’s stuck.” Confirm the device actually applied the change by checking the MDM event log for Event ID 819, which fires when the CSP accepts the new configuration.

Identify what broke

Three views earn their place on the screen:

Per-setting status on the policy itself. Tells you which specific setting is failing and on how many devices. Critical when one of fifty settings is the only one in conflict.
Device assignment status for that policy. Per-device, filterable, exportable to CSV. (See device configuration policies)
IME logs on a sample affected device, at C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\. This is where Win32 app failures and PowerShell script errors actually surface.

If you see a config profile reporting error code 2016281112, the Windows CSP returned XML that didn’t match what Intune sent. That almost always means two policies are fighting over the same setting and the conflict, in Microsoft’s words, “must be manually resolved.” Neither value applies cleanly until you pick one. (Device configuration profile error 2016281112)

Recovery action by failure mode

Failure mode	First action
Config profile conflict (error 2016281112)	Identify the conflicting policy in per-setting status, resolve manually
Tattooed setting stuck after removal	Push corrective policy with desired value, confirm Event ID 819
Required app won’t install (0x87D1041C)	Fix the detection rule; the install ran but Intune can’t see it
App needs to be removed fleet-wide	Push same app with Uninstall intent, but remove Required first
Compliance policy locking users out	Add grace period or exclude affected group; check encryption-method mismatches
Conditional Access lockout	Sign in with break-glass account excluded from CA
ASR rule deleting legitimate files	Switch rule to Audit mode, run recovery script if files are gone
Bad PowerShell remediation looping	Unassign script, push corrective remediation, check 32-bit vs 64-bit registry hive
Autopilot ESP stuck (0x81036502)	Required ESP app failed detection or its dependency isn’t staged
BitLocker key needed	Devices > [device] > Monitor > Recovery keys

A few of these need expanding.

App pushes: Required beats Uninstall

For Win32 apps, Required always wins over Uninstall when both apply to the same device. If you push an app with Uninstall intent and nothing happens, the Required assignment is still in place. Remove the Required first. Also note: Available does not uninstall. Removing an Available assignment is a no-op on already-installed apps, and Uninstall only works on Intune-managed installs in the first place. (Add and Assign Win32 Apps)

If users report a required app stuck “install pending” after Autopilot, the cause is often not your config. Intune has a hardcoded 3,600,000 ms (one hour) timer before required apps appear in the check-in queue after OOBE sign-in. (Why Do Required Apps Wait 60 Minutes After Autopilot Enrollment?)

Compliance and Conditional Access

The NHSmail incident from September 2025 is the textbook example: Intune-enrolling devices defaulted to XTS-AES 128-bit BitLocker while the compliance policy required 256-bit, so every newly enrolled device was marked non-compliant and blocked from Microsoft 365. Microsoft developed a remediation script for it. (NHSmail — Intune Conditional Access policy preventing access)

If you push a CA policy and lock yourself out, the recovery is the break-glass account: a cloud-only emergency access account on the *.onmicrosoft.com domain, excluded from all CA policies, secured with FIDO2 or certificate-based auth. Microsoft requires at least two. If you don’t have one and the Global Administrator is locked out too, you’re opening a tenant-lockout case with Microsoft Support and waiting hours for identity verification. (Manage emergency access admin accounts)

ASR rules eating files

On January 13, 2023, Defender security intelligence builds 1.381.2134.0 through 1.381.2163.0 caused the “Block Win32 API calls from Office macro” ASR rule to flag .lnk shortcut files as malicious and delete them across Intune-managed fleets. Shortcuts vanished from desktops, Start Menus, and taskbars. Microsoft disabled the rule and published a PowerShell recovery script, tracked as SI MO497128. (BleepingComputer — Buggy Microsoft Defender ASR rule deletes Windows app shortcuts, Microsoft Tech Community recovery guidance)

The pattern matters more than the incident. When an ASR rule starts deleting things, switch it to Audit mode first, then chase the recovery. Block-mode rules don’t stop just because you opened a ticket.

PowerShell remediations

Two failure modes account for most of the pain. First, the 32-bit hive trap: the Intune Management Extension runs scripts in 32-bit context, so writes to HKLM:\SOFTWARE\ land in HKLM:\SOFTWARE\WOW6432Node\. Detection scripts looking at the native path then fail every cycle, and the remediation runs forever. Second, scripts running longer than 30 minutes are silently killed with no error in the portal. (PowerShell Scripts for Remediations)

Escalating force

When config-level fixes aren’t enough, Intune offers a ladder:

Action	Stays enrolled?	User data?
Restart	Yes	Yes
Collect Diagnostics	Yes	Yes
Retire	No	Yes
Fresh Start	Yes (re-enrolls)	Optional
Autopilot Reset	Yes	No
Wipe	Optional	No

Collect Diagnostics retains data for 28 days, up to 10 collections per device, and is what you want before any destructive action. (Collect Diagnostics, Retire or wipe devices)

If BitLocker recovery is part of the fix, the keys are at Devices > [device] > Monitor > Recovery keys in the Intune admin center, or in Entra under Identity > Devices > [device] > BitLocker keys. The account needs microsoft.directory/bitlockerKeys/key/read. Keys only escrow automatically if encryption happened after enrollment with an active escrow policy. (Get BitLocker recovery key)

When to escalate

Open the support case when you can’t isolate the failure to a single policy, when a Microsoft service-side bug is suspected, or when device wipes are starting to look like the answer. Microsoft will ask for the correlation ID from the failed operation, the IME logs from the path above, a Collect Diagnostics CAB, and MdmDiagnosticsTool.exe -area "DeviceEnrollment;DeviceProvisioning" output. Have them staged before you open the ticket. (Get support in the Intune admin center)

What you wish you had today

Most of the recoveries above would have been a non-event with three things in place: a deployment ring structure that catches the problem before it hits production, a break-glass account that survives a bad CA policy, and a JSON backup of the policy you were about to change. The Windows Autopatch model splits the fleet into First (1-5%), Fast (9-15%), and Broad (80-90%) rings for exactly this reason. Pair that with a community tool like IntuneBackupAndRestore and a dev tenant from the Microsoft 365 Developer Program, and the worst case becomes a 20-minute rollback instead of an all-day outage. (Windows Autopatch groups overview)

The reason most “bad Intune deployment” stories are bad isn’t the deployment. It’s that there was no ring, no break-glass, and no backup, so the only available move was to live with the consequences. Build those three before you need them. PatchDay Alert’s daily digest covers the Intune-adjacent CVEs and Microsoft service incidents that tend to land in the rings you forgot to set up.