Issue
You edit a policy — change its targeting, adjust its schedule, approve or reject patches, or move devices into or out of a group — and the next run does not reflect the change. Devices patch on the old settings, run on the old schedule, or are still in (or out of) scope as if the edit had not been made.
Environment
- Automox (current agent release)
- All operating systems; any policy type (patch, worklet, required software)
- Console areas: Devices (Device Details), Policies, Groups
Overview
Policy settings live in the Automox console, but the agent on each device acts on the copy of those settings it last received. A device only picks up a policy edit — new targeting, a new schedule, a changed approval, or a group move — the next time it scans. Until that scan happens, the device continues to behave on the settings it already had.
This is a timing gap, not a lost change. Two things drive when an edit lands:
- A check-in is not a scan. A check-in is a lightweight status report the agent sends about once per hour; it does not re-evaluate policies or pull down changed policy settings. A scan is the fuller pass that collects the device's current state and re-evaluates its assigned policies against the latest settings. Only a scan applies your changes. See What is a Check-In vs. Device Scan?.
- Scans run on an interval. By default a device scans every 24 hours (configurable per group, typically between 4 and 24 hours) and after every reboot. If you change a policy shortly before its run and no scan happens in between, the run uses the pre-change settings.
Targeting and group-membership changes have the same dependency. Automox schedules a run only for the devices a policy currently targets. When you re-tag a device, change a policy's device filter, or move a device between groups, each affected device must scan for its new scope to be recalculated — a device newly added to scope will not be picked up for a run until it has scanned in with the new membership.
Resolution
- Confirm the change was saved:
- Reopen the policy (or the group/device) and verify the edited targeting, schedule, or approval state is what you expect.
- Force a scan on the affected devices so they pull the updated settings immediately, rather than waiting for the next scheduled scan:
- For one device, open Devices Device Details and use Scan Device.
- For many devices, select them from the Devices list and run Scan as a bulk action, or scan the whole group.
- Note that a restart on its own does not force a scan of the current settings — issue a scan explicitly.
- For targeting or group-membership changes, scan the devices whose membership changed, then confirm in the console that each device now shows the expected policy in scope before the run.
- Allow a scan to complete before the policy's scheduled run:
- As a rule of thumb, make policy edits at least one scan interval ahead of the run, or force a scan right after editing. See Scan Interval Best Practices for how the interval and manual scans reset the timer.
- If a device stays online but still runs on the old settings after a completed scan, verify the device actually finished a scan (Device Details shows its last scan time) and that it is in the policy's current scope.
Notes
- Best practice: schedule or force a device scan between a policy change and the policy's next run. This is the single most reliable way to guarantee updated settings take effect.
- A manually initiated scan resets that device's scan-interval timer — for example, a manual scan at 1 p.m. with a 4-hour interval moves the next automatic scan to 5 p.m. (see Scan Interval Best Practices).
- Offline devices cannot scan, so their settings only refresh once they come back online and scan. A device that never seems to pick up changes may not be scanning at all — check its last scan time in Device Details.
- Removing a device from Automox is a delete of the device in the console; there is no local deregister step for this workflow.