We have about 3000 Windows servers managed by an ePO installation. All managed servers run the VSE 8.8 with the latest patches, and usually everything works fine. However, sometimes VSE on some servers just stops updating its DAT file. The DAT version freezes and is not updated as dictated by the schedule. VSE also doesn't react to update commands from the ePO server. Attempts to start the update manually from the command line also fail: the update window appears but displays no actions, only the "automatically close in XX seconds" countdown is displayed. Restarting McAffee services on the machine doesn't help, too.
No reasons for such behavior can be found by examining Windows Server logs. Servers can stay in this state for days or weeks, or sometimes this bad condition suddenly resolves on its own in several days. I believe server reboot can solve it as well but this procedure in our environment is extremely complicated and can take up to a week. In the same time, servers must stay compliant all the time, this is a mandatory requirement.
Any ideas how to resolve this situation without rebooting the server?
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.
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).