Create a regular Windows event log report
The need for monitoring the Windows event log is undeniable. Articles on this topic regularly appear, including on Habré. However, for some reason all the examples come down to monitoring a predefined EventID. In my WinLogCheck utility, I chose another way - to get a report on EventLog, eliminating events that regularly appear and are not of interest to me.
As it turned out, this is not a unique option; the Linux utility, logcheck , is based on the same approach . But it is quite possible that my decision, nevertheless, appeared a little earlier.
In this article I will try to do without technical details. A little bit about the history of creation - in my opinion, this will make it possible to understand why and in what conditions this utility appeared and where it is better to use it somewhere. The following is a brief description of the operation algorithm and something similar to the instructions for use.
This solution allows me to currently control more than a dozen Windows Server and has been helping me with my work since 1998. The first version was written in ActiveState Perl to monitor three servers on Windows NT 4. For Windows Server 2003, a shell for Logparser was written in JScript. But with the release of Windows Server 2008, I had to start from scratch. There was an attempt to write in Powershell, but since sometimes I take part in the development of programs and know a little C #, this option turned out to be convenient for me.
The very first version was designed to work in a domain - the utility was launched on one of the servers and a report was generated on all servers in the domain. However, already in Windows Server 2003, a request to the event log over the network began to be executed for too long (did not understand the reasons), and servers appeared outside the main domain of the company in which I work. Therefore, it is simply impossible to use any ready-made centralized solution in some cases.
When a few Linux servers appeared in my “submission” I learned about the existence of an analogue of my utility, logcheck. For those who are not in the know, the utility is mentioned and recommended in many Linux and FreeBSD security materials, for example, in the Debian Security Guide. After that, it was decided to make their utility more convenient to use and publish under the name WinLogCheck (originally it was called UnknownEvents).
As a result, the utility became even more similar to logcheck - I have it running at 9:00 on each server and after 5-10 minutes in my inbox there are more than a dozen messages with reports. Usually a couple of minutes is enough for me to see everything.
Several times I tried to find a ready-made monitoring tool, but I never met anything convenient, simple and practical. Perhaps it's all a matter of habit. However, if you do not have a very large number of servers - try it, maybe you will like my version.
The main mode of operation:
Despite the fact that .NET has its own methods for obtaining a list of events, I use WMI (more details WMI Tasks: Event Logs ). It’s easier to work with the message test. The only negative is the delay in executing queries with a large number of log entries. For example, on one of the domain controllers creating a report takes 5-6 minutes.
At the beginning of the working day for each server I get something like this report (this is a report from a really working Windows Server 2008 R2 with Hyper-V):
Everything is in order, a one-time error in the DNS-Client does not require special attention. Pay attention to the Subject messages - most often the letters do not even need to be opened: usually the subject ends with the phrase “errors = 0, warnings = 0, other = 0”.
The utility is launched from the command line with administrator rights.
Mandatory parameter - operating mode: EXCLUDE or INCLUDE. Starting in the main EXCLUDE mode:
Two optional parameters are provided for the INCLUDE mode (for myself I call it special reporting mode):
-l- to indicate the log by which to get the report
-f - the name of the filter in the file “\ path \ to \ winlogcheck \ include \.conf
For example, for a separate report on successful connections to the RAS server on this server, I have the file “\ path \ to \ winlogcheck \ include \ system.conf” with the following text (about the file format with the filter - below):
It also
starts once a day: Naturally, the same filter exists for EXCUDE mode - so that these entries are not included in the general server report. One of the reports:
In EXCLUDE mode, I use the optional parameters for testing only.
Parameters are stored in the winlogcheck.ini configuration file. The file is small, so I give it completely with additional comments:
NLog is used in the development of our company, so I did not begin to reinvent the wheel. The configuration file for NLog included in the package is configured to output the execution log to the console and to the file “\ path \ to \ winlogcheck \ logs \ winlogcheck.log” with rotation (a new file every day, the storage period is 10 days).
We pass to the most interesting. Typical Event Viewer screen on a server with IIS installed:
Probably everyone knows the events:
Everything is clear with them - we do not need them in the report.
Filters are recorded using SQL syntax, the names of the fields in the event log are different from what we see on the screen. To compile a filter, we can use:
And what we see in the description of the event is in the Message field.
Thus, in order to exclude the above events from the report, it is necessary to create the file “\ path \ to \ winlogcheck \ exclude \ system.conf” with the text:
Comments on the file format with filters
The main filters that I use in my work are included in the archive with the utility.
A special relation is only to the security log - very often there are a lot of events in it, therefore the default filter is applied: only errors get into the report.
Very often, the issue of monitoring Active Directory is raised. My solution can be used to solve this problem. However, I have not been managing large domains for a long time, so I did not come up with fictitious examples for monitoring AD events.
This solution does not claim to be universal, but, in my opinion, it may well come in handy on any network with a small number of servers running Windows.
As it turned out, this is not a unique option; the Linux utility, logcheck , is based on the same approach . But it is quite possible that my decision, nevertheless, appeared a little earlier.
In this article I will try to do without technical details. A little bit about the history of creation - in my opinion, this will make it possible to understand why and in what conditions this utility appeared and where it is better to use it somewhere. The following is a brief description of the operation algorithm and something similar to the instructions for use.
A Brief History and Who Can Use WinLogCheck
This solution allows me to currently control more than a dozen Windows Server and has been helping me with my work since 1998. The first version was written in ActiveState Perl to monitor three servers on Windows NT 4. For Windows Server 2003, a shell for Logparser was written in JScript. But with the release of Windows Server 2008, I had to start from scratch. There was an attempt to write in Powershell, but since sometimes I take part in the development of programs and know a little C #, this option turned out to be convenient for me.
The very first version was designed to work in a domain - the utility was launched on one of the servers and a report was generated on all servers in the domain. However, already in Windows Server 2003, a request to the event log over the network began to be executed for too long (did not understand the reasons), and servers appeared outside the main domain of the company in which I work. Therefore, it is simply impossible to use any ready-made centralized solution in some cases.
When a few Linux servers appeared in my “submission” I learned about the existence of an analogue of my utility, logcheck. For those who are not in the know, the utility is mentioned and recommended in many Linux and FreeBSD security materials, for example, in the Debian Security Guide. After that, it was decided to make their utility more convenient to use and publish under the name WinLogCheck (originally it was called UnknownEvents).
As a result, the utility became even more similar to logcheck - I have it running at 9:00 on each server and after 5-10 minutes in my inbox there are more than a dozen messages with reports. Usually a couple of minutes is enough for me to see everything.
Several times I tried to find a ready-made monitoring tool, but I never met anything convenient, simple and practical. Perhaps it's all a matter of habit. However, if you do not have a very large number of servers - try it, maybe you will like my version.
How Winlogcheck Works
The main mode of operation:
- Get a list of registered event logs. For regular Windows Server 2008 - 7, for a server with Active Directory - 10.
- For each event log, a request is generated - get a list of events for the last day (approximately), excluding events specified in the exception file “\ path \ to \ winlogcheck \ exclude \
.conf - From the list received, a report is generated in HTML, which is written to a temporary file (in case the letter with the report does not reach).
- The report is sent by mail.
Despite the fact that .NET has its own methods for obtaining a list of events, I use WMI (more details WMI Tasks: Event Logs ). It’s easier to work with the message test. The only negative is the delay in executing queries with a large number of log entries. For example, on one of the domain controllers creating a report takes 5-6 minutes.
At the beginning of the working day for each server I get something like this report (this is a report from a really working Windows Server 2008 R2 with Hyper-V):
Everything is in order, a one-time error in the DNS-Client does not require special attention. Pay attention to the Subject messages - most often the letters do not even need to be opened: usually the subject ends with the phrase “errors = 0, warnings = 0, other = 0”.
How to use WinLogCheck
Command line options
The utility is launched from the command line with administrator rights.
Mandatory parameter - operating mode: EXCLUDE or INCLUDE. Starting in the main EXCLUDE mode:
winlogcheck -m excludeTwo optional parameters are provided for the INCLUDE mode (for myself I call it special reporting mode):
-l
-f - the name of the filter in the file “\ path \ to \ winlogcheck \ include \
For example, for a separate report on successful connections to the RAS server on this server, I have the file “\ path \ to \ winlogcheck \ include \ system.conf” with the following text (about the file format with the filter - below):
[General]
RASconnects : SourceName = 'RemoteAccess' AND EventCode = 20272
It also
winlogcheck -m include -l system -f RASconnectsstarts once a day: Naturally, the same filter exists for EXCUDE mode - so that these entries are not included in the general server report. One of the reports:
In EXCLUDE mode, I use the optional parameters for testing only.
Program parameters
Parameters are stored in the winlogcheck.ini configuration file. The file is small, so I give it completely with additional comments:
[General]
## Глубина запроса (в часах).
## По умолчанию: за 24 часа (за последние сутки)
##
#TimePeriod = 24
## Каталог для записи отчетов
## По умолчанию: 'path\to\winlogcheck\reports\'
## Если вы не хотите получать отчеты по почте, можете записывать
## их в каталог, доступный на внутреннем веб-сервере.
## Когда-то я использовал такой вариант.
##
#ReportPath = c:\inetpub\wwwroot\winlogcheckreports
## CSS оформление для отчета.
## В одну строку!
##
ReportCSS = h1 {margin:0;font-weight:400} .servername, .subhead {font-weight:700} table {width:100%;} td {padding:0.25em} th {border:1px 0} tr:nth-child(odd) td {padding-bottom:1.5em, border-bottom:1px} tr:nth-child(even) {background-color:rgb(248,248,248)} caption {font-size:120%;text-align:left;padding:10px;background:rgb(216,216,216)} .error, .failure {background:rgb(255,127,127)} .warning {background:rgb(255,233,127)}
## Настройка почты
## Если закомментировано - отчеты не посылаются.
## Я использую свой почтовый сервер, поэтому
## аутентификация не поддерживается.
##
#[Mail]
#SMTP_Server = localhost
#Mail_From = Winlogcheck SERVERNAME
#Mail_To = Administrator SERVERNAME Monitoring the utility itself
NLog is used in the development of our company, so I did not begin to reinvent the wheel. The configuration file for NLog included in the package is configured to output the execution log to the console and to the file “\ path \ to \ winlogcheck \ logs \ winlogcheck.log” with rotation (a new file every day, the storage period is 10 days).
Filter settings
We pass to the most interesting. Typical Event Viewer screen on a server with IIS installed:
Probably everyone knows the events:
- Winlogon: ID 7001 or 7002 - User Logon / Logoff Notification for Customer Experience Improvement Program
- “Service Control Manager”: ID 7036 or 7040 with messages: “The WinHTTP Web Proxy Auto-Discovery Service service entered the running / stopped state” or “The start type of the WinHTTP Web Proxy Auto-Discovery service was changed from ... to ... „
Everything is clear with them - we do not need them in the report.
Filters are recorded using SQL syntax, the names of the fields in the event log are different from what we see on the screen. To compile a filter, we can use:
- The name of the event log. In this case, “System”, then we write the filter into the file “\ path \ to \ winlogcheck \ exclude \ system.conf”.
- Level - EventType (integer). In the journal itself is determined by the numbers:
- 1 - Error
- 2 - Warning
- 3 - Information
- 4 - Success
- 5 - failure
- Event ID - Eventcode (integer)
- Category - CategoryString (string)
- Source - SourceName (string)
And what we see in the description of the event is in the Message field.
Thus, in order to exclude the above events from the report, it is necessary to create the file “\ path \ to \ winlogcheck \ exclude \ system.conf” with the text:
[General]
UserNotify : SourceName = 'Microsoft-Windows-Winlogon' AND ( EventCode = 7001 OR EventCode = 7002 )
WinHTTP : SourceName = 'Service Control Manager' AND (EventCode = 7036 OR EventCode = 7040) AND Message LIKE '%WinHTTP%'
Comments on the file format with filters
- Initially, filter files used data types built into the language, for example, in the JScript version, the Dictonary object. Then I tried JSON. But in all cases it is easy to make a mistake, so the ini-file format was chosen.
- The filter name is required, but is currently used only in INCLUDE mode when building special reports.
- A line of conditions - should not cause questions.
- As you may have noticed, all examples are for the English version of Windows Server. Nevertheless, everything works fine on the Russian version. This requires that the filter files be in UTF-8. The value of the SourceName and CategoryString fields is translated into the Event Viewer itself, so in requests you must use English analogues, but the message text is in Russian. Perhaps in the next update of the program I will include an example for the Russian version of Windows Server.
The main filters that I use in my work are included in the archive with the utility.
A special relation is only to the security log - very often there are a lot of events in it, therefore the default filter is applied: only errors get into the report.
Recent comments
- On Codeplex, an archive with the program and source codes for the program are published under the LGPL license (not particularly understood). Since I am not a professional programmer, I do not boast of code.
- The utility was written specifically for WIndows Server 2008, but it also works on the only available Windows Server 2003. I have not tested it on the new version of WIndows Server 2012, but there should be no problems. It should also work on Windows XP / Vista / 7/8.
- Description and brief instructions for Codeplex were prepared using Google Translate. The finished translation was checked by knowledgeable ones and found to be similar to real English. :-). If anyone has experience translating technical documentation, I will be glad to hear comments and suggestions.
Very often, the issue of monitoring Active Directory is raised. My solution can be used to solve this problem. However, I have not been managing large domains for a long time, so I did not come up with fictitious examples for monitoring AD events.
This solution does not claim to be universal, but, in my opinion, it may well come in handy on any network with a small number of servers running Windows.