4 Replies Latest reply on Apr 15, 2010 9:56 AM by Tristan

    GEM updates failing


      I have an issue on one particular machine with its updates


      Normally it's fine but every now and then it decides to download the full 60Mb avvdat because the GEM update fails.


      This doesn't help as the particular machine is the other side of a 256Kb WAN link.


      Below is a snippet from the agent log and there are no errors in any other log files pointing to why it should do this.


      14 April 2010 16:22:31
      Downloading DAT.
      14 April 2010 16:22:31
      Downloading gdeltaavv.ini.
      14 April 2010 16:22:32
      Downloading 59455946avv.gem.
      14 April 2010 16:22:35
      Downloading 59465947avv.gem.
      14 April 2010 16:22:37
      Downloading 59475948avv.gem.
      14 April 2010 16:22:48
      Downloading 59485949avv.gem.
      14 April 2010 16:22:55
      Downloading 59495950avv.gem.
      14 April 2010 16:24:45
      Downloading avvdat-5950.zip.

      I'm running all the latest software versions


      Windows XP SP3, IE8 fully patched


      VSE 8.7 Patch3

      Engine 5400.1158

      EPO 4.5 (not patch 1 yet)


      I've got a suspicion that there is something wrong with a certificate or something within XP as if i attempt to run a SDATxxxx.exe logged on as the domain administrator i get a error when it attempts to extract the files, yet if i do a 'run as' and use another domain admin account (my account) the SDAT runs correctly.


      Anyone out experienced anything similar?



      Update: i found this in the McAfee knowledge base which appears to be similar to my problem but should be fixed in the versions i'm using


      https://kc.mcafee.com/corporate/index?page=content&id=KB53979&actp=search&search id=1271261473003





      Message was edited by: Tristan on 14/04/10 17:15:40 IST
        • 1. Re: GEM updates failing

          You can look at my similar thread here:



          Does yours always occur, or just once in awhlie?


          I wonder if there is some sort of timing issue. Mine occurs after it tries to copy, so I wonder if it's trying to start something, or scan itself, before it's actually finished copying?

          • 2. Re: GEM updates failing

            I did see that post but it was with VSE 8.5 seeing as my issue is with VSE 8.7 V2 DATs and BOC shouldn't be an issue


            My particular issue only occurs now and then. I've yet to determine any pattern, yesterday my issue occurred with 5 GEMs. I've just tried it just now and it's thrown the same error attempting to down load 1 GEM.


            Update: Attempting to update from 5950 to 5951, GEM fails and begins to download avv DAT, i cancel the download, VSE gets its knickers in a twist and now says that there is no engine or DAT installed, re-apply 5950 superdat and reboot, VSE now quite happily downloads GEM and updates....Go Figure! We'll see what happens tomorrow.



            Message was edited by: Tristan on 15/04/10 15:38:45 IST
            • 3. Re: GEM updates failing

              There might be some diagnostic log levels you can increase, which might give more information about the errors. Have a look at :


              https://kc.mcafee.com/resources/sites/MCAFEE/content/live/PRODUCT_DOCUMENTATION/ 20000/PD20051/en_US/epo_400_troubleshootingwithlogs_en-us.pdf


              (The agent side of things of course!).


              As I've posted in the other thread, I'm actually curious why so many of these types of issues seem to be reported. Is there an issue with patching the dat file, now that it's growing in size? Is there a timeout when copying? etc etc etc.


              ~150kb for a gem update is a huge bandwidth difference from ~61Mb for the zip update... so really it's something that needs to be worked out!

              1 of 1 people found this helpful
              • 4. Re: GEM updates failing



                I have been going through the logs but there was absolutely nothing that stood out as errors around the time of the DAT update.


                I've increased the logging level of the agent. Hopefully i'll get some insight into the cause.