I have a custom field called Patch_Days which is used to define some views which get used by policies to schedule Automatic Update. Currently I have views that simply check if the custom field is equal to mon, tue, wed, thu, fri, sat, sun, or daily. If I want a policy for monday, wednesday, and friday, I have to set the custom field to "mon wed fri" and make a view that checks if it's equal to that exact value - this also means "wed mon fri" would not work since it's in a different order. In order to create every combination of the 7 days, I would need to make 128 views and 128 policies. It also means patching has to be run at the same time, so I thought it would be nice to make a custom field called Patch_Time which would be a number between 0 and 23, which means I'd have 3072 views/policies to cover every combination of day and time.
It is not possible to have a view that checks the custom field for *mon* (seeing if it contains mon) and another one check for *tue* to accomplish multiple days of patching. This causes the agent to be in both views, which causes both policies to be deployed in conflict - it will not get a schedule for both days since Patch Procedure Schedule settings in policy management are not additive.
I would like to actually have an agent procedure parse these custom fields and schedule Automatic Update accordingly. My initial thought was to have an agent procedure scheduled at noon on every agent every day. That agent procedure would check to see if today is a patch day according to the Patch_Days custom field (using "contains") If today is a patch day for the agent, it would look at the Patch_Time value and calculate how many minutes until that time. It would then schedule Patch Automatic Update for that many minutes in the future (ScheduleProcedure takes minutes of delay as a parameter)
The only problem with that method is the fact that you cannot schedule the Patch Automatic Update system script because it does not have a scriptID. I have scheduled other system scripts such as patch scans and credential tests by finding the scriptID and using it in an exported agent procedure's XML but it looks like Patch Automatic Update and Initial Update do not appear in the scriptIDtab table. I noticed that when I run Patch Automatic Update on an agent, it also does not show up in the script log - it just creates a dynamic script for that patching session.
I'm curious how other people schedule patching. I am trying to get away from having one-off policies and would like everything in policy to be controlled by a custom field, which gets a default from its machine group via a Managed Variable. If anyone has any tips on how I can schedule this, it would be much appreciated. We've considered writing our own patching application that uses a list of missing approved patches from Kaseya, but it would be much less work to use the built in patch management.
Resurrecting zombie thread...
I like the cut of your jib (in regards to attempting to schedule Automatic Updates in this fashion).
I too am running into the same issue. I went so far as to spend a couple hours trying to reverse-engineer the patch scheduling process and the SQL queries that execute as a result of same; however, I ended up at a dead end as the scheduler code responsible for the series of resulting SQL queries are part of the "new" core (not the old classic ASP pages). It's not a good 'ol Stored Procedure in the database... it's a series of mutually-dependent database calls that are being orchestrated from within code I can't see.
Best I can do at the moment is the super-limited version of what you outlined (we've got 4 different patching windows and a Manual option as well). Obviously, having Policy Management try to chew through 3,072 Views and Policies would bring the DB to its knees... so even if I could automate the creation of the Views and Policies that would account for the 3,072 permutations you outlined, it wouldn't run in the "real world."
It would be nice if the Automatic Update schedule "stacked," but it's just not how the product is architected on the backend.
At any rate, have you found a better approach? Or a non-compiled version of the core processing code ?
I just had an idea that might help with Matthew's Patch Schedule idea and reduce the number of views an policies he is using.
So this "Suspend Auto Update" feature that they added to Patch Management can be manipulated via an agent procedure using a sqlwrite command to change the "suspendAutoUpdate" field in the "patchParams" table.
(0 turns it off and 1 turns the "Suspend Auto Update" feature on for the agent)
Now all you do is configure the agent to patch daily and then you use the custom fields to specify the days that you want to patch. Next you schedule the agent procedure to run daily before the daily scheduled patch window under patch management, turning the "Suspend Auto Update" on or off depending on the custom field values.
The only potential problem I can think of at the moment is if the agent was offline, WOL powers it up and the Patch schedule executed before the "Suspend Auto Update" auto update procedure does.
Not sure if I'm going to use this but I will definitely make the sqlwrite command as it could be used to automate suspending patching on agents.
On a related note, I would LOVE to be able to kick off the latest audit in a script. Often, I will install software via scripting, but the machine will go offline before the next scheduled audit runs. I then have machines listed in the view for "missing" the software, but they just haven't run an audit. If I could start the latest audit as the last step in any software installation scripts, I wouldn't have this problem.
<?xml version="1.0" encoding="utf-8"?><ScriptExport xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.kaseya.com/vsa/2008/12/Scripting"> <Procedure name="Latest Audit (Scripted)*" treePres="3" id="1651220505" folderId="802324764524737" treeFullPath="Built-In Kaseya Functions"> <Body description=""> <Statement name="ExecuteScript" continueOnFail="true"> <Parameter xsi:type="StringParameter" name="ScriptID" value="136" /> <Parameter xsi:type="StringParameter" name="ScriptName" value="Latest Audit" /> <Parameter xsi:type="StringParameter" name="TimeDelay" value="" /> <Parameter xsi:type="EnumParameter" name="TimeUnit" value="Immediate" /> </Statement> </Body> </Procedure></ScriptExport>
Latest Audit's script ID is 136. Once you import this though, you won't be able to edit it because, as you may be aware, the script editor will not resolve names of System scripts, nor will it let you save the script if it can't resolve the name.
Just along the lines of eperson and Brian Dagan posts here are some more system procedure ID's (not sure how many of them are still valid since I found them back in 2012-2013 so use at your own risk);
"107" name="Credential Test"
"118" name="Patch Test"
"135" name="Baseline Audit"
"136" name="Latest Audit"
"137" name="System Info"
"200" name="Get Add/Remove Programs List"
"132" name="K Agent Update"
"252" name="Mac Agent Update"
"332" name="Linux Agent Update"
"145" name="Uninstall Agent"
"305" name="Uninstall Legacy Agent"
"306" name="Uninstall Agent New"
"256" name="Uninstall Mac Agent"
"333" name="Linux Agent Uninstall"
"230" name="K-VNC 4.x Uninstall"
"273" name="K-VNC 4.x Install"
"390" name="Enable Network Access Driver"
"391" name="Disable Network Access Driver"