This content has been marked as final. Show 30 replies
Failed/interrupted update not writing back the registry values for the last update I would assume.
although this was also an issue with older versions of EPO server 3.6.0 that was fixed in 3.6.1 see readme:
The "DAT/Engine Coverage" report would show the
engine version as N./A due to the format of the
engine 5000 version number.
The "DAT/Engine Coverage" report accurately
reflects the engine version.
We are on EPO 184.108.40.206 and CMA 220.127.116.114 and the problem still exists.
depending on how many you have I would just make them uninstall and reinstall VSE again from EPO then, that will clear it.
did it happen after rolling out patch 4 perhaps (got a few corrupt entries after this on some of my epo setups)
We had this problem before CMA patch 4.
Only a few PC have this problem. For example, today a PC is reporting the current DAT and Engine to EPO and something happen the next day cause the PC to report "N/A".
The fix is very simple...I don't need to uninstall/reinstall VSE.
All I do is run the latest SuperDAT and reboot.
that would do it, I just assume this if its happened once then it may happen again so I prefer a clean install
This issue is out of control for us!
We have ePO 18.104.22.168 and 5000 XP/2003 Server Clients all running VirusScan 8.0i Patch 14. and I would say I see between 5-15 clients fall susceptible to this issue everyday.
The only "fix" McAfee could give me is installing the SuperDAT. I cannot have EVERY machine pull the superDAT files from the repositories as it would be killing the bandwidth in some offices. Plus, it's only happening to a small percentage of clients so no reason to distribute to every client anyway (as it would be overkill). And going physically from machine to machine is ridiculous - why pay for ePO? Instead of going to every machine, I created a site in ePO and have set all the agents pull the SuperDAT from the Evaluation Branch where I created a Repository Pull Task to place the SuperDAT. But some machines have been in this site for weeks before updating (why is that - I see they are on and have a recent agent connection time) while others are in for only a few days, in the mean time more and more are being added as they are showing up with the DAT version of N/A.
Is there anything else we can do?
Bumping this thread as we are seeing a similar problem. Our setup is nearly identical, EPO 22.214.171.124, CMA 126.96.36.1994, running VSE 8.0i patch 14 on XP/2k3.
Given that my options seem to be:
1) uninstall/reinstall VSE80
2) run Superdat (which could be tricky due to its size) or
3) use it as an excuse to move to VSE85
I would still like to hear some input on possible causes, even if it's only speculation. For myself, we have been having trouble lately pulling our daily dat update from McAfee, if a 'corrupted' file gets pulled down and doesn't get checked in to the master repository, then the subsequent replication out to our distributed repositories screw up as well. I am wondering whether an agent checking in to a jacked-up repository could wind up in this state?
Any thoughts? :confused:
I get the same sort of problem from time to time, but instead of it being on the engine and dat info, it is under the Product Info and shows "N/A.N/A" instead of the Patch version. This happens on both 8.0 and 8.5 systems. Removing and reinstalling VSE clears the problem up, but since it otherwise works ok (system updates dats and communicates to ePO fine with the exception of the N/A business) I usually don't have time to devote to it.
Example: 188.8.131.521.Wrk.N/A.N/A (instead of 184.108.40.2061.Wrk..5)
We also see the N/A on the DAT's and Engine fields. We have about 1500 systems and only have about 6 systems report this issue.
I usually ignore the issue since the reports do show the the systems having the latest DATs. Our helpdesk doesn't have the time to fix these issues. It is usually fixed by uninstalling the EPO agent, VirusScan 8.0 or 8.5i and then removing any left over registry entries.