This content has been marked as final. Show 9 replies
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").
have a nice day
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...
How are others experiencing this?
I had a user who believed the sign was an indication that he needed to do a DAT update, so he'd got and click on "update now" every time... He was a bit fed up until I explained what it really was.
I haven't found any place where I could tell VSE or the Agent not to put the warning sign on the icon. The only possibility I've found was to log less actions, but that means less information :(
I've instructed our helldesk to tell our users not to worry, I also put a small (4 pages) info sheet on common issues with VSE. Users can find it on our infernal website and it helps.
Yeah we have the dame issue. People keep asking if their anti-virus is running correctly, cause it looks like an icon for an issue such as anti-virus is not running or something.
Im thinking if enought of us tell McAfee about it as an issue we may get a Hotfix. Im not after a whole new patch release.
It does it with just HIPS and McAfee Agent installed to.
I plan to tell support about this in a few days, along with a few other suggestions.
I have raised a call with McAfee but have not been promised a fix, nor any feedback from technical aknowledging the problem, just that it will be sent to the relevant team.
I am hoping i can get a little more feedback on this issue from McAfee as this ! is a real concern for the company i am working with at the moment
FYI this still occurs after installing HIPS7.0 patch 5. I was hoping it was related to the occasional flash of "Driver not installed" which is addressed in patch 5. But no such luck.
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 18.104.22.1688 on about 5000 machines and 22.214.171.1243 (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 126.96.36.1993 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.