SCOM 2012 – Using ACS to Capture Events From ‘Other’ Event Logs

 

image

Audit Collection Services (ACS) out of the box is designed and configured to collect events from the Security log.  A common request from customers is to be able to collect events from other logs using ACS.  There are blog posts out there that show how to use ACS to collect from other more standard logs.  This is achieved by modifying the EventSchema.xml file on the collector.  The next time a forwarder connects, it will pull the new schema and then start submitting the events that match the definition in that schema.  With the addition of a single line into the xml file, the forwarders will start sending you events from any of the traditional logs (e.g. the Application log).  If you want those events formatted and mapped correctly so that you can report on them, it does require a little more work than a single line, but it is very doable.  Unfortunately, this does not work for events under the ‘Forwarded Events’ or events buried in logs deeper under the ‘Applications and Services Logs’ header.

Best guess: The logs that were created using the legacy APIs are able to be seen by ACS and collected from.  The logs created using the newer API are not.

Legacy API: http://msdn.microsoft.com/en-us/library/windows/desktop/aa363652(v=vs.85).aspx

Current API: http://msdn.microsoft.com/en-us/library/windows/desktop/aa385780(v=vs.85).aspx

This would require more testing to validate.  Ultimately, it is a moot point for the purposes of this post.  The goal is to be able to collect the events from any of these other logs.

Event Forwarding: http://technet.microsoft.com/en-us/library/cc748890.aspx

Following these steps, a machine can be configured (manually or through GPOs) to both send and receive events.  Post that, a subscription can be configured to ship events from any log to one of the logs that ACS can see.  Once these steps are complete, the forwarder can start collecting these events and submitting them to the collector.

Leave a Reply