Perhaps I'm the only one that feels this way, but I'm going to say it anyway.
I don't understand the concept of "Pending Approal" equalling "Deny"...basically. This methodology pretty much prevents the ability to leverage multiple default policies. To me it would make FAR more sense to have Patch Policies work like this:
Approve = Approved (unless Denied by another Patch Policy Membership)
Pending Approval = Deny (unless Approved by another Patch Policy Membership
Deny = Denied
It would at least be nice to have a check box that allows me to do it your way or my way.
I completely agree with you seftink. This would allow us to have policies for just installing IE9 for example, and assign to machines in a staged process. I would really like this to be reviewed.
Certified Kaseya Administrator
I use overlapping patch policies without many major issues with the exception of patch classifications which is a story for another post. You really should only have 1 primary/default Patch Policy and this policy should be the only one that has the Pending Approval checks enabled the other policies should only use the Deny and Approve checks enabled.
Say for example you have a workstation, you have your Default Patch Policy that specifies what Classification of patches you want to Approve, Deny or Pending Approval.
The next policy is specifically targeted at Workstations, so you would by default Approve or Deny by Product type, since its for a workstation you filter all of the product types out for server OS's and server applications such as Exchange.
The next Patch Policy is optional and I set it to approve everything by default and then I use the filters to find Superseded, Manual and Web Only installs and set them to Deny. You could use the "Override Default Approval Status" check boxes however that means you have to leave everything in the Pending Approval queue which would not work so great as the majority of the Superseded patches would already be in the Approved queue. To use this policy I simply go through the Approved queue every week and clear out the Superseded patches.
The very last layer is the KB Override option, this is very handy for approving or denying specific patches for all your managed machines and it came in very handy when I had to deny IE9 from installing last year. Patch policies uses a GUID for each Patch, some patches are re-released with a different Patch GUID but has the same KB number. This is where KB Override option comes in as it overrides all patch policies by the patch's KB number instead of the GUID. They only thing I really need them to add is the option to do the KB Override per Machine Group or even added it to the Policy Manager.
This is what works for me I'm sure that there might be other schools of thought around how to use multiple patch policies, some that might even be more efficient than what I mentioned above, however I hope it is of some use.
Also something I left out is the Pending Approval you would use for patches that you are unsure of, I used the Pending Approval queue mainly for reviewing Optional Software.
Perhaps I'm missing something or misunderstanding something. According to the documentation if a patch is listed as pending approval, it's the same as being denied. If you apply multiple policies to a device, the MOST restrictive applies as it relates to a patch. As such, if I apply 1 default policy that auto approves critical patches and I want another policy that auto approves specifically Service Packs that I can apply on a per device, per client, etc. basis, I also have to approve those critical patches on the Service Packs policy or they will now be denied because they are listed as Pending Approval (Denied) on the Default Critical Patches policy. Likewise, because those Critical Patches are Pending Approval (Denied) on the Service Packs policy, the end result is that Kaseya sees the most restrictive policy showing all patches for that device being Pending Approval (Denied). Am I misundestanding this or am I coming to the correct conclusion?
If they can't give me a switch between there way or my way, it would be nice if I could have a forth option of "No Selection" that basically says that assume Denied unless approved by another applied Patch Policy. That would probably be a better solution that I could manage on a Policy by Policy basis.
The core idea behind these policies is that the most restrictive policy will win and the Pending Approval status is there to give use more control over what gets Approved or Denied by the Patch Policies which I personally think is a good thing.
If you look at a policy under "Approval by Policy" you have the option to set the "Default Approval Status" to Approve,Pending Approval and Deny patches by Classification and Product. This means when new patches are released depending on the the "Default Approval Status" they will either auto Approve, Deny or wait for your to Approve them.
If you don't like the concept of Pending Approval simply set the "Default Approval Status" in your policies to either Approve or Deny. Make sure to check both the "Default Approval Status" under both the Classification and Product views. Keep in mind if you do this there is a chance that these type of policies will Approve patches that you don't want to install and Deny Patches that you might want to install.
If you want to use the "Pending Approval" feature your Primary Policy should be the only one that queues patches for Pending Approval otherwise it will create additional work that you really don't need to do.
The other Policies you should set the "Default Approval Status" to Approve everything except for "Products" that you do not wish to install on the target machines and that where you use the "Default Approval Status" of Deny.
I understand the principals behind the design. I'm also not saying it's a bad design. Personally I like the "Pending Approvals" as well because it does allow me to more easily manage what is approved or denied. The challenge that I have is the Pending Approvals equalling Deny. The only reason that I have that challenge is that I don't have an option to have a Pending that doesn't Deny by default. As I mentioned in my last post, I believe a 4th option would wrap this up nicely. Perhaps Approved, Pending Approval, Pending Denial, and Denied.
Approved = Approved
Pending Approval = Denied unless approved by another Policy
Pending Denial = Denied even if approved by another Policy
Denied = Denied even if approved by another Policy
That way you still have the "Pending" functionality your referencing as well as allowing each of us to manage the default actions of Pending as we see fit on a per policy, per package, per device basis with the utilization of multiple default policies.
The bottom line is that I have default policies that apply differently for different reasons. Therefore it was determined that our best course of action was to create policies that fit specific roles and apply multiple policies where we see fit. The hope was that we would have policies that had numerous product and classification groups that we didn't want to Deny or Approve by default as those decisions would be made by other policies that are applied. So it was a hope of "No Action" for those lines. Then we found the documentation and realized this won't work. What you're referring to won't work for us either. Hence my request.
I too completely agree with you seftink.
From a purely logical perspective whats the point of Pending Approval...since it is *identical* to denied.
It's counter-intuitive simply adds confusion and complexity to patch management.
Patch policies should parallel NTFS permissions:
Explicit approve - approved (Except if explicitly denied)
Pending approval - inherit from any other policy, otherwise apply system default.
Explicit deny - dened regardless.
System default: if no policy applied, choose approve, deny or ignore.
So, the logic becomes default: use system default option. If any applicable policy approves, approve. If any applicable policy denies, deny. if both denied and approved, deny.
What Classification/Product patch types do you guys set as pending on a Policy and do you model your patch approval status around any existing patching system?
Im bringing this post back to life as I think the patch approval rules need a slight rework, and its been raised many times in the forums. Whats the point of being allowed to assign multiple patch policies to machines if "Pending Approval" is effectively a deny? Theres no point. This stops us from using multiple patch policies to have a standard patch approval policy for all our machines, and another for a staged rollout of something like IE11.
Is there any support for the following?:
This just makes sense to me. Or give us another status where its effectively "Denied unless approved by another Policy"
All feedback welcome.
Pending Approval has a very specific function. Its purpose is not to do as you are suggesting (this would be a feature request), but, rather, gives admins an easy "bucket" to find patches that have been recently released that may need a human to decide if the patches in that classification or product need to be approved or denied. Let's take IE as the example, since you used it in your post.
IE is a patch that does not have its own unique Classification or Product. Microsoft groups all IE patches under their respective OS products. You'll (potentially) find IE patches in any of the OS-level products - Win7, XP, 2008, 2012, Vista, etc. You cannot completely automate the denial or approval of IE patches unless you want to either approve all or deny all OS-type patches.
A recommended group of Patch Policies could look like:
"Base Server" (denies all patches that you ALWAYS want to block for ANY server; ideally all classifications and products are set to EITHER approved OR denied (no "pending approval" - or at least try to limit the number of classifications/products listed as Pending Approval)
"Base Workstation" (same as Base Server, but tailored to workstations)
"No Service Packs" (Default approval status for Service Pack Classification = Denied. All other classifications and products = Approved)
"No Silverlight" (Default approval status for Silverlight Product = Denied. All other classifications and products = Approved.)
Now, with the above patch policies, you can mix and match them between your machines. If your "base" policies don't use any "pending approval," then you theoretically never have to touch the four patch policies above. Default approval status will make sure the patches get approved or denied as you have configured. This means spending less time managing patch policies (which is a huge time saver).
Now you have to deal with IE. You can't configure a patch policy to automatically block IE because MS doesn't provide a product listing for IE. So you create a "No IE" patch policy. This policy sets ALL classifications to approved. All Products EXCEPT the OS-level products are set to Approved. OS-level products are set to "Pending Approval."
You run patch scans on all your machines. The first four patch policies are hands-off - they take care of themselves. You go into the No IE patch policy, find all of the patches marked as "Pending Approval", use the Patch Filter to find the IE patches (in the patch filter, use the Title field and search for *explorer* to get just the IE patches). Select all the patches that return after filtering to the IE patches and deny them. Clear the filter. The only patches remaining are non-IE patches. Since this policy blocks ONLY IE patches, select the rest of the patches and Approve them. Now your "Pending" column, when no filter is set, should show zero patches.
Next patch scan cycle (week, month...depending on how often you run scans), You can leave the first four patch policies alone. They're still taking care of themselves. Go into the No IE policy. You've already processed a few hundred or thousand patches from prior patch cycles and don't want to have to dig ones you've already dealt with them just to find the IE patches. Because you have the OS products set to Pending, and since you cleared out the "pending" column last time around, you know that the patches that are in the pending column this time around are new - no older than the last time you cleared the Pending column. So, just like you did last cycle, select all "Pending" patches (click the hyperlink at the bottom of the pending column), filter to IE patches and deny those and approve everything else that's left. You do this each week or month to make sure the "good" OS-type patches aren't being inadvertently blocked for extended periods of time, and the whole process takes just a couple minutes. If you had to dig through several hundred or thousand patches each time just to find the "new" IE patches, you'd be spending a lot of time waiting for pages and list of patches to load. Even worse, if you were dealing with trying to find patches that required you actually review each individual patch before you approved or denied them (where maybe you couldn't use the filter to help ease the process), you'd have to somehow identify the "newly discovered" patches from a massive list. Pending approval gives you a "clean slate" each cycle so you can very easily identify the newly discovered patches, look through them, and then filter them off to approved or off to denied.
Pending Approval is a very powerful function of patch policies, but it's intended to to this very specific task. Trying to get it to do something else would be taking away a very key component to automating and simplifying the management of patches. For a rollout of a patch like IE, assign the "No IE" policy to all machines, then remove it from those machines that are slated to upgrade to the next version of IE. When the next group of machines is identified as the 2nd phase, remove the No IE policy from those machines. Because the No IE policy is the ONLY policy (in my example above) that would be blocking the IE patches, the patch make its way to each group of machines as you remove that policy.
Your suggestion to have a way for the system to interpret "pending approval" (or some other not-currently-available status) as approved would need to be thought through very carefully. It is much "safer" to be more restrictive when there are conflicts - not allowing a patch to install usually won't have a negative impact on a customer or machine (and even if it does, it's quick and easy to resolve). Installing a patch that is not explicitly approved across all assigned patch policies could lead to the deployment of patches that you didn't intend to make it out, and the chances of this occurring would be quite high. This can be detrimental and create a tremendous amount of work for both admins and end users. I would not see this as something that ALL Kaseya users would want (and know many that would specifically rebel against that kind of behavior). However, it's absolutely something you should consider submitting as a feature request - perhaps some server-level override can be configured to allow admins, on a per-K-server-basis, to allow the behavior you're suggesting for your specific server, but default to the current behavior unless an admin explicitly chooses to override the behavior.
Thank you for your response. However your description sounds a lot more complicated than I think it needs to be.
I have one policy assigned to all my PCs that I review every month. Sometimes I have to either deny or leave a patch as pending because I cant have it deployed to all the PCs. If I could just create a policy called "Allow IE11" for example, I could slowly add machines to this policy (which only has IE11 as the approved patch), as well as the standard PC policy to roll it out. I can also NOT add it to clients who cant use IE11. Its very simple. Plus I can do it through policy manager by just updating a global variable through policy manager.
Thanks again for your response, but Ill agree to disagree and create an enhancement request.