Well for one, if you had 20k GUPS that sure makes for an awful lot of bandwidth consumption.

Each GUP needs to download the updates to hand out to the other clients. If a client downloads a full update package (100-120mb) and thats for 20k machines, that will cause alot of congestion. Your looking at 2Tb downloaded per day! I don't see any reason why you want to do this. For me personally, I would only have 2 machines set as a GUP at each location. I have 10k machines and only 62 GUPs and everything runs smoothly.

Maybe, a better query would be:

If you have 20 (e.g.) clients and assign them all as GUPs, would they get updates from each other aside from the server or would they all download from the server? Is it possible for a GUP to get updates from another GUP?

Hello,

Multiple Group Update Provider

Multiple Group Update Providers use a set of rules, or criteria, to elect themselves to serve groups of clients across subnets. To configure multiple Group Update Providers, you specify the criteria that client computers must meet to qualify as a Group Update Provider. If a client computer meets the criteria, the Symantec Endpoint Protection Manager adds the client to its list of Group Update Providers. Symantec Endpoint Protection Manager then makes the list available to all the clients in your network. Clients check the list and choose the Group Update Provider that is located in their subnet. You can also configure a single, dedicated Group Update Provider to distribute content to clients when the local Group Update Provider is not available. You use a LiveUpdate Settings Policy to configure the type of Group Update Provider. The type you configure depends on how your network is set up and whether or not your network includes legacy clients.

In other words, here are the steps we should take to confugre Group Update Providers:

1. We define the conditions for a computer to be a GUP
2. All the computers that fulfill that requirement, will report to SEPM that I can be a GUP
3. SEPM will populate a list of all the GUPs
4. When a client that is supposed to get updates from GUP, it will receive the list of GUPs from SEPM and choose the appropriate based on subnet
5. If GUP is unavailable, client can optionally speak to SEPM and get definitions 

   Clients will receive list of GUPs is populated in a file called as globallist.xml.

If every client is a GUP, then they all will be first reporting to SEPM for updates.

It is more like you are stating SEP clients to report to SEPM first. (This situation is more like not assigning GUP at all.)

Again, by doing this the port 2967 will get a major conjestion. 

Why would somebody do that, when it is more easier to configure Liveupdate to look for updates at a particular time. You can also provide the user the power to Launch LiveUpdate. 

Again, How would you add 20k to the GUP list?

I would recommend you to Check the Following:

https://www-secure.symantec.com/connect/articles/configuring-group-update-providers-symantec-endpoint-protection-110-ru5

> 3. What about the gup global list, does this get sent to every client and how big will this become?

Do be careful in very large organizations.  The current release of SEP can handle a GUP list of several thousand hosts, but versions prior to RU6 MP2 can only process lists of a certain size. For more infromation, please see What is the maximum number of Group Update Providers which can function in a network? (http://www.symantec.com/docs/TECH138695)

Thanks and best regards,

Mick

How do we add clinets form different networks into our SEP Manager?

Hello Conlin,

Are you talking about the deployment to different subnets or location?

In that case there is a tool called Push Deployment wizard which will be available in downloaded software as "Non-supported tools" I believe. You can transfer that tool to a different site along with the package to any of the remote client & start your deployment process. This will reduce the bandwidth consumption.

With regards to GUP probably you can opt for a failover configuration with mutiple SEPM.