A bulletproof way to configure your Kaseya patch management

Written by Tullibo

Topics: Featured, Kaseya


I’ve had a truckload of enquiries lately about patch management and patch management configuration. I whacked up a variation of this post on the Kaseya forums a while ago. Here it is again. I’ve rolled out this config to quite a few kserver deployments and its bulletproof so long as the config is maintained and is deployed properly for each new machine group.

If you’re struggling with patch management I’m more than happy to assist – head over the Contact page and drop me a line.

The different areas of patch mgmt that need to be configured are:

  • Patch scan/audit scheduling
  • Patch approval policy setup & management
  • Patch source management
  • Patch source bandwidth management
  • Patch deployment schedule
  • Post patch reboot config

Patch scan/audit scheduling

I usually scan workstations every 2-3 days and servers every 5 day at night. Why I first started with Kaseya I had everything doing scans daily but as agent number grew to several thousand agents this really started to hurt the box at peak times. Scheduling at a longer interval doesn’t negatively affect patch deployment once machines are up to date and significant reduces load on the kserver and sql backend.

Patch approval policy setup & management

I have two master groups, workstation & server and all machines are member of one or the order. I then have two policies specifically for each client, workstation and server again. By default patches are all pending approval. I generally only use the master policies unless I specifically need to approve/deny a patch for a client. For example with IE8, some end clients wanted it, some clients it would break for particularly if they were using line of business apps that were browser based. So with my approach I can approve patching on an individual client basis or across the entire system and neither method interferes with the other.

Patch source management

Here I use a combination of pull from internet, from system server, from local file server (which then is configured to pull from system server or net). I also use bandwidth control in conjunction with System Server source to throttle patch deployment. This where you’ll come unstuck with patch management if you don’t deploy and maintain your configuration properly. I like to automate my template deployment for machine groups so I can setup templates and then don’t need to worry about patch management configuration on a regular basis.

A lot of Kaseya deployments I deal with have clients with remote offices on slow links so the download from system server option is a great way to deploy patches at a throttled speed. I also heavily utilise the chassis type – often applying different policies to desktops and laptops at a site as laptops can often be away from the LAN for several weeks at a time and might need a different configuration.

Patch source bandwidth management

I generally apply different bandwidth policies to servers, desktops & workstations depending on remote office speed. I also use the naming policy feature along with auto applied templates to reconfigure laptops as they move between branch offices to the patch management config for that specific branch office. My general rule here is to use 9kb/sec for workstations, 25kb/sec for servers but ultimately this depends on their link speed.

Patch deployment schedule

Again, different schedules depending on whether the users are at a branch office, desktop, laptop or server. Generally speaking, desktops and laptops are weekly or daily and servers are manually deployed. At some sites we have prearranged server outages weekly to allow for patch deployment and then just approve policies in the approval policy and the patches auto deploy. Once more, here’s where you’ll fall down if you don’t maintain this proper. I recommend keeping your configuration documented in a spreadsheet centrally so you can keep track of how each machine group and type of machine should be configured.

I like to use daily patch deployment for workstations where I can because once workstations are fully up to date, this setting doesn’t really have any negative impact on end users and as patches start deploying the same day or within 24 hours of being approved. This really makes critical patch deployment much more simplified.

Post patch reboot config

Generally, nothing reboots after patching unless it has been pre-arranged. When I first started with Kaseya a few years ago I used to configure agents to hassle users for a reboot but this caused too many unexpected dialog boxes that users hit OK on and lost work. It also caused unnecessary inbound helpdesk phone calls. If I really absolutely need something rebooted, I used a script or send message function under the remote control tab.

I also recommend you run a fortnightly report showing you workstations that have no been rebooted in the last fortnight and servers that haven’t been rebooted in 90+ days. << Yes some admins talk about Windows server uptime like they’re a hero if they can keep a box up for several months at a time but in the real world, Windows Server needs to be rebooted. Ultimately we’re trying to reduce support overhead and rebooting servers as part of general server maintenance to me seems to resolve more issues than it causes.

Anyway, hope you find this information useful and would love to hear from you with any suggestions, improvements or feedback.