Welcome to the Windows port of Logcheck, the famous UNIX log processing
tool.

As you probably know if you bothered to download and unpack this archive,
Logcheck helps spot problems and security violations in your logfiles
automatically and will send the results to you in e-mail. However, it can
only work with what it's given. I personally find the Windows Event Logs to
be verbose, yet un-informative. So when you get e-mailed messages with three
or 4 lines on arcane gibberish, remember that it's the same information as
you would see in the Event Log, except it's in a slightly different format,
and you are actually SEEING it! (Of course, you would have reviewed the
Event Logs anyway, right?) :-)

The beginning of each log entry contains the name of the Event Log, the date,
and the time, like: "DIR,7/20/2001 11:52:12".  this is followed by the event
details.  The three letter codes for the Event Logs are:
    APP    Application
    SEC    Security
    SYS    System
    DNS    DNS (Win2000 Server(?) only)
    DIR    Directory Service (Win2000 Server(?) only)
    RPL    File Replication (Win2000 Server(?) only)

It will help to look for those codes to isolate one event from the next,
since your mailer will probably wrap the lines.

Also, the MS API for the Event Logs will return the application log if the
Event Log being asked for does not exist. Once it returns the handle, there
isn't any way that DumpEvt can tell which log is being read. For example, if
you dump RPL on an NT box, or DNS on W2k Pro it dumps the APP log instead.
This causes duplicate entries in the capture file. The only work-around
right now is to edit wrapper.cmd and REM out the Event Logs that do not
exist on that machine.

While the actual logcheck.sh script could have been ported to the CMD.EXE
shell, I thought it was much more efficient and effective to make as few
changes to that as possible, and instead create a "wrapper" program to
translate "Windows" into "UNIX."

I gave the wrapper the highly imaginative and interesting name of
"wrapper.cmd." Note that it only runs under Windows NT and 2000 (and
probably XP though I have not tested that). In short, logcheck is pointless
without logs, which means the Event Logs. Since the Win9x series doesn't have
those... 

See the "Tools-Readme.txt" for details about what tools are needed.

Paths/Dirs

I struggled with the default directory location for a while. I *hate*
programs that put themselves in the %SYSTEMROOT% (e.g. c:\winnt) directory.
However, I wanted to be a little obscure, so I thought c:\etc was a little
too obvious. And I wanted to be reliable, so "c:\Program Files" or
"c:\Documents and Settings" were both too long, and had annoying spaces.
C:\Progra~1 and c:\Docume~1 are not 100% reliable. So %SYSTEMROOT%\etc it
is... Of course, you can change that if you want. 

    %SYSTEMROOT%\etc
    %SYSTEMROOT%\etc\lcwin	Keyword files
    %SYSTEMROOT%\etc\bin	Binaries
    %SYSTEMROOT%\etc\tmp	Secured Temp directory
    %SYSTEMROOT%\etc\bin	Documentation and help files

Note the word "secured" above.  YOU need to set proper permissions on those
directories so that the account under which logcheck runs as the proper
access, but "Everyone" else does not.  See the INSTALL-Windows.txt file for
more details.

At the heart of logcheck are two basic things, grep and mail. If they fail,
so will logcheck. While in the UNIX world you can assume the ability to send
mail from the command line, in the Windows world you can't. So make sure
Blat is working. Again, see the INSTALL-Windows.txt file for more details.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CREDITS

First, to Craig Rowland for writing the deceptively simple yet brilliant
original logcheck.

Second, to all the people who wrote or ported the tools I needed to get
logcheck to run under Windows, notably K. M. Syring, the guys at
Somarsoft, and Tim Charron.

Third, to G.P. and I.P. who sent me logs to test to help me tune the
keyword files, and answered various other questions.

I should also mention the guys at Bastille Linux, who's style I've copied
here a bit in the Setup program "interview."

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Finally, a few notes about other tools or resources that may be of interest,
if you've managed to read this far.

I've found the following book to be essential in other Windows scripting
projects, and it proved helpful in this project as well. For anyone who
thinks you couldn't possibly find enough material in the old DOS batch file
language to write a book about it -- that's what I thought when I saw it.
Check it out! While not nearly as powerful, flexible or easy to use (though
some would argue that last) as UNIX shells, Windows's CMD.EXE is actually a
lot more powerful than you think. Forget about Command.com though...

Windows NT Shell Scripting, by Tim Hill
New Riders Publishing, Paperback, Published April 1998, 377 pages, ISBN 1578700477
http://www.bookpool.com/.x/s7mz6avzii/ss/1?qs=windows+nt+shell+scripting


Other Methods of accessing the NT Event logs (not free):
	Win2K Server ResKit Perl scripts: EventLog.pl & EventQuery.pl
	NT (etc.) ResKit Elogdmp.exe or Dumpel.exe event log dumpers

Other Tools of interest (free):
	NTSysLog  An NT service to send NT Event Logs to SysLog server
		  http://www.sabernet.net/software/ntsyslog.html
	NTLast    A UNIX-like "last" command for NT Event Log (ntobjectives.com)
		http://www.foundstone.com/rdlabs/termsofuse.php?filename=NTLast30.zip

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Last Updated: Fri Jan 18 18:13:30 EST 2002
-- JP Vossen <jp@jpsdomain.org>
