Video Screencast Help

Bandwidth issue, clients pulling large amounts of data for updates

Created: 08 Mar 2013 • Updated: 12 Mar 2013 | 24 comments
This issue has been solved. See solution.

We have a site that has been having consistent bandwidth issues, and we want to make sure Symantec is not part of it. The problem though is we still see users pulling 400mb from the Symantec website to obtain updates. Is this necessary? There is a GUP onsite, which is where the clients should be getting the updates from. What can I do to reduces the bandwidth and make sure clients are updating quickly and correctly from the correct source?

Thank you

Operating Systems:

Comments 24 CommentsJump to latest comment

_Brian's picture

400mb is pretty large, a full def size is around 150mb if that. Did you verify client is pulling updates from GUP?

On that client, if you check the System log, it should show if it ispulling from GUP with an entry that says "Downloaded content from GUP"

Check for that entry

You can also enable sylink logging to show where it is pulling updates from

How to confirm if SEP Clients are receiving LiveUpdate content from Group Update Providers (GUPs)

Article:TECH97190  |  Created: 2009-01-03  |  Updated: 2011-08-16  |  Article URL http://www.symantec.com/docs/TECH97190

 

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

SOLUTION
Bryan S's picture

I did verify that they are pulling from the GUP, but sometimes they bypass it, seems.

_Brian's picture

In that policy, set the option to "Never" for the option regarding bypassing the GUP. Also, do you have LiveUpdate Scheduling enabled in the policy?

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

Bryan S's picture

Here is what I have
In the Server settings
"User the default management server" is checked.

So is "Use a LiveUpdate Server"
The Radio button is selected on "Use the default Symantec LiveUpdate Server"

Use a group update provider is checked

Enable third party content is NOT checked

Under the GUP Button the ONLY thing selected is "Single Group Update Provider IP address or host name. The server is in the white field.

"never" is seleceted.

 

_Brian's picture

In the policy, on the Schedule tab, is "Enable LiveUpdate Scheduling" checked and is a schedule set?

This means the client would go out to LiveUpdate

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

Bryan S's picture

This lead me in the right direction to confirm clients that SHOULD report to the GUP DO report to it.

SMLatCST's picture

Have you checked if these clients have corrupt defs?  That's usually the cause for clients to repeatedly download the full defs file.

Also, can you confirm that you have a sufficient number of defs retained by your SEPM to avoid endpoints unnecessarily grabbing the full defs?

Bryan S's picture

All machines with the exception of one have current definitions. I will put this to the test on that PC. This site is the SAME site that I am having rollback issues on.

Mithun Sanghavi's picture

Hello,

Check this Article:

How to Troubleshoot High Bandwidth usage issues in Symantec Endpoint Protection

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

Hope that helps!!

Mithun Sanghavi
Senior Consultant
MIM | MCSA | MCTS | STS | SSE | SSE+ | ITIL v3

Don't forget to mark your thread as 'SOLVED' with the answer that best helped you.

_Brian's picture

Clear out the defs:

How to clear out definitions for a Symantec Endpoint Protection 12.1 client manually

Article:HOWTO59193  |  Created: 2011-09-08  |  Updated: 2012-09-25  |  Article URL http://www.symantec.com/docs/HOWTO59193

 

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

Bryan S's picture

All machines with the exception of one have current definitions. I will put this to the test on that PC. This site is the SAME site that I am having rollback issues on.

SMLatCST's picture

My second comment was with regards to the "Number of content revisions to keep:" option found under ADMIN -> Servers -> Local Site Properties -> LiveUpdate tab.

An especially low number would mean clients are less likely to receive delta definition updates (~200kb) and more likely to grab the full fat defs (~200mb), which is why I mention it.

Diane Marie's picture

We came across the same scenario, in a 7 site 2000+ workstation environment there were about 50 misbehaving PCs that would repeatedly try and pull almost 800MB a day from the parent bypassing the local GUPs, 90% of teh workstations were properly operating.

We found an old reference to GUPs and differening subnets, the Symantec tech I talked to insisted that the subnets were not an issue, but we kept seeing results that disproved it as an issue, and our answer was local LU servers in the sites, this resolved it 100%.

We found that some were corrupt defs, some had full C: drives and unable to decompress the defs, and then others were just a mystery.

I know it's not the approved method, but it worked for us.

cus000's picture

If i remember correctly there was a bug where clients bypass GUP and take defs from main SEPM...

not sure if it has been 100% fixed but it sounds matched your situation...

kavin's picture

If you have enough space on the SEPM server then increase the number of contents from 3 to may be 15 - 20 depending on the space you have on the SEPM server.

also can you please collect the sylink logs of around 500KB from the misbehaving client and add it to the thread it would help us to understand if the client is actually bypasssing the GUP or not. also the number of unused contents kept on the GUP increase that aswell.

 

Bryan S's picture

Why do I want to do that? What will it do and are there any cons to doing so?

John Cooperfield's picture

Content revs:

1. When you have 3 content revs in the SEPM, the SEPM can only provide microdefs for clients having one of the three most recent AV def releases. For a client that check in with a def that is fours revs back it will have to get a FULL def not a microdef.

 

2.  At first, increase to six defs. After three releases, measure how much more space you have used on the SEPM.  That will give you guidance on how much further you can increase defs with the SEPM space you have.

3. There is a point of diminishing return, and that is reach when the microdef is just as big as a full defs. Having more content revs than that is a complete waste of resources and gets you no advantage.   I did some research on this and the point was reached somewhere below thirty content revs. Offhand I do not recall exactly.

 

 

 

Bryan S's picture

We have found serveral Virtual OS installations which were pulling data. They have been decomissioned.