Has anyone else experienced systems not updating from dat 5402? We have about 150 systems that appear to be stuck on that dat. Over 90 of these systems are servers. Wakeup calls show that they communicate, but they won't update. Sending an agent re-install usually does the trick, but that certainly shouldn't be necessary.
I've occasionaly noticed this behavior before, but never to this extent.
i mean, when you try to update a client the agent, or the update windows, says something, like "downloaded pkcatalog.z", something like that.. you can see it remotely by accessing http://client:8081 if you left the default port.. so, what does it say? does it find the repository? does it try to download the updates? just curious, never happened to me happy
Its like these machines check into the epo server at their assigned times, but simply don't see that there is an update to download. If I run an Immediate DAT Update task, then they update fine.
So, to answer your question, it looks like when they communicate with the epo server, they are failing to see a repository. There is no attempt to download the package.
When this has happened in the past (these past occurances would only involve a handful of machines at most, never a group the size of todays occurance), after nudging them with the Update Task, they continue to run fine and will recieve future dats with no problem.
Thats worth a shot! I've disabled the old task and created a new one so I'll let you know how it goes. However, since this has always been a sporadic event, it might be tough to determine if this was the culprit. Plus, you'd think that if the old task was corrupted, it would affect more than just an occasional batch of systems...?
All I'm seeing in the ePO Agent's Status Monitor is the time for the next Enforcement and the next ePO Communication. I don't see an exact reference for the next Update. Am I looking in the wrong place? The systems appear to be communicating on schedule. (Problem just seems to be when this occurs, the problem system doesn't look for a repository.)
I've created the new task, and so far so good. However, that doesn't tell me much since this has been a sporadic problem for well over a year. That's been the big frustration with this issue: not only is it infrequent, but it is also random machines. Trying to think back, this may have been occuring since my last ePO upgrade, which was from 3.5 to 3.6.1, so you might be on the right track concerning a corruption during an upgrade. (And, if I recall, the upgrade did have a few issues, mainly due to lack of good McAfee documentation.) I hope I don't compound the problem when I eventually move to 4.0.
I appreciate you guys taking the time to think about this.