5 Replies Latest reply on Aug 25, 2010 3:47 AM by Attila Polinger

    VSE updates successfully but Framework service doesn't realise

    Tristan

      Basically an update task appears to fail and the agent tries to download the 65Mb avvdat definition file (very noticeable over a 256Kb WAN link), it will then repeatly attempts to download the full definition file at every scheduled update.

       

      However if i just simply stop and restart the VSE, engine and framework services on the offending machine then everything is magically fixed and the computer reports as up to date.

       

       

      Message was edited by: Tristan on 23/08/10 15:01:27 IST

       

       

      Message was edited by: Tristan on 23/08/10 15:02:16 IST
        • 1. Re: VSE updates successfully but Framework service doesn't realise
          Attila Polinger

          Hi,

           

          please post McScript.log and McScript_backup.log here from an offending machine and mark the timeframe of the problem update session.

           

          Attila

           

           

          Message was edited by: Attila Polinger on 8/24/10 12:54:46 PM CEST
          • 2. Re: VSE updates successfully but Framework service doesn't realise
            Tristan

            Both files are in DB.zip

             

            In McScript.log the successfull update starts around line 4090 (11.54 23-08-2010) and finishes at line 4230 (11:57 23-08-2010)

             

            At lines 4595, 4967 & 5339 you can see the avvdat-6082.zip being downloaded.

            • 3. Re: VSE updates successfully but Framework service doesn't realise
              Attila Polinger

              Hi,

               

              after looking at your McScript.log my first tip is that the problem update might be continually exceed allotted time (in ePO client update task: Schedule tab - Stop the task if it runs for X mins and Y secs option) - that is from 11:54 till 12:30 may not be enough time for the update to finish properly:

               

              2010-08-23 12:21:20 I #2756 ScrptMgr Downloading avvdat-6082.zip.

              2010-08-23 12:21:20 I #2756 imsite Download to: C:\Documents and Settings\All Users\Application Data\McAfee\Common Framework\Current\VSCANDAT1000\DAT\0000\avvdat-6082.zip

              2010-08-23 12:21:20 I #2756 imsite Download from: (ePO_OMEGA) Current/VSCANDAT1000/DAT/0000/avvdat-6082.zip

              2010-08-23 12:21:20 I #2756 naInet Open URL: http://172.16.0.45:8080/Software/Current/VSCANDAT1000/DAT/0000/avvdat-6082.zip

              2010-08-23 12:30:00 I #948 SutDnWtch Requesting mue termination

              2010-08-23 12:30:00 I #2756 imsite NaInet library returned code == 7

              2010-08-23 12:30:00 I #2756 imsite NaInet library returned code == 7

               

              2010-08-23 12:30:00 E #2756 ScrptUtl Failed to download from repository

              2010-08-23 12:30:00 I #2756 imsite Download to: C:\Documents and Settings\All Users\Application Data\McAfee\Common Framework\Current\VSCANDAT1000\DAT\0000\SiteStat.xml

              2010-08-23 12:30:00 I #2756 imsite Download from: (ePO_OMEGA) SiteStat.xml

              2010-08-23 12:30:00 I #2756 imsite NaInet library returned code == 7

              2010-08-23 12:30:00 I #2756 imsite Download to: C:\Documents and Settings\All Users\Application Data\McAfee\Common Framework\Current\VSCANDAT1000\DAT\0000\SiteStat.xml

              2010-08-23 12:30:00 I #2756 imsite Download from: (ePO_OMEGA) SiteStat.xml

              2010-08-23 12:30:00 I #2756 imsite NaInet library returned code == 7

              2010-08-23 12:30:00 I #2756 ScrptExe Setting flag after file not found to restart update.

              2010-08-23 12:30:00 I #2756 ScrptExe Failed to get the files from the server. Setting bRet to FALSE

              2010-08-23 12:30:00 I #2756 ScrptExe User termination invoked.Further commands will not be executed

               

              I would also check if the repository is consistent as for control files and signature files are concerned. For example: are all files present (.gem files) that are referenced in control file (gdeltaav.ini).

              My second tip therefore would be that full DAT is downloaded because some incremental files are not there (for V2 DAT it only occurred normally if your client were more than 30 days behind DATs).

               

              Attila

               

               

               

               

               

              Message was edited by: Attila Polinger on 8/25/10 8:53:31 AM CEST
              • 4. Re: VSE updates successfully but Framework service doesn't realise
                Tristan

                The timeout has been added my me to try and prevent the 65Mb download staturating the 256Kb WAN link.

                 

                My question is about the fact that the log files clearly says that the update to 6082 completed successfully, yet at the next scheduled update the framework service decides that it's not the case and downloads the full definition file.

                 

                I can simply stop and restart the McAfee services and framework service will happily see that everything is up-to-date on not attempt to download the 60Mb file.

                 

                It's as if a registry entry is not being written/read correctly or at the right time.

                 

                I can confirm the the repo status is up to date as i have 200 clients pointing to the same repo with no issues.

                 

                 

                Message was edited by: Tristan on 25/08/10 09:12:07 IST

                 

                 

                Message was edited by: Tristan to correct typos on 25/08/10 09:12:39 IST
                • 5. Re: VSE updates successfully but Framework service doesn't realise
                  Attila Polinger

                  Basically either update should deal with incremental files and not full definiton files. Yours seemed to revert to the fullDAT after about 4 incrementals, which troubles me. The logic would be that unless the client DAT is not beyond X version behind current one, the incrementals should be used to update the client, not the full DAT.

                   

                  Also, if a registry entry would be blocked from writing, then it would be so during either types of update I suppose.

                   

                  Could you also post the Agent_hostname.log (and backup log if needed) which has the timeframe of the updates (the good and the bad)?

                   

                  /I'm curious of the scheduled update frequency, too. Is that not scheduled for too frequent runs a day?/

                   

                  What is the client opsys and Virusscan version (gathered from the client) ?

                   

                  Attila