AnonymousNot that I can see. Of course I missed the ability to prompt for a script parameter until I watched this youtube video from Benjamin
You can do it with a get variable and there is a new option "Prompt when a procedure is scheduled"Legacy Forum Name: Scripts Forum, Legacy Posted By Username: smbtechnology
It's unfortunate that the poster of the video has since removed the video. Would be nice to watch it.
Regarding the false fail indication. I log as follows:
smartctl 5.42 2011-10-20 r3458 [i686-w64-mingw32-win7-sp1] (sf-win32-5.42-1) Copyright (C) 2002-11 by Bruce Allen, smartmontools.sourceforge.net === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED Please note the following marginal Attributes: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 190 Airflow_Temperature_Cel 0x0022 045 030 045 Old_age Always FAILING_NOW 55 (0 82 61 16 0)
Note that the erronous string match is on the phrase "WHEN_FAILED". i.e. the word FAILED is part of a larger string. The main status is read from "result: PASSED". So, since the erronous string has an underscore character before it and the real result has a space character before it.
So, in your script, test for " FAILED" (i.e. include the space in the pattern match) and you won't false trigger, because "_FAILED" is not a match to " FAILED".
I tweaked this script to add the capabilty to scan ALL local physical disks on the computer, not just the C: drive. I also slightly tightened up the reporting to HEALTHY, WARNING and FAILED status in the custom field. I also eliminated the false positives by correcting the pattern match on FAILED to look for : FAILED, which locates the proper status on the disk (avoiding the false failure reading due to other appearances of FAILED elsewhere in the output
Very nice, David. Thanks.
Great script. What should I know about the "Warning" result V.S. a FAILED or Healthy? Is it still a good enough reason to replace the Hard Disk/Back up data?
Also, is this not to be run on servers? May I ask why?
Excellent! Very much appreciated.
The reason why not on servers, is mostly because RAID controllers generally don't like software accessing individual drives directly.
Just use some common sense - if you know a server uses only discrete disks, go for it. If it uses a RAID controller, however, best not to run the script just in case t upsets the RAID controller; you don't want to risk crashing an array or corrupting client data.
I want to know what are the following courses of action for each deemed result.
Warning = ?
Failed = Definitely backup data and replace the hard drive. Right?
Failed is obvious as you note. Warning would just indicate a degraded state, but I'm not sure about much else.
In response to Craig's note about running on servers with a RAID controller, my experience in running this script across a few hundred HP Proliant and a few Dell servers, all of them end up reporting healthy. The RAID controller masks the underlying drives, so the script is useless to find bad drives on the array controllers. However, the script does NOT cause any issues at all... it's just not possible to run a SMART query and have it cause a corruption or fault on the array.
So bottom line, you can run it to your hearts content, just realize that it can't peer past an array controller to see the drives.. . the drives have to be natively visable to the OS.