This tutorial tells how to integrate data from Windows event log into our rsyslog configuration. We will do this integration via the UDP syslog protocol so that we finally can show this in a real case. No advanced topics are covered. We use CentOS 7 and Windows Server 2012 (because it still is in more widespread use). This is part of a rsyslog tutorial series.
Scope
We will introduce Windows Machine W into our configuration and make it forward its Event Log messages via UDP to LC. With the setup done in our last tutorial, LC will then relay the messages to syslog server LR. The choice if UDP is arbitrary. The intent is to finally have a system sending via UDP so that we can show how the configuration works. For practical deployments, TCP is probably a better option.
Note: you do not necessarily need to have followed the previous tutorial. Basically you just need to have a syslog server up and running to which we can send messages.
To configure the scenario, we only need to touch W. The rest of our tutorial scenario will remain as-is because it already provides the necessary functionality. When finished, our base lab scenario will be in the following configuration:
Note that we still do not configure any system to actually send data to LC. This will be done the next tutorial. Note that if you did not complete the last tutorial, it may be wise to have a look at it. We will work with the configuration it generated.
Prerequisites
You need to
- know basic use and administration of Windows systems
- have a working syslog server accepting messages via UDP (in the tutorial series this role is done by “LC”)
Installation
Rsyslog Windows Agent must be downloaded from the rsyslog site. It does not come pre-installed on Windows. The download page lists various versions. Pick the most current one (as of this writing: 6.0). Older versions are primarily provided for people who need a specific older version for a reason.
Note: in order to download the setup files in Windows Server hardened configuration, you need to add www.rsyslog.com to the trusted web zone.
You can download the agent software first or run it directly while downloading. In any case, a standard Windows installer will start. Accept the default and let the installation carry on. Note: depending on the components on your Windows machine, the installation make take some time and may even require a reboot. The latter is the case if parts of the .NET runtime need to be installed or updated.
Configuration
After installation, the configuration needs to be applied. The agent is configured via a Windows configuration program. Experts may also use a text-based configuration file format, but this is outside the scope of the tutorial.
Our use case of forwarding all Event Log messages to a syslog server is very common. As such, a default configuration for it already exists. We just need to make some adjustments to it.
Event Log Monitor
To apply the configuration changes, we start the program “rsyslog Windows Agent Configuration Client” and go to the predefined service.
The configuration already contains a so-called “Event Log Monitor V2” service. This is the service which reads the event log, formats its content in syslog-compatible format and hands it over to a rule set for processing. Reminder: although terminology and concepts between rsyslog Windows agent and rsyslog on Linux are similar, both have different code bases and slightly different methods to perform tasks.
If you like, you can also explore the additional tabs, most importantly “Event Channels”. The latter contains in-depth definitions of which exact event log channels to forward – and how to do that. As the defaults are sufficient for our simple use case, we do not modify anything there.
Forwarding to LC
To forward the messages to LC, we need a rule inside a rule set (just as on Linux). As such, we expand the default rule set and its rule. We select the “Rsyslog” action and can edit the defaults.
Note that the default protocol is TCP, because it is the best choice for most environments. However, we want to use UDP for our lab, so we need to change that setting. Also note that we need to change the target syslog server address. Place to IP address or hostname of LC into that field. We do not need to change the port number, because we use the same default. If you do not follow the tutorials in sequence, be sure to place the correct port your syslog server is using into the respective dialog.
Note that we do not use most of the customization options. You can explore them via the Windows Agent documentation. You usually need to make adjustments depending on your intended enterprise configuration. For clarity, we have limited ourselves to minimal changes.
Checking that everything works
Save your configuration. Do not forget to start (or restart) the Windows Agent when you have applied configuration changes. Like rsyslog on Linux its Windows counterpart also needs a restart to activate configuration changes. It also supports centralized auto-configuration management, but this is an advanced topic we will not cover in the tutorials.
After the Windows Agent has been restarted, it will quickly send messages to LC, which in turn forwards them to LR, which in turn writes them to its local messages file. Note that LC will not record the messages itself because we prevented this in the previous tutorial. If you check both messages files, you should see this:
If there is any problem, you can simply restart to Rsyslog Windows Agent to generate a new Windows event. A more advanced debugging technique is to reset to so-called “Last Record” to a lower value (or zero). This setting controls which event of the respective channel has been transmitted last. If you re-set it, Windows Agent will re-process all events from the record number you set it to. You can press the “Reload All LastRecords” buttons to obtain current values.
Important: if you modify “Last Record”, be sure to save the configuration!
This concludes the tutorial. If you have time left, I suggest to play a little bit with the several settings of Windows Agent. You may find it especially interesting to try the various format options given on the main Event Log monitor configuration dialog. Keep on your mind that Windows Agent is highly customizable and all canned formats can be overridden by formats that your enterprise setup requires. The agent can also pre-filter events. This is often used to drop “noise events” right at the source.
Result
We are now sending event log entries from Windows server W to LC, and make LC forward them to LR, which currently is the final destination. LR will write these entries to its usual log files. The Rsyslog Windows Agent on machine W is configured almost in default configuration, we just changed the protocol to UDP and adjusted the target server (LC).
Note that we use UDP not because it offers advantages here: we simply use it so that we have a system sending UDP in our lab scenario. Most often, this role is played by some (low-end) routers which do not offer any other choice.
In order to achieve this setup, we installed Windows Agent and adjusted its configuration. We did not need to change anything on the Linux systems as their setup was already done in the last tutorial – and is now actually being used for the first time in our tutorial series.
Additional Info
As a functional enhancement for Rsyslog Windows Agent, you can also use MonitorWare Agent or EventReporter.