My research reminds me the secret of WMI
is that the operating system knows everything; it must be all seeing to perform its job. Fortunately, Microsoft allow us to share this privileged information thanks to WMI commands.
This Week's Mission
This week's
advanced script
interrogates the event logs and outputs the results to a text file. For instance, we may want to discover how many illegal attempts have been made to logon as administrator. Our mission emphasises the ability of scripts to automate boring
and time-consuming tasks, such as scouring the logs for one particular Event ID. This script also illustrates my mantra of how a manual walk through of the task, helps us understand the commands and thus build
a better script.
If you are looking for handy network utilities, try some of the free downloads at
Tools4Ever
Real work v Getting started
In the real world, we would concentrate on detecting illegal attempts to logon as administrator. As this is unlikely to have happened on
your test system, therefore, purely to get some action in the output file, I substituted Event ID 680 success for 675 failure.
Walk-through
A walk through is important not only for understanding my script, but also to
amend the Event IDs for your scenario. Frankly, if you take my advice then you will gain control of this script; whereas if you don't have a walk through of the Event Viewer, I fear that all which follows, will seem as clear as mud.
Open Event Viewer
Match what you see in the security log with variables, strLogType, intNumberID and intEventType in my script.
Select Security Log (Not System)
WMI variable strLogType = "'Security'" Note one set of single quotes, inside one set of double quotes, no spaces.
Event ID number intNumberID value = 680. Feel free to research our own numbers
Filter for Event 680 (Substitute 675 for illegal logon)
Filter for Success intEventType = 4 (Substitute intEventType = 5 for failures)
WMI Script to Check the Event Log
Normally I prefer to build WMI scripts in stages but on this occasion, I created only the final script. I am assuming that you have a grounding in VBScript in general and FSO in particular.
When we ask WMI to interrogate the Event Logs, the key Win32 object is called, Win32_NTLogEvent. Take care with the spelling as there other objects beginning with Win32_NTLog....
As
ever, my script will get you started, but it is worth understanding where you could change the values to suit your Windows network.
Instructions for Creating your VBScript to Check Administrator Logons
Pre-requisites. For this script to work, you need access to a Windows computer with a Security Log.
To reduce the chance of an authentication problem, I would first run this script at a Domain Controller. If that is not possible, run the script from a member server on an XP machine and edit
strComputer on line 15.
Check the strFolder and strFile values. Where do you wish the script to appear?
Copy and paste into notepad, or a good script editor.
Press OK when confronted by a message box, which says "Press OK and Wait 30 seconds (ish)"
Just open your text file from the folder displayed by Explorer!
' EventLogFSO.vbs ' Sample VBScript to write event log data to text file ' Author Guy Thomas http://computerperformance.co.uk/ ' Version 1.6 - November 2005 '
-----------------------------------------------------------' Option Explicit
Dim objFSO, objFolder, objFile, objWMI, objItem, objShell Dim strComputer, strFileName, strFileOpen, strFolder, strPath
Dim intEvent, intNumberID, intRecordNum, colLoggedEvents Dim intEventType, strLogType
' -------------------------------------------------------- ' Set the folder and file name strComputer = "."
strFileName = "\Event680.txt" strFolder = "e:\logs" strPath = strFolder & strFileName
' Set numbers intNumberID = 680 ' Event ID Number intEventType = 4 strLogType = "'Security'"
intRecordNum = 0
' ----------------------------------------------------- ' Section to create folder and hold file. ' Create the File System Object Set objFSO =
CreateObject("Scripting.FileSystemObject")
' Check that the strFolder folder exists If objFSO.FolderExists(strFolder) Then Set objFolder = objFSO.GetFolder(strFolder) Else Set objFolder =
objFSO.CreateFolder(strFolder) WScript.Echo "Just created " & strFolder End If
If objFSO.FileExists(strFolder & strFileName) Then Set objFolder = objFSO.GetFolder(strFolder) Else Set
objFile = objFSO.CreateTextFile(strFolder & strFileName) Wscript.Echo "Just created " & strFolder & strFileName End If ' -------------------------------------------------- ' Two tiny but vital
commands (Try script without) set objFile = nothing set objFolder = nothing
' ---------------------------------------------------- ' Write the information to the file Wscript.Echo " Press OK
and Wait 30 seconds (ish)" Set strFileOpen = objFso.CreateTextFile(strPath, True)
' ---------------------------------------------------------- ' WMI Core Section Set objWMI =
GetObject("winmgmts:" _ & "{impersonationLevel=impersonate}!\\" _ & strComputer & "\root\cimv2") Set colLoggedEvents = objWMI.ExecQuery _ ("Select * from Win32_NTLogEvent Where Logfile =" &
strLogType)
' ---------------------------------------------------------- ' Next section loops through ID properties
For Each objItem in colLoggedEvents If objItem.EventCode = intNumberID
Then If objItem.EventType = intEventType Then strFileOpen.WriteLine("Category: " & objItem.Category _ & " string " & objItem.CategoryString) strFileOpen.WriteLine("ComputerName: " &
objItem.ComputerName) strFileOpen.WriteLine("Logfile: " & objItem.Logfile _ & " source " & objItem.SourceName) strFileOpen.WriteLine("EventCode: " & objItem.EventCode)
strFileOpen.WriteLine("EventType: " & objItem.EventType) strFileOpen.WriteLine("Type: " & objItem.Type) strFileOpen.WriteLine("User: " & objItem.User) strFileOpen.WriteLine("Message: " &
objItem.Message) strFileOpen.WriteLine (" ") intRecordNum = intRecordNum +1 End If End If Next
' Confirms the script has completed and opens the file Set objShell =
CreateObject("WScript.Shell") objShell.run ("Explorer" &" " & strPath & "\" )
WScript.Quit
' End of Guy's FSO sample VBScript
VBScript Tutorial - Learning Points
1) Begin by checking the variables. Experiment not only with strComputer, but also with intNumberID. Double check Win32_ object
name.
2) Here is a tiny addition to join two output properties and then write them on the
same line. strFile.WriteLine("Category: " & objItem.Category _ & " string " & objItem.CategoryString) A tiny improvement to save space in the output file.
3) Another cosmetic VBScript effect is to name the file after the Event Log ID, strFileName = "\Event" & intNumberID & ".txt". Although such improvements are minor, each contributes to a
more professional script.
4) Although the VBScript example was
getting rather long, I still could not resist adding a command to open the folder when the script creates the output file. Set objShell = CreateObject("WScript.Shell")
objShell.run ("Explorer" &" " & strPath & "\" ).
5) I admit that I have ignored the FSO (File System Object) section, which writes the information to
the file. However, I do cover this important feature of VBScript in other ezines and pages on my website.
Remember that the operating system
knows everything. Thank Microsoft for providing a library of WMI commands with which to interrogate systems like the Event Logs. WMI scripting is tricky because there are so many elements.
Take the time to have a walk through of how you examine an Event Log property sheet. In particular, match the Event ID, Success or Failure and type of Log with variables in my script.
Their topics and material are ideal for getting you started with VBScript. The
videos are easy to follow and you can control the pace. Try their free demo material and then see if you want to buy the full package.
See more about VB Script Training CD.
*
Guy
Recommends: Orion's NPM - Network Performance Monitor
Orion's performance monitor is designed for detecting network outages.
A network-centric
view make it easy to see what's working, and what needs your attention.
This utility guides you through troubleshooting by indicating whether the
root cause is faulty equipment or resource overload.