OEMConfig policy says "success" in Intune but the setting never applies on the device

Intune's green tick on an OEMConfig profile means the configuration was delivered to the OEM's app — not that the device enacted it. Here is where that trust gap comes from, the documented Knox Service Plugin failure modes behind it, and how to verify what the device actually did.

The problem

You deploy the Knox Service Plugin (KSP) via Microsoft Intune to fully managed Samsung Android Enterprise devices, with an OEMConfig profile setting something simple — say, Screen timeout = 5 minutes. The app installs, Intune reports the profile as Succeeded, and the device carries on exactly as before. The setting never changes.

This is the case documented in the Android Enterprise community thread linked below. The admin confirmed every prerequisite: fully managed devices, Intune MDM, KSP deployed through managed Google Play. The policy showed as applied in the console. The device ignored it.

The tell-tale detail is the workaround: opening the KSP app on the device and tapping Apply latest configuration made the setting take effect immediately. So the configuration had unquestionably reached the device — it just was never enacted. That is not a sync problem, a targeting problem, or a syntax problem. It is a reporting-plane problem: the console says green while the device does nothing.

Anyone managing Android devices through an OEMConfig app can hit this class of issue — KSP on Samsung is simply the most widely deployed example. The pattern also transfers conceptually to any MDM whose "applied" status describes delivery rather than outcome.

Why it happens

OEMConfig works in two stages, and Intune's status only describes the first:

1. Delivery. Intune hands your settings to managed Google Play as an Android managed configuration — a bundle of key/value pairs addressed to the OEMConfig app (KSP). When that bundle lands on the device and is accepted for the app, Intune reports success.
2. Enactment. The OEMConfig app must then wake up, parse the bundle, and call the OEM's own device APIs (the Knox SDK, in Samsung's case) to change actual device state. Intune has no per-setting visibility into this stage. A failure here does not turn the console red.

"Profile applied" therefore asserts only: the configuration was delivered to the OEMConfig app. Whether the device did anything with it is a separate question with separate failure modes — several of them documented:

• Android 13 foreground-service denial. In the community thread, Samsung's log analysis found KSP was, in the admin's words, "attempting to start a foreground service, but getting denied" on Android 13. Recent Android releases have progressively restricted when apps may start foreground services from the background — and enacting a freshly delivered configuration is exactly the kind of background-initiated work those restrictions catch. KSP received the bundle but its enactment service was blocked. Manually opening the app puts it in the foreground, where the work is permitted to run — which is why the Apply latest configuration tap works.
• Prerequisite-setting dependencies. Many KSP keys are gated behind a parent enable toggle within the same schema. If the parent control is off, the child settings are silently ignored — with no error surfaced anywhere.
• Licence activation. KSP policies depend on a valid Knox Platform for Enterprise licence key supplied in the profile. If licence activation fails on the device, policies do not enact.
• Schema/app version mismatch. An older KSP app version does not understand newer schema keys and will ignore them, again without turning the console status red.

In the documented thread, the admin had tickets open with both Microsoft and Samsung, and at the time of the final post (January 2024) automatic application still had not been restored — the root cause sat in the Android 13 conflict with the app's foreground-service initialisation, not in the Intune profile itself.

The fix

You cannot make Intune's status colour mean something it does not mean. What you can do is verify enacted state deliberately, and know where to look when delivery and enactment disagree.

1. Verify on the device, not in the console. Check the actual setting (for the example above: Settings → Display → Screen timeout). This thirty-second check is the only ground truth available.
2. Read KSP's own results screen. Open the Knox Service Plugin app on the device — it reports the results of applying its configuration, per policy area. Enable Debug Mode in your KSP profile to get verbose, per-key results in the app's UI. This is the enactment-plane report that Intune's status does not carry.
3. Unblock a stuck device. Tap Apply latest configuration in the KSP app. Treat this as a diagnostic signal, not a solution — if it works, delivery was fine and enactment was blocked, which points at the foreground-service class of failure.
4. Update KSP via managed Google Play. OS-conflict bugs such as the Android 13 foreground-service denial are fixed on the app side; running the current KSP build is the actual remediation path. Re-check enacted state after the update, not just the console.
5. Check prerequisites inside the schema. Confirm the parent toggle for each policy group is enabled, and that the Knox Platform for Enterprise licence key in the profile is present and valid.
6. Re-verify after every major OS update. Behaviour changes like Android 13's foreground-service tightening are precisely when green reporting drifts away from device reality. A profile that was genuinely working can stop enacting without any console change.
7. Make enacted-state verification part of your rollout process. After any OEMConfig change, physically confirm the outcome on at least one pilot device before broadening assignment. Write down what "verified" means for each setting so it is a checklist item, not a vibe.

How Decolla handles it

Straight answer first: Decolla does not fix this issue. Decolla provisions Windows devices over your own Intune/Autopilot tenant — it does not manage Android, Samsung Knox, or OEMConfig at all. If you arrived here for the KSP problem, the section above is the useful part; nothing we sell changes it.

The reason this article lives in our knowledge base is that the underlying trust gap is not an Android quirk. Windows admins meet the same thing: a console that reports a profile as delivered while the device's enacted state says otherwise. Decolla is built around not trusting status colours:

• Every build starts from a written, itemised plan — each item lists its delivery method and reversibility class (automatic, reversible, or irreversible and flagged) — which you approve before anything runs.
• Deployment then runs unattended in your tenant, and Decolla's verification step checks enacted device state, not console status colours — the difference between a build that reports green and a build that is green.
• Anything Decolla changed can be rolled back per item. (Rollback covers Decolla's own changes only — it is not a general undo for your tenant.)
• The Library — 260+ pre-built, industry-tested policies, scripts and fixes across 21 sections — exists because "the console says applied" and "the device is right" are two different claims, and only the second one counts.

Decolla is pre-launch and waitlist-only at decolla.app.

Sources

• Android Enterprise community: OEM Config policy with Samsung Knox Service Plugin — the documented case: policy "applied" in Intune, device unchanged, manual "Apply latest configuration" workaround, and Samsung's log analysis showing the Android 13 foreground-service denial.
• Samsung Knox documentation: Knox Service Plugin admin guide — KSP prerequisites, schema structure, and Debug Mode.
• Android developer documentation: foreground services — the platform restrictions behind the enactment-service denial class of failure.