I believe the reason is this: Since the main purpose for having that data there is for event log configuration, it only shows the configuration information.
To pull actual event log data, there's a VB script in the Samples directory tree. If you set that up as an extended object, then that would do the trick. You could try one of these paths:
1. Copy it out to the remote server. Have a remotely-execute extended object run "cscript ".
2. Use "scriptutil" to run it remotely. I'm not super-familiar with scriptutil, so I'm not sure if you can use it to copy and execute a script with prefixed words (i.e. cscript).
Option 1 worked fine. However, I want to avoid manually copying the vbs file to the remote server everytime, and the remote servers don't have access to the appserver to retrieve the file on their own, so I don't know how else to get the file from the appserver to the remote server.
I tried centrally executing this in the EO:
scriptutil -h ??HOST?? -s cscript /usr/nsh/eo/win_event_log_csv.vbs
As Jarrod expected, the result was:
Unable to find script "cscript" for host uswsap1019[...] "C:/tmp/_uswsap1019-16234-0-win_event_log_csv.vbs": The system cannot find the file specified.
Running this without the cscript generates the "C:/tmp/[...] cannot find the file specified" message as well, does that mean the script was never copied?
And how to get around cscript not working with scriptutil?
Give this a go. It is very early days, but it is a perl/tk based gui that uses nsh to get Windows Event logs.
Save the attached file somewhere. You need Perl 5.6 or 5.8 with the Tk module. This should work fine on Windows and UNIX platforms.
Add a custome command
Name: Event Log Viewer
Command: perl c:\xxx\adjuster.pl %H (for Windows)
Associate with Servers
Run on Windows
Select "Run the command once againsta all hosts" and "Execute w/o option to select additional"
It is early days, I eventually want it to emulate the appearance of the standard event log viewer (maybe make it even better!!).
adjuster.pl 2.3 K
I've updated the script in the previous note.
Just to be clear, this script isn't an extended object (like the posts from Sean in this thread), but a custom command.
The benefit over an extended object is that it allows browsing rather than waiting for the whole event log to be loaded.
The disadvantage is that browsing is all you can do! No audits or snapshots.
On the todo list:
Show progress bar for loading of data
Show data as it is loading
more closely emulate windows event viewer
Archive off event log to database
Message was edited by:
I'm trying to use this perl script - when i execute it from the command line and browse an event log i get the message:
nexec ifcapps29 cscript c:\windows\system32\eventquery.vbs -FO CSV /NH /V /L app
and nothing seems to load - the event logs are rather large...
also, if i i click on the servername in the TK window i get this message:
Showing host ifcapps29
Show event ifcapps29
Use of uninitialized value in concatenation (.) or string at adjuster.pl line 58
nexec ifcapps29 cscript c:\windows\system32\eventquery.vbs -FO CSV /NH /V /L |
Use of uninitialized value in concatenation (.) or string at adjuster.pl line 59
i've got the following perl setup:
Binary build 816 provided by ActiveState http://www.ActiveState.com
1. Tk 804.27.0.5 Tk - a Graphical User Interface Toolkit
Sorry about this guys. There were a couple of errors in the script. I forgot to use the right number of escaped "\" characters!! So, "
" gets escaped to "
" by perl, and "
" gets escaped to "\" by nexec!
I also forgot to clear the event log when selecting a different one, and I forgot to check for clicking on a node (rather than an event log).
This should be run as a custom command. (I haven't been able to make it work from nsh).
Setup a custom command something like this:
Name: Event Log
Command: perl "C:\xxx\adjuster.pl" %H
Associate with Servers
Operating System - Windows.
Run the command once against all hosts
and the command will execute without the option to select additional hosts.
It will take a while for event logs to appear. (Longer if you have long event logs).
If you want to limit the number of events shown (to improve performance), then just add "/R 1000" on line 62 between the /NH and the /V flags.
For help on eventquery.vbs, just run cscript c:\windows\system32\eventquery.vbs /? on a Windows machine.
This is the log output from a sample run:
Showing host win03-www2
Showing host win03-www
Showing host win03-db
Show event win03-www2\application
nexec win03-www2 cscript c:
eventquery.vbs -FO CSV /NH /V /L application |
Show event win03-www\security
nexec win03-www cscript c:
eventquery.vbs -FO CSV /NH /V /L security |
Show event win03-www
Select an eventlog for this node
On the demo drive it takes about 30 seconds to show an event log.
This is horribly slow on a real system - it's been waiting for maybe 3 min - but I've got some pretty big event logs. Has there been any submission to product managment about the ability to view/audit, etc natively from the product?
The perl thing and the vbs probably work ok for a demo, but for an actual deployment we'd need something more robust. I know I've heard from customers about wanting to do this, though there are alot of products out there that do event log aggregation and analysis...
Did you try /R 1000 to limit the event logs?
I added it (see attached), and it took 19 seconds to start (for 3 servers), and 7 seconds to read each set of event logs (using the demo drive).
You should get similar times on any system.
This is really just a proof of concept. It wouldn't be right as an extended object, as it should cope with any number of commands.
In an ideal world this would be written in C# or Java with access to the available servers using the same login credentials as used by Config Mgr. Unfortunately, I can't get that to work.
my 2 cents are that log collection and aggregation might be better served by products dedicated to this task. There are a lot of requirements and issues surrounding log collection from operating systems, applications and network devices. While the solution described here might solve a specific problem, most companies have larger initiatives around log collection that includes Windows platforms. I worked at one of the vendors that developed log collection and analysis solutions (Network Intelligence), so I am aware of all the regulations and requirements around this.
I'd agree w/ Hayim actually: I see 2 different areas here.
The 1st is configuration compliance - that would be the purpose of the event log objects in the CM - that the event logs are configured properly.
The 2nd is security log aggregation/analysis/storage. Unix already has a free solution for some of this in syslog, it's Windows that's left to 3rd party solutions.
The only thing I can see here, is that if we offered a way to give someone view event log access through ACLs, then we could include them in a complete 'production read only' role for an application team.
So we could give them access to look at the registry hive, the directories, the metabase, the services, and read the 'application' event log - all under the access control of BladeLogic, and thusly taking away the last need they would have for local access to the server. I certainly see a use case for it.