Just wondering what triggers a machine being defined as "Attached to Patch Management"?
Is it having a Scan Scheduled, an Automatic Update Scheduled, Membership of a Patch Policy, or something else?
Battling this myself.. Removing all system policies makes that message go away. Then I add a system policy to apply a specific Software Management scan policy and BAM! - the agent is "attached to Patch Management" again, even though Patch Management doesn't reference the machine.
I've got a ticket open, since we're trying to migrate all of our clients over before our next server patch cycle starts. I'll let you know what we find.
Thanks Glenn, and good luck with your migration.
Any update Glenn? We have this battle as well, will be logging a ticket shortly.
We have removed all reference to patch Management from policy, yet we can't do anything in Software Management as it claims a policy with Patch Management still applies. Frustrating.
SO - yes - update, but not currently a good one..
We have policies that apply settings and schedules to workstations, and settings to servers, We have a few dozen policies that we use to perform a few tasks (disable alerts, reboot) and then deploy updates that are assigned manually to a server (each policy has all configuration for a single update schedule, so one schedule policy per server.)
We exported all of the patch related policies as a backup, then figured we could simply remove the patch settings from the policy and add the S-M settings, eliminating the need to remove and re-assign all of the policies for server scheduling.
Turns out that we're facing two issues with this design.
1. "Policy Persistence"
The Patch settings in the policy remain in the policy, but are disabled. It seems that Software Management scans the settings but doesn't take the Enabled/Disabled status into account. Ticket 208573 references this issue and was confirmed and escalated to engineering just minutes ago. Our current workaround was to create all new policies for Software Management based patching, remove (unlink) all Patch Management policies, manually clear all assigned patch profiles, schedules, and policies, and then link the new software Management policies, which promptly resulted in -
2. "All or Nothing"
In our design, we have a policy that applies to every workstation to schedule the Scan/Analysis. The intent is to scan every workstation for reporting, even if we don't manage patching. A second policy, filtered to exclude the unmanaged systems (build group, audit group, etc.) should enable the Deployment policy. What we found is that Software Management does not allow policy combining. The Scan/Analysis policy is applied, and this marks the second Deployment policy as "conflicting" and prevents it from applying. This was confirmed by Kaseya in ticket 210330 and is being reviewed in today's engineering meeting. Short of combining the Scan/Analysis and Deployment profiles into a single policy, there's no good workaround at this time.
Both tickets were raised as Sev-2. BTW - with item 1, even clearing all the settings and then disabling the Patch Management options left some kind of tattoo in the policy.
I've got another "annoyance" with Software Management, and would appreciate the thoughts of others..
Defining a new (or editing) Deployment Policy - I tab from field to field, rarely using the mouse. When I tab to the Blackout Window section and press SPACE to enable the Mon-Fri schedule, TAB moves to the Sat-Sun field, not the Start Time field. Need to mouse-click in each of the Start and End time fields to select them, and then the focus is lost about 40% of the time, requiring a second click. Then - the input is in 12-hour format, not the 24-hour format of most other time input fields in Kaseya. It requires that you type 2 characters to search, so 11 return NINE choices - four for AM and five for PM.. Typing any 1-9 value requires that you add the colon (:) - off the number pad and a shift. Enter "2:" thinking 2AM/PM and you actually get SIXTEEN choices presented - eight for 12: am/pm and eight more for 2: am/pm. These two issues make it very difficult to power-through the creation of deployment profiles. Kaseya support reported this as "as designed". That may be the case, but that doesn't make it a good design, in my opinion.
A second issue with the Blackout schedules is that it doesn't distinguish between weekday and weekend. Exclude Mon-Fri 6am-11pm, then schedule Sunday at 10am and it reports a conflict with the blackout schedule. This was raised to engineering as a bug - just mentioning it as an FYI that it's an issue.
Through testing yesterday, I discovered that even though you have removed Patch Management scan from a policy, Software Management reckons otherwise.
I accidentally found that if I copied the policy to a different folder and then back to it's original location, the settings were "cleared" and it was no longer attached to the old module.
Appears to be still a few bugs in this module - and a lack of forum activity suggests not many are using it?
Good info Jo, regarding the move to clear solution. I'll have to give that a try here.
We're committed to using S-M and have been working heavily this past month on integrating it into our automation platform. We had just started a datacenter refresh here or might have participated in the S-B early release program. We got in right at the tail end.
Based on my experience so far with SM, I will only be licensing our OSX devices (for now). I'll continue to use Patch Management and Software Deployment (with Ninite license) to look after Windows machine operating system and third party patching.
I expect Kaseya will improve SM, but want to see some more maturity before moving completely across.
And thanks Glenn for the your post. Feels like you've had to reverse engineering the product- if only there was documentation form Kaseya that covered this :)
Thanks, aread. The information that I posted above, aside from the Sev-2 tickets, has been shared with the engineering management team. We do a lot of development around Kaseya and often use features more aggressively than most, so they often get an earful from us. :)
So - another small update/workaround.
As I said, we want to deploy the scan schedule to every computer and the patch/update (deployment) process to most, but not all. We have a policy that deploys the scan to all workstations and the deployment to those not excluded. I could get it to deploy the scan, but not the deployment (showed a policy conflict).
The order that the policies are linked into the Global Org section defines precedence, so I was able to tweak this concept somewhat. I added the Scan profile to the Deploy policy - workstations permitted to patch now get both scan and deploy profiles. Workstations excluded from patching do get the scan policy without conflict. I had to move the Deploy (now Scan/Deploy) policy up in the link order to make this work.
I'm still working on the servers configuration, since we have 48* specific deploy schedules that are manually linked by policy to each server. I'd have to update all 48 policies to include the scan, and then remove it when it is fixed. Since we have so many policies for the specific weekend change windows, I prefer to keep the common configuration and scan settings in a single policy, and use the specific policies only to disable alerts, reboot, and deploy updates on a specific schedule. At this point, I'll probably just (Ugh!) manually link the scan profile to the servers. That works, but I hate to manually configure anything other than the server update schedules (which we do by linking a schedule policy, but are moving to doing this via a custom field - still manual, but easier to update.)
*We have 6 Saturday, 6 Sunday, and 2 Wed mid-day patch windows 3 weeks each month.
Kaseya have come back to me on my ticket where agents are still attached to Patch Management - they found the bug and will be fixing it.
Basically if you remove Patch Management settings from an existing policy, Software Management will not recognize the change.
Issue: When using SM and attempting to disconnect machines from "Patch Management" the SM module flags the agent as belonging to a Patch Management Policy even though there are no Patch Management settings with the assigned policies to said agent. This is caused by records from PolicyObjectType linking a previously used policy for Patch Management even after all Patch Management settings are unchecked.
After further investigation, your issue has been identified to be a product defect and has been reported to our development team. It will be prioritized and addressed in a future release cycle as part of the normal patch process.