Blueprint convergence fails on non-Google OEM tablets — System Update Policy compatibility
If you are managing a mixed fleet that includes non-Google OEM tablets (Redmi, OnePlus, and some Lenovo models) alongside Google Pixel devices, and you are using the "Disable Updates" System Update Policy in your Blueprint, you may see certain devices enter Drift mode with an error similar to:
Blueprint application failed. Error(s) – [System update policy "Disable Updates" is not compatible on this device.]
This article explains why this happens and how to resolve it.
Which devices are affected
The "Disable Updates" option under System Update Policy in Esper Blueprints is only supported on Samsung and Lenovo devices. When the same Blueprint is applied to Redmi, OnePlus, or other non-Samsung/Lenovo OEM devices, the Esper agent cannot apply this policy and the entire Blueprint convergence fails.
Google Pixel and most stock Android devices handle this policy differently — they may succeed or partially apply, which is why the problem often only surfaces on mixed OEM groups.
What "Drift mode" looks like in this case
The device appears to be partially configured — some Blueprint settings may have applied — but the device is flagged as Drift in the console and the Blueprint cannot converge successfully. On the device itself, opening the native Settings app may show the message "This action is blocked by your admin" even if your Blueprint doesn't explicitly block Settings access. This is a side effect of the failed partial convergence.
How to fix it
- In the Esper console, open the Blueprint applied to the affected group.
- Locate the System Update Policy setting.
- Change the value from "Disable Updates" to a compatible option:
- Automatic — updates install as soon as available
- Windowed — updates install during a defined maintenance window
- Postpone — defers updates for up to 30 days
- Save and publish the updated Blueprint.
- Go to Devices & Groups → select the affected group → trigger a Converge on the affected devices.
- Verify: Confirm in the event feed that the Blueprint applies without errors and the devices exit Drift mode.
Preventing this in mixed-OEM deployments
If your fleet includes multiple OEM brands, consider splitting them into separate groups and using separate Blueprints — or use a parent Blueprint with OEM-specific child Blueprints that override only the settings that differ by device brand. This gives you precise control over which policies apply to which hardware without risking failed convergence across the whole group.
Please sign in to leave a comment.
Comments
0 comments