Thnx to Artur, I have succeded in collecting message tracking logs from Exchange 2010. However, although collected, the logs are not parsed (or normalized?) enough.
To be precise, almost all usefull information from message tracking logs, as log type (RECEIVE STORE), message subject, sender or receiver info, are showed in Packet tab where you can see original log message but cannot search for its parameters, for example: to search for all messages where sender or receiver is firstname.lastname@example.org.
By the way, I have noticed this also in logs comming from Microsoft Forefront TMG, and from Oracle DB
From what I see in the Policy Editor there is one ASP rule for MS_Exchange Events. If that is not parsing correctly there are a couple of ways to resolve this.
First you could make a copy of the current ASP rule and then edit the copy so the fields are parsed as needed. Make sure you disable the original ASP rule and enable your new one at the correct scope in the Editor for your Data Source.
Secondly, you could submitt a PER for an updated ASP rule at https://mcafee.acceptondemand.com/index.jsp
The Exchange Server (ASP) device source is a little bit curious. When you configure that data source and go to the policy editor you can see one ASP default rule (first on the picture):
But, when you switch from the ASP to the Data Source rules, you can see more rules for this device. It is not possible to see, how exactly that rules are configured, and it is not possible to edit them! I did a lot of tests with my colleagues, and we did not find ANY way to add WORKING custom parsing rule for the Exchange Server ASP data source. AND - all events are parsing by the rules from the Data Source tab.
So - is it ASP data source definition or not? How we can add a CUSTOM rules to this data source?
When I check on my system which has not had any Exchange Server Events I see only the ASP rule with no Data Source Rules. So the ones that you are seeing have been learned by the ASP rule. Some ASP rules, which have been written in a certain way, will generate those DS Rules. This makes the parsing of events and generating of alerts more efficient.
What you should be able to do is select one of those DS Rules and then go to Edit > Purge Autolearned Rules and Purge all auto learnined rules for this DS. That may have been the problem with testing your new ASP rule - those DS rules were getting triggered and not the new ASP rule.
I checked that more than two times, and I have to say, that for Exchange ASP data source type are available one ASP rule and a lot of Data Source rules. I confirmed it in a few ours testing environments and in the our customer's production environments... Of course from time to time ESM creates anotler (autolearned) rules, but in this case we have Data Source rules out of the box.
That rules can't be removed, because for them "purge autolearned rules" option is unavailable:
An again - below I show, that rules aren't autolearned, but just downloaded from the update server:
Chris - could you explain me how exactly the parsing mechanism work? Is it possible to create more than one ESM events from the one data source event, when event data fits to more than one rule? Which rule will be chosen first? We did some tests for the Exchange Message Tracking logs, and we can't to add our working ASP rule - always ESM choses the Data Source rules - so the ASP rules did not work.
Yes you are correct that those have been added by McAfee Rules. I had only looked at the Rules for Device Type 348 and had not assigned a DS as Exchange Server (ASP). Once it is assigned then those are also part of the 348 rules. Some ASP Rules also include DS Rules and that varies on the DS that you are using.
As you point out those DS Rules cannot be purged but can you try disabling those DS Rules and then the ASP Rule should be triggered.