We have started to apply updates to our workstations and servers using Kaseya and I have had some low success when performing the action with the "out of the box" options.
I originally set my scan, schedule, update, reboot action manually via the modules. I have since moved to using policies to control these actions to avoid manual processing and to ensure that most of my devices are following the same scheme.
After every patch cycle, I have a lot of failed patch content which I know that will happen but I believe that I am having lower success because of my approach.
I followed this post to set my patch policy settings for workstations and server- http://community.kaseya.com/xsp/f/30/t/20995.aspx
Since I am running this on a weekly basis and this approach does not separate office/ie and security patching, the patch will run and if the files are in use I will continue to have failed patch application.
I am trying to find out if someone has an existing configuration that has proven more successful. I don't want to recreate the wheel but in my previous tool I was able to schedule multiple patch application\reboot actions per patch group\individual patch. Where here, outside of creating other procedures to rescan, reapply, create another reboot.
Challenge- Workstations have multiple outstanding patches that may be failing because the files are in use. No pre-defined maintenance window is established across organization.
-** Possible solution** Create different patch offer via a policy. Apply security based patches only on certain days and just perform reboot via offer to user. Create a different patch offer for office/ie updates with a pre-procedure to ask user to close applications and failure to have a respond will automatically execute close and then apply updates and perform reboot offer.
My challenge with the servers is that I have a very limited window 12am-3am and I need to run the same concept of applying security, windows/office/ie updates separately, reboot with each installation to have more success as right now I am pushing all and rebooting once and continually have failures.
Sorry for the long winded discussion but I am certain I am not the first to ask this. I know that I can run the initial update on workstations with little to no issues but I cannot do that on our servers as I cannot allow some updates to be applied to the machines.
that's how i have it set up. only a few windows 7 and older windows 10 fail for me.
I'm not entirely sure what you mean by "files in use". From the Kaseya documentation the patches are installed in sequence so until one patch is finished installing and has completed the reboot action if necessary. I previously had ours do the same thing on a monthly basis, scan, update, suppress reboot unless necessary. One thing that I didn't see noted on that post was to auto-deny patches that have been superseded. You'll find a lot of older KBs that have been replaced still listed in the queue.
We're currently reviewing our Patching policy so I'm sort of starting over myself. I'm tempted to test Software Management instead but it's not co-operating with switching my test group over from Patch Management.
I has set superseded to be denied. The policy will set newer (approved/non superseded) patches into pending approval, while the other policy already has the setting for auto approve all existing and deny the others that we have deemed that will not be pushed for workstations and servers respectively.
When I mention "file in use" I am assuming that Kaseya, same as a manual update or a push from our old patching tool, would run the installer to apply the update and if the application was in use (IE/office etc) then the update could not run because you have to close it before executing.
I believe that this is why a lot of users and preset patch policies have separate policy options for patches and others for ie and finally another one for office.
After our patches from 12-3 I noticed a handful of devices that were holding a reboot flag under patch status, I have since spent most of the am applying the reboot action and then allowing auto refresh to let me know how many more reboots were pending per machine.
This is what I am trying to automate in a sense for our servers. set patch schedule during maintenance window and apply patch, reboot. Then rescan, apply patch, reboot as many times as necessary as long as it happens during the maintenance window we are ok.
For workstations since I don't have a maintenance window and is dependent on the end user, I have to be more creative / aggressive to try to get more success from my patching approach. This is where the file in use and or application in use would be more of a problem.
Interesting - we have 2564 workstations at this moment, and when I define a view to report those missing 5 or more updates, the filter reports just 3 machines. Similarly checking servers - 351 servers in total, 109 are missing 5-9 updates and only 1 is missing 10+. Since we've just started the current server patching cycle (weeks 3, 4, then 1), this is not unusual.
We run workstation patches weekly, and server patches monthly during very specific change windows and schedule times. We reboot servers prior to updating, and suspend alerting for all affected servers for the duration of a 6 or 9 hour change window.
We're going to be hosting a short webinar with Q&A on our patch process on November 15th - check the training/seminars page on our web site for more info. It will be a good time to share info.
PS - Trevor - I used to do what you're trying using the WUS APIs. I had written a system service that starts patching at a specific time, reboots, downloads/updates more patches, and repeats until there's less than 15 minutes in the change window. It seems that the APIs changed with Windows 2016, so the wash-rinse-repeat method no longer functions. I can't even get the API to deploy updates anymore.
Thanks for your reply and for providing some feedback on how you perform these functions. I may looking way deeper into the patch application and less on the patches themselves.
I was under the impression that you had to selectively apply security, patch reboot and then apply office etc separately to confirm that the patch success would be achieved.
One thing that I did not mention is that our process has never been 100% effective and I have servers that have about 20 patches that have been lingering for years now. These boxes are 2008 R2 and have some 2014 patches and other types that repeatedly fail and don't successfully apply. I may need to dig deeper into every patch and perhaps start making exceptions if there is not way to successfully apply them if I cannot achieve this manually either.
As for workstations, I have yet to define a global policy that can run effectively to apply to all new and existing devices to scan, patch, reboot etc effectively and thus not have outstanding devices in the wild that later need remediation.
As with anything, the more background you have the better it may be to provide a possible solution.
Since creating this thread I have ran a report for the machines with the highest outstanding patches and started making sure they have all of the scheduled events and have set them all up to perform update via the machine update option in the patch management module.
Once I get most of the devices up to a manageable level, I may have to do less leg work to and rely more on the automation.
Just to give you an idea what I have to work through
Top 20 missing patch counts for workstations range from 117-48
Top 20 missing patch counts for production servers range from 23-13
On the odd occasion where a patch won't install, we usually go to the machine and try to install it manually, watching the results.
As we'll cover in our seminar, we have had to deal with customers that haven't patched in years. We onboarded a client 2 years ago that had not patched in over 2 years and had more than 300 outstanding updates. Since VSA uses the AU interface, and that chokes with more than 60 updates or so, we created blocking policies to limit what got deployed to them. Block all but critical, then all but optional, and in 4 months, every system was current and in a normal patch cycle.
We don't have a "no patch" patch policy - seems wasteful to spend time denying every update when you can simply not schedule updates and turn Auto-Update off. We have a total of 13 patch policies and that covers every customer/system requirement - most systems get just two policies, sometimes three to get the job done.
We have several MSPs using this methodology with great success, and we've been following this method in our MSP practice for a good 3 years now.