Kaseya Community

Revisting old Patch Management process

This question is not answered


We have been using Kaseya since 5.0 was out and after some stops and starts have been using the same patch policy for the past 3-4 years.   We are looking to try and streamline the entire patch process, from approval to deployment to troubleshooting as the time being spent on patch management has started to become excessive and I was hoping that I could see what others in the community are using as their patch process.  We use email connectors to send all notices to our ticketing software (ConnectWise).  We have 191 servers and 1330 workstations that we monitor across 60+ customer sites.

A quick rundown of our patch process:

1)      We patch servers on the 22nd of every month.

2)      Workstations are scheduled to check for available patches once a week.  The day/time varies depending on the customer site.

3)      A patch scan is run every 3 days on Kaseya monitored systems (this is staggered)

4)      We do not automatically deploy Service Packs, IE Upgrades, full .NET installs, or Exchange Rollup packages.

5)      We have four main policies in use.  An internal server and internal workstation policy and a customer server and customer workstation policy.

6)      On the 2nd Wednesday of the month (after MS releases the new patches) I start the process of reviewing the patches to see what issues have come up and what recommendations others who have deployed the updates have to determine if updates should be approved, denied, or left in pending status.   These are all documented in a Patch Approval document that then goes to my supervisor for approval.

7)      Once approved, I then go through the internal server and workstation policies and approve/deny patches.   We patch our systems (workstations and servers) before approving updates for customers.

8)      On the 22nd (or the last business day before the 22nd) I go ahead and approve the updates for the customer sites after confirming no issues with what has been deployed.

After patches install on the servers we get tickets in for each server that has had patches applied that the server should be rebooted.  Our help desk will then group the tickets and notify customers of the need to reboot and schedule a procedure to reboot the server(s).  Failed patch tickets come in for each patch that fails to install on a particular computer.  These are then scheduled for deployment again on workstations.  Server failed patches are always manually scheduled to run at 10:00 PM that evening.

In reviewing the forums it seems that this is quite cumbersome in comparison to how other approach patching.  In addition to the normal patches, how do others approach deployment of Service Packs, IE Upgrades, and other major updates?  Are these handled separately or are they allowed to run as normal?  How are server reboots handled and what if a customer does not do the reboot of a server?  Are they moved to a no patch policy?  How are failed patches handled?  Are superseded patches allowed to be installed or are they denied?

I do appreciate any assistance on this.

All Replies
  • Just came across your post and had a few minutes to spare.

    Your workflow seems to be in order and I don't see a lot wrong there.

    Our normal workflow does run along similar lines.

    The Wednesday after Patch Tuesday I scan the list and look at any special fixes.

    If there is no impact indicated or expected I'll approve these updates.

    Any suspect patches are denied at first, but may be approved a week later.

    We don't roll out service packs, are distinctly picky when approving tools or feature packs and optional updates. The rest is normally allowed to keep our customer's systems in shape.

    We tell them security issues need to be patched, other fixes can be applied when needed.

    We patch our own workstations and servers first, which filters a lot, but not everything.

    We do maintain a weekly patch schedule for servers and workstations.

    We reboot workstations if users are not logged in. We tested with nag screens, but that didn't go smoothly. People always thought there machines were slow after a nag screen, while at that time the biggest impact from the installation is already done. We now do get some errors were reboots need to be done afer patching (depending on OS, Windows 8.1 is really good in minimizing impact).

    We are struggling a bit with doing this at night, since we protect our HP notebooks by default with encryption that needs a password on reboot. So, using Wake-on-Lan takes some pain out of patching, but not all.

    Servers are patched at night and directly rebooted if possible. We do have some health and care related customers and then we usually set up patching and reboots once a month or even every 3 months.

    In closing some last answers. IE updates are delayed a month or two and tested internally first. Using a No patch policy is sometimes needed, mostly for special servers, 24/7 webservers or security related servers. These are patched on location during scheduled downtime. Failed patches are ignored if there are no more than 5 but we do have contracts for general periodic checks where every failed patch is checked. Here Kaseya is just a tool, but the care goes a good deal further. We have chosen not to install superseded patches, since there is no point to do so, that I can think of.

    Thinking about this I jogged  down some notes to talk to my colleagues about. So, maybe it helps you, it even refreshed my lookout on patching.

    Regards, Eric.