Event Log Parsing for the WSH Administrator
(Page 1 of 4 )
In the first two segments of this series we explored ways of analyzing and archiving event logs with WSH. In this article, I’m going to demonstrate specific applications of this that can benefit network administrators who are responsible for maintaining large numbers of machines.
This scripts we’ll be creating in this article will take a two-fold approach. The first is designed to be run from a server to consolidate event logs from several machines. The second is designed as a network logon script that can be deployed on each machine in the network.
The two-fold approach has two major benefits. The first script can be managed from a single location. It doesn’t require installation on every machine, which means it can be run at will as needed.
The second script is designed to be run from each machine. This gives us the advantage of creating a real time monitor that can be used for instant notification when specific conditions occur.
You can use these methods independently of one another or in conjunction to obtain the desired level of efficiency that you are seeking. I’ll discuss this further as I show you specific case scenarios.
You’re going to need the script that we ended with in the last article. We’re going to further modify it for our needs. Both of the scripts that will be introduced in this article will grow off of the examples you’ve already seen.
I’m not going to be showing you how to sort and manage the data that we retrieve from the event logs. I may write an article later for that purpose, but for now, my goal is simply to show you how to prepare the data.
I’m going to be making two assumptions throughout this article. I believe they represent the most common opinions of network administrators as a whole. You can, however, modify any of these to fit your own specific needs.
The first assumption is that all event log entries should be archived. For the sake of size and time you may wish to limit this to only certain types of events, but I believe that most administrators will agree that historical data is best preserved in its entirety.
The second assumption is that you do not need to know about every single event that takes place in a system—especially when you are managing large numbers of systems. Whenever monitoring or creating notifications, I will be limiting the range of data that we are watching.
Again, any of these options can be modified to fit your own specific needs and style.
One third and final thing to note is that I will be archiving all data in one central database. Since each event is labeled by a machine name, sorting data for specific machines is not impossible. You could easily create multiple databases for individual machines or groups of machines if you preferred.
Next: Modularizing the script >>
More Windows Scripting Articles
More By Nilpo/Developer Shed Staff Writer
/ 2 
