So we're 2 years into Kaseya. Kaseya Professional Services led the way for us in creating Global Policies for monitors that we want to apply to all machines, such as Agent settings, drive space monitors, CPU and memory monitors, etc. We were told that to create exceptions, just create a new Policy with the same monitor (but different settings) at either the Machine Group or Machine level, and that will override. Even the Kaseya documentation confirms that. I've also had support review our configuration on override policies and confirm "yep, that's how it works....nope, not sure why it's not working". Well, now that i've pushed for escalation, kaseya is now officially telling us that multiple policies are now cumulative and there's no option to override a monitor set. We now have to target overrides by using Views AND also removing our global policies, and I'm sure all of you know what a pain that's going to be. This also means that for every new client, we have to duplicate monitor sets all over the place instead of relying on Global Policies. This borders on insanity. Does anyone know the real answer and how to properly create a policy override? Let's say we have 2000 endpoints that we want to monitor CPU at 90% with a Global Policy, but there's 1 machine we want to monitor at 95%. Are you telling me that we have to blow away Global Policies and target this one machine with a custom View and apply the 90% monitor at every Org or Machine Group otherwise? Makes no sense if that's the way this was developed. Hugely frustrating. Someone please talk me off the ledge.
create child group under main company group; one to which you want to apply policy and second to which you want to deny. Then apply policies to child group level not to root level. Hope this will help.
We provide our clients with a few hundred policies to control monitors, agent config settings, patching, updating and other operational tasks. Every policy we provide is linked to the Global Org root level. If you want to override, its done either by changing a control setting or applying a policy to the org at the appropriate level. For example - we patch workstations on Thursdays. Want to patch on the third Saturday at 2 AM using a server schedule? Just set the correct server schedule code on the workstation. It removes the default workstation patch policy and links the server schedule instead. Still gets workstation updates.
100+ VA clients and 90K+ agents and we've never had to "unlink" a global policy that we built to apply an override. Last month's upgrade brought even more control to workstation patching with early/late schedules and the ability to resume patching in the morning if the workstation was offline, and either reboot or nag hourly with a countdown to a forced reboot. This is configurable not only per org, but multiple configurations can be delivered within a single org location. All with policies..
What's important to understand is that some settings merge while others replace. When you have settings that merge, you need more control to allow overrides by removing the global and allowing the local. Settings that replace are easy - just link the policy with the settings at a level closer to the agent. Some other guidelines we follow - we never duplicate policies, never create client-specific policies, never link policies directly to an agent, and never use "monolithic" or "do everything" policies.