Kaseya Community

Patch Management - A sharing moment...

  • Time to share how I'm doing patch management - I've read how others do it, I've discussed with Kaseya engineers, and aparently we have a "great" way of doing things.

    We have a common workstation policy.  Patches that most, if not all of our customers want.  (We also have a "Server" policy, but for sake of example, going through workstation...)
    Some client exceptions: One has a design department which cannot move to XP SP3.  One has a "We have to support IE 7, please don't install beyond this".  One has a "Do NOT install .NET 4" policy.

    Rather than create a set of full similar policies for just that client / rules, create a series of sieves which allow all but the blocked.  Some of ours: No .NET4, No IE8, No SP - Windows, No SP - Office, No SP - Exchange, No SP - SQL Server, No WGA (we all have / had "That client"... legit now, but then... *sigh*)

    Example: Client has a workstation which wants most "common" policies, no .NET 4, no IE8

    Member of 3 policies: "Common", "No IE8", "No .NET4".

    1. "Common" - Accept that which we want across the board, deny that which we don't.
    2. "No .NET4" - Manually run through, search out and deny .NET4 framework installers, approve everything else.
      Set all non-relevant categories (hotfixes, security updates) to Approved
      Set all obvious non-relevant software (Eg: Office, SQL Server, Exchange, Report server) to Approved
      All other categories / software gets set to "Pending Approval"
    3. "No IE8" - Everything is approved, IE8 is denied.  Same mentality for categories / software packages as "No .NET4".

    Repeat for "No Office Service packs", "No Server Service packs", "No Server Software Service Packs", "No [special environment]"

    Process: We go through on a weekly basis and check patches that came through, for all policies.  Most of the exception policies, deny the relevant patches and approve everything else (nothing should sit in "Pending Approval" for more than a few hours).

    This way, the "exceptions" are blocked, and everything blows through to the next policy.  The only policy which "should" allow/deny the main patches would be the common policy - this is all based on the simple idea that:

    • Deny will override any Pending Approval or Approved
    • Pending Approval will override any Approved

    "Common" could install IE8, but the "No IE8" would prevent it from getting through.  

    Seems to work great.  Hope it helps anybody struggling with it.

    [edited by: tkindree at 3:30 PM (GMT -7) on 3-24-2011] Membership note
  • Nice approach and clear description of 'how you do it'.  We're evaluating our own patch policies/process as we prepare to migrate to K2 so this is good food for thought!

  • Hey Tkindree!

    It sounds very well.

    Just to make it sure, i can combine any policy memberships and the DENYs in it overrides ANY allowed? So i can combine each with each other, and all NOs prevent installing?

  • The most restrictive will ALWAYS prevail.  Therefore, if you have a patch set to approved in 3 policies and denied in 1 policy, all 4 policies are applied to a single workstation, the patch will be denied because it is not approved in all policies.

    Bear in mind that a status of Pending Approval is functionally a deny, so if a patch is approved in 3 policies and Pending Approval in 1 policy, all 4 policies are applied to a single workstation, the patch will still be denied because, again, it is not explicitly approved in all polices.

  • Great explanation. Thanks.

  • It's part of the nature of how this kind of system works well for us - the default is "Install everything" (with some blocking - Eg: MS Security Essentials).  The "block these" would have the "Prevent this from installing", which are cumulative.

    The only real issue is that you need to go through policy management once or twice a week, scan through all the exceptions to ensure that there isn't anything in "pending approval" status.  If you can guarantee that no new patch / system configuration would allow the offending software through, all the classifications / products could be set to allow, and everything *should* get through (An exception would be any new software previously not found within the list of products at time of configuration - the default new product status is "pending approval")

    Example of the reason to not auto-approve all products & classifications:

    We have a policy which blocks IE8.  A client requires some computers to remain on IE7.

    We've blocked it in Windows XP 32/64, Vista 32, Win7 32/64, 2003 32/64, 2003 SBS, 2008 64, 2008 R2 64 - all systems / environments which we have in place at our client sites.

    A new system pops up - Windows Vista 64 - previously didn't have any.  It would suddenly appear within Pending Approval.  had we set everything to "Approve Automatically" for both product and classification, it would be approved - it falls under "Windows Vista" for product.  Any Vista 64 bit system, with this policy attached, would have unexpected results.  Which would repeat continually until the issue was caught.

    It DOES speed some things up, and allows for the same policies to be applied to multiple groups / orgs / clients / _____ without having to recreate all policies for small exceptions.  "6 systems in QA cannot have IE 8 / 9 installed", "These developers can't have .NET 4.0", "KB_______ conflicts with the software used by this department".