AND... I've downloaded and installed 2.7 but am getting the same results. Looking at read_win_el.c (line 57 this time) it looks to still be using OpenEventLog rather than EvtOpenLo.
Is my diagnosis of the problem correct? If so, are there any plans to migrate to the new Windows API? Regards, Nick On 22 November 2012 15:42, Nick Davies <[email protected]> wrote: > Or maybe I could just read the release notes <sigh> > http://www.ossec.net/?p=577 > > Regards, > > Nick > > > > On 22 November 2012 15:38, Nick Davies <[email protected]> wrote: > >> Talking to myself a little it looks like the problem could be due to >> read_win_el.c using OpenEventLog (line 56) which is the pre-Vista flavour. >> I'm guessing it's having problems coping with the new format log files >> hence failing with a %4 in the event log name and falling back to >> monitoring the application log (as per >> http://msdn.microsoft.com/en-gb/library/windows/desktop/aa363672%28v=vs.85%29.aspx >> ). >> >> There's a thread on problem (but with python) at >> http://mail.python.org/pipermail/python-win32/2012-May/012292.html which >> seems to suggest that EvtOpenLog would be needed ( >> http://msdn.microsoft.com/en-gb/library/windows/desktop/aa385447%28v=vs.85%29.aspx) >> to cope with the newer event logs. >> >> Are there any plans to add this to OSSEC? I would try myself but I'm a >> read-only 'C' coder. >> >> Regards, >> >> Nick >> >> >> >> On 22 November 2012 13:28, Nick Davies <[email protected] >> > wrote: >> >>> This appears to be a bit of a FAQ but I can't find anywhere that it's >>> been answered. >>> >>> I want to monitor additional Windows events logs, specifically the >>> Windows print operational log. >>> >>> I've added a new localfile directive: >>> >>> <localfile> >>> <location>Microsoft-Windows-PrintService Operational</location> >>> <log_format>eventlog</log_format> >>> </localfile> >>> >>> But don't seem to be getting anything in the archive log (logall being >>> enabled). >>> >>> I've tried a number of things in the <location> tag (restarting the >>> agent after each change), including (with results) >>> >>> *Microsoft-Windows-PrintSrvice Operational:* >>> The ossec agent log entry for this was "2012/11/22 13:09:17 >>> ossec-agent(1907): INFO: Non-standard event log set: >>> 'C:\windows\System32\Winevt\Logs\Microsoft-Windows-PrintSrvice >>> Operational'." but was followed with a later "2012/11/22 13:09:20 >>> ossec-agent(1951): INFO: Analyzing event log: >>> 'C:\windows\System32\Winevt\Logs\Microsoft-Windows-PrintSrvice >>> Operational'." >>> >>> *Microsoft-Windows-PrintService%4Operational* >>> This gave the agent log entry: "2012/11/22 13:23:58 ossec-agent(1906): >>> ERROR: Error parsing file: 'Microsoft-Windows-PrintService%4Operational'." >>> >>> * >>> %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-PrintService%4Operational >>> * >>> This gave the agent log entry: "2012/11/22 13:08:13 ossec-agent(1906): >>> ERROR: Error parsing file: >>> 'C:\windows\System32\Winevt\Logs\Microsoft-Windows-PrintService%4Operational'." >>> >>> *%SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-PrintService >>> Operational* >>> This gave the agent log entry: "2012/11/22 13:17:59 ossec-agent(1907): >>> INFO: Non-standard event log set: >>> 'C:\windows\System32\Winevt\Logs\Microsoft-Windows-PrintService >>> Operational'." "2012/11/22 13:18:02 ossec-agent(1951): INFO: Analyzing >>> event log: 'C:\windows\System32\Winevt\Logs\Microsoft-Windows-PrintService >>> Operational'." >>> >>> In all cases no archive log entries were seen that matched up with >>> entries in the corresponding Windows log (as seen by event view). I seem >>> to be lacking the appropriate incantations to get this working. Has anyone >>> had any joy with this sort of thing? >>> >>> Regards, >>> >>> Nick >>> >> >> >
