Endpoint Protection

For no reason this morning, SEPM started spewing GB's of data out to all our clients.  This caused a BRUTAL saturation of all our links.  This isn't the first time it has done it, and it probably won't be the last... it would be nice to know what causes this.

Has anyone else had this experience? 

12.1.2015.2015

Were content updates being pushed out? For that much data, thats about all it could be...

Are you using GUPs?

How are clients configured to get updates?

Using Group Update Providers to distribute content to clients

Article:HOWTO80959

|

Created: 2012-10-24

|

Updated: 2013-01-25

|

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

Configuring Group Update Providers

Article:HOWTO80900

|

Created: 2012-10-24

|

Updated: 2013-01-25

|

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

 

Yes, we're using GUP's. Yes, it was likely content, but we do content 4x /day and have no problem. At some random interval SEPM suddenly seems to decide "To Hell with differential updates and to Hell with the GUPs - you're getting it ALL from me."

Kindly confirm these all clients are on same location or it on remote location.? If it in remote location then you can create the GUP(Distribution Point) for the remote location clients Configuring the Group Update Provider (GUP) in Symantec Endpoint Protection 11.0 RU5 http://www.symantec.com/business/support/index?page=content&id=TECH96419&locale=en_US How to: Setup a Group Update Provider (GUP) http://www.symantec.com/business/support/index?page=content&id=TECH105005&locale=en_US Guide to create the GUP for remote location https://www-secure.symantec.com/connect/downloads/create-gup-symantec-can-help-conserve-bandwidth-clients-remote-location Video’s created on Group Update Provider on the Symantec Connect website. https://www-secure.symantec.com/connect/videos/group-update-providers-part-1 https://www-secure.symantec.com/connect/videos/group-update-providers-part-2

In the used liveupdate Policy do you have selected the following option?:

"Maximum time that clients try to donwload updates from a GUP before trying the default management server" - this is the only setting that ever allows clients configured to get updates from GUP to ask SEPM for it.

Sebastian, I had it set to 1 hour. I just set it to NEVER to see if it stops.

Check the GUP setting and change it never option

Maximum time that clients try to download updates from a Group Update Provider before trying the default management server

This option lets clients bypass a Group Update Provider if they try and fail to connect to the Group Update Provider. You can specify a length of time after which clients can bypass the Group Update Provider. When clients bypass the Group Update Provider, they get content updates from the default server.

Select one of the following options:
•Check Never if clients only get updates from the Group Update Provider and never from the server. For example, you might use this option if you do not want client traffic to run over a wide area connection to the server.
•Check After to specify the time after which clients must bypass the Group Update Provider. Specify the time in minutes, hours, or days.
 

That will be the setting that's triggered the problem - 1 hour is really low. Set it to never - this way you will block all possibility of traffic congestion from SEPM. It will require some more monitoring over the health of your GUP though as they will be now the olny source of updates with no backup (which was SEPM).

As per documentation:

• Check Never if clients only get updates from the Group Update Provider and never from the server. For example, you might use this option if you do not want client traffic to run over a wide area connection to the server.

How long has it been set to 1hr? Since you created the policy?

As already mentioned, that should be the fix setting it to Never

Yeah, it's been at 1 hour since GUP's were inventend :)

I also just implemented QoS at the server level (which works really well at limiting the existing bandwidth until the policy is picked up) and have sort of QoS'ed myself out of bandwdith.... 

Nothing like a bit of fun on a Friday :)