Our SBS 2003 server is secured with McAfee Enterprise VSE 8.5i (patch 5), engine 5200.2160. The server has Protection Pilot 220.127.116.11 installed, and We have 25 client PCs - a mix of W2k, XP and Vista, with either McAfee 7, 8.0, or 8.5i installed. All clients are updating fine, currently with engine 5200 and DAT 5323.
We have relatively recently encountered a problem with Brightstor Arcserve Backup tape report logs not being sent/received within our corporate network, (there are also other possibly related issues which I shall ignore at this time). From the server's VirusScan console, the Access Protection Log file contains regular and identical incidents: "Blocked by port blocking rule - C:\Program Files\CA\SharedComponents\Alert\ALERT.EXE - Anti-virus Standard Protectionrevent mass mailing worms from sending mail - 10.0.0.2:25". The time of these incidents coincide exactly with the times of the overnight tape backup process. Incidentally, it appears that the problem started to occur the night after upgrading the server from VSE 8.5 up to patch 5. This may be pure coincidence, but I have a hunch. . .
A Google search suggested opening the VSE Console on the server and changing some settings in the Access Protection section. Under the "Anti-Virus Standard Protection" category, the rule named "Prevent mass mailing worms from sending mail" is ticked for blocking. In the Rule details, I added "alert.exe" to the process exclusion list, clicked OK, then "Apply".
I then sent a test message via the Brightstor Arcserve Backup Alert Manager software. This worked perfectly; an email was received instantly at my desktop in Outlook. Fixed it I thought. . . Wrong !!! . . . Over the last few days, I've discovered that McAfee appears to reset the process exclusion list with the original items. The error messages are back. The time before a "reset" occurs is only about 5 minutes.
Incidentally, the client PC that receives the alert messages is Windows XP, recently updated with patch 3 (this may be a red herring, but you never know).
I then had a hunch it was related to the Common Standard Protection category item "Prevent Modification of McAfee Files and Settings", so as a test I tried unticking this item, then re-added "alert.exe" to the process exclusion list once again. However, a few minutes later I noticed everything had been automatically reset once again, including the "Prevent Modification of McAfee Files and Settings". It reminds me of the movie 2001 - it's as though the system is trying to protect itself at all costs.
Thanks for the info. The relevant server's PP 'console' policy changes have done the trick; alert messages are now sending OK. I suppose the solution is obvious in retrospect. I guess I just expected that locally implemented changes (albeit under Administrator privileges) would take precedence.
To be honest, I hate using the server's Protection Pilot; IMHO the interface is extremely user unfriendly, it's hard to find things, and I'm particularly wary of accidentally altering settings 'system-wide' that may have unforseen and adverse consequences.