Category: windows event log

Posted on

converting NetApp Filer to syslog – and MS API Changes…

One of the things that is done with EventReporter and MonitorWare Agent is forwarding NetApp Filer event logs via syslog. There are essentially two ways how this can be done: either via backup event log files (*.evt), which NetApp writes in a Windows compatible format or (a newer approach) via an Event Log API Emulation inside the NetApp box. If you’d like to know details, you can find them in our NetApp EventLog to Syslog forwarding paper.

Unfortunately, changes in recent Windows versions cause some trouble with the way the forwarding works. Unfortunately, Microsoft seems to have changed the on-disk format of backup event log files. That’s OK and something that usually can happen. What I find strange is that Microsoft does no longer supply code inside Windows (and its APIs!) to read downlevel event logs. So, for example, on Windows 2008 it is no longer possible to read a backup event log from an older release. This includes the NetApp .evt files, as they are written in the older Windows format.

I do not understand the Microsoft decision. It would not have been hard to preserve backward compatibility – a header flag inside the file plus very few code inside the o
operating system would have been sufficient. But without that, we see trouble that the NetApp .evt files can not be accessed by Windows Event Viewer and, consequently, not yet by our eventlog to syslog tools. Thankfully, though, we support all modes NetApp provides, and so the work-around is to use the NetApp Event Log API emulation, which will also get the necessary information out to syslog. But, again, I do not understand how Microsoft can break backward compatibility in thus an unnecessary way.

Anyhow, things are as they are ;) So far, we are also looking at ways to be able to process the NetApp backup event log files even under these new constraints. And as you know, we are already full of ideas. Of course, I also recommended to opening a support ticket with Microsoft – I am too eager to learn the official response to this situation (and -maybe- a solution)? I’ve been told we’ll open the ticket today, so let’s see what comes out of all that…

Posted on

Will Microsoft remove the Windows Software RAID?

These days, hardware rates are quite inexpensive. So everybody is moving towards them. However, all mainstream operating systems still support software RAIDs, maybe even for a good reason: an os-controlled software raid may be a bit better to optimize under some circumstances. Anyhow. Microsoft seems to move away from that feature set:

As you probably know, Adiscon provides premier Windows event log processing solutions. Some of our customers use the products for example to monitor if their RAIDs break. And some of them use software RAIDs. So we wrote a nice article on how to monitor RAID health using the Windows Event Log.

Since the days of Windows NT 3.1 (or was it 3.5), the Windows logged an error message if the RAID failed. Actually, I’d consider this a necessary functionality for any working RAID solution. Why? Well, if the RAID solution works, you will not notice that a disk has died. So if nobody tells you, you’ll continue to use the system as usual, not suspecting anything bad. So guess what – at some time the next disk fails and then (assuming the usual setup) you’ll be “notified” by the disk system, with those nice unnercoverable i/o errors. So without any health alerts, a RAID system is virtually useless.

We learned, that Windows Server 2008’s RAID system does no longer issue these alerts! (aka “is useless” ;)). So a long while ago, we reported this to Microsoft. The bug went through several stages of escalation. A few minutes ago, my co-worker got a call from the frontline Microsoft tech. He told him that, regrettably, Microsoft won’t fix this issue. According to his words, Micorosoft has confirmed this to be a bug, and the group responsible for ftdisk has confirmed that it should be fixed but someone more powerful up in the hierarchy has opted not to do that. Boom. The tech tried to persuade us to switch to a hardware RAID, but actually that was not the point of the support call ;)

What does that mean? To me, it looks like Microsoft is actually moving away from providing software RAID. How other can one explain that there is no interest in providing any error message at all if something goes wrong with the RAID. Given the wide availability of hardware RAIDs (which, btw, provide proper alerting), this step does not look illogical. But do they really want to leave Linux with being the only widely deployed mainstream operating system that provides software RAID? Or do they intend to keep it on the feature sheet, but provide a dysfunctional solution like in Windows Server 2008?

Let’s stay tuned and listen what the future brings…

Posted on

Low-End Windows Event Log Tool Released

Adiscon, my company, has just released EventConsolidator, an easy-to-use tool for Windows event log consolidation targeted to the small business market. Unlike our full-blown EventReporter and MonitorWare Agent products, this is a purely agentless solution to monitor the standard Windows Event Log files. Also, it does not (yet) store any events in a central repository but rather works on the native event logs of the Windows machines it monitors.

The tool comes with basic display and searching abilities and some preconfigured reports. This is Adiscon’s first move into that market segment. I am very interested to see which feedback we get from that tool. We are very open to all customer suggestions. I have to admit that I argued it may be better to do the essentials first and then look for what people really need rather than to build a complex one-size-fits all approach. So it will be interesting, at least for me, to see if that thought works out. Just for the records, EventConsolidator is commercial software, but a full featured free trial is available form the EventConsolidator site.

Posted on

Windows 2008 Event Log…

Did you know – Windows 2008 has a much changed event log format. There are new APIs and formats all over that operating system. The first incarnation of the new logging system was seen in Windows Vista, but, being a workstation OS, it did not receive much attention from the corporate world.

When Vista came out, we at Adiscon immediately introduced the new event log monitor V2 service in MonitorWare Agent and EventReporter. That service worked well, but not many customers ever used it (who really monitors the workstation event logs…).

With the rise of Windows 2008 Server, we saw a notable increase in interest. And we finally got questions! While we always supported all properties, some of the former event log monitor properties are not available under the Windows 2008 event system. A number of customers asked if we could map them. Makes an awful lot of sense, especially if you have log analysis scripts that expect those fields. So I went to development (no longer working on Windows myself these days) and asked what we could do. I thought it would be trivial. But it wasn’t. Some mappings seem to have really hard, plus we got the impression (from lack of discussion and coverage) that we are probably among the first to ever work in this area). But nothing can stop a good programmer ;)

So I was quite happy to learn today that we have finally manage to include a full emulation of pre-Windows 2008 event properties. The code currently is in beta, and is available both for MonitorWare Agent and EventReporter.

I am especially happy as the new emulation also makes it far easier for phpLogCon to work with Windows events in a consistent way. Not to mention that I like happy customers ;)