If I understood what you are seeing correctly, then you do eventually get these events, yes?
If that is the case, then I would suggest that it's either a severity level that doesn't match your policy setting for event forwarding, and/or that the events are eventually being uploaded dring the normal ASCI. In either of those cases, it might be worth changing the Agent policy for those mail servers to see which of the settings has an impact.
The events do indeed eventually make it to ePO during the next ASCI communication. The ASCI is set quite high in the organisation's agent policy as the understanding is that all alerts should be handled by the "priority event forwarding". Doing some testing with modifying the priority event forwarding settings on the server I have come across the following information (which could be completely unrelated).
When configuring the priority event forwarding in the Agent policy it changes the "AgPlcyEventTriggerThreshold" in the Agent.ini.
0 = Informational
1 = Warning
2 = Minor
3 = Major
4 = Critical
Numbers appear to correspond to Severity level within the events generated by VSE. A test virus alert (eg. EventID 1024) will come up with a Severity 4 (Critical) and therefore is uploaded the next minute due to the policy assigned.
When generating alerts on MSMS (eg. EventID 8000), the evt has the Severity equal to 0. My assumption is that the Agent.ini would see this as an informational Event; while ePO reads this type of event and is able to interpret that this product deems its severity levels to be:
0 = Emergency
1 = Alert
2 = Critical
3 = Error
4 = Warning
5 = Notice
Of course i may be reading too much into it. I have a tendancy to want to understand the workings of things to enable me to resolve issues such as this.
While I could either decrease the ASCI or modify the priority forwarding to threshold of 0; neither solution is viable long term as I don't want the complexity of multiple Agent policies.
The re-defining of Event ID is done by several products, but apart from the case you've mentioned - I don't recall seeing two different products wanting to overwrite an event with their own definition.
8000 does seem to be used in a few products in different ways - but I think all of them share the same common code (eg McAfee Security for Exchange, McAfee Security for Domino, McAfee for Sharepoint etc etc). Definately something that McAfee needs to think about and resolve.
I think your [last] analysis of Event ID severities is right on the mark. I'm still a bit confused where the severity is created (I believe the point product creates it), but the EPO Agent is the one responsible for working out which ones to send back to EPO and which ones are "send immediately" etc. This decision flows down from Event Filtering in EPO, and also the settings under the Agent for immediate forwarding.
Keep harassing McAfee with your cases, because you're on the right track. I presume there will be hotfixes created for MSDW and MSMS that will resolve your issue (eventuallly ... or perhaps it will be deferred to a later version)
The writing of the definition i believe is done by ePO.
Initially ePO (4.5 P3) used to describe EventID 8000 as "Infected item found(Critical)"
Once the MSDW extensions were checked in, EventID 8000's description had changed to "McAfee Security for Lotus Domino, v7.5 Virus detected (Info)"
A called was logged to McAfee as the assumption was that if the Event described itself as being "Info", this may be causing the issue with events not being uploaded as part of the priority forwarding. A new MSDW extension was provided which reclassified EventID 8000 to "McAfee Security for Lotus Domino, v7.5 Virus detected (High)"
I am guessing that EventID 8000 was originally designed to be a generic Critical alert, so it shouldn't be an issue with having 2 different products using the same ID normally; but now Sharepoint has to deal with being called Lotus Domino (a compliment in my books!) in my organisation. Maybe the assumption was made that anyone running Lotus Domino would naturally run Quickr as a collaboration tool so they shouldn't have to worry about the conflicts? In any case, i wonder what other products will want to use that ID further down the track.
After doing a tiny bit of testing today, i have found that modifying the severity level manually in the evt file doesn't allow the file to be uploaded by the Agent any quicker. So maybe that assumption is incorrect. Still find it weird the reverse severity order between products though.
I'm wondering now what would happen if i removed the MSDW extensions. It may be interesting to see how they behave if i can get the 8000 event back to being it's original description / purpose. Just a little hesitant to play too much as i have almost 100 Domino servers running MSDW and really don't want to break them too much.
The answer to what happens when you remove the MSDW extension is that you lose eventID 8000 altogether.
I currently have a call logged to see whether i can get the process to re-instate this eventID back to its original state without having to reinstall my dev server (or create another one). Hopefully I will be able to get that so i can continue with testing MSMS and see whether it behaves as it should without extension interference.
One interesting thing to note is that when you remove the MSDW 7.5 extension (and lose eventID 8000), installing the MSMS 2.5 extensions will not re-instate the event. At least it doesn't appear to have the same issue even though it uses that event.
So what happened in the end with this? Did a hotfix get created?
The root cause of the issue appears to be the lack of registry keys which set the priority for the event to be uploaded. HKEY_LOCAL_MACHINE\SOFTWARE\Network Associates\TVD\Shared Components\Events\<language_code>\<eventID>
I created my own registry key for event 8000 on the Sharepoint servers based on the MSDW one which I received from support and have been using this successfully in my environment (due to business timeframes etc).
A hotfix was recently provided for this for Sharepoint. Problem for me now is that it has raised more questions with regards to the sharing of EventID numbers between MSMS and MSDW (as it appears now to be more then just eventID 8000 affected).
There has been KB article recently published for this issue occuring with MSDW. The events numbers the registry file imports are exactly the same as the one the MSMS hotfix imports (which i have been advised are Sharepoint ones also), so i guess they are interchangeable. Problem now is that my ePO server see's them all as MSDW due to the extensions imported.
But that's another service call which is ongoing...
The Hotfix referred to on MSMS side is HF659985 and is available for download from the mcafee service portal (http://mysupport.mcafee.com ). however, if you are using both MSMS and MSDW in your environment than the shared event ids would mean that which ever extension was last checked in is what gets reported.
Development is working to remedy this -