Effective policy scheduling is critical for ensuring a secure and stable environment while minimizing disruption to end-users. Failing to properly stagger policies can lead to scheduling conflicts, overwhelmed device command queues, and failed patching operations.
This article outlines best practices for determining your frequency strategy, managing the Automox execution queue, and configuring schedules to avoid concurrency issues across any operating system.
Understanding the Automox Execution Queue
Automox agents process commands in a First In First Out (FIFO) kind of scenario. A crucial technical limitation is that the agent can only handle one workflow at a time.
Any and all commands can be sent at a time, but only the first in line will be processed.
The agent processes the first command in the queue to completion before moving to the next.
If multiple policies are triggered simultaneously, the others are queued and wait for the previous one to finish.
If multiple policies are triggered simultaneously, the command queue on the device can become overwhelmed. This flooding can lead to agent communication issues, resulting in messages getting lost in the queue, responses being dropped, and reporting errors within the console.
Factors That Can Delay Policy Execution
Several factors can impact how quickly a device moves from one policy to the next. If a previous task is still utilizing resources, the subsequent policy may be delayed.
Network Bandwidth
Large updates or numerous concurrent downloads can saturate your network. If a device is struggling with low bandwidth, the policy execution will slow down, pushing back the start time of the next scheduled task.
High Worklet Volume
If your environment relies heavily on Worklets, keep in mind that a scan typically triggers after an installation or reboot. When the device scans, it will trigger the evaluation of every worklet that is associated with the device. Depending on what the worklet is doing, it can cause the device to slow down and push back the start time of the next scheduled task.
Notifications
Automox notifications cannot overlap. Because a notification is considered a functional part of the policy, the next scheduled policy cannot begin until the current notification process is completed or dismissed. If a user takes a long time to respond to a notification, it will naturally hinder the start of the next task.
Determine Your Patching Frequency Approach
A prerequisite to setting your schedule is defining your overall strategy. Depending on your priorities, you should choose a patching frequency approach:
Aggressive Approach
Goal: Rapid completion of patching to address vulnerabilities quickly.
Patching Frequency: Deploy critical updates and updates that do not require a system restart daily.
Relaxed Approach
Goal: Minimize disruption to end-users by allowing updates to be deferred.
Patching Frequency: Deploy lower-risk updates requiring user interaction once a week, reducing potential work interruptions.
Best Practice: Staggering Schedules
You must stagger your policy schedules to avoid overlap.
What is "Best Practice" Staggering?
While leaving a minimum of 15 minutes between policy deployments for the same group is a good starting point to reduce scheduling conflicts, this sits at the bare minimum of what we recommend.
For robust updates or complex environments, a 15-minute gap can still lead to overlaps. Ideally, we suggest 30 minutes to an hour between policies. This ensures that one workflow completely finishes before the next one hits the queue.
Staggering Example
If you have multiple patch policies, do not schedule them all to run simultaneously (e.g., 5:00 PM on Friday). Instead, configure them sequentially:
5:00 PM: Policy A (e.g., Apply Critical Patches)
6:00 PM: Policy B (e.g., Apply Security Definitions)
7:00 PM: Policy C (e.g., First Party / OS Updates)
Recommended Patching Order
Regardless of the operating system, it is crucial to sequence your patches logically. Always ensure prerequisite updates or underlying security definitions run before larger, more impactful OS updates.
For example, in Windows environments, certain patches should run before others to avoid dependency failures. The Windows - First Party Updates policy is the most impactful policy in the Windows patching chain and should be the last to run. The recommended order for Windows is:
Windows - Servicing Stack Updates
Windows Security Definitions Updates
Windows - Microsoft Office KB Updates
Windows - Feature Upgrades
Windows - First Party Updates
Best Practice: Managing the "Missed Patch Window" (MPW)
Staggering your schedules is only effective if the device is online. The "Missed Patch Window" setting introduces significant concurrency risks if multiple catch-up policies are involved.
If MPW is enabled, any device that is offline during the scheduled time will still attempt to run every single policy simultaneously the moment it checks back in.
As a result, a device missing its window could have multiple distinct policies hitting its queue at the exact same time, overloading the agent. Consider disabling MPW on non-critical patch policies to avoid overloading agents upon check-in.
Additional Scheduling Considerations
Avoid Overlapping Scopes
Avoid having multiple policies targeting the same updates, which can cause the agent to "fight" itself over the same resources.
Verify Schedule Configurations
Periodically open each patch policy to verify the schedule configurations. If a policy is set to only certain months, it will be skipped in all other months.
Related Resources
To help you get started with pre-configured approaches that align with these best practices, check out our guide on What Are the Recommended Best Practices for Patching in Automox?
For detailed instructions on configuring policy schedules within the console, read Setting a Patching Schedule.