Kaseya Community

Patch Management is Daunting

  •    OK. I am new to Kaseya but have been in the network arena since 1980. This patch management has to be the most confusing, dis-organized thing I have ever seen. Helter-Skelter. I played with it for a whole day yesterday and got nowhere. All I want to do is patch critical updates on the server and all workstations every Sunday. That doesn't sound like too difficult a task but wow. Can someone shoot me some documentation or something that might make this patch management a little easier to understand?


  • Ziggy32,

    I recommend you check Kaseya University.  The is a free tutorial on major modules, as well as links to various resources.  Create a free account at university.kaseya.com.  (In-depth training is available for purchase through your account manager.)

    To get going with what you're trying to do, there are a few basic steps (this is very high-level, but should point  you in the right direction):

    1.  Run patch scans (Patch > Scan Machine) on your agents.  This will allow Kaseya to learn which patches are appropriate for which machines.  You cannot install patches without this step.  

    2.  Create a Patch Policy (Patch > Create/Delete)

    3.  Assign the Patch Policy to agents (Patch > Membership)

    4.  Define the settings for your Patch Policy (Patch > Approval by Policy)

    -Configure the Default Approval Status based on the classification

    -Manually approve or deny patches that are already known to your VSA (Default Approval Status applies only to patches that are newly discovered, not to patches already known to the VSA)

    5.  Configure Automatic Update (Patch > Auto Update) to run on Sunday

    6.  Configure Patch > Windows Auto Update to "Disabled" (otherwise the local Windows Update utility may run and install other patches)

    7.  Optionally configure the Reboot Action (Patch > Reboot Action) to your preferred behavior

    You can also optionally define the File Source to direct how patches make their way from the internet to the endpoint.  

    Kaseya University will give you more information.  You can also find TechJams from the Support organization (posted within Kaseya University).  If you'd prefer to browse the TechJams directly, you can find them posted in Kaseya's YouTube channel here:  www.youtube.com/watch

  • This video from the Kaseya University will explain the basics;


    To make the patch policies easier to maintain I do the following;

    Remember that the most restrictive Approval status rule will always apply. (Denied -> Pending Approval -> Approved)

    Step 1

    Create your Default Server and Workstation Policies and set the "Default Approval Status" to either "Approved" or "Denied". Ideally these two policies should not have a "Default Approval Status" of "Pending Approval" as you will rarely have to ever make any changes to these two policies. I would start with the "Policy View / Group By" Classification first and pick the "Default Approval Status" that you want. (See example images below)

    Next change your "Policy View / Group By" to "Product" and set the "Default Approval Status" to either "Approved" or "Denied" making sure you deny all the workstation products for the default server policy and all the server products for the default workstation policy.

    If done correctly you will only have to update these two policies when Microsoft releases new products.

    Step 2

    Create a Default Patch policy that is assigned to all (workstations and servers) machine you intend to patch. (See example images below)

    Unlike the default server and workstation policies that you only have to update when new product are released, this default policy can include the "Pending Approval" patches in either the product or classification view/groups and therefor should be checked once a week after every patch Tuesday.

    You will also use this Default Patch policy to deny previously approved patches that have been superseded by new patch to reduce the number of patches that needs to be deployed to new machines.

    Step 3

    As shown in the video apply the default workstation policy to all the workstations and the default server policy to all the servers and apply the default policy create in step 2 to both servers and workstations.

    You can also create Deny policies to;

    • Deny all patches for machines that should not be patch
    • Deny specific patches for specific machines
    • Deny specific products for specific machines

    To deny specific patches for all machines globally use the KB Override feature, I often use it to quickly block patches that has known issues.

    Additional info around Kaseya Patch Management

    Other important Patch Management topics I did not see covered in the video are; 

    • "Agent Credentials", they are critical for patch deployment especially if you are using a file source/patch repository.
    • "File Source" or like I prefer to call it, the Patch Repository helps reduces the number of times most patches are downloaded from Microsoft's download servers and can also reduce the time it takes to patch other machines that require the same patch.

    There are some known issues that you have to keep in mind and work around.

    • The total number of missing patches is not always accurate as sometimes 1 update can block other patches from being shown as missing. A good example of this is Service Pack 1 for Windows 7, after you have installed the service pack ± 100 patches are unlocked to be installed. Instead of relying on just the missing patches I also look for a specific update like the Internet Explorer Cumulative Security Update that is released the second week of every month except for January.
    • Not all patches can be deployed via Kaseya's Patch Management, a common one are Exchange Rollup Updates that will not be visible as it is not included in the Microsoft update Catalog (http://catalog.update.microsoft.com/), you have to manually install these patches.
    • Large update like service packs over 100MB might have trouble to install because of their size, in most cases you can silently deploy them via an Agent procedure.
    • Some updates require direct access to Microsoft's update servers to install, proxy servers and some firewall appliances can interfere with these updates. Here is a list of the update servers that you might want to white list if you run into this problem (https://technet.microsoft.com/en-us/library/cc708605%28v=ws.10%29.aspx)
    • The Patch Management's Patch Reboot feature causes Windows Server to report an unexpected shutdown, I'm unsure if this has been fixed since 6.5 VSA but to get around this issue I configure servers not to reboot and use the Post Patch Procedure to use the Windows shutdown.exe command with the correct switches to reboot the server with a Reason for the restart.
    • Another common update issue is the Windows Update Agent, Kaseya Patch Management can't update it and if it is not updated new updates can't be deployed. There is a KB article to deal with it (http://community.kaseya.com/kb-legacy/w/wiki/986.aspx) however not everybody likes this "solution"

    hope this helps

    [edited by: HardKnoX at 3:58 PM (GMT -7) on Mar 17, 2015]
  • how to add java updator in policy of patch management?