ACS (Audit Collection Services) in SCOM uses a WMI filter to reject certain events from being collected and stored in the Audit database.
This filter supports about 4800 characters, so the filters can get very large and very advanced. It is important to test these before implementing to ensure you are getting a valid filter.
ACS uses WQL queries. https://msdn.microsoft.com/en-us/library/aa394606(v=vs.85).aspx
I recently had a customer trying to exclude a specific EventId from being collected, but ONLY when a specific parameter was present.
In the ACS event queue, the event parameters are mapped to specific “String” ID’s, which don’t match up to the parameter header or number….. so we must match on the specific StringID value. The easies way to get this is to collect the event, and then search for it in the ACD DB. In this case, my customer wanted to exclude event ID 4648, but only when String06 = “C:\Windows\System32\svchost.exe”
Seems easy enough?
Here is the first ACS filter we used: SELECT * FROM AdtsEvent WHERE NOT (EventId=4648 AND String06='C:\Windows\System32\svchost.exe')
However, it didn’t work. We still collected the 4648 event, even with this match in String06.
One thing to always do before implementing a change in your ACS filter – is to TEST the syntax using WBEMTEST:
Open WBEMTEST on the ACS Collector.
Connect to root\default
Select “Notification Query” button.
Paste in your exact query you want to use.
I reached out to Jimmy Harper on this, as he is an ACS guru.
My rookie mistake. I forgot that the “Backslash” is not allowed in a WMI query. Backslash is a special character used to escape other special characters. See: https://msdn.microsoft.com/en-us/library/aa394054(v=vs.85).aspx
So in this case – if we want to use a backslash character, we need to escape it with another backslash. Here is my new query:
SELECT * FROM AdtsEvent WHERE NOT (EventId=4648 AND String06='C:\\Windows\\System32\\svchost.exe')
I can test this in wbemtest and it works just fine.