Perhaps the agent-to-server port is locked btween the computer and the ePO server, if you don't even see last connection time on your epo server it can be this.
Try a telnet from one of these machines to the ePO server agent-to-server port and see if it gets connected
Altogether this is for ~5% of my systems.
You can make a test deploying MA 4.0 to one of these machines (or use CMA 126.96.36.1998 instead of the one you are using if you don't want to upgrade to 4.0 now) and see if it returns all the info as it should be.
I had the same problem some time ago and after upgrading to CMA 3.6 patch 4 (188.8.131.528) it workd fine
I updated the agent to the latest patch (184.108.40.2068) and the problem remains :sad:
MA 4 is not yet validated, we're testing it and we're following issues here :)
Was this ever resolved or know the solution? I understand this is an old post but I'm experiencing this issue on a number of my systems running the latest patch of the 4.0 agent. The client is fine and reports the correct DAT but what is listed in the Proptoserver file is 0 and that's what is showing up on the ePO server. I've tried pushing out the agent again but this does no good. I contacted McAfee support and they walked me through uninstalling then reinstalling and suprise this worked but I don't have that luxury to do this for everyone since many of these systems are remote.
Thanks for your support.
I'd more or less forgotten I'd raised this issue and was thinking of checking (again) in the Kb and here about this.
No, the issue hasn't been solved.
I was told (somewhere) that switching to McAfee Agent 4 should resolve this... it didn't.
We're now using MA 220.127.116.114 (latest patch AFAIK) on "all" systems (for some reason, some systems didn't upgrade the agent).
To summarize, I have about 5200 systems,
- 4500 have agent 18.104.22.1684,
- 180 have MA 22.214.171.1241,
- 500 have CMA 3.6.0.xxx
- 950 have a last update date of more than 2 weeks
- 850 have a last update date of more than 1 month
(I usually consider thos inactive computers as "zombies" as I'm not told when old Pc's are replaced or trashed, I have tofind out by myself if inactive systems are actually having a problem or if they have been replaced.)
If I only look at active systems (last update less than 2 weeks), I have 4327 systems, of these 15 have MA other than 126.96.36.1994.
346 are what I define as "non compliant" (MA version, VSE version, DAT and Engine versions) and in those I still see funny things like
- [blank] VSE version, DAT or engine
- VSE Engine version reports as "N/A"
- VSE Engine version reports as "%%NewEngineVersion%%"
- DAT version reports as "[Blank]"
I have been unable to find out exactly what goes wrong why where... I couldn't find any real link between systems showing this problem.
Most of the time, uninstalling all McAfee software and reinstalling solves the problem.
I'm not even sure that it's always the same systems that show the problem every week.
Since it only concerns a fraction of 8% of the systems, I can't spend too much (not enough) time on this.
Please check your extension and make sure both VSE and the reporting extension are updated. It should be 202 for VSE 8.5 and 146 for the reporting extension (I think) . If they are up to date check on one machine what is actually sent to ePO. The file is called LastPropsSentToServer.xml in the agent directory. Does that contain correct data? There are other things to be checked but this might be a start.
Oh Serge, you are totally in the same boat I'm in. I have all kinds of systems that I can not get updated with the latest patches or I can not get to install additional McAfee apps like SiteAdvisor or HIPS. It's frustration but then again our environment is not standard by any means which my guess is part of the problem.
I'll keep playing with it. Might even give McAfee another call to see if another tech gives me another solution. Since I report a dashboard to the management team, they don't like to see systems we have no idea what DATS they are running so I'm forced to find a solution. If I find anything I'll post it here.
Just as a bit of clarification - this kind of thing is certainly possible. Here's the background - please bear with me
The agent on the client machine is not, strictly speaking, responsible for collecting the properties of the products installed on the machine. Instead, each point product provides an interface to the agent: when the agent wants to collect properties, it effectively tells each product "collect your properties and tell me when you've finished." The agent then packages up the properties from each product and uploads them to the server. However, it doesn't check that the properties it has make any kind of sense - it can't, since it doesn't know what constitutes valid properties. It relies on the point products to collect the correct properties.
If, therefore, a point product makes a mistake or fails to collect the correct properties, the agent is going to send this up to the server. In the case of DAT and engine versions, which cause the most trouble, this information has to be retrieved from the engine while it's running: if for any reason the engine is busy at the the time it is asked for its properties it may not be able to respond in time, and this in turn leads to a blank DAT or engine version.
Once this has happened, it's possible that it won't correct itself until the next dat version is installed.
There are a couple of different possible solutions to this. One is the full-properties wakeup call. If you have a machine whose properties are incorrect, you can send a wakeup call to that machine with the "Get full product properties" option enabled: this tells the agent to collect everything again and often solves the problem.
Alternatively you can tell VSE to collect its properties from the registry rather than from the engine: please see KB 60100 for more details on using the bReadEngReg value.