Showing results for 
Search instead for 
Did you mean: 

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

6 Replies
Level 21
Report Inappropriate Content
Message 2 of 7

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

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

Level 12
Report Inappropriate Content
Message 3 of 7

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
Level 7
Report Inappropriate Content
Message 4 of 7

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
McAfeeHttp HTTP

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

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.



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