Hi,

 

this is our (current) setup:

One server is configured as Symantec Endpoint Protection Manager, and this server downloads virus definition updates through the default Symantec LiveUpdate server.

As we have quite some remote sites with 'low speed wan connections', we use Group Update Providers on each remote site to deploy locally virus definitions updates.

So far, so good but users of older client computers complain about the impact of virus definition updates on their computer. This is generating quite some IOPS, and the reaction time on the computer is significantly increasing while virus definition updates are installed.

My idea to solve this problem was to install virus definition updates while users have their break at noon.

 

My question:

Is there a possibility to configure when clients pull to the GUP for virus definition updates or should I setup an internal live update server at each remote site to be able to configure the time that clients pull the GUP ?

 

Thanks for your feedback!

 

Gijs.

 

What is the configuration you have done for the GUP?

You can be configure the multiple gup for the site.

Configuring the Group Update Provider (GUP) in Symantec Endpoint Protection 11.0 RU5 and later

Article:TECH96419

|

Created: 2009-01-28

|

Updated: 2012-04-23

|

Article URL http://www.symantec.com/docs/TECH96419

How many client not be update? 

GUPs cannot be scheduled to retrieve updates at a specific time.Scheduling option is only possible on connections to Liveupdate internet servers

Schedule SEP GUP to get update at specific time

https://www-secure.symantec.com/connect/ideas/schedule-sep-gup-get-update-specific-time

Group Update Provider cannot be scheduled via Symantec Endpoint Protection Client's LiveUpdate policy

 

Article:TECH131336

|

Created: 2010-01-30

|

Updated: 2011-10-12

|

Article URL http://www.symantec.com/docs/TECH131336

Thumbs Up to the above 

As James has mentioned, there is no option to schedule the updates via GUP (short of only switching hte GUP on during lunchtime, and even then it's varied by the heartbeat and radomisation window).  The only scheduled update option is using LiveUpdate, in which case you're looking at using the LUA and local Distribution Centres in each site.

Before you get that far though (as it would mean reduced protection from only updating once a day), have you ensured all "Active scan on definition update" and "Rescan file cache on definition update" options have been disabled?  Both are known to cause alot of disk I/O because they effectively kick off another scan when new defs are downloaded.

More info here:

http://www.symantec.com/docs/TECH191600
http://www.symantec.com/docs/TECH106098

Hi,

 

the GUP configuration works as it should.

The GUP downloads its virus definition updates at random time from the symantec enpoint protection manager. When I check this file:

D:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\data\outbox\agent\gup\globallist.xml

=> the group update providers configured appear in this list as expected.

The only problem / question is when the clients within the remote sites (all clients except the GUP) pull the definition updates from the GUP. Now this is at random and I would like to schedule this at a specific time during the lunch (so that definition updates are no longer installed during working hours).

 

As I understand setting up a live update server (especially when I have to configure this for each remote site) is not something what is done in 5 minutes and quite complex...

It can be pretty drawn out, as you'll have to setup a machine on each remote office as a Distribution Centre, and configure the LUA to push content to each of these.

You'll need to consider WAN bandwidth as well as scheduling as the content pushed by the LUA is faaaaaar larger than that used by the normal SEPM/GUP update process (which usually uses delta files).

This is why I pointed you at the articles above, as these may negate the requirement for scheduling.

Hi,

 

thanks for the feedback (I didn't expected all this feedback this fast!)

 

Both options ('active scan on definition update' and 'rescan file cache on definition update') are unchecked.

This is the reason I think I have only one option left and this is configuring the time when clients get their update...

 

Regards,

 

Gijs.

In that case it really does sound as if you're stuck with the LU option 

What version of SEP are the clients on?  Later versions include some performance enhancements and whatnot.

If you are bound for the LU option however, then i'd recommend the below articles:

http://www.symantec.com/docs/HOWTO41810
https://www-secure.symantec.com/connect/articles/helpful-liveupdate-administrator-2x-analogy
https://www-secure.symantec.com/connect/articles/managing-liveupdate-administrator-2x-space-usage
http://www.symantec.com/docs/TECH132545

Hello,

 

Clients run on client version 12.1.4013.4013.

More recent versions include performance enhancements?

 

I'm currently monitoring the I/O with Process Explorer from Sysinternals to see if there is really a significant IO increase during definitions update but I'm almost sure this is the cause...

 

if you see any other possibilities...

Yeah, I meant over the old days of v11.

Have you checked if the affected clients are nabbing the full defs or the deltas?  Does this affect all clients? Perhaps check for heavy disk fragmentation?

Simply not possible to schedule updates from GUPs but the info provided by SMLatCST should get you what you need. -br

hmm, disk fragmentation could be a cause. I'll check it once.

 

About the full defs or the deltas, good question. => how can I find out this?

You can see from the system log of the client under View Logs -> Client Management -> System Logs or on the SEPM itself under Monitors -> Logs -> System Logs -> Client Activity.

Essentially, if you see them pulling down "xdeltaYYMMDDRRR.dax" files then they're using delta files, if you see the "full.zip" file being pulled down then it's using the full fat defs.  AFAIK, there's more processing involved in using the full defs as the client must download a larger file, extract it, and pull it into it's own local repository.

Hi,

 

I went through the client activity log of some computers and I see it's a bit of a mix.

Sometimes the defs are a delta.dax (as you mentioned) and sometimes its a full.zip.

If you want, I can send you an extract of such a log (private message). Should I send it once?

Is this a logical behaviour?

 

regards,

 

Gijs.

Set BITS throttling .. You can use GPO for that

It is perfectly natural for a client to request a full def file if they are so far out of date that the SEPM cannot create a delta for it.

The below article explains it fairly well, and contains links to further reading that deals with how many definitions the SEPM retains (which directly affects its ability to create delta files):

http://www.symantec.com/docs/TECH131528

Feel free to PM me with the logs, but I tend to respond on the forums in order to improve the distribution of knowledge.

Cebeo,

One thing that is not always mentioned when the "oh you need to use a LUA if you want to schedule" suggestion is made, is that LUAs "incrementals", and I use that term loosely, are much larger than the deltas a SEPM can provide to either the SEP Agent directly, or via a GUP.

Some background can be found here:
http://www.symantec.com/docs/TECH198160
and
https://www-secure.symantec.com/connect/articles/how-big-are-current-symantec-endpoint-protection-definitions

Continually we come back to the same root issue, and that is that until Symantec address the size of their definition files that exist on a SEP Agent, and also unify them, they can only do so little to try lessen the storage & bandwidth impact that their large files are so notorious for. This isn't a knock, just simple fact.

In reference to "unify" you have one set for x86, for x64, for Mac, for Linux, for SPE, for SMSME, etc etc, as well as other fragmentations like 11, 12.1 RTM, 12.1 RU2, 12.1 RU4, etc

The other major vendors (for the most part) use the SAME definition files for ALL the products that use their 'traditional AV" file-based protection engine. One is hopeful significant work in this area would be on the roadmap in the coming years, as this kind of work does indeed take years.

Hi,

 

thanks everyone for the feedback.

 

I'll try to defrag the client computers where the users complain about the impact of the defs update.

 

If I read the tech articles and all the feedback, LUA could be a solution but then other problems could occur (a lot of management to do, disk space, bandwith, ...)

 

GUP is a very good solution in our setup, the only big disadvantage is that there are no scheduling options...

 

Regards,

 

Gijs.

The reason GUPs cannot have scheduling implemented is because of the fact GUPs cannot be synced, i.e. it pulls files from the SEPM as Agents request it of them.

Why is there no sync? Back to previous arguments, Symantec's updates are too big, and so this is the middle ground they've decided upon. Vicious cycle. :(

If only they could reduce the overall size of their definitions, they're product could be re-designed to be so much more powerful and flexible when it comes to their content updating architecture.