Endpoint Protection

I have an issue where SEPM is hogging up a ton of bandwidth and had to disconnect the server from the LAN.  Automatic upgrade schedules have been disabled.  GUPs are capped at 64 kbps and 5 machine max for downloading.  The moment I enable the network adapter on the server, it queues up a bunch of different machines for updates.  I'm wondering if there's a way to clear the existing queue and just have it revert back to the configured schedule.

Thanks.

From the SEPM there is no way to stop updates once the clients have received the command. I've read previously that you can make the outbox folder read-only which would stop any remaining clients.

From the sounds of your description, if the clients are connecting as soon as the SEPM is put back online, then they may be configured for PUSH mode communications, correct?

You also mentioned you're using GUPs, and that they are throttled down to 64kps and only allow 5 simultaneous connections.  Why is this?

Further to the GUP question, is the LU policy set to allow clients to bypass it in the event it's been unavailable for a while?

Your options at the moment however (as the SEPM has to be online for us to change any of the settings I've asked about above) are quite limited.  A couple of ideas spring to mind...

1. Set a FW rule for the SEPM (either via software or via a network device, how you execute it is up to you) to allow port 8014 to a subset of your clients to begin with, and block all others.  Wait until the traffic dies down, then expand the allow.
2. Get the latest defs out to your clients first using the Intelligent Updater (http://www.symantec.com/docs/TECH102606) before putting the SEPM back on the network.  This way means the clients will only need to upload their logs and won't need defs from the SEPM, but does require you to have either a small number of clients, or some way to distribute the defs without hammering your network.

There used to be a throttling option that you could set on the v11SEPM (within IIS), but that's missing now in v12.1 (for now at least).

Now, onto the reasoning behind my earlier questions:

PUSH mode communications are network intensive (each client maintains a constant connection to the SEPM and retries the connection every 5mins by default when disconnected).  Symantec recommends using PULL mode comms is most environments, with a heartbeat of at least 30mins (http://www.symantec.com/docs/TECH92051).

On the GUP side, it is possible to configure the clients to never bypass the GUPs, and therefore never grab defs straight from the SEPM.  This could help minimise network load.

Also, lowering the number of connections to the GUP means fewer clients can update at the same time from the GUP.  Assuming the GUP is on the same subnet as the clients its updating (and is communicating with them at LAN speeds), this provides no network benefit.  Increasing the number does not increase the bandwidth between the GUP and the SEPM.  The amount downloaded by the GUP will remain the same regardless of how many clients its updating at once.

I'm not sure if creating a firewall rule to block 8014 will work? Seems to be something hard-coded in SEP to always allow 8014, unless of course you se Windows or some other firewall.

Makes sense I suppose since you block all comms but have you gotten this to work?

Yeah, the smc process on the client side can always get out.  Blocking inbound port 8014 on the SEPM itself work fine though (I've done this in the past).  So if working with the SEP FW, this "block 8014" rule should only be applied to the SEPM, nothing else.

But as I mentioned, the execution method is up to the OP (it's only meant to be temporary in order to get everything up and running again so that Best Practice settings can be applied instead to get the network usage to a more manageable level).

Gotcha, good to know, thanks!