MDM admin sees successful policy push but device never checks in after carrier swap

Field Summary

MDM admin sees successful policy push but device never checks in after carrier swap is a Mobile Device Management ticket where the visible symptom can be misleading. Endpoint tickets usually live in profile state, local services, drivers, update health, management policy, encryption, or security tooling. Prove whether the issue follows the user or the machine before rebuilding anything. The fastest path is to identify which layer changed and prove it with logs or a repeatable test.

Common Symptoms

• Issue follows one device or one user profile
• A service, driver, update, enrollment, or encryption change happened recently
• Management console looks healthy but endpoint behavior fails

Fast Triage

1. Record device name, user, OS/build, last reboot, and recent changes.
2. Check Event Viewer, services, Device Manager, management portal, or security alerts as relevant.
3. Test another user or device if it isolates profile versus machine.
4. Capture exact error before remediation.

Likely Causes

• Local profile corruption
• Service or agent hung
• Driver/update regression
• Policy/enrollment mismatch
• Security tool block
• Encryption protector or escrow issue

Useful Commands

sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
manage-bde -status

Tier 1 Fix Path

1. Restart the affected app or service when safe.
2. Apply a pending reboot only when user impact is acceptable.
3. Run basic repair checks when OS/update behavior points there.
4. Do not remove encryption or management enrollment as a first step.

Tier 2 / Admin Investigation

1. Review policy assignment, agent/service logs, event logs, update history, driver version, and security quarantine.
2. Compare against an endpoint in the same policy.
3. Check whether the problem follows profile, device, network, or policy.
4. Use repair/reinstall only after logs show component failure.

Advanced Remediation

Profile rebuilds, agent reinstalls, decryption, and reimage work should follow logs and backup/escrow checks, not guesswork.

Verification

• The affected workflow succeeds from the user side.
• The relevant portal/log shows a clean result at the same timestamp.
• The result survives app restart, reconnect, policy refresh, or reboot when relevant.
• No broad bypass or unrelated change was introduced.

Ticket Notes to Capture

• Affected user/device/site/customer
• Exact symptom, error, timestamp, and screenshot or log excerpt
• Scope tested and working comparison used
• Relevant logs/portals checked
• Root cause or most likely layer
• Fix applied and verification result

Escalate When

• Multiple users, sites, or business-critical workflows are affected
• Logs point to vendor, server, security, or policy ownership outside your access
• A disruptive remediation is required
• The same symptom returns after a verified fix

Prevention

Add the final root cause, detection signal, and validation step to the client runbook. If a change caused the issue, add a post-change check that would catch it next time.