SCCM 2012 Hard Drive with Bad Blocks Baseline

This PowerShell script will detect systems where the main hard drive is developing bad blocks.
Or as I call it, the "Click of Death".

Continuing with my previous posts on SCCM 2012 baselines items...
http://gmnetadmin.blogspot.ca/2015/01/using-sccm-2012-compliance-settings-to.html

Same steps as Option 2 in the above mentioned post but using the discovery script below...
Changes...

1. You can add more If statements or expand it use ElseIf to record bad blocks from other hard drives.
2. Or change the text in the If statement to just '*bad block*' to count all bad blocks event entries.

#Version 1.00 Feb 2, 2015
#SCCM Baseline for Bad Block on C Drive
$AllEvents = 0

#Default Event Logs
$Provider = "Disk"
$HourChange = 24 
$TimeNow = [DateTime]::Now
$TimeChange = [DateTime]::Now.AddHours(-$HourChange)

#Check Event Log for errors
$EventLogNames = "System"

ForEach ($log in $EventLogNames){
    $entry = " " 
    #Search Event Logs
    
    $LogEntry = Get-WinEvent -LogName $log | Where-Object {$_.timeCreated -ge $TimeChange -and $_.ProviderName -eq $Provider}
        ForEach ($entry in $LogEntry){
            $EvLevel = "Level: `t" + $entry.LevelDisplayName + $nl
            $EvEventID = "EventID: `t" + $entry.ID + $nl
            $EvMessage = "Message: `t" + $entry.Message
            $EvSource = "Source: `t" + $entry.ProviderName + $nl
            $EvTime = "Time Created: `t" + $entry.TimeCreated + $nl
            #write-host $EvLevel + $EvEventID + $EvMessage + $EvSource +$EvTime + $nl

           If ($EvMessage -like '*The device, \Device\Harddisk0\DR0, has a bad block*'){
                $AllEvents += 1
            }
                        
        }

}
write-host $AllEvents


More SCCM related posts

Using SCCM 2012 Compliance Settings to Determine Hard Drive Health

As long as your computer has S.M.A.R.T hard drive diagnostic capabilities, the following can be used to track hard drive failures.

Configuration Item(s) in SCCM 2012.

Option 1 - Using WQL query

Name - Hard Drive Predictive Failure

Platforms - All (Although, if they are virtual machines this will not work.)

Settings -

• Name: Storage Driver Failure Prediction
• Type: WQL Query
• Data: String
• Namespace: root\wmi
• Class: MSStorageDriver_FailurePredictStatus
• Property:PredictFailure

Compliance Rules

• Name: Possible Hard Drive Failure is True
• I named it this to remind me that "False" is the result we want.
• Rule: Storage Driver Failure Prediction Equals False
• Noncompliance severity: Critical

 Option 2 - Using PowerShell script to read system event log

This option will read the System event log and count any 'disk' source logs that are not Information level. 
Note: This will include issues with temporarily attached external hard drives or USB drives.

Name - Event Log Disk Errors
Platforms - All (This will work for servers and virtual machines)
Settings

• Name: Report disk errors found in Event Log
• Type: Script
• Discovery script (See end of post)
• Counts the events and writes that value.

Compliance Rules

• Name: Disk error count
• Rule: Less than 1 (That's a number one)
• Noncompliance severity: Critical

Now that you have created the Configuration Items, you can add (one or both) to a Configuration Baseline and deploy them to your collections.

Once deployed create collections for the non compliant systems and then use that information in reports for your help desk or create a Task sequence that alerts the end user that the hard drive is may be failing.

Here's the PowerShell script...
- Updated Feb 3, 2015 to exclude '*Device\Harddisk1\DR1*' event logs.

#Version 2.30 Feb 3, 2015
#Designed for SCCM Baseline
$AllEvents = 0
#Default Event Logs
$Provider = "disk"
$HourChange = 24 #Up to you how far back you want to go
$TimeNow = [DateTime]::Now
$TimeChange = [DateTime]::Now.AddHours(-$HourChange)
#Check Event Log for errors
$EventLogNames = "System"
ForEach ($log in $EventLogNames){
    $entry = " "
    #Search Event Logs
   
    $LogEntry = Get-WinEvent -LogName $log | Where-Object {$_.timeCreated -ge $TimeChange -and $_.ProviderName -contains $Provider -and ($_.LevelDisplayName -eq 'Warning' -or $_.LevelDisplayName -eq 'Error' -or $_.LevelDisplayName -eq 'Critical')}
        ForEach ($entry in $LogEntry){
            $EvLevel = "Level: `t" + $entry.LevelDisplayName + $nl
            $EvEventID = "EventID: `t" + $entry.ID + $nl
            $EvMessage = "Message: `t" + $entry.Message + $nl
            $EvSource = "Source: `t" + $entry.ProviderName + $nl
            $EvTime = "Time Created: `t" + $entry.TimeCreated + $nl
            #write-host $EvLevel + $EvEventID + $EvMessage + $EvSource +$EvTime + $nl

            #If ($entry.LevelDisplayName -eq "Critical" -or $entry.LevelDisplayName -eq "Warning" -or $entry.LevelDisplayName -eq "Error"){
            If ($EvMessage.tostring() -like '*Device\Harddisk1\DR1*'){
                #nothing
            }
            ElseIf ($entry.LevelDisplayName -eq "Critical" -or $entry.LevelDisplayName -eq "Warning" -or $entry.LevelDisplayName -eq "Error"){
             $AllEvents += 1
            }
                       
        }
}
write-host $AllEvents


More SCCM related posts

Recovering Laptop Harddrive with Sync Toy and USB Dock Master

Needed to recover data off of a laptop and moving the files just wasn't working...

 

 

Decided to try Microsoft's SyncToy. We use it on some of our laptops to backup data from the laptop user's documents folder to a server which has it's own backup.

 

Created folder pairs for syncing between the failed harddrive and new folder on my desktop.

Since the harddrive was failing (faint click sound), paging errors and the odd bad block error showed up in the event log and SyncToy would stall, but not stop responding.  (Unlike Windows explorer)

 

To get it to start copying again, simply unplugged the USB cable from my desktop and plug it in again.

 

Now most copy jobs would stop completely when you do this, but not SyncToy. It moved on to the next file and try to copy that one.  

 

Granted there would be some files that would be missed based on how long Windows took to re connect the drive however, that is better than no files at all or manually copying over file by file and trying to find out which one was failing.

 

Once that was done, reran the Windows Chkdsk program on the drive and then ran the SyncToy folder pairs again to recover more files. 

 

Since SyncToy catalogs and compares file changes, this time the Sync took less time.  The harddrive still had that faint click of death and still required unplugging and plugging the USB cable.  When SyncToy stalled on a bad file, wrote down the file name(s) and then went back into the Folder pair settings and excluded the file(s).  This helped recover as much as 90% of the folders contents in some cases.