Kaseya Community

Patch policy "layering"

  • Apologies if this has been answered before. I searched but did not find a thread that answered my questions.

    We are a managed services provider and have about a dozen clients in our Kaseya system. A few months back we test-deployed patch management with simple policies for most of the servers in our system, but we stopped because of various issues we ran into. We're now revisiting using PM in Kaseya and I had some questions about a proposed patch policy setup we've come up with.

    What I want to do is have Kaseya install ONLY security and critical patches within certain product-specific patch groups. This will make more sense after reading further.

    First we created policies specific to each operating system class (Windows server, XP/2000, Vista, etc.) -- under the "Approval By Policy" tab I chose the "Product" drop-down option and approved all patches relative to each OS. For servers with Exchange or SQL Server I've also approved patches for those products as well.

    Next we created a policy called "Security and Critical Only" -- under Approval By Policy I chose Classification, denied non-critical and non-security updates and approved critical and security patches.

    Finally I applied the OS-specific policy, any product-specific policies and the Security and Critical Only policies to the servers.

    The reason we're doing is is because we have numerous Win2K3 SBS servers in the field and most of them do not use the included SQL Server; a couple also don't use Exchange. Problem was that Kaseya wanted to download patches for these pieces anyway and in several cases Kaseya told us to reboot after a "successful patch installation" -- except that it wasn't successful, and Kaseya then said to reboot it again, and so on, ad infinitum. So now we're trying to granularize our patch policies and go back to automatic install, no-auto-reboot patch management.

    My question is: Will this work like I think it will? If not, what would be a better way to proceed?

    Legacy Forum Name: Patch policy "layering",
    Legacy Posted By Username: mightyteegar
  • Patch Approval works more on the idea that if it's denied in any of the assigned policies than don't install it.

    It would be better to have something like the following.

    General - Contains all patches that you general want installed on a full SBS system. Just deny those things you don't want on any server. Assign this to all servers.

    NoExchange - Assign this to any machine not using Exchange and deny any patches that have to do with exchange. Approve everything else.

    NoSQL - Assign this to any machine not using SQL and deny any patches that have to do with SQL. Approve everything else.

    If you have an SBS server that does not use exchange or SQL and you assign all three policies to it, even though the General one says Exchange patches are approved they will not be installed on that machine because the other polciy denies them.

    The same holds true for thos patches that you do not want on any machine. Even if they are approved in NoExchange and NoSQL, since they are denied in General they won't be installed. Just don't forget to assign General or you might have NoSQL and NoExchange installing some of those things you absolutely didn't want to have.

    Legacy Forum Name: Patch Management,
    Legacy Posted By Username: doug.jenkins@ispire.ca
  • Hello

    It is my understanding that Patch Management will only apply those patches that are pertinent to the operating system the Agent is installed on.

    Why then would you Deny patches for Exchange on an SBS Server? I understand that if you are not using Exchange, you might not worry about it, but at the same time, what would be the reason to deny them?

    I am looking at patch management now. We too have Policies based on OS (this seems to be the best and most popular option).

    Even if you Approve e.g. an SQL Patch under a policy, this won't get installed if SQL is not installed, and won't even show up on the missing list for that machine, even though it has been approved.

    Am I right here?

    If so, then would I also be right in thinking that the best use of a Policy would be to Deny any patches you specifically don't want installed that are relevant to that OS? For example, IE8 would apply to all OS, but you might deny this. There would be no point in denying Exchange Updates on an XP Policy, since these would never be installed anyway?

    Thanks in advance

    Geoff

    Legacy Forum Name: Patch Management,
    Legacy Posted By Username: geoff@lynxcomputing.com
  • Remember that the default approval status is Deny, so nothing will be installed if no action is taken. There are basically 2 ways of approaching this. First would be to approve all by default and create a approve/deny policy, which is slightly more confusing than the second way. As suggested by Doug, (if I may), is to deny all and create a deny/approve policy.

    Different strokes for differnt folks... I prefer the former because I don't have to worry about the denys. Lemme explain

    If everything is approved by default I can have 4 groups Server 2k3, SQL, and Exchange 2k3 and Exchange 2k7.

    I just add the machine to what ever groups apply Server 2k3 is my base, if it has SQL on it I add it to my SQL group, in this group only SQL updates are "approved" but since my default approval status is "approved" it wont deny my 2k3 group. So on and so forth.

    For me it's a bit easier to keep track of multiple memberships.

    For Dougs way things just got a bit muddled for me... not to say it dosen't work, and I believe that this is the way that the K bootcamps say to do it. but it's just not for me

    Mow mind you, I've done this for almost every company we take care of so I've got lots of policies in place. Some want IE8 some don't etc etc etc...

    Legacy Forum Name: Patch Management,
    Legacy Posted By Username: thirteentwenty
  • mightyteegar
    Problem was that Kaseya wanted to download patches for these pieces anyway and in several cases Kaseya told us to reboot after a "successful patch installation" -- except that it wasn't successful


    How were you installing the patches? If you are going to Patch Mgmt, Machine Update, are you sure that "Hide patches denied by patch approval" was ticked? If it wasn't ticked then it may have tried to install patches you didn't want installed.

    That said, I believe that it won't present patches for installation on a machine that aren't applicable to that machine. EG exchange patches won't be offered to a server that isn't running exchange, even if the server is in a single patch policy group for which the patch is approved.

    Legacy Forum Name: Patch Management,
    Legacy Posted By Username: wodger