I have a group with 4 servers. One of the servers I do NOT want to patch. This group is set up through Patch Management. Is just clicking the "Suspend" button under Automatic Update and assigning it the "DoNotPatch" Membership sufficient enough to NOT patch the machine? Of should I remove the patch scan, group membership, reboot action etc off of the machine? I have not been using Kaseya for an entirely long time. I noticed that even with it being suspended, the "Patch Automatic Update" procedure is still scheduled to run on the machine and it did do a reboot on that night particular. I just could not tell if anything actually patched through or not.
I use the suspend feature with a custom patch group "DENY ALL PATCHES".
DENY ALL PATCHES is a group where I just deny every patch.
This will ensure the machine is suspended, and if Kaseya "hick-ups" on the schedule the group membership will kick in and no patches will be applied resulting in no reboot.
How can I configure this for just one server in a group? This particular client has 5 servers, but one server I cannot patch because every time we do, it breaks some software they use.
Using the "Suspend" feature on the Automatic Update page will prevent the patch cycle but keep the schedule in place so you can "unsuspend" wihtout having to reconfigure the schedule. There is a 'check' in place at the beginning of the cycle. If suspend is on, you'll see an entry in the Config Changes log at the time of the scheduled (but suspended) patch cycle indicating Auto Update did not run because the suspend is enabled. This ensures there is tracking to determine why a cycle didn't run. If we just skipped the cycle without any info, then several weeks later you might try to troubleshoot why a cycle didn't run. The entry in the Config Changes log helps preven running down rabbit holes unnecessarily.
You certainly can assign a patch policy with all patches denied, but this is unnecessary. You could also just delete the Automatic Update schedule, but this is also unnecessary and would require you then reconfig the schedule when you're ready to resume patching. That can be troublesome for businesses who have defined days/times allowed for patching for specific machines.
+1^^^ I use the strategy Brande Schweitzer references with the additional DENY ALL PATCH Policy fail safe.
::Create a policy::
Patch Management > Patch Policy > Create/Delete
Enter Name for policy
:: DENY PATCHES ::
Patch Management > Patch Policy > Approval by Policy
Select the Policy from the drop down
Click Pending Approval
:: ASSIGN POLICY ::
Patch Management > Patch Policy > Membership
Highlight the policy you want
Select the server you want the policy to apply to
Thank you Brande.
Where can I find the Config Changes log? I do not see it anywhere under Patch Management.
Also, while we are on the subject. IS there a better way to view WHICH patches were installed? I feel that the "Machine History" is not that great because under Status, the dates are all a mess and nothing is in chronological order according to installed date.
Logs are part of the Agent module. Navigate to Agent > Agent Logs, select the endpoint in question, then choose the Config Changes log (either from a dropdown or from tabs, depending on the version of VSA you're running).
The Agent Procedures log will list each patch that was installed during a specific cycle, if you want to dig into something specific. The AP log also has a lot of other info, so it can be more challenging to read, but it isn't impossible. You could always create a report if you need to regularly review which patches were installed when.
Thank you Brande and Kohen. Not sure how to give +1 rep here (if that is even a thing) but I thank you both. I now have the info I was looking for!