1 of 1 people found this helpful
One of the troubleshooting steps to do when machines stop updating is manually download the DAT file from: McAfee, Inc. - Downloads - Virus Protection - DAT Files and run it as an administrative user. It doesn't require a reboot and more often than not gets the machine automatically updating again.
Thanks for the hint. I did it today with a couple of such machines. We'll see how it will behave tomorrow.
Sorry, it didn't help. Both the servers I updated yesterday manually with a downloaded file still don't update automatically and can't be updated from command line.
Hmmm, how odd. Are you getting any communication errors in the McAfee Agent Status Monitor on the problem servers? Can you wake up the agent from the ePO server successfully?
Bearing in mind you don't want to restart the server, next thing I would try is to force a re-install of the McAfee Agent. It's documented that it doesn't require a reboot and in my experience I've not found it to cause problems.
Probably worth contacting support and sending them a MER report from one of the problem servers while it has the problem. If you've not done it before, support will take you through it.
No communication errors. In ePO, the last communication time is current. Managed servers are accessible from ePO over port 8081. This is not a communication problem, as it sometimes happen even to the agent running on the ePO server itself.
However, if I send the Wake signal from the ePO server, I see no reaction in McAffee Agent Monitor running on the problematic server. And if I try to start the update process manually (with "mcupdate,exe /update" command), there is no reaction as well. Something is wrong with the agent itself.
Reinstalling the agent might help but it's not always possible. Reinstallation is a WIndows Installer-based process, and if WI's state is inappropriate (because of recent installations and pending reboots, for example), it fails. It happens rarely but happens nonetheless. That's why I'm trying to find a less drastic solution.
Thanks for help. I thought it might be a known problem that has a quick solution, However, seems we really have no other choice but to open an incident with McAffee support.
hello Lotto, i started to observe the same on some (lest than 10) of our (more than 280) Win servers . i just restarted a couple of them (in test env) and they restarted to perform DAT update. but i cannot freely restart all servers involved as you can imagine.
So far I discovered several reasons for this problem:
1) (non-interesting and specific to our environment) An incorrect agent package is installed in the server via SCCM (several agent packages are obsolete and point to a wrong ePO server). the correct package should be installed.
2) (a little more interesting) In reality, the DAT file continues to update but the server record in SNOW remains frozen and doesn't show that the DAT file is updated. The reason: the agent was reinstalled and created another duplicated server record in ePO. The obsolete records is shown in reports as non-compliant. It just needs to be removed.
3) (another not-so-interesting scenario) VSE is obsolete and is incompatible with the agent. VSE should be upgraded to the new version.
4) (the most interesting case) ePO agent policies are not applied to protected servers due to VSE blocking registry update. Yes, VSE blocks activities of its own agent when the agent tries to write new values into its own registry keys. It leads not only to DAT update problems but to new policies' being unable to apply as well. Solution: disable the Access Protection feature and use the agent monitor console to force policy application (and enable Access Protection manually if it doesn't turn on automatically).