Kaseya Community

Policy Management & Individual Settings

  • Hi All,

    I apologise if this has already been reviewed but I was unable to find any reference to it using search.

    When using Policy Management, we use a number of policies to complete various tasks (Global Credentials, Global Remote Control Settings, Patch Management for Desktops, etc). This works great and extremely well if everyone machine under the view for the policy never required any individual changes, however that isn't the case.

    The biggest gripe that I have with the system is that if I need to change a free space alarm threshold on an individual machine and then sometime down the track re-apply the policy for free space, I end up with 2 alarms.

    When you start getting to hundreds of machines that require individual settings, this becomes earth shatteringly boring and tedious very quickly.

    Is anyone out there able to point me in the direction of a fix or work around?

  • *BUMP*

    Anyone have any thoughts on this?

  • I think what you describe is just an inherent weakness in the concept of policy-driven machine settings.  If you set up a policy and apply it to all of your machines (or machines matching a certain view even), there will always be exceptions.  I don't believe that this is a defect in the Policy Management product.

    That said, managing "exceptions" can be a pain unless you take a step back and think hard about how you want to handle the outliers.

    Example: I have a Machine Custom Field called Automatic_Monitoring-Detected* that gets updated nightly (on servers) with a comma-delimited list of found roles (NTDS, DHCP, DNS, EXCH2010, etc...).  The companion to that field is Automatic_Monitoring-Excluded* that gets manually updated if there's a particular automatically-detected service that I don't want to monitor.  In the view definition, under Advanced for, say, a "Automatic Monitoring - Exchange 2010*" View, I would have the fields as follows:

    Automatic_Monitoring-Detected* = *EXCH2010*
    Automatic_Monitoring-Excluded* = NOT *EXCH2010*

    So, by populating the Automatic_Monitoring-Excluded* field with EXCH2010, that machine would fall out of the "Automatic Monitoring - Exchange 2010" View, and not have the Exchange monitor sets applied to it.

    I take a different approach with the Disk Free Space Monitor Sets... during the onboard, I add a heap of registry values (A through Z) for each drive.  I then determine, "Is this a server or workstation?"  If it's a server, I set those thresholds to 15%, and a workstation, 5%.  So, each value (A through Z) has a corresponding "default" threshold number.

    I then apply the 5% Monitor Set to machines in the Monitoring_Type-Workstations* View, and the 15% Monitor Set to the Monitoring_Type-Servers* view.

    The key is the next bit... if a drive is below the threshold, instead of firing an alarm, have it fire an Agent Procedure first that checks the registry for the corresponding drive letter (you can get at these from the <ln> variable (see http://help.kaseya.com/webhelp/en/vsa/6020000/index.htm?toc.htm?1936.htm))... and if the drive letter in the alarm has a lower threshold, compare that lower threshold value (from the registry) to the <lv> (log value) and alert from there if necessary.  Once you learn about these variables, a whole world of possibilites are opened up along the avenue of "Automatic Remediation" (fire an Agent Procedure instead of a ticket/e-mail/immediate alarm).

    I think the whole key here is deploying as much as you can through Policy, using Machine Custom Fields and Custom Views to dictate which machines fall into or out of that Policy, and manually apply the rest (my Server reboot schedules are still done manually, for example... so I just leave that policy undefined).

    Hope this helps... it's a very powerful product, and you sometimes have to think a bit laterally to get what you want out of it... but once you get started on this and dive really deep into it, you'd be amazed how much time a properly-thought-out Policy deployment can save you in the long run.  It just takes a bit more re-thinking and time investment up front... that trust me will pay dividends later on.  Smile

  • Brian, that's a brilliant solution.  Thanks for chiming in and sharing with the community here.  You've helped me greatly!

  • Luke Bragg

    Hi All,

    I apologise if this has already been reviewed but I was unable to find any reference to it using search.

    When using Policy Management, we use a number of policies to complete various tasks (Global Credentials, Global Remote Control Settings, Patch Management for Desktops, etc). This works great and extremely well if everyone machine under the view for the policy never required any individual changes, however that isn't the case.

    The biggest gripe that I have with the system is that if I need to change a free space alarm threshold on an individual machine and then sometime down the track re-apply the policy for free space, I end up with 2 alarms.

    When you start getting to hundreds of machines that require individual settings, this becomes earth shatteringly boring and tedious very quickly.

    Is anyone out there able to point me in the direction of a fix or work around?

    i dont see how it's possible to get 2 alarms. are you creating a new  monitorset and applying it to the machine and removing the original one ? so when you reapply the original  policy you then have two monitorsets monitoring the same thing and therefore 2 alarms?

    Cos if you want to change the settings on one machine that has been applied to many you could simply individualise the original monitorset (there is a button for this) meaning there is still only one monitor set.

    while there is nothing wrong with  suggestion and it's quite right. Doing that kind of thing becomes very complicated and unclear to your enginners what's the actual alarm threshold is as it's no longer what's set in the monitorset or whats showing in monitorlog. To me it seems 100% simpler and clearer to everyone to simlpy create a new monitorset and policy and apply it to the machine you want as it will Over ride the original monitor set's settings. Job done

     

     



    [edited by: Michael Dixon (enfusion) at 9:08 PM (GMT -7) on 12 Jul 2012] l