I have a question in regards to Patch Management. Currently we are running VSA 126.96.36.199 with the 188.8.131.52 patch level. Before I get into it, I do recall seeing this same thing even in a previous build, which I believe was VSA 6. We upgraded to 9 from 6.
Now, I do understand the concept of the distribution window. What I am seeing when I try to schedule patch scans, as well as automatic updating, is it seems like 90% of the time the scheduler will completely ignore my distribution window. Let's say I select 10 machines, tell them to scan for missing patches on Tuesday night at 10:00pm, tell that to distribute over 30 minutes or even 60 minutes, select the date, tell it to run every 1 week, select the day, select no end date, and hit submit. More often than not, I end up with those 10 machines scheduling scans all over the place, across multiple days, with no rhyme or reason with the set time. If I tinker with the distribution window and change it to 10 minutes, 5, minutes, 0 minutes, I will see the same behavior. I say that this happens 90% of the time because sometimes it seems I will get lucky and all of the information I put in is registered correctly - and scan schedules or automatic update schedules will be set correctly.
I feel like I have always just accepted this happened at times and never paid too much attention to it - until recently. We have a growing customer base and it's come to my attention that nearly all of our endpoints are a year or more behind on patches. It seems as though, even scheduled, most of our agents just stopped scanning for missing patches. If I run a manual scan, the script finishes successfully and the patch status page updates as expected.
I have tried installing the latest patch level, reapplying the schema, and ensuring our VSA server is up to date on MS patches. Does anyone have any suggestions or possibly have seen this type of behavior before? Is it possible our SQL database could use some maintenance?
Thank you all in advance!
Thanks for the detailed information. The distro window should be honored - all schedules be set to begin at randomly-selected times beginning with your "start time" and ending with the end of the distro window you select. The actual run-time may extend outside of this window (if the scan is scheduled to begin at the very end of your distro window, the scan itself will start within the window but could run for several minutes later), but the start time should be scheduled within it.
Outside of a bug, there are two key pieces that can make the above appear to not be working properly: "schedule in agent time" and "skip if offline".
Schedule in agent time:
If your machines are spread across time zones (or the local OS is configured as though it were), and if you select the "Schedule in agent time" option, you could see schedules that appear to be spread across a dizzying window since the agent clocks don't all match each other. This is fairly easy to rule in/out: check the time zone of the endpoints. If they all report within the same time zone but you're seeing schedules outside of your distro window, something else is going on. Time zone is visible on the Agent > Machine Status page (add the column, if necessary) and within Audit.
Skip if offline deselected
This wouldn't be the cause of the issue if the schedule is outside of the distro window at the time you first schedule the machines. However, if this option is selected, and if a machine is offline at the scheduled start time, there will be a 15 minute grace period for that machine to come back online. If it does, the procedure will run. If it does not, the procedure will be postponed until the next scheduled time (e.g., a week later), but the start time may be shifted by that 15 minute grace period. Over time, this can cause the scheduled start time of the procedure to run several hours or days later than originally intended, if the endpoint is continually offline. One might argue this is a bug (I won't take a specific stance on that), but it's the way the scheduler functions, so for now, let's just say: it's a good thing to know about this quirk.
If the behavior you're seeing can't be explained by either of the above, you may be running into a bug in the scheduler and I recommend opening a ticket (helpdesk.kaseya.com). It would be good to note in the ticket whether you're scheduling the tasks using the module (Patch Management > Scan Machine) or if you're using Policy Management to schedule the tasks against the agents. It would also be worth a quick test to check if you see the same behavior when scheduled either via the module or via policy as that tidbit could help identify if it's an issue specific to either patch or policy, or if it's more likely a scheduler engine issue. Support will probably ask you to do this as a test, so if you can, it would be beneficial to do this ahead of time. This will give them more info to work from at the start. It would also help them attach to a parent ticket if there are other reports of similar behavior under the same circumstances.
We had our scheduling go all over the place, differences of hours, days and even weeks occur. Unfortunately this is a known issue with scheduling and has been for weeks!
We had a patch installed, that was undone by installing 184.108.40.206 - so I recognize this straight away. The fix is supposed to be present in 220.127.116.11 that could be out any day.
as others have mentioned, this is indeed a known bug issue that was supposed to be included in the .16 patch. since the .16 patch was mishandled (to be polite) the official fix should be included in .17 patch. we've worked through this issue with support and there is an out of band patch available if you can not wait. its a simple replacement of a DLL file.
Thanks for the replies everyone! Brande, in regards to your two suggestions, those were indeed two settings that I had already adjusted. I tried changing the scheduled patch scans and automatic update times, within a distro window, both with and without using the local agent time. As for the "skip if offline" box, that is always left unticked for scheduling purposes. Even with these 2 additional settings, I still see schedules skewed all over the place. All of our agents are UTC -5 as my client base is in the Midwest. Very strange!
As for the Policy Management module, that is something that we have never ventured into. I just spent a good bit of time in there (which I have now become fond of this method), and I can confirm that when scheduling both patch scans and automatic updates from here the distribution window is applied. I tested this a few times by overriding the schedules, reapplying the policy, and each time both scan and update schedules were within the distro window.
Which leads me to believe, as the other posters have mentioned, that this is likely a bug. I will keep an eye out for the 18.104.22.168 patch to be available, apply it, and go back to testing these schedules at that time.
Has anyone updated to .17 yet and tested this out to see if .17 resolves the issue? I did not see anything in the release notes.
I just ran the .17 patch on our VSA server here, rebooted, and attempted to change a Scan Schedule from within the Patch Management module, and the distribution window is still not working correctly. I tested on 7 machines, with a 30 minute window, and my schedule was over 2 days with completely random times. It's clear that this is still not working correctly and this patch level doesn't fix this. I would keep waiting for a future patch release which explicitly states it addresses this issue.
Like I mentioned earlier, the Policy Management module does work correctly with scheduling. If you feel like venturing into that module for patching, which I do recommend checking out, you will be able to use distribution windows effectively from there!