DAT files aren't updating

[hbss_admin]

We're having an issue where numerous systems are communicating correctly with the ePO server, they have a client task configured to pull DAT file updates daily, their local SADR server is in sync with the master repository on DAT file version numbers, but the systems are still behind several version numbers on the DAT files.

The users are getting a pop up error message from the McAfee Agent Updater stating "Unable to find a valid repository. Update process failed."

Any suggestions?

PG

[Tristan]

First step is confirm the repository list on the client

From the VIrusScan console

Tools -> Edit AutoUpdate Repository List

Make sure the SADR (?SuperAgent Distributed Repository? not an abbreviation i'm familiar with) is on the list and maybe your Master Repository as well. While your there double-check the proxy settings as well.

Next step would be to check access to the repositories from the problem client.

Usualy you can do this by simply entering http://ePOServer:port/Software/Current/SiteStat.xml into a browser. I know this works for a master repository not sure if it works for a SuperAgent.

If the repository is avaliable you should get something like   "<SiteStatus Status="Enabled" CatalogVersion="20120917000349"/>" displayed in the browser

[hbss_admin]

Yes, SADR is "SuperAgent Distributed Repository". And yes, the McAfee Agent policy is configured with the local SADR first on the list, our E-SADR second on the list, and the ePO server 3rd on the list. No proxy is used.

This is the message you get from the ePO server on your second step.

<SiteStatus CatalogVersion="20120916210010" Status="Enabled"/>

[Tristan]

Ok that means that the repository is avaliable, which is odd that the agent is producing that error message.

Two things i would try at this point.

1. Create a group in the system tree with a new (fake) repository policy attached to it. Move the problematic machine into that group, preform a wake-up with policy refresh, move the machine back to it's correct group and wake-up again. Basically i'm trying to get the client to redownload it's correct repository policy again in the hope that it's simply a corrupt policy. Just attempting to force a update of the same one might not do the trick but pushing a new one and then the correct one sometimes gives it the kick it needs to rewrite it.

2. Re-install the agent.

[hbss_admin]

We get that "Unable to find a valid repository" frequently enough on systems that aren't having any issues updating and communicating with the ePO that we almost ignore it now.

I tried pointing a representative system at a different SADR server, doing a wakeup, and moving it back, and doing another wakeup, but it doesn't seem to resolve the issue.

[hbss_admin]

Btw, re-installing the agent will be a very last resort fix; we're talking hundreds of different machines experiencing this issue. Re-installing the agent on that many machines won't be a trivial task.

[Tristan]

Just a thought what's the IP allocation method of your SADRs? Are they fixed or DHCP?

Is it that DNS records are not updated fast enough when a SADR is given a new IP via DHCP.

[hbss_admin]

Static IPs. It would be silly to have critical servers on DHCP!  🙂

[hbss_admin]

If anyone is still following this thread, we noticed our infrasture servers (ePO, SQL, agent handlers, SADR servers) had all stopped updating their DATs on August 19, so I removed and reinstalled VSE on all of these servers. The removal/reinstall of VSE included a reboot on all servers.

After doing that the problem seemed to resolve itself. I suspect the rebooting probably had more to do with the resolution than the reinstallation of VSE, but don't know for sure.

[Tristan]

We're you not aware of the bad DAT issue with 6807 that was released on the 18th/19th?

http://service.mcafee.com/FAQDocument.aspx?lc=1033&id=TS101446 .

Uninstalling and reinstalling VSE was one fix you could also apply the hotfix the correct the issue.