Endpoint Protection

 View Only
Expand all | Collapse all

Bandwidth issue, clients pulling large amounts of data for updates

pete

peteMar 08, 2013 09:16 AM

Migration User

Migration UserMar 08, 2013 09:22 AM

Migration User

Migration UserMar 08, 2013 10:54 AM

Migration User

Migration UserMar 08, 2013 11:07 AM

Migration User

Migration UserMar 11, 2013 04:01 PM

  • 1.  Bandwidth issue, clients pulling large amounts of data for updates

    Posted Mar 08, 2013 09:08 AM

    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



  • 2.  RE: Bandwidth issue, clients pulling large amounts of data for updates
    Best Answer

    Posted Mar 08, 2013 09:11 AM

    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

     



  • 3.  RE: Bandwidth issue, clients pulling large amounts of data for updates

    Posted Mar 08, 2013 09:14 AM

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



  • 4.  RE: Bandwidth issue, clients pulling large amounts of data for updates

    Posted Mar 08, 2013 09:16 AM

    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?



  • 5.  RE: Bandwidth issue, clients pulling large amounts of data for updates

    Broadcom Employee
    Posted Mar 08, 2013 09:16 AM

    do you have policy to bypass GUP?



  • 6.  RE: Bandwidth issue, clients pulling large amounts of data for updates

    Posted Mar 08, 2013 09:17 AM

    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?



  • 7.  RE: Bandwidth issue, clients pulling large amounts of data for updates

    Trusted Advisor
    Posted Mar 08, 2013 09:19 AM

    Hello,

    Check this Article:

    How to Troubleshoot High Bandwidth usage issues in Symantec Endpoint Protection

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

    Hope that helps!!



  • 8.  RE: Bandwidth issue, clients pulling large amounts of data for updates

    Posted Mar 08, 2013 09:22 AM

    No



  • 9.  RE: Bandwidth issue, clients pulling large amounts of data for updates

    Posted Mar 08, 2013 09:28 AM

    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

     



  • 10.  RE: Bandwidth issue, clients pulling large amounts of data for updates

    Posted Mar 08, 2013 09:29 AM

    I do not understand what you mean in the 2nd sentence.



  • 11.  RE: Bandwidth issue, clients pulling large amounts of data for updates

    Posted Mar 08, 2013 09:35 AM

    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.

     



  • 12.  RE: Bandwidth issue, clients pulling large amounts of data for updates

    Posted Mar 08, 2013 09:42 AM

    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



  • 13.  RE: Bandwidth issue, clients pulling large amounts of data for updates

    Posted Mar 08, 2013 09:43 AM

    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.



  • 14.  RE: Bandwidth issue, clients pulling large amounts of data for updates

    Posted Mar 08, 2013 09:44 AM

    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.



  • 15.  RE: Bandwidth issue, clients pulling large amounts of data for updates

    Posted Mar 08, 2013 10:02 AM

    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.



  • 16.  RE: Bandwidth issue, clients pulling large amounts of data for updates

    Posted Mar 08, 2013 10:37 AM

    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.



  • 17.  RE: Bandwidth issue, clients pulling large amounts of data for updates

    Posted Mar 08, 2013 10:54 AM

    Number of content revisions to keep is 3



  • 18.  RE: Bandwidth issue, clients pulling large amounts of data for updates

    Posted Mar 08, 2013 11:07 AM

    This option is not checked.



  • 19.  RE: Bandwidth issue, clients pulling large amounts of data for updates

    Posted Mar 11, 2013 04:50 AM

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



  • 20.  RE: Bandwidth issue, clients pulling large amounts of data for updates

    Posted Mar 11, 2013 05:45 AM

    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.

     



  • 21.  RE: Bandwidth issue, clients pulling large amounts of data for updates

    Posted Mar 11, 2013 09:10 AM

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



  • 22.  RE: Bandwidth issue, clients pulling large amounts of data for updates

    Posted Mar 11, 2013 03:23 PM

    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.

     

     

     



  • 23.  RE: Bandwidth issue, clients pulling large amounts of data for updates

    Posted Mar 11, 2013 04:01 PM

    That was an awesome explanation!

    Thank you



  • 24.  RE: Bandwidth issue, clients pulling large amounts of data for updates

    Posted Mar 12, 2013 04:42 PM

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



  • 25.  RE: Bandwidth issue, clients pulling large amounts of data for updates

    Posted Mar 12, 2013 04:50 PM

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