Only one OEMConfig profile per app per device — why stacking profiles causes silent chaos

Splitting OEMConfig settings into a base profile plus site-specific overlays feels like good hygiene. On Android it is a trap: the platform stores exactly one managed-configuration payload per app per device, so stacked profiles overwrite and race each other — with no conflict warning anywhere in Intune.

The problem

You manage rugged or dedicated Android devices — Zebra scanners, Samsung kiosks, Honeywell handhelds — through Intune with OEMConfig. You did the sensible-looking thing: one base OEMConfig profile with your organisation-wide settings, plus a second site-specific profile per depot or store. Both are assigned to the same devices.

Then the weirdness starts. A setting you configured in the base profile is present after one check-in and gone after the next. Two devices in the same group behave differently. Kiosk lockdowns half-apply. Nothing in the Intune admin centre flags a conflict — device configuration status can show every profile as Succeeded while the device itself flip-flops.

This is documented, if bluntly. Microsoft's OEMConfig documentation states:

"the OEMConfig model only supports a single policy per device. If you assign multiple profiles to the same device, you can see inconsistent behavior."

Zebra devices are the one partial exception — Intune allows multiple OEMConfig profiles there — but Microsoft's Zebra OEMConfig documentation adds its own caveat:

"the order that profiles are deployed isn't guaranteed."

So on non-Zebra hardware, two OEMConfig profiles on one device is an unsupported configuration that fails silently. On Zebra, it is supported but nondeterministic in ordering. Either way, you get devices whose state depends on sync timing rather than on your intent.

Why it happens

OEMConfig is not a normal Intune device-configuration profile. Under the hood it is an Android Enterprise managed configuration (app restrictions) targeted at the OEM's own agent app — Samsung's Knox Service Plugin, Zebra's OEMConfig app, Honeywell's UEMConnect, and so on.

One restrictions bundle per app

The pipeline works like this:

1. The OEM publishes an OEMConfig app on Google Play with an embedded configuration schema.
2. Intune renders that schema in the profile designer; what you build is serialised into a single app-restrictions payload.
3. The payload is delivered through Google Play's managed-configuration channel to the OEMConfig app on the device, which then applies the settings via the OEM's device APIs.

The critical constraint sits in step 3: Android holds exactly one managed-configuration bundle per app per device (or per work profile). There is no layering, no merge, no precedence order. Assigning a second OEMConfig profile does not add a second bundle — it creates a second writer to the same bundle. Whichever profile Intune processes last wins, and because that depends on sync and processing timing, the winner can change from one check-in to the next. That is the flapping you are seeing.

Why there is no conflict warning

For ordinary configuration profiles, Intune understands each setting and can report conflicts. An OEMConfig payload is opaque to Intune: the schema belongs to the OEM's app, and Intune's job is only to build the bundle and hand it over. It cannot compare two payloads setting-by-setting, so it cannot detect that your base and site profiles both set (or contradict) the same value. Both profiles report success, because from Intune's perspective each delivery did succeed — briefly.

The Zebra exception, and its limit

Zebra's OEMConfig app is built to accept multiple configurations and process them as transactions, which is why Intune permits multiple OEMConfig profiles on Zebra devices specifically. But delivery ordering across profiles is not guaranteed — a Google Play managed-configuration limitation, not something Intune or Zebra can override. Steps within a single Zebra profile execute in order; profiles relative to each other do not. Any cross-profile dependency (profile B assumes profile A already applied) is a race.

The fix

The pattern to adopt: one consolidated OEMConfig profile per OEMConfig app per device, varied by group assignment — never layered on the same device. Here is how to get there today.

1. Inventory the overlap. In the Intune admin centre go to Devices > Configuration and filter by profile type OEMConfig. For each OEMConfig app (Knox Service Plugin, Zebra OEMConfig, etc.), list every profile and its assigned groups. Any device that can be a member of two of those groups at once is affected — check for nested groups and All-Devices assignments, which are the usual culprits.
2. Consolidate to one profile per device population. Merge the base settings into each site-specific profile so every device receives exactly one complete profile. Vary configuration by assigning different consolidated profiles to different groups — Site A group gets the Site A profile, Site B gets Site B's.
3. Make group membership mutually exclusive. Since assignment is now doing the work that layering cannot, guarantee a device can only ever match one profile: use exclusion groups or tightly scoped dynamic-group rules so no device sits in two OEMConfig-targeted groups for the same app.
4. Keep a source of truth for the duplicated base. Consolidation means your common settings are now copied into every variant. Export or record each profile's configuration (the JSON from the profile's configuration designer/JSON view) into version control, and diff the variants against a reference base whenever you change a shared setting, so drift between sites is caught at review time rather than on devices.
5. On Zebra, prefer consolidation anyway. Multiple profiles are allowed, but with no ordering guarantee the only safe multi-profile design is one where the profiles are completely independent of each other. If any sequencing matters, express it as ordered steps inside a single profile, where order is honoured.
6. Cut over cleanly. Remove the superseded profile assignments and add the consolidated profile in the same change window, so devices do not pass through a transient double-assignment state. Then sync a pilot device, confirm the intended state on the device itself, and watch it across several check-in cycles — stability over multiple syncs, not a single green tick, is the pass criterion.
7. Encode the rule in your process, because Intune will not. There is no built-in guard against re-introducing a second profile later. A naming convention such as OEMConfig-<app>-<population> makes it visible at a glance when someone is about to assign a second profile for the same app, and a line in your change checklist ("one OEMConfig profile per app per device — verify group overlap") costs nothing.

How Decolla handles it

Straight answer first: Decolla does not manage OEMConfig, and its library contains no OEMConfig templates — this landmine is one you design out yourself, using the consolidation steps above. Decolla is a zero-touch Windows provisioning product from The Cloud Platform Ltd that runs over your own Intune and Autopilot tenant. Its build catalogue does include a small set of Android Enterprise enrolment basics — Managed Google Play binding, zero-touch and Samsung KME prerequisites, a corporate compliance policy — but configuring rugged and dedicated Android hardware through OEMConfig is outside its scope.

What is worth noting is that the failure mode in this article — overlapping opaque policies, no conflict warning, nondeterministic device state — is exactly the class of problem Decolla is built to prevent on the Windows side. Instead of accumulating overlapping profiles, you pick from a curated catalogue of 260+ pre-built, industry-tested items across 21 sections, with a conditional engine that defaults each item deliberately against your estate, and Decolla produces a written, itemised plan — every item with its delivery method and reversibility class (reversed automatically, reversible, or flagged irreversible) — which you approve before anything runs in your tenant. One reviewable plan instead of stacked opaque payloads is the same discipline this article recommends for OEMConfig. Decolla also supports per-item rollback of the changes it made itself.

Decolla is in private build and waitlist-only. If deterministic, plan-first Windows provisioning appeals for the same reasons deterministic OEMConfig does, the waitlist is at decolla.app.

Sources

• Microsoft Learn — Use and manage Android Enterprise devices with OEMConfig in Microsoft Intune
• Microsoft Learn — Use OEMConfig on Zebra Android Enterprise devices in Microsoft Intune