Endpoint Protection

Did anyone else see a crazy huge spike in LiveUpdate traffic this morning?  For some reason we used a crazy amount of bandwidth this morning and I can't figure out what happened.  Nothing has changed that I'm aware of.  Thanks.

Can't say I noticed anything this morning, but I've seen Client locations have spikes in bandwidth when pointing to Oustide Live Update servers, I would point your clients to your SEPM or Live Update Server.

Yeah OK.  Thanks for your input.  It was really strange...I haven't been able to figure out what it was.  We do know for sure though that it was coming directly from the SEPM...whatever it was.

Delifeath,

If the bandwidth was on your due to your SEPM and becomes more fequent you should look at Live update servers or SEPM servers at each physical site location to reduce the bandwidth usage.

Also on a side note, you could check the update logs on the clients to see if they pulled an update around the time of the high bandwidth utilization, if not it could be something else like a the clients pulling down a new client installation package... or something else...

Actually using GUP's would reduce the bandwidth too.  GUP's are easy to implement.

There'something wrong.  It happened again this morning btw.  It's not like it's slowly ramped up at these locations over time.  Every day for years things have been normal and just in the last 2 days when LiveUpdate kicks off and goes to send the new defs it sends at least 10 times more than it ever has before.  I did just come across this other post which is very similar.  My issue is very similar but for me it's affecting most clients (not just 1 group).  If corrupted defs is my problem does it make sense that it would be the defs on the SEPM even though clients are successfully up-to-date and the SEPM is showing a LiveUpdate Success?

http://www.symantec.com/connect/forums/client-sepm-clogging-network-traffic

Also this in the release notes for the newest MP.

I have a case open with Symantec, but so far they aren't sure what's happening.  They haven't even mentioned this fix posted above...  Thanks for any input.

Have you tried clearing out the Defs to see if it is corrupted defs (on small set of clients obviously)?

Also have you recently pushed an updated install package to your clients?  Looks like one suggestion in that post was that it could be a failed update of the client.

Lastly just out of curiousity are all your clients going to your SEPM for defs right now?  or do you have a Live update server or GUP in place?

On a side note... too bad he doesn't have a resolution to his issue.

I have not tried clearing out the defs on any clients because I'm not sure how I can pinpoint which one's may be corrupt...I'm also not sure how I'd know if it was effective.  Do you think it could be a mass client def corruption?

No I haven't pushed any install packages out anytime recently.  No changes to the system really in any way except for upgrading to RU6 a few months ago.

Almost all clients (this definitely includes some of the problem sites) come back to the SEPM for updates.  Thanks.

Has support mentioned anything about definition corruption?

No they haven't...they just wanted to see logs from the support tool and then changed their mind when they saw that fix in the release notes.  Does it sound like def corruption to you?  Server or clients side?  Would it be eventually successfully updating the clients if it was corrupted on the server?

Well the only way a definition corruption would make sense to me is if it was on the server side, however, I don't think the clients would ever be successful if the definitions on the server were corrupted...

What does your System log look like on one of the "troubled" clients?

The "troubled" clients all appear to be up-to-date and the logs don't show anything out of the ordinary.

Are the logs showing any failed updates? or any updates at all during the bandwidth spikes?  That would narrow it down to Definition updates or something else it's pulling from the SEPM Server.