HomeKb › Kme housekeeping traps
Knowledge base · Android

KME housekeeping traps: unapproved uploads and reseller-only re-adds

Two quiet Knox Mobile Enrollment (KME) housekeeping traps, both documented by Samsung: reseller device uploads wait silently in a pending queue until an admin approves them, and deleting a device from the Knox portal can be a one-way door that only your reseller can reopen.

The problem

You hand a box of new Samsung devices to users and every one of them boots straight into an ordinary personal setup — no Knox Mobile Enrollment screen, no enrolment profile, no record in your MDM, and no error anywhere to tell you why. Or the reverse scenario: you tidied up the Knox portal, deleted some stale device entries, and now find there is no button anywhere in your console to add them back.

Both traps catch competent admins because the console gives no warning at the point of failure:

Anyone receiving reseller-purchased Samsung fleets into Intune (or any MDM) via KME can hit the first trap; anyone doing routine Knox console housekeeping can hit the second.

Why it happens

KME's trust model explains both behaviours. Device records enter your Knox tenant through your reseller, who uploads the device identifiers they sold you against your customer ID. Samsung treats that upload as unconfirmed until an admin accepts it — the get-started guide is explicit: "Once your reseller uploads devices to the console on your behalf, you must approve them on the UPLOADS tab of the Devices page." The approval guide adds that you "must first approve these uploaded devices prior to enrolling or configuring them."

Nothing downstream flags the pending state. A device has no relationship with KME until its record is approved and an enrolment profile assigned, so at first boot it simply runs a normal consumer setup. Your MDM never sees an enrolment attempt, so there is no failure to log — it is a silent no-op, which is why the UPLOADS tab is worth checking before anything else.

Deletion is one-way for the same structural reason: your console consumes device records, it does not mint them. Samsung's device-management documentation spells out the consequence: "Once devices are deleted from all services, you must contact your reseller to re-upload them back into your account." Third-party MDM vendors document the same dependency — ManageEngine's Knox enrolment guide notes that "the Reseller needs to be informed to add the devices again". There is one narrow escape hatch: if the device was registered with more than one Knox cloud service and you deleted it only from KME, the record still exists in the Knox Admin Portal's common device list and can be recovered from there.

The fix

Why isn't my Samsung picking up its KME profile?

  1. In the Knox Admin Portal, open Devices and select the UPLOADS tab.
  2. Find the reseller's upload batch and click View in the Details column to see the pending devices.
  3. Click Approve all (or approve selectively). Status moves from Pending to Approved.
  4. Assign an enrolment profile to the newly approved devices — approval alone does not attach a profile unless you have configured a default.
  5. Factory-reset any device that already went through consumer setup; it picks up KME during the out-of-box experience once its record is approved and a profile is assigned.

Then prevent the recurrence: in each registered reseller's preferences you can enable Auto approve devices and set a default enrolment profile, so future uploads flow straight through with no queue to remember.

I deleted a device from the Knox portal — how do I get it back?

  1. Check whether the device still exists in another Knox cloud service (Knox Manage, Knox Guard, and so on). If it does, open the Knox Admin Portal's common device list and assign an enrolment profile — that recovers the KME registration without involving the reseller.
  2. If the device was deleted from all Knox services, only your reseller can restore it. Send them the IMEIs or serial numbers and ask them to re-upload against your customer ID. The upload then lands in your UPLOADS queue — approve it as above.

Prevention beats the cure here:

How Decolla handles it

Honestly: it doesn't. Decolla provisions Windows devices over your organisation's own Intune and Autopilot tenant — it has no involvement in Samsung Knox or Android enrolment, so it cannot approve your uploads or recover a deleted Knox record.

What Decolla is built around is the exact discipline this article recommends: knowing which actions are one-way before you take them. Every Decolla deployment starts with a written, itemised plan — each item shows its delivery method and a reversibility class (automatic, reversible, or irreversible and flagged for explicit sign-off) — and nothing runs until that plan is approved. Afterwards, Decolla's own changes can be rolled back per item. If the Knox console flagged "delete device" the way Decolla flags irreversible items, this article would not need to exist. Decolla is pre-launch; the waitlist is open at decolla.app.

Sources

See it on a real device.

Decolla is in private build — early-access members see a build defined, deployed and rolled back first.

Get early access