Endpoint Protection

We use SEP 12.1 and want to use some servers as GUPs to service our desktop fleet. We use AD import to mirror the sturcture in SEP and the servers are in a different OU.

Firstly,

1. Presumably you cannot just specify any old client as a GUP in policy if the policy doesn't also apply to the group the GUP is in, correct? i.e., if you want a machine to be a GUP, you need to apply the liveupdate policy to it that specifies it as a GUP
2. The machine we want as a GUP is in a different SEP group than the machines we want it to service as a GUP. Is this possible?
3. We currently use a Liveupdate server rather than SEPM to distribute defs. We need to enable 'use default management server' when using GUPs. Does this mean the GUPs will only ever get the defs from SEPM now and if we apply this policy to clients will they then also get policies from the GUP, SEPM or the LU server? Is there a priority?
4. Additionally, all the GUPs are in one group but are on different subnets. Is it better to allow SEP to work out which GUP to use and assign them all to the top level of our workstation group or only assign one to each group based on subnet. e.g., Our OU structure is based on location and thus we could assign the GUP in the location's subnet to that group.

cheers

My experience is mostly SEP 11, with a little SEP 12.1

1. The GUP must have the same Liveupdate policy as the clients it serves.

2. The GUP can be in a different Group, providing it uses the same Liveupdate policy as its clients (as 1. above). eg, we successfully use servers (in a Servers Group) as GUPs, while the desktops, laptops and workstations which use the GUP are in a different group with its own firewall and AV policies, but a shared Liveupdate policy

3. We used to use Liveupdate servers with early SEP 11 clients before the GUP was scaled to our needs, but we have now moved completely to GUPs, serving groups in some instances of 3000+ clients. I think if the policy states "use default management server" and "use Liveupdate server", it will use the management server on its heartbeat, and the Liveupdate on a schedule. (we use only the management server so I have not fully investigated). We have "do not allow clients to bypass GUP", so only the GUP talks to the management server, and all clients go to the GUP.

Additionally to SMLatCST's post (thumb up), have a look at this document:

Understanding and Identifying the different Group Update Provider (GUP) Options in SEP 11.0.5 RU5 and Later

http://www.symantec.com/docs/TECH139867

Don't read over this important paragraph:

However, there are two situations where a GUP in a different subnet may be contacted:

• If you have configured a "Backup" Group Update Provider on a different subnet (if Group Update Providers on the local subnet are unavailable). 
• If you have configured a GUP from a different Subnet as a Single Group Update Provider.

The GUP whitepaper is also a good reference.

1. You have it correct, GUPs need to know they're GUPs, other clients need to know what GUPs to use.  As long as the policies assigned cover both criteria, the policies don't need to be the same (i.e. I have LU policy 1 assigned to a GUP defining the GUP as a 'Single GUP', and LU Policy 2 assigned to other SEP Clients, defining the GUP in the 'Multiple GUP List', and the other SEP Clients will successfully use the GUP for content updates).
2. Different groups and different policies are fine, as long as the GUP knows its a GUP, and the other SEP Clients know what GUP to use.
3. Policies are obtained from the SEPM no where else.  The GUPs and LU provide content only (definitions) and there is no priority; it's all down to the scheduling (SEP Communications heartbeat for updating via SEPM&GUP, LU Schedule for updating via LU).  Which one you get updates from depends on which schedule hits first (unless you enable the LU Skipping options in SEP12.1).
4. Which method you use will depend more on where the GUPs are in relation to the SEP Clients, than where they reside in your SEPM Console.  If the GUPs are in the same subnets as the SEP Clients, then it would be far easier to use the "Multiple GUP" option and let the SEP Clients automatically pick the GUP that is closest.

• Presumably you cannot just specify any old client as a GUP in policy if the policy doesn't also apply to the group the GUP is in, correct? i.e., if you want a machine to be a GUP, you need to apply the liveupdate policy to it that specifies it as a GUP

Yes, absolutely you are correct with the GUP concept.

• The machine we want as a GUP is in a different SEP group than the machines we want it to service as a GUP. Is this possible?

*Create a sub group in the servers and move the GUP server to that sub group

* Uncheck inherit policy on that sub group

* Create a liveupdate policy configure the GUP and assig the policy to the subgroup and the  workstation group.

* Now both the GUP and the client have the same policy then it can provide the updates to the clients

• We currently use a Liveupdate server rather than SEPM to distribute defs. We need to enable 'use default management server' when using GUPs. Does this mean the GUPs will only ever get the defs from SEPM now and if we apply this policy to clients will they then also get policies from the GUP, SEPM or the LU server? Is there a priority?

* Yes GUP's will receive the updates only through the SEPM server not from anyother LU source

* If you assign the policy to the clients 1st source will be GUP, 2nd is SEPM if GUP is not available or busy.

• Additionally, all the GUPs are in one group but are on different subnets. Is it better to allow SEP to work out which GUP to use and assign them all to the top level of our workstation group or only assign one to each group based on subnet. e.g., Our OU structure is based on location and thus we could assign the GUP in the location's subnet to that group.

* you can create sub groups for each GUP and create separate LU policy and configure the GUP and assign the policy to the clients and GUP groups that the best way.