clients connect to ePO but dont download DATs

[itsnBrockport]

most notably are the XP machines with VS 7.1 on them which connect to ePO, download the policies but do not download the DAT files.

we had out 2000 machines going fine(most recently they stopped downloading the DATs, but still download the policies)

the log file on the client machine shows "No Package received from server" which there clearly is an updated DAT file on the ePO 3.0.1 server. please help! please feel free to ask questions.

 

[JimmyZ1]

do you have an epo udate task running? is it enabled?

Last cube on the left, next to the backdoor...

 

[itsnBrockport]

no we dont, we never have before and it seemed to work whenever we did a wakeup call.

 

[JimmyZ1]

do you use super agents?

Last cube on the left, next to the backdoor...

 

[itsnBrockport]

no we do not use superagents

we have figured out the problem of getting our machines to download the DATs (we just retraced the settings from our old server, dont know what exactly worked though)

so back to our major issue which is the fact that Windows XP machines download the policy but not the DAT. Thanx!

 

[primate]

I find that sometimes one of two things can remedy the situation:

Firstly manually update the clients to the latest DAT version and they often start working next time there is a new DAT version to be downloaded from the ePO server, s

Secondly manually import the sitelist.xml file from your ePO server or a working client to the affected clients and again this seems to get them going. I am not sure why but I was stuck exactly the same as you with a few random clients not doing what they should be doing and usually one of these two options worked.

 

[JimmyZ1]

do you mean the sitelist.xml or the sitemaplist.xml??

Last cube on the left, next to the backdoor...

 

[primate]

sitelist.xml, on the virusscan console, "Tools/Import Autoupdate repository" list then browse to sitelist.xml thats what I've done anyway

 

[JimmyZ1]

what about the sitelist.xml under the commonframework dir under all users? can you use this sitelist.xml??? which one of these does this thing use......AHHHHHHHHHHHH epo's making my brain hurt......

Last cube on the left, next to the backdoor...

 

[primate]

Yes thats the one I mean.

The ePO documentation makes my brain hurt I don't know about anything else, the admin guide is about 10 times longer than it needs to be and one of the worst written pieces of technical documentation I've read.

 

[JimmyZ1]

Can I get an AMEN!!!

AMEN!!

If I had a penny for every framework issue i'd have alot of pennies....

 

[primate]

lol, indeed you can.



Sponsor me to run the Great North Run for Henshaws Society for Blind People - click the link

https://secure.justgiving.com/greatnorth

 

[jbouy]

I believe I may have be able to help. This is what NAI told me when I had a similar situation.

It appears from the MER results you sent that the machine is not updating due to a missing registry value for the Mcafee AutoUpdate component. This key is referenced by the ePO Agent to keep track of what products/components are installed on the system in order to determine the correct tasks and policies set by the ePO server. The specific reg key and values are below:

[HKEY_LOCAL_MACHINE\Software\Network Associates\ePolicy Orchestrator\Application Plugins\CMNUPD__3000]
"Plugin Path"="C:\Program Files\Network Associates\Common Framework\FrmPlugin.dll"
"Software ID"="CMNUPD__3000"
"Uninstall Command"=""
"Language"="0409"
"Product Name"="McAfee AutoUpdate"
"Version"="3.1.1.184"

Since this key is missing on the XXX-EPO machine, the ePO Agent does not recognize the Update task you are configuring as one that it needs to run. This is also evidenced by the agent's log, which shows it enforcing policies and collecting properties for products it sees as being there, but not for Mcafee AutoUpdate (CMNUPD__3000) :