Devices unexpectedly factory resetting or reverting Blueprint: Samsung Knox MDM issuing wipe commands in parallel with Esper

Android

If your Android devices are experiencing unexpected factory resets or reverting to unintended Blueprints, the cause may be Samsung Knox issuing wipe commands in parallel with Esper. This article explains how to diagnose and resolve this dual-MDM conflict.

Understanding the issue

When devices are enrolled in both Esper and Samsung Knox MDM simultaneously, factory resets can be triggered by the Knox management layer instead of Esper. These resets occur without any visible action in your Esper Console, which can make it appear that Esper is causing the problem.

After a Knox-initiated reset, your device re-enters the Android setup and provisioning flow. Depending on your provisioning configuration, it may re-provision to an unintended Blueprint or fail to re-provision entirely.

Before you begin

You'll need:

• Access to your affected device's recovery logs
• Admin credentials for your Samsung Knox account (if applicable)
• The device's serial number

Step 1: Confirm the reset reason in device logs

Pull your device's recovery logs to determine whether the reset was initiated by Knox or another component.

1. In the Esper Console, go to Devices & Groups → [Device Name] → Actions → Bug Report to request logs from the device.
2. Alternatively, collect logs directly using ADB:

   adb shell cat /cache/recovery/last_kmsg

   or

   adb shell dumpsys device_policy

3. In the logs, search for the string DeviceWipeByMDM(com.sec.enterprise.knox.cloudmdm.smdms). If this string is present, the reset was triggered by Samsung Knox, not Esper.

Step 2: Check your Samsung Knox command history

If you confirmed a Knox-initiated reset, log into your Samsung Knox admin portal to identify what triggered it.

1. Go to https://www.samsungknox.com and sign in with an admin account.
2. Navigate to Knox Manage → Devices and locate the affected device by its serial number.
3. Open the device record and select the Command History tab.
4. Look for any Factory Reset, Wipe, Unenroll, or Remote Lock commands issued around the time of the unexpected reset.

Step 3: Remove or modify the conflicting Knox policy

Once you've identified the Knox command that triggered the reset, take action to prevent it from happening again.

1. Determine whether the command was issued manually, by a compliance policy, or by an automated rule.
2. Disable or modify the offending Knox policy in your Knox Manage configuration.
3. If no one in your organization currently has Knox admin access (for example, due to multi-factor authentication or outdated credentials), use Samsung Knox's account recovery process to regain access. This may take several days to weeks.

Step 4: Monitor for recurrence

After you've removed the conflicting Knox trigger, verify that the issue is resolved.

1. In the Esper Console, go to Devices & Groups → [Device Name] → Device History and monitor the device for any new unexpected resets.
2. Request new bug reports from the device over the next few days.
3. Confirm that no new entries with reset reason DeviceWipeByMDM appear in the recovery logs and that the device remains on the assigned Blueprint without reverting.

If the issue persists

Try the following troubleshooting steps:

• Knox Command History shows no wipe commands: The device may be enrolled in a different Knox-integrated MDM (not Knox Manage). Check for other third-party EMM or MDM registrations using the Knox license key applied to the device.
• Reset reason string does not match: If the recovery logs show a reset reason string that does not contain com.sec.enterprise.knox.cloudmdm.smdms, the cause may be a different component. Contact Esper Support and provide the full bug report, device history, and exact reset reason string from the recovery logs.
• Wrong Blueprint after reset: If devices are continuing to re-provision to the wrong Blueprint after Knox is ruled out, check your provisioning configuration in the Esper Console. Go to Devices & Groups → [your group] → Settings → Default Blueprint and verify the correct Blueprint is assigned.
• Multiple devices across different groups affected: If reset events are confirmed as not Knox-originated, or if the issue recurs after you've corrected Knox policies, contact Esper Support with details about the affected Devices & Groups.

Still need help?

If you've completed these steps and the issue persists, submit a support ticket with the following information:

• Device serial numbers affected
• The exact reset reason string from your recovery logs
• Screenshots of your Knox Manage command history (if applicable)
• Full device bug reports or ADB logs from the affected devices
• A timeline of when the resets began