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
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"/>
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.
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.
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.
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.
Could you check the Agent Repository Settings in your ePO, verify that which repository have you assigned?
Change the settings to McAfeeHttp as well to troubleshoot.
Let the settings as :
Repository list selection =Use this Repository List
Use Order in Repository List.
Move the McAfeeHttp to the top of list, save the settings and Run a Update Task, selecting DAT and Engine.
Static IPs. It would be silly to have critical servers on DHCP! :-)
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.