Kaseya Community

Attached to Patch Management Help

  • In Software Management, can anybody please explain why when I have no machines by policy or procedure attached to Patch Management, that on any given day, machines re-attach themselves and I need to dis-connect them.

    From what I can see, if a change is made to any policy, or procedure, or profile and then saved and applied, I run the risk of the machine attached to Patch management.

    I have 1700 machines, and minimally, I need to review to make sure they remain unattached.


  • Policies for Software Management are "broken", as in "they work differently from standard system policies".

    System Policies for all other products will "merge", so if you have multiple policies, the settings apply from each policy, with policies applied later/lower in the structure overriding settings from earlier/higher policies. Unfortunately, the Software Management settings "replace" the settings. This can result in strange and often unwanted results, which is one of several reasons that we stopped using Software Management.

    We use separate policies for each group of common setting (much like GPOs in AD) and as such, did not test combining Software Management settings with other system settings. Our Software Management policies did schedule two procedure, and we did have many compliance issues with them, but our focus was on the inability to merge settings. I had no desire to define the configuration in every schedule policy (we have about 90 schedules for server patching but just one policy to define most of the configuration settings).

    I'd try creating separate policies for just Software Management if you're combining settings and see if that helps. (we use Patch Management still, all controlled by System Policies, and across 3000+ agents, all systems are current for patch and application updates. Never had that during the roughly 7 months we worked with Software Management!)


  • Thanks Glenn for your response.  

    I do have a 2 policies, one for servers and one for workstations with the necessary overrides and profiles.  I then crated a policy in policy management to include the message reminder procedure, etc. thinking that when a new machine comes on board, it would adapt the Software Management module along with another on-boarding necessary.

    If I understand you, I should remove the Policy management policy and just rely on the Software Management Module profiles and overrides. Maybe they are working against one another?  We do not use Patch Management or Software Deployment at all.


  • We drive everything with policies, never create manual settings for anything.

    What we found is that the Software Management settings in policies didn't follow the same "merge" rules that all other settings honor, which pretty much prevented reasonable patch and update management scheduling with policies. We had other issues that arose once we started using Software Management and Policies - even though we had separate policies for everything. My concern (and can't test without returning to Software Management) is that defining a Software Management setting in a policy will impact the other settings, and possibly in other policies. We rely on the ability to merge policy settings, and that's what's fundamentally different (broken) with Software Management settings in policies - they work by replacing the settings with lower/more specific policies.

    We continued our testing by removing all policies related to Software Management and - for a while - managed Software Management manually. Since so much of VSA administration is automated, we decided that Software Management wasn't going to cut it with the amount of manual administration it required and went back to Patch Management.

    We have nearly 100 server update policies, one for every schedule in each change window (9 schedules * 2 change windows * 2 days * 3 weeks for patching). This allows us to define a patch schedule using a code and ensure that application groups reboot in the proper sequence. Managing that many Config + Schedule policies didn't make sense, particularly if a setting needed to change. Now, we have one common setting policy where those are defined, and the other policies define the schedule - suspend alarms, reboot, patch/reboot.

    We use an Excel spreadsheet to define the org, server, and patch code and a tool we wrote to update VSA with all the server patch codes. Makes scheduling server updating a breeze!


  • , it sure sounds like you have something in a default policy somewhere.  Next time it happens, go to Policy management-> Assignment-> Machines and hover over the offending machine's Policy Mgmt icon, until the pop up screen comes up.  The look at the 2nd tab, "Machine effective Policy settings" and see if you see anything changing one of the Patch Management fields.

  • Let me add an obvious point about Policy Management that I'm not seeing here.

    If possible Policy settings will be merged, that is if you apply different policies to a machine and those policies apply monitor sets for you, these will be merged. That's what you hope to accomplish in most cases by using Policy Management.

    But, some policy settings can't be merged and lower, more specific, policies will always overwrite these settings. Removing the setting from the policy you applied at a higher level. A good example is the setting for the Working Directory. You can't have 2 different settings for that, so whatever you set at the lowest level prevails over the other policy choice you might make higher up in the chain.

    I'm not sure if there is a sort of checklist what settings belong to the merge or overwrite class. It seems Software Management is implemented by the simplest method. Overwrite what you find. Changing that sounds like a fair bit of work. It'll require extended logic in Policy Management and might even mean changing the way Software Management settings are stored in the database.... Hmmm...