Video Screencast Help
Protect Your POS Environment Against Retail Data Breaches. Learn More.

SEPM suddenly starts spewing data to ALL clients

Created: 25 Jan 2013 • Updated: 25 Jan 2013 | 9 comments
This issue has been solved. See solution.

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

Comments 9 CommentsJump to latest comment

.Brian's picture

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

 

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.

consoleadmin's picture

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

How to: Setup a Group Update Provider (GUP)
http://www.symantec.com/business/support/index?pag...

Guide to create the GUP for remote location
https://www-secure.symantec.com/connect/downloads/...

Video’s created on Group Update Provider on the Symantec Connect website.
https://www-secure.symantec.com/connect/videos/gro...
https://www-secure.symantec.com/connect/videos/gro...

Thanks.

Dragonspeed's picture

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

SebastianZ's picture

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.

SOLUTION
Dragonspeed's picture

Sebastian,

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

consoleadmin's picture

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.
 

Thanks.

SebastianZ's picture

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.
.Brian's picture

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

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.

Dragonspeed's picture

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 :)