1 2 Previous Next 12 Replies Latest reply on Nov 18, 2008 4:11 PM by Travler

    Systems stuck on 5402

    Travler
      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.

      Any ideas as to what causes this?
        • 1. RE: Systems stuck on 5402
          what does the update log say?
          • 2. RE: Systems stuck on 5402
            Travler
            If you're referring to the updatelog.txt at:
            Documents and Settings\All Users\Application Data\McAfee\DesktopProtection
            it appears that all the affected systems are missing this file.
            • 3. RE: Systems stuck on 5402
              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
              • 4. RE: Systems stuck on 5402
                Travler
                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.
                • 5. RE: Systems stuck on 5402
                  maybe your update task has become corrupted. try by creating a new update task for the ePO agent at directory level if they start updating automatically again.
                  • 6. RE: Systems stuck on 5402
                    Travler


                    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...?
                    • 7. RE: Systems stuck on 5402
                      you can check if when the agent starts it sets also the next execution of the update task.
                      It should.
                      • 8. RE: Systems stuck on 5402
                        It's so hard to find out in these events what the actual cause is, but if a task does not run the way it should and the agent is working flawlessly, than it's basically the only possibility there is.

                        I know that when upgrading ePO from one version to the next, such corruption can occur.

                        Also when moving around groups could lead to such corruption, this is a known issue in older ePO version, so especially when you have upgraded to ePO 4.0 this could be an explanation.

                        I reckon that if recreating the task solves your issue, although bald, do yourself a favor and just move on and don't look back wink
                        • 9. RE: Systems stuck on 5402
                          Travler


                          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.
                          1 2 Previous Next