Kaseya Community

Excluding disk space monitoring from a single drive

This question has suggested answer(s)

We are using policies to monitor and alarm on free disk space when it drops below 2Gb.   Some servers have a 100Mb partition, and this alert is firing on them.  How are others getting around this?  Is there a way to exclude only one drive for a particular client from the monitor?  Policies work well for us, but there are always exceptions to the general rules, and no obvious way of getting around them.  If we remove from the machine, the policy shows in an override condition.  And because the monitor checks ALL drives, this is no good as it turns off the alert for ALL drives, not just one.

All Replies
  • Hi,

    Are you using the Low Disk Alert function or a Monitor Set to monitor free disk space.  The Low Disk Alert function is limited and monitors all drives using the same threshold.  For more robust/complex monitoring scenarios you would be advised to create Monitor Sets for the various drives and thresholds you need.

    Regards,

    Matt Warburton

    Kaseya Professional Services

  • Agree with ... don't use the Alert function, use Monitor Sets.

    Myself and others have outlined our solutions to this issue here: http://community.kaseya.com/xsp/f/133/t/18703.aspx

    Hope this helps!

  • We are using monitor sets for disk space monitoring.  Was hoping to be able to get away with a global policy for all, and modify for exceptions as we need to.  Doesn't look like this is able to be done without creating a monitor set for each possible drive letter, and then adding a separate policy for each client as required.  

    I haven't tested this yet - but would there be any issues in having a monitor set applied to a server that includes monitoring for a drive letter that does not exist on that particular server?

  • tonijo
    ...would there be any issues in having a monitor set applied to a server that includes monitoring for a drive letter that does not exist on that particular server?

    Just make sure that Counter Matching is enabled for each monitor set.

    Also, be aware that there's a bug when creating a new Monitor Set from scratch, in that "Counter Matching" isn't "sticky," i.e. it doesn't stay checked upon first creation/save of the Monitor Set.  You have to re-open the Monitor Set after your first save, re-check "Counter Matching" and save again.  Kaseya is aware of the bug, but for whatever reason, they "Feature Request"-ed the fix.  Huh?

  • Counter matching when set in a monitor set will automatically NOT monitor something that doesn't exist.

    So A Low disk monitor set for drives C-Z assigned to a machine that only has a CD and E will only monitor those three drives , counter matching will remove monitoring for F-Z.

    So using Policy management to deploy Kaseya just sorts this out automatically.

    The trick is when there is in fact a fixed drive that you want to ignore

    So several ways to tackle this.

    1) Just let policy management deploy the full Low Disk set and then individualise it and remove the particular drive you want to ignore ( or just change its thresholds so it never alarms.

    2) Create a custom field and in that field list the Drive Letter to ignore , then on a Low Disk Alarm have a script compare the Alarmed Drive against the custom field

  • Paul Haaker
    2) Create a custom field and in that field list the Drive Letter to ignore , then on a Low Disk Alarm have a script compare the Alarmed Drive against the custom field

    Ding ding ding Big Smile  (Breaking Bad reference, for those not in the know Smile)

  • Thanks for the tip Brian about that bug on counter matching - you'd think they would fix that with some priority....  I have just done some testing, and indeed counter matching is not working so will go into each setting and toggle it.

  • Another method I use is to test for Volume labels into the Script.

    I.E. I  have the script ALWAYS ignore any alarm if the drive volume label is "HP Recovery" or "System Reserved" or "HP Tools" etc etc

  • I recently implemented scripted method to do this that writes values to 4 custom fields;

     - DiskDrive_Exclude
     - DiskDrive_LocalDisk
     - DiskDrive_LocalDiskLarge
     - DiskDrive_Removable

    I used this script from the Microsoft Scripting Guy as a template as it had a critical component for automating disk identification. What you need to find out is what interface these local disk uses (USB, 1394, SCSI, IDE, HDC) and categorize them accordingly. I also added Size check so that I can auto assign the Minimum Low Disk space monitor sets by either 15% or 10GB.

    I then created view filters (for each drive letter) for my Policies and configured the "Advanced agent data filter" to filter the 4 custom fields as follows;

    Critical Low

    Minimum Low Large

    Minimum Low Small



    Added missing pictures
    [edited by: HardKnoX at 4:16 PM (GMT -7) on Aug 29, 2013]
  • So even with counter matching turned on, is it normal to see "Not Responding" in Monitor Log for a drive that does not exist?

  • Run an "Update List By Scan"

  • Do I need to process policies after the update list by scan, or should it eventually sort itself out?

  • tonijo
    Do I need to process policies after the update list by scan...?

    Yes.

    Then, for good measure (and to get the ball rolling immediately), Reprocess Policies.

  • ...and, for the record, ATTN: the new Management at Kaseya.  Hello!  Welcome!  We look forward to what you've got in store (honestly!)!  ...but please don't take away this forum--which; despite the occasional negativity, helps all of your Customers reach out, connect, and help each other out with our day-to-day issues!  Wink

  • Hi Brian .. what makes you think the forum will disappear ?