6 Replies Latest reply on Jul 16, 2010 3:34 AM by LawrenceH

    can I disable the 60M gem file archive that is sent every 35 days

      I am running McAfee enterprise antivirus (V2) and my AV clients are updated via an ePO controlled repository.  However, I only have Internet access to these repositories, via a satelilte link. Therefore, I have to minimize the (expensive) bandwidth used for antivirus updates.

      I am OK with the 200- 300 kilobit bandwidth required for the daily GEM file updates, however, the 50-60Mb super DAT (GEM file archive) that is sent every 35 days would be very expensive over satellite.

      It was told by McAfee tech support that I can turn off the 35 day super DAT update for a couple of months at a time, however, I wanted to ask this community if anyone has actually done this, or has any comments to offer.

      I would greatly appreciate it if anyone has some numbers, or an actual graph of the bandwidth utilized for their AV updates.

      Thank you

        • 1. Re: can I disable the 60M gem file archive that is sent every 35 days
          Peter M

          Moved provisionally from Community Help to VirusScan Enterprise for better attention - Moderator

          • 2. Re: can I disable the 60M gem file archive that is sent every 35 days

            The zip file is actually sent once every day - it is refreshed daily in the dat set when a new version of dats is released.

             

            Have a chat to McAfee support and see what options there are. I believe they have some workarounds for replicating data to small pipe sites.

             

            On average the GEMS are 100-200Kb/day, although this does fluctuate both up and down - for example, a couple of gems released last week were 600Kb, and others were 80kb etc. There was even one that was 2Kb within the last few weeks:.

             


            Here's the rolling 35:

            59975998avv.gem                   03-Jul-2010 11:00   101k 
            59985999avv.gem                   03-Jul-2010 11:00   141k 
            59996000avv.gem                   03-Jul-2010 11:00   117k 
            60006001avv.gem                   03-Jul-2010 11:00   159k 
            60016002avv.gem                   03-Jul-2010 11:00   179k 
            60026003avv.gem                   03-Jul-2010 11:00   130k 
            60036004avv.gem                   03-Jul-2010 11:00   118k 
            60046005avv.gem                   03-Jul-2010 11:00   119k 
            60056006avv.gem                   03-Jul-2010 11:00    67k 
            60066007avv.gem                   03-Jul-2010 11:00   154k 
            60076008avv.gem                   03-Jul-2010 11:00   189k 
            60086009avv.gem                   03-Jul-2010 11:00    78k 
            60096010avv.gem                   03-Jul-2010 11:00   203k 
            60106011avv.gem                   03-Jul-2010 11:00   144k 
            60116012avv.gem                   03-Jul-2010 11:00    88k 
            60126013avv.gem                   03-Jul-2010 11:00     2k 
            60136014avv.gem                   03-Jul-2010 11:00   112k 
            60146015avv.gem                   03-Jul-2010 11:00   135k 
            60156016avv.gem                   03-Jul-2010 11:00    72k 
            60166017avv.gem                   03-Jul-2010 11:00    64k 
            60176018avv.gem                   03-Jul-2010 11:00    78k 
            60186019avv.gem                   03-Jul-2010 11:00    55k 
            60196020avv.gem                   03-Jul-2010 11:00    68k 
            60206021avv.gem                   03-Jul-2010 11:00   260k 
            60216022avv.gem                   03-Jul-2010 11:00   134k 
            60226023avv.gem                   03-Jul-2010 11:00   117k 
            60236024avv.gem                   03-Jul-2010 11:00   140k 
            60246025avv.gem                   03-Jul-2010 11:00   150k 
            60256026avv.gem                   03-Jul-2010 11:00   172k 
            60266027avv.gem                   03-Jul-2010 11:00    69k 
            60276028avv.gem                   03-Jul-2010 11:00   243k 
            60286029avv.gem                   03-Jul-2010 11:00   608k 
            60296030avv.gem                   03-Jul-2010 11:00   478k 
            60306031avv.gem                   03-Jul-2010 11:00   635k 
            60316032avv.gem                   03-Jul-2010 11:00   148k

             

             

            Message was edited by: Mal09 on 04/07/10 05:42:05 GMT
            1 of 1 people found this helpful
            • 3. Re: can I disable the 60M gem file archive that is sent every 35 days

              As far I know if you use only V2 you could use "V2 only" Repos:

               

              McAfeeFtp FTP ftp.nai.com/commonupdater2/
              McAfeeHttp HTTP update.nai.com/Products/CommonUpdater2

              1 of 1 people found this helpful
              • 4. Re: can I disable the 60M gem file archive that is sent every 35 days

                I use Robocopy to copy over everything with <AV Repo Location>\Current\VSCANDAT1000\, but exclude *.zip files.  Also copy over the three files from the root of the repo (replica.log (probably not really needed but gets done anyway), catalog.z and sitestat.xml).  This will mean anything that's within ~30 days out will update with the daily updates, however, anything older than this will look for the avvdat-60xx.zip file and will fail because it's not present so I copy these over on a monthly basis.

                 

                Daily: Copy contents of VSCANDAT1000 including subdirs but excluding all .zip files, copy those three files from the root of the repo.

                Monthly: Copy all contents of VSCANDAT1000 with no exclusions and those three files again.

                 

                I'm doing this on 5 (soon to be 8) satellite links to ships and it's working nicely   We pay a flat monthly fee for unlimited bandwidth.  If you pay per MB it might be wise to not do the monthly one unless you really have to.

                 

                 

                Message was edited by: LawrenceH on 15/07/10 07:42:18 CDT
                1 of 1 people found this helpful
                • 5. Re: can I disable the 60M gem file archive that is sent every 35 days

                  Lawrence, thank you very much for the info, it is directly related to my satellite application on ships.  We have to pay if we exceed our flat rate of satellite time allocated. Therefore, can you plse tell me what problems I may encounter if if do not copy all contents of VSCANDATA1000 once a month?

                  Is there a chance that I might be missing some updates?

                  Have you done any bandwidth monitoring to see how much bandwidth the daily and monthly updates use?  This will give me an idea about how much I will have to pay the satellite provider to do the AV updates over satellite.

                  I really would appreciate your input.

                  Regards

                  Russ

                  • 6. Re: can I disable the 60M gem file archive that is sent every 35 days

                    No problem.

                     

                    Looking at my repository at the moment, the oldest daily update I have is 60086009avv.gem.  If any PC has DATS 6007 or older it's not going to be able to update with the dailys and is going to look for the current 60mb zip file... since this is missing it's going to fail.  This is the case if you deploy VScan to a new PC for example - if you do this you'd have to push the zip file over also.  As for bandwidth, I'd imagine you're looking at about 5-500kb depending on the size of the GEM file.

                     

                    I've attached my Robocopy jobs, this will apply for one vessel but you'll have to change the source/destination (just open it in notepad) to suit your environment.  I run a batch file as a scheduled task to do the daily dats, then the catalog files for a daily update, or full dats and then catalog files for a full dat update.  The full update will also delete the old .gem files that aren't needed any more.

                     

                    I'm sure there's a better way of doing this but it's working ok for me, if you think of a better way let me know