Windows 2008 R2

My First PowerShell Script

Posted on

Necessity being the motherf***er of invention, I took my first step at becoming an IT adult.  I was inspired by my colleague Dean Bunn here on the UC Davis campus who has done incredible scripting to automate and make our IT day a little shorter and easier.  Thanks, Dean.

I used The Windows PowerShell Library at Microsoft’s TechNet site for syntax and use.  Great resource!

This script is presented with no warranties, rights or responsibilities for it’s use in any situation.  If you use this script for your own purposes, it’s your fault if you EFF something up…PERIOD.

I recommend that you “#” (comment-out) the Clear-EventLog $log -ComputerName $server line before you start modifying and testing the script.  You’ve been warned.


# EventLogMaintenance.ps1
# By Brian McQuaig

# This script will go to each server, retrieve and save error events from specific logs
# save the logs as CSV files on your local computer and the remote server.
# This script expects:
#   Your local computer has a C:\adminlogs directory.
#   Your remote server has a c:\adminlogs directory.
#   You are logged into a computer with the proper setup to obtain NETBIOS resolution.
#   You are logged in with your global ADMIN credentials.That is,
#     credentials that cover your local and remote connections.
# NOTE: It is common for you to see errors when the script is looking for “failure audit”
# entries in anything but the security log. So, please disregard those errors, if encountered.
# ——————————————————-

# Set names of path & date
$t = get-date
$p = “c:\adminlogs\”

# Create an array of your server’s NETBIOS names…
$servernames = “Server1″,”Server2″,”Server3″,”Server4″,”Server5″,”Server6″,”Server7″,”Server8”

# Create an array of the types of logs we’re going to review
$logtype = “application”,”security”,”system”

# First loop: Yank each servername in-turn.
Foreach ($server in $servernames){

# Second loop (nested in first, to get/save each log from the specific server in-focus.
Foreach ($log in $logtype) {

# $filname is going to equal the local adminlogs path + the name of the file.
$filename = $p + $server + “_” + $log +”_” + $t.Year + $t.Month + $t.Day + “_” + $t.hour + $t.minute + “.csv”

# $sharename is going to equal the remote server’s path to the adminlogs directory + the name of the file.
$sharename = “\\” + $server + “\c$\adminlogs\” + $log +”_” + $t.Year + $t.Month + $t.Day + “_” + $t.hour + $t.minute + “.csv”

# Now get $server’s $log and export it to your local adminlog directory for review. Then tell me that you’ve done it.
Get-EventLog $log -ComputerName $server -EntryType error,failureaudit | Export-Csv $filename
$filename + ” written.”

# Now get $server’s $log and export it to the $server’s adminlog directory for safekeeping.  Then tell me that you’ve done just that.
Get-EventLog $log -Computername $server -EntryType error,failureaudit | Export-Csv $sharename
$sharename + ” written.”

# OK…Eventlog saved, now clear the event log and go on to the other logs/servers.
Clear-EventLog $log -ComputerName $server
$log + ” on ” + $server + ” cleared.”
“Script Finished.  Now rifle through the CSV files on your local computer at c:\adminlogs and fix stuff!”
# done

Windows 2008 R2, VSS Error 8193

Posted on Updated on

This fix from David Shen (TechNet) solved my issue so I wanted to pass it along.  My issue stemmed from my backup server running Backup Exec 2010 failing to do a proper snapshot “freeze” of my server volume because the server’s VSS (Volume Shadow Service) was having “issues”.  Those issues were generating massive VSS Error 8193’s in my server’s System log.  Here’s a sample of what I was seeing:

VSS Error 8193
VSS Error 8193

And here is David’s fix, which worked for my situation:


According to the research, the issue may be caused by an invalid entry inside the following registry sub tree.

HKey_Local_Machine\Software\Microsoft\Windows NT\CurrentVersion\ProfileList

Please open the registry editor with regedit.

Expand and local to the subtree, check if there is an entry that has a “.bak” value appended. If so, this may be cause the failure when trying to resolve the SID of the writer.

Please backup the registry key first, and then delete that entry with the extra “.bak”

Then you may reboot the problematic server to check if it the issue can be fixed.

Hope it helps.
David Shen – MSFT

I found the .bak entry and I deleted it and after the restart, it was fixed.