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:
Discussion Filed Under:
Comments 24 Comments • Jump to latest comment
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)
SEP Knowledge Base
Endpoint SWAT
I did verify that they are pulling from the GUP, but sometimes they bypass it, seems.
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?
SEP Knowledge Base
Endpoint SWAT
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.
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
SEP Knowledge Base
Endpoint SWAT
This option is not checked.
This lead me in the right direction to confirm clients that SHOULD report to the GUP DO report to it.
do you have policy to bypass GUP?
Cheers!
Pete
Help Link: http://www.symantec.com/business/support/overview.jsp?pid=54619
No
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?
http://www.cstl.com/
I do not understand what you mean in the 2nd sentence.
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.
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
Symantec Technical Support Engineer, SEP
MIM | MCSA | MCTS | STS | ITIL v3
Twitter: @mithun_sanghavi
Don't forget to mark your thread as 'SOLVED' with the answer that best helps you.<&a
Clear out the defs:
How to clear out definitions for a Symantec Endpoint Protection 12.1 client manually
SEP Knowledge Base
Endpoint SWAT
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.
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.
http://www.cstl.com/
Number of content revisions to keep is 3
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.
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...
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.
Why do I want to do that? What will it do and are there any cons to doing so?
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.
That was an awesome explanation!
Thank you
We have found serveral Virtual OS installations which were pulling data. They have been decomissioned.
Would you like to reply?
Login or Register to post your comment.