Kaseya Community

Patch automatic update settings remain after moving machine from one policy to another.

  • I'm trying to create a "SLA Zero" policy (basically, do absolutely nothing other than run an audit), and have applied this Policy to a machine group. Since I'm a glutton for punishment, I then moved my own computer into this group to see what would happen ... 

    Almost everything disappeared, except one item: Patch Automatic Update is still scheduled for Thursdays at 10:41 PM ... 

    Currently "Patch Procedure Schedule" is unchecked for this SLA Zero policy, meaning "no settings". In this case, this also seems to imply "do not remove existing settings". 

    In a previous incarnation, "Patch Procedure Schedule" was checked, "Patch Scan" was scheduled to once in a blue moon, but "Automatic Update" remained blank. Still, when moving the machine into the machine group with the policy, the Patch Automatic Update is still there, still for Thursday night.

    And, I tried clicking the "Reset" button for the "Automatic Update" schedule, thinking this would erase any setting that might be there, but still no go. 

    So, how do I go about creating a Policy that will completely remove the "Patch Automatic Update" setting on computers to which this policy is applied? Any takers?

  • I have found a work-around, but it doesn't feel safe, because if Kaseya patches it, then bad things may happen.

    Two changes to make this work:

    1. Schedule the "start on" date to be way in the future, like 2022

    2. Use the "Exclude the following time range", and enter the exact same time in both fields (ie. 12:00:00 PM to 12:00:00 PM). That's a 24 hours window :)

    When applying this policy to the machine group, the "Patch Automatic Update" was removed.

    But Lars, why did you do #1 if #2 is what fixed it? Well, I'm afraid that Kaseya may alter the behavior of the "Exclude time range" bit, so by scheduling the first patch to take place in 10 years, I'm pretty sure nothing will happen in a while...

  • Lars,

    That's an interesting take on things.  After moving the machines to the "sla zero" policy, if you select the endpoints and click "Clear Overrides" button on the Policy Management > Machines page, and then click the "Reprocess Policies" (or wait out the reapply interval you have configured on the Settings page), are the patch auto update settings then removed?

    Please let me know either way and I'll discuss options for better addressing this type of situation with our engineers.



  • No, I've cleared overrides and re-applied policies all morning, and nothing works to get rid of this. I just noticed that the same applies to the Audit portion. Since I have no interest in re-auditing SLA Zero machines over and over, I just scheduled the "Baseline Audit" and "System Audit" to grab all the info on the machine once. But, if the machine has all three audit options already scheduled, the new policy just overwrites the two that you've set, leaving the third (Latest Audit) with its original setting.

  • Lars,

    To follow up on this conversation, the issue you're experiencing is caused because the object within the policy ("Patch Procedure Schedule") is one of the objects that is configured to merge (rather than join) data.  Some objects, like Agent Procedures, are configured to join together when two policies (assigned to the same machine) include different data.  Other objects such as the patch object wouldn't make sense to join so, rather, the "winning" policy settings are used when the object is assigned to the endpoint.

    With schedules, the configuration is such that if a schedule is set in multiple policies assigned to a single machine, the policy assignment rules are enforced to determine which policy setting is obeyed and which is ignored.  When two schedules are set, the rules will determine which schedule to follow.  However, if one has a blank schedule, the blank schedule is ignored, even if that policy is the "winning" policy.  This same logic is used when a policy had been applied that contained a schedule, that policy is removed, and a policy with no schedule set is then applied to the same endpoint.  The blank schedule is ignored and the old schedule remains in place - this is exactly what you're seeing, and this particular behavior will remain going forward.

    However, planned for release in 6.3 is the ability to choose "none" as a schedule option.  This "none" option would overwrite any existing schedule setting.  Blank schedules will still be ignored, but the "none" setting - which is really just a blank setting with "special" rules - will clear the old schedule and resolve the issue you're currently seeing.  Standard Disclaimer:  This is planned for release into 6.3, but there is always a possibility it could be pulled (at this point, I'm fairly confident it will be there, but until it actually releases, I can't make a guarantee).  

    Hope this helps!