Co-management promises the best of both worlds: the on-premises power of Configuration Manager and the cloud agility of Microsoft Intune. But when remote actions like Wipe start failing, that promise quickly turns into a support nightmare.
You click Wipe in Intune. The console happily shows Pending. Hours pass. Nothing happens on the physical device. No reset, no factory default—just silence.
If this sounds familiar, you’re not alone. Co-managed devices have unique behavioral quirks that can block a wipe command even when everything looks healthy. Let’s dig into why this happens and exactly how to fix it.
Why Wipe Commands Get Stuck in Co-management
A wipe command is not a simple instruction. It must travel from Intune → Windows Notification Service (WNS) → the device’s MDM agent → the native Provisioning CSP. In a co-managed environment, several things can break that chain.
1. Workload Authority Misalignment
Contrary to popular belief, core MDM commands like Wipe do not require every workload slider to be moved to Intune. However, a common failure scenario occurs when no workload has ever been transitioned—the device remains in a pure ConfigMgr‑managed state with only a lightweight MDM enrollment. In that case, the device may reject the wipe because it does not recognize Intune as a co-authority for state‑change actions.
Fix: Transition at least one workload (e.g., Compliance Policies or Client Apps) to Pilot Intune for the target device collection. This forces a full MDM enrollment handshake and establishes Intune as a legitimate command authority.
2. MDM Channel Communication Breakdown
Co-managed devices use both the Intune Management Extension (IME) and the native Windows MDM agent. If the device has not performed a hardware inventory or discovery cycle since the co-management state changed, the wipe command may never be recognized.
The MDM agent needs to pull the command from Intune. No sync → no wipe.
3. WNS Latency or Blockage
The Wipe command is not a real‑time push. Intune uses WNS to wake the device, telling it to check in. If WNS is blocked by a firewall, proxy, or broken handshake, the device never receives that wake‑up signal. It will eventually poll Intune on its own (every 24 hours or after a user sign‑in), but that delay often leads to “stuck Pending” status in the console.
4. Device State Conflicts
If the device is in the middle of a ConfigMgr task sequence, an update deployment, or a pending reboot, the native Provisioning CSP may delay or outright reject the factory reset request until the local process completes. Worse, if the ConfigMgr agent is stuck in Provisioning Mode, it will block any MDM‑initiated state change.
Quick Diagnostic Checklist
Before diving into logs, verify these fundamentals:
- Network – Can the device reach
*.notify.windows.comand*.manage.microsoft.com? (Port 443, outbound) - Licensing – Does the last signed‑in user have an active Intune license? Expired licenses can restrict the MDM channel.
- Client state – Is the ConfigMgr agent in Provisioning Mode? (We’ll show you how to check below.)
Technical Verification Steps
1. Event Log Analysis
Open Event Viewer and navigate to:
Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin
Look for:
- Event ID 1202 – MDM server successfully sent a command to the client.
- Event ID 1205 – Client acknowledged receipt of the command.
If you see 1202 but not 1205, the device never picked up the command (sync issue). If you see neither, the command never left Intune (possible workload authority issue).
2. IME Log Review
The Intune Management Extension logs everything related to side‑car actions.
Path: C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log
Search for RemoteAction or Wipe. If you find entries like “Wipe command received but MDM authority not set to Intune”, you’ve identified the root cause.
3. WMI Query for MDM Authority
Run this PowerShell command on the affected device (as SYSTEM or admin):
Get-CimInstance -Namespace root\microsoft\management\mdm -ClassName MDM_ConfigSettingExamine the MDMAuthority property:
ConfigMgronly → Wipe will likely be ignored.IntuneorCoManaged→ Good.
4. Force an MDM Sync (Bypass WNS)
If you suspect WNS is the problem, manually trigger the MDM sync schedule:
Get-ScheduledTask -TaskName "\Microsoft\Windows\EnterpriseMgmt\*-Schedule" | Start-ScheduledTaskThen check the same diagnostic log for Event ID 1411 (sync requested) and 1412 (sync completed with command count). A non‑zero command count means the wipe was waiting.
5. Check ConfigMgr Provisioning Mode
From a PowerShell prompt (admin):
# Change to CCM directory
cd C:\Windows\CCM
.\WmiBridgeClient.exe get "CCM_ClientProvisioningStatus" -namespace "root\ccm"If ProvisioningMode = TRUE, the ConfigMgr agent is in a provisioning state (e.g., a running task sequence) and will block MDM wipe. Cancel or complete the task sequence, then retry.
6. Verify WNS Channel Health
Run the device registration status tool:
dsregcmd /statusLook under the Device State section:
DeviceJoined = YESIsComanaged = YESWNSChannel– should showActiveorConnected
If the WNS channel is Inactive or missing, check firewall/proxy rules.
Strategic Alternatives When Wipe Refuses to Cooperate
Sometimes, even after all checks, the wipe command remains stubbornly pending. In those cases, consider these alternatives.
Autopilot Reset
For devices that need to be repurposed, Autopilot Reset can be more resilient because it uses the ResetProtection CSP and doesn’t rely on a healthy local recovery environment (WinRE). However, it still requires a working MDM channel and TPM attestation.
Fresh Start (Recommended for Co-management)
Fresh Start downloads a clean OS image from Microsoft, bypassing corrupt local policies or ConfigMgr agent states. It is the most reliable option for co-managed devices with deep‑seated client issues.
Remote Retire
If your goal is only to remove corporate data (not to factory reset the device), use Retire instead of Wipe. Retire performs a selective wipe of management profiles and Intune‑provisioned apps via the IME, which tends to succeed even when a full wipe fails.
Temporary Workload Transition
As a last resort, move the Compliance Policies workload to Pilot Intune (or fully to Intune) for the affected device collection. This forces the device to re‑establish the MDM channel with Intune as a co‑authority. Once the wipe completes, you can move the workload back.
Final Thoughts
A wipe command that hangs on “Pending” in a co‑managed environment is rarely a mystery—it’s almost always one of the four root causes outlined above. The key is systematic troubleshooting: check WNS, check MDM authority, check ConfigMgr provisioning state, and force a sync.
And remember: when all else fails, Fresh Start is your co‑managed get‑out‑of‑jail‑free card.
If you’ve run into other weird remote action behaviors on co-managed devices, drop a comment below—I’d love to hear your war stories.
