Kaseya Community

Blocking any patching at the group/org level in Policy Management

This question is answered

If there are default patch settings in a policy at the Global level, including:

- Patch Schedule

- Source

- Profile

- etc.

Does anyone have a good method of completely BYPASSING Kaseya Patching and NOT affecting the patching a customer is doing on their own? For example we're pushing out agents for an Audit of a prospects network. If we affect their current patching they will of course freak out.

I'd hate to have to assign all our patching at the ORG level just so one group doesn't get affected under Global.

Thanks for any thoughts or advice.

Verified Answer
  • Simply setup a custom field that will flag a machine as disabled for patch:

    DisableKaseyaPatch : (0/1)

    The from there in Policy Management configure the patch configuration settings and make sure that the view only shows machines that have the boolean set to 0 (false)

    Then the policy should only propagate to all the ones who DisableKaseyaPatch field is set to false.

    The rest should not receive the patch configuration by policy.

  • Interprom,

    I understand where you're coming from, but the only place you potentially would run into issues is IF the prospective client is allowing end users to manage their own patching via the Windows Update Client (the "Windows Update" or "Automatic Update" option available in the Control Panel) and if that client does NOT employ Group Policy or similar functionality to dictate the configuration of the Windows Update client AND if you configure Kaseya to allow the Windows Auto Update setting to "disable" the local Windows Update client.

    A Kaseya-side Patch Policy configured to "deny" does not touch the client machine - it just tells Kaseya which patches to instruct the Windows Update Agent (which is the underlying component of the Windows Update Client (thank you Microsoft for confusing terminology)) to install or tells Kaseya which patches to download and install (the install method varies based on the File Source Config).    The patch schedule settings of "None" only instruct Kaseya what time the Kaseya-side procedures should kick off and instruct the agent to begin patch installs.  Since None = Never, the processes won't schedule on the KServer, the instructions won't be sent to the agent, and Kaseya will not attempt to install patches on the workstations.  

    Disabling windows auto update is the only place you *might* affect the client's own patching processes.  Everything else regarding patch processes are wholly Kaseya-side, and that's only if they are relying on the Windows Update Client (not the Service, but the Client) to patch AND aren't using something like GPO to define the Windows Update Client registry setting (support.microsoft.com/.../328010).

    Regardless of what method you use to block patching from the prospect, I highly advise you tread carefully with the Windows Auto Update > Disabled setting if you aren't certain of whether they're using GPO to define the windows update client config on the local machines.  If you have this Policy Object defined (and set to disabled) at the Global level, it will trickle down to all machines at this client if you choose to bring that client into Policy Management.  Even if you use the Custom Fields to help with the assignment of the patch settings, the Windows Auto Update setting will make its way to the machines if you have that defined in a higher-level policy.  

All Replies
  • Simply setup a custom field that will flag a machine as disabled for patch:

    DisableKaseyaPatch : (0/1)

    The from there in Policy Management configure the patch configuration settings and make sure that the view only shows machines that have the boolean set to 0 (false)

    Then the policy should only propagate to all the ones who DisableKaseyaPatch field is set to false.

    The rest should not receive the patch configuration by policy.

  • Interprom,

    Any policy objects you assign as a lower level will take precedence over any conflicting policy objects assigned at a higher level.  Therefore, a policy assigned at the org will take precedence if any of the object conflict with a policy at the global level (machine group takes precedence over org, sub-group over a parent group, etc.).

    Create a client-specific policy and enable the patch objects (use a view that is sure to capture all computers at the client level, not just workstations).  Configure the schedules to "none."  This will override the schedule defined in the org-level policies leaving the schedule blank for the machines that get this policy.  If the schedule is blank, the process won't run.

    Assign this policy to the org.  The file source won't make a difference - if the install process can't run, then then the file source is moot.  This policy object does not change anything on the local machine, so it's configuration in this case is insignificant.  

    If you are using the policy object "Patch Windows Automatic Update" at the global level, you may want to verify how the prospective client is managing their Windows Auto Update (WAU) settings.  If the prospect disables the WAU client is disabled using Group Policy, then it won't harm anything for the Kaseya setting of "Disable Windows Auto Update" to populate to the machines.  However, if they are allowing users full access to the WAU client, then you may need to consider how to handle the WAU setting - either uncheck that policy object in the global policy or change the configure the Patch > Windows Auto Update settings on the prospect's machines after policy apply.  If the prospect is using Group Policy to dictate WAU settings, Group Policy will overwrite the settings assigned by Kaseya, but if you want to prevent stepping on any toes, it would be better to be proactive about this particular setting.

    If you wanted to add an additional layer of comfort, you could also create a Patch Policy which marks all patches as denied.  Add this patch policy to the Policy Management policy so the system assigns the "deny all" patch policy to all machines in the client's org.  This patch policy will prevent any patches from installing since the patch policy "deny" will take precedence over any other patch policies that get assigned to the machines.

  • Thanks for two excellent answers!

    Brande, my concern with your solution as it relates to my setup is that even though we've told Kaseya Patching NOT to install patches - we still may have blocked the customer's access to their own method of patching. It's not really something I even want to risk when dealing with a prospect. We have to gain their trust and installing an agent we say is benign and then changing their environment. I'm copying your answer though. It's going to come in handy!

    Flavio, Thanks for reminding me how powerful views are when paired with policies!

  • Interprom,

    I understand where you're coming from, but the only place you potentially would run into issues is IF the prospective client is allowing end users to manage their own patching via the Windows Update Client (the "Windows Update" or "Automatic Update" option available in the Control Panel) and if that client does NOT employ Group Policy or similar functionality to dictate the configuration of the Windows Update client AND if you configure Kaseya to allow the Windows Auto Update setting to "disable" the local Windows Update client.

    A Kaseya-side Patch Policy configured to "deny" does not touch the client machine - it just tells Kaseya which patches to instruct the Windows Update Agent (which is the underlying component of the Windows Update Client (thank you Microsoft for confusing terminology)) to install or tells Kaseya which patches to download and install (the install method varies based on the File Source Config).    The patch schedule settings of "None" only instruct Kaseya what time the Kaseya-side procedures should kick off and instruct the agent to begin patch installs.  Since None = Never, the processes won't schedule on the KServer, the instructions won't be sent to the agent, and Kaseya will not attempt to install patches on the workstations.  

    Disabling windows auto update is the only place you *might* affect the client's own patching processes.  Everything else regarding patch processes are wholly Kaseya-side, and that's only if they are relying on the Windows Update Client (not the Service, but the Client) to patch AND aren't using something like GPO to define the Windows Update Client registry setting (support.microsoft.com/.../328010).

    Regardless of what method you use to block patching from the prospect, I highly advise you tread carefully with the Windows Auto Update > Disabled setting if you aren't certain of whether they're using GPO to define the windows update client config on the local machines.  If you have this Policy Object defined (and set to disabled) at the Global level, it will trickle down to all machines at this client if you choose to bring that client into Policy Management.  Even if you use the Custom Fields to help with the assignment of the patch settings, the Windows Auto Update setting will make its way to the machines if you have that defined in a higher-level policy.  

  • Brande this is an excellent explanation! Thank you.

    Gavin