The is a complete set of applications, which all work together to fullfill the whole mission in a secure manner. It consist mainly of:



The serviceapplication is the most complicated part of this set of applications. Globally, it is responsible to collect the events from a configured number of machines, servers or even workstations. Internally, it consist of - technically spoken - a lot of classes programmed in the C# language from the , the relatively new programming environment of Microsoft.

Application internals

The main classes are:

The application implements a windows nt service and is externally represented by the file ECS.ServiceApplication.exe. This class is responsible to manage the service and initialize the CollectorService, which is responsible to read the configuration-file and determine, which machines should be monitored. The CollectorService initializes one EventCollector for each machine.

Working priciple

The CollectorService is invoked and initializes - and possibly creates - a queue, I'll come back to this shortly. It instanciates a EventCollector and creates a individual query for the destination-machine. The EventCollector in turn, tries to connect to the machine which's should be monitored. It checks for the availablility and the access rights it has and advices the remote to watch for events in an asnchronous way. The EventCollector then waits for events.

For each event received by , it fires this message to the CollectorService, which itself stores this message into a queue. The is used because of it's speed and high availability. Regard, that there are possibly several hundred EventCollector's, which deliver events and the database - the final destination of the messages - could go offline for maintenance.

The CollectorService has an interface, which enables access to internal data by remote access, in the called remoting. This is currently used by the EventlogCollectorServices web-application to provide a status-view.

The rest of the job is done by the DBWriter.

The crux of the status

Tracking state is probably always a not to simple thing. This is also true for running queries. You'll not be notfied, if is temporarely stopped on the remote machine and/or the wire will be broken for a period of time. The EventCollector provides some status-tracking, which's description provide some help to interpret the status-display in the web-application the right way.

The EventCollector uses an internal timer, which fires at a specified interval. Additionally, the last received message is remembered also. If the next timer event is received, it is checked, if there was a message since the previous event. If there was none, the internal state is set to <suspect>. Each new message resets this state back to <online>. If a new timer-event is received, the status is checked again. If the status is already set to <suspect>, the status is advanced to <waitconfirm>. Importent:This moment the EventCollector writes also a message to the remote machines eventlog!! Because it has adviced the remote machine to deliver new messages from the eventlog, it must get it back! If the next timer-event fires, the status will be set to <unreachable> and the collector will be stopped and restarted. But if the send message was received, the status was reset to <running>

The behavior is by design, just to ensure, each query remains running. As a small side-effect, you'll see the EventCollector's EventCollectorServiceNotificationMessage0 in the remote machines eventlog. This message may be suppressed and does usually not go to the event-database.


This application starts and looks for messages in the configured queue. It stores the existing messages directly to a . After this, it registers with to receive each new message automatically.

Each received new message in held in memory, although this gives some risks. If a short period of time has gone, all collected messages a stored into the in one bunch.


This web-application part is the newest part and a more detailed description can currently not be given here, but a few infos.

The web-application is implemented by ASP.NET. If the user is already ntlm-authorized, it starts checking if the user has the right browser and only is currently supported [the minimal version is 5.5]. It checks for scripting and cookies enabled also, these are importent features used by this application. is a necessity, because it is the only browser, which implements html-components, which are re-usable html-snippets and even active elements. These are implemented in a mixture from html text and client-side scipts. These components are stored in files with extension .htc and these components are used at many places inside this application.

The application consist mainly of - like you have possibly already seen - three components:

You'll find more details about this three components inside this documentation, start looking at The Application Parts.

Application maintenance hints

The application is currently completely in beta-state and there are really some bugs. Feedback about each issue is really wanted, see also the Feedback-page.

The application was build with maintenance in mind. But this is mostly the database, which may go offline for some time. But this is naturally not true for the service, which must be online all the time. The DBWriter may go offline also, the events are not lost, but - naturally - not stored into the database and so not seen in the EventlogViewer.