McAfee 'M' Tray Icon showing Yellow warning apostrophe icon with HIPS, but no error
i am currently running through the pilot of a HIPS deployment and have run into some issues with all machines displaying a Yellow apostrophe on thier 'M' icon about 10 seconds after boot, with HIPS installed.
When i then right click to view what the warning is, the twllow apostrophe disappears and does not display any links to logs or displays any errors like you would if malware were found or an access protection rule is violated.
This M Tray Icon is the consolodated one, not the individual HIPS icon.
Things i have tried:
1) Disable the Mcafee agent icon so all products show their own icon. I do this, but on boot, the HIPS icon or others display no unusual behaviour, and funny warnings on thier icons.
2) Disabled all the various elements of HIPS, FIrewall, IPS and application blocking and hooking, but with the McAfee Agent icon enabled, showing the M, it still shows the Yellow apostrophe.
3) Checked all error logs on the EPO server, and local FireSvc.log files etc on the clients. No clues.
4) Uninstalled HIPS conpletely. When this is done, i get no Yellow apostrophe, showing it is definelty the presence of HIPS that is causiing the McAfee M Tray icon to display the warning.
This happens without fail , about 10-15 seconds after log in, and as soon as i right click on the M icon to look further into the error, the apostrophe goes and no clues remain.
Any Ideas? This is not going to be acceptable during deployment.
The little 'i' just means "information". I appears regularly when McAfee has "something to say". I see it most of the time with ViruScan when it has logged or blocked something according to the settings. (We don't block too much but log more here). So, VSE logs something it its log-file and then puts a little 'i' on the icon to let you know it's alive and active
Tell your users not to panic if they're asking. If it's just you, I'd suggest looking in the log files either through the McAfee interface (VSE console, HIPS console) or in the files themselves (look under "C:\Documents and Settings\All Users\Application Data\McAfee").
That "i" is a big cause for helpdeks phonecalls, why can't you include an option to disable it? It looks like an ! and do anyone acctually think that the user will go check the logs if that "thing" appears and not call helpdesk? Not mee...
Thanks for the info. Ive raise a call, and its got lost in the Abyss of future change requests.
I am just deploying HIPS now to 2000 nodes. 100 so far.
Decided NOT to upgrade to patch5 as few people had spoken previously of issues, and as we saw no issue sin pilot testing of patch4, it seemed like a stable release. If its not broke (for me), why fix it, and all that. Maybe we will see some issues, when the deployment is expanded, i will be keeping a close eye on it
what was this issue you spoke of and how many nodes do you have with HIPS?
I have HIPS 188.8.131.528 on about 5000 machines and 184.108.40.2063 (Patch 3) on about 3000. For the most part only IPS is enabled. We're still working on developing and rolling out a firewall rule policy. I only installed patch 5 on a few test devices to see if the yellow "i" issue was resolved.
Issue: The McAfee Host Intrusion Prevention tray icon displays “Driver not installed”. (Reference: 456937)
Resolution: A delay during service startup could cause this message to be displayed inappropriately. Internal timeouts have been increased to allow for a delay during service startup.
That's the issue I was referring to. On some 220.127.116.113 machines if you look at the HIPS icon right after logging in while the OS is still finishing startup, you could see a red circle over HIPS with the message "Driver not installed" and then it would disappear as the OS load finished. I was hoping this was responsible for triggering the yellow "i" on the icon.
I'm going to continue testing patch 5 in our environment since there are numerous fixes I'm interested in. The main problem I'm aware of is the filtering of localhost traffic. Although that appears to be by design and just requires proper testing and exceptions where needed etc....
This is another fix I'm interested in:
Issue: Returning packets of outgoing traffic were blocked as incoming traffic. (Reference: 476116)
Resolution: Returning packets of outgoing traffic are no longer blocked.
I don't pretend to know all the workings of tracking session state in a stateful firewall....but to see a fix for allowing return traffic in patch 5 is somewhat surprising.