4 Replies Latest reply on Nov 21, 2011 7:49 AM by Tristan

    Successfull update is a lie


      I have an issue where a managed computer says it's updated successfully to the latest DAT but on it's next check it decides that it hasn't


      The machine is fully up to date XPsp3 with VSE 8.8 and Agent


      I've attached the agent log from the offending machine and as you can clearly see....


      At 08:23:09 (line 531) i get the line:


           - 2011-02-24 08:23:09 i #2536 Updater Update succeeded to version 6266.0000.


      OK VSE and the framework service has done their bit and updateed the DAT....or has it?


      At 09:14:30 (line 913) the agent is processing it's next sync to the epo server and has magically forgotten that is already updated to 6266 and tries to do it again.


           - 2011-02-24 09:14:30 i #5712 Updater Downloading 62656266avv.gem.

           - 2011-02-24 09:14:30 I #5712 Uec Done processing progress information

           - 2011-02-24 09:14:51 I #5712 Uec Received ipc data from mue

           - 2011-02-24 09:14:51 I #5712 Uec Processing progress information

           - 2011-02-24 09:14:51 i #5712 Updater Downloading avvdat-6266.zip.


      Annoyingly it fails and decides to to download the massive 80Mb avvdat update which is a show stopper at the end of a 256Kb WAN link.


      Has anyone seem or experienced this issue?


      It's easy to remedy as i just manualy roll back the dat and re-run the update and everythings ok until it does it again a few weeks later. I would like to find a more perminent solution.

        • 1. Successfull update is a lie

          Uninstall VSE, delete all VSE registry entries/folders, re-install. I've had the same problem in the past and this has fixed it. Something with VSE bugs out and it won't update, I've seen all sorts of updating issues over the years.

          • 2. Successfull update is a lie
            Sailendra Pamidi

            Since this is a recurrent issue, Please enable McScript debug logging  on the client computer, increase the log size to 10MB, reproduce the issue so that the debug information is captured in the log. Then collect a MER log and escalate to McAfee Support for investigation.


            • Click Start, Run, type regedit and click OK.
            • Navigate to the following registry key:

              [HKEY_LOCAL_MACHINE\SOFTWARE\Network Associates\ePolicy Orchestrator]

            • Right-click on LogLevel and select Modify from the menu.
            • Type 8 in the Value data box.
            • Click OK.
            • Create the DWORD Value entry for LogSize if it does not exist.

              NOTE: This value defines the size of the log in megabytes. The default value is 1. The value needed for level 8 logging varies depending on evaluated function.

              1. Right-click the ePolicy Orchestrator key and select New, DWORD Value.
              2. Type LogSize in the New Value field and press ENTER.
              3. Right-click the new LogSize value and select Modify.
              4. Set the Value data to an appropriate size in megabytes and click OK.


            For CMA or McAfee Agent level 2 debugging:

            1. Click Start, Run, type regedit, then click OK.
            2. Browse to the key:

              [HKEY_LOCAL_MACHINE\SOFTWARE\Network Associates\TVD\Shared Components\Framework\]

            3. Right-click Framework and select New, DWORD Value.
            4. In the Name field, type dwDebugScript.
            5. Right-click dwDebugScript and select Modify.
            6. In the Value Data field, type 2.
            7. Click OK.
            • 3. Re: Successfull update is a lie

              Any news on that ? Ive got the same problem.

              Thank you

              • 4. Re: Successfull update is a lie

                I gave up in the end. All McAfee tech support would repeatly suggest was to apply the SuperDat.


                Basically from what i could tell the update task was taking so long on our older/slower computers that the two update tasks were colliding and causing the issue.


                We changed our update task to once a day instead of every 4 hours. The clients now update every morning 30 minutes after boot-up with a little randomization.


                So far the problem hasn't come back.


                I know it's not a real solution but you could try adjusting the gap between updates to see if it makes a difference.


                Message was edited by: Tristan on 21/11/11 13:49:43 GMT