Kaseya Community

Excluding Server Drives under 2GBs from Monitor Set

This question has suggested answer(s)

We are in the SaaS environment and are having trouble finding a good way of excluding small drives on our 300+ servers that we manage. Typically these are Witness disks or OEM recovery disks/partitions.

All Replies
  • Create a custom field called "Excluded Drives"

    Add the drive letters you want to exclude on a per machine basis

    Then configure your Low Disk Monitoring to run a script when a low disk alert/alarm occurs.

    You can pass into the script the drive letter as a variable that the alarm relates to

    Then have the script compare this letter to the ones added to the custom field.

    If there is a match then just exit the script

    If there is no match i.e. you do want an alert/ticket , then use the "SendAlert" step in the script to create both

    Paul

  • I think the issue here is that we are not using service desk or real integration in Autotask. So alert events are emailed. Would the script run prior to the email alert being sent?

  • OK    .. so you can still run a script as suggested .. and then send the email from the script.

    It's exactly the same process except you would use sendemail instead of sendalert

    It also means you could built automation into that script to do disk cleanups etc and reduce the qty of email sent to autotask .. so a win/win

  • I ran into this issue too. I ended up creating monitors for every drive letter and then individually remove the drives I did not want to monitor.

  • I like this idea and have been toying around with a script that does something similar. I am basically using parts of the KITs script. First the script outputs the powershell commands to a txt file (Machine name and group, OS and Disk Space Free and utilization percentage). Next a cleaning happens which is basically a delete of the c:\temp, c:\windows\temp and a couple other items. After the cleaning the script continues  running the KITs disk script to output to the same txt file with the same information. Then the txt file contents would be emailed to my NOC.  This would basically give us a disk space usage before and after the cleaning.

    However the agent procedure I'm using keeps saying successful but it never actually ends. It doesn't fail, it just never finishes and sometimes the txt files aren't created. Im not sure if i am over complicating this or not.

  • How are you individually removing the drives from the policy for specific machines?

  • In Policy Management I do drive (Space) monitoring by monitor sets with different value and drive letters. I run a design Audit script that looks at a specfic server. When it has drives with many TB or low GB it sets a Profile in an Custom Agent Field. Then Policy Management applied the Monitor Set or just remove it.

    This work for us good. I was looking in another option that contants advance monitoring by drive with the help of a diskspace table with views on it and so deploying other sets specific per drive.

  • We finally came up with a script to deal with this issue.  I am no scripter, so it't probably longer than it needs to be :-) but all it does it compare the alarmed drive to the contents of a custom field, and decides if an alarm is to be raised or not, then doe the appropriate action.

    I have attached the script as an example - it took so long to get this solution together, I am more than happy to help someone else out!!

    Procedure Disk Monitored or Not Logic.xml



    formatting
    [edited by: Jo Bowers at 11:53 AM (GMT -7) on Aug 6, 2017]
  • Here's a few tips re the script and monitor sets for Low Disk

    1) If you use a "MonitorSet" based on perfmon counters , then the variable #LN# will the monitorSets "CounterName"

    e.g. typically something like "LogicalDisk::Free Megabytes"

    So for these edit the monitorset and change the Countername to just be a C or D or E etc

    Also there's not harm in creating 1 monitor set that contains all 26 letters. You dont ened 26 seperate sets.

    2) If you use Alerts/Low Disk then the #DL# will disks Drive Letter .. and #DL# is ONLY passed from the Alert Low Disk

    Both the above variables are passed fromthe monitor/alert etc to the Script.

    So in the script you can use these variables as they are automatically made avaiable

    3) In you CustomField you can also enter mulitple letters

    e.g. in DrivesNotMonitored you can enter E:F:G:H: as a single string represnting multiple drives to ignore

    4) Therefore in your script you can get rid of most of the ines and replace wit5h just a couple

    1st detemine if the scriopt is being called via an Alert or a Monitor Sets

    then do the comaprison , then set you Create alarm flag

    e.g.

    If #DL# exits then

    If #DrivesNotMonitored# contains "DL"

    GLOBAL:CreateAlarm = "NO"

    else

    If #DrivesNotMonitored# contains "LN"

    GLOBAL:CreateAlarm = "NO"

    I mioght seem a bit backwards but take an example of the E: Drive creating an alrm

    And you have put D:E:F:G in your custom field

    thenthe If statemt actaully reads like this

    If "D:E:F:G" contains "E:"

    GLOBAL:CreateAlarm = "NO"

  • Procedure Disk Monitored or Not LogicV2.xml

    Try this example

    I got rid of the createalarm global variable and just put the sendalert in each if branch as the subject / body differed for each as I use #DL# in one and #LN# in the other

    Also because all this is happening in the script all variables need to be #.# ... not <<.>>

    And if you ever plan on doing some dedupping of ticket/alerts based on matching subjects .. then I'd remove the #AT# as this would mean no 2 subjects would ever be the same as the time will always be different

    So import this one and have a play

  • I have posted my script that we have used successfully.  Then I edited my post because of yukky formatting, and the moderation police grabbed it.  :-(  Will repost shortly

  • We finally came up with a script to deal with this issue.  I am no scripter, so it't probably longer than it needs to be :-) but all it does it compare the alarmed drive to the contents of a custom field, and decides if an alarm is to be raised or not, then doe the appropriate action.

    I have attached the script as an example - it took so long to get this solution together, I am more than happy to help someone else out!!

    1462.Procedure Disk Monitored or Not Logic.xml

  • Also posted a rewrite of your example .. but the moderators have also grabbed it so it should turn up soonish once they release it

  • KJM,

    To answer your questions about individually removing the drives.

    Once you have your policy set. You can go to the Monitor > Agent Monitor > Assign monitoring and filter the machine you want to remove the drive letter and click on the notepad with the pencil (I believe it is called edit) next to the monitor you want to delete, then hit "clear." This will do an override for that particular machine.

    The thing you will have to keep in mind is the only way to get everything back to the way it was; you will have to override the policy through policy management.

  • Procedure Disk Monitored or Not LogicV3.xml

    Uploaded a modified version of the script as I forgot to include a coupe lines needed for the SendAlert

    Basically lines 3 and 5 allow you to decide if you create an Alarm or Ticket or Both depending on how you enable them

    Also in you monitor sets make sure you have the "Enable Matching" check box ticked ..and run an update list by scan every now and then as this will help  auto remove from what is actually applied from your monitor set to the actual machine

    e.g. it would auto remove any drives that do not exist on that machine

    So again use a single monitor set that has ever drive letter included , assign it via policy management and let the "Enable Matching" and Update List by scan process auto manage what drives are actively monitored.