Video Screencast Help

Explicit GUP and groups

Created: 01 Jul 2013 • Updated: 03 Jul 2013 | 26 comments
This issue has been solved. See solution.


I know that with 12.1.1, GUP machine must be in the same group as GUP clients (Single GUP).

Now with 12.1.2 I though Explicit GUP permited to bypass this.. I mean having a server in a Server group that I want to be explicit GUP & GUP client in a Workstation group (on diferente subnets, different from the GUP server). So I created a LU policy with explicit GUP IP ans subnets of clients and set this policy to the Clients group (not the server) => clients of the Workstation group receive the policy and updated the registry with the UseMasterClient key (not the MasterClientHost but maybe it's only when Single GUP option set, not explicit...). And My server chosen for GUP role is still not GUP (no port listening...).

=> Do I have to understand that even for Explicit GUP, GUP and clients must be in the same group ? If yes, it's difficult as servers and workstations don't have the same policies....

Any help will be appreciated.

Thansk in advance,


Operating Systems:

Comments 26 CommentsJump to latest comment

Brɨan's picture

They don't need to be in the same group.

You can configure an explicit list of Group Update Providers that clients can use to connect to Group Update Providers that are on subnets other than the client's subnet. Clients that change location frequently can then roam to the closest Group Update Provider on the list.

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.

SMLatCST's picture

Nopes, the GUP and the endpoints using those GUPs do not have to be in the same group.  The important rules about using GUPs are really:

  • GUPs must know they are GUPs
  • SEP Clients must know which GUPs to use

What this means is that the intended GUPs must be receiving a policy that tells them they are to be GUPs.  The crucial thing in case of Explicit GUPs, is that the Explicit GUP option does not enable GUP functionality (it's merely an link list of which subnets should use which GUP).  This means that the LU policy assigned to the group containing the GUPs must use either the Multiple GUP or Single GUP option.

And, obviously, the other SEP clients must receive a LU policy telling them which GUPs to use.

As long as those rules are met, you can put the clients and GUPs in whatever group you want.

Xtof's picture


If I understood, I need to set a single GUP option on the group where my GUP machine is and then another LU policy with explicit gup subnets on the group where are clients ?

Is it the reason why having only one explicit gup policy on the clients group does not update the global.xml file ? Or just because this policy is not on the group where is my desired GUP machine ?

I didn't find example of explicit GUP configuration on different groups... If someone has, I'll appreciate.

Thanks in advance,


SebastianZ's picture

Usually you assign the same LU policy to both GUP and the clients - inthe policy you specify  the single GUP (or multiple) and explicit GUP mapping to subnet of clients etc.

Xtof's picture

Thanks for this confirmation.

As it's not possible to have the same LU policy for the group of GUP clients and GUP machines, I understand that I've to set a specific configuration :

- on the GUP machine group, let the LU policy with SEPM connection + Add the signe SUP option for my desired GUP machine

- On the GUP clients group, set a LU policy with SEPM + Explicit GUP to the GUP machine for all clients subnets.

Is it the good way ?

Do the machines in the group where is the GUP machine still update theirself on the SEPM ?

It seems that when I enable GUP option in the LU policy, I need to Kepp the SEPM option as well. Why ? Isn't it possible to have clients updating only to GUP ?


SebastianZ's picture

As it's not possible to have the same LU policy for the group of GUP clients and GUP machines

- why not? that's the whole point of it

On the GUP machine group, let the LU policy with SEPM connection + Add the signe GUP option for my desired GUP machine

- you dont need to do that - GUP by itself knows to get the updates from SEPM (as a matter of fact that is only possible option), it does not need extra policy to tell him that

It seems that when I enable GUP option in the LU policy, I need to Kepp the SEPM option as well.

- you don't. You can enable only GUP updates and completely block clients from getting any content updates directly from SEPM

SMLatCST's picture

Yup, that will do the trick!

As far as your questions go:

  1. All the machines in the same group containing the GUP (and therefore receiving the same LU Policy), will try to go to the GUP for updates.  You can configure a timeout in the LU Policy so that they will go to the SEPM after a while
  2. The "Update vis default management server" option must be enabled to use GUPs, as the entire process is still managed by the SEPM.  The GUPs just cache the data, and have no real intelligence in themselves
Xtof's picture

Thanks SMLastCST. I think that's the right answer.

So If I set the LU policy with SEPM + Single GUP => the GUP will be activated and ALL servers in this group AND on the same subnet than the GUP (?) will use the GUP (excepted the GUP that will go directly on SEPM) ?

SebastianZ's picture


- on the same subnet than the GUP -> yes, if you specify it via explicit group mapping GUP to the subnet

- GUP itself will always go only to the SEPM for updates

- The SEP client on the GUP machine will take the updates from the GUP as well

SMLatCST's picture

Not quite smiley

If you assign a LU policy that enables updates via SEPM+SingleGUP to a group containing lots of clients, then only the identified single GUP will have the GUP function enabled.  Everything else in the group, will try to go to the Single GUP for updates.

If you want more than one machine to be a GUP, then you have to use the Multiple GUP option to define them as GUPs as well.

That covers off the "make sure the GUP knows it's a GUP" part.

As far as "telling other SEP Clients which GUP to use" goes, you'll still need to assign a policy to the other clients telling them which GUP to use (can be the same policy, can be a different one.  As long as it points the clients at a machine that knows it's a GUP, then you're fine).

As a last point, the SEP Client acting as GUP will actually connect to itself first on 2967, and then to the SEPM to grab it's updates (bit odd I know).

Xtof's picture

Sorry but my question was about the other clients of the same group and subnet (?) that will use the GUP for update.

So If I set the LU policy with SEPM + Single GUP => the GUP will be activated and ALL servers in this group AND on the same subnet than the GUP (?) will use the GUP (excepted the GUP that will go directly on SEPM) ?

I mean that if I have a group with 10 clients, I set a LU policy with a single GUP mapped on one ip of these 10 clients => 1/10 will be GUP. 9/10 will ask updates to the GUP if and only if in the same subnet.

Is it right ?

SMLatCST's picture

Ahhh, that's what you meant!

As far as this one group and policy goes, all 9 other clients will go to the GUP.  This is because the policy you described uses the Single GUP option, which tells clients to use the GUP regardless of subnet.

If you want the SEP clients to only use the GUP if they are in the same subnet, then you have to define the GUP using the Multiple GUP option.  It just means that you only define one GUP in there is all.


Maybe this will help.  I put together a little description of the GUP options in the below thread:

Xtof's picture


thanks for this clear explanation. I always heard that Single GUP was used for clients of the same subnet... and that backup GUP was needed to allow clients to go on a GUP from another subnet.. Strange !

But that's good for me :)

I'll test that asap now.


SebastianZ's picture

I always heard that Single GUP was used for clients of the same subnet... and that backup GUP was needed to allow clients to go on a GUP from another subnet..

It was like that before explicit GUP functionality was implemented in SEP.

Xtof's picture

Update : I think the possibility to have a single GUP for different subnets was a new feature of the 12.1.2... That may explain why I had an opposite answer from the support.

SebastianZ's picture

That's correct - this came with 12.1 RU2:

Understanding "Explicit Group Update Providers (GUPs) for Roaming Clients" in Symantec Endpoint Protection (SEP) 12.1.2

Article:TECH198640  |  Created: 2012-10-19  |  Updated: 2012-11-15  |  Article URL

SEP 12.1.2 includes a new "Explicit Group Update Providers (GUPs) for Roaming Clients" feature.

Xtof's picture

Ok we agree :)

I read on your other post :

The logic being that a SEP Client will look for a GUP in the local subnet first, if none found then look to see if it is in a subnet assigned with an explicit GUP, if none found then use the single/backup GUP, if none found then use the SEPM.

=> That means that if I have a Single GUP on a group that matches for a GUP machine + same LU policy with signe gup on clients groups with different subnets inside, I don't need to use explicit GUP because clients will be able to use GUP from other subnet ?

Also, does that mean that If I have another single GUP on antoer subnet my clients will contact him maybe (because of the 2 gups in the globalist.xml) ? Or will they only use the one set in the local LU and don't check other gUP from the globallist.xml file ?


SMLatCST's picture

Yeah, if you're using Single GUPs only in your LU policies, then they ignore subnets entirely and you don't have to go messing with Explicit GUPs.

A SEP Client will only use the Single GUP specified by the LU policy it is currently receiving.

By the by, historically, the Single GUP option has always crossed subnet boundaries (see below article):

Xtof's picture


last message I received from Symantec suport is : "Document on our site is wrong : Single GUP delivers only for clients of the same subnet !". It was for version 12.1.1... That's why I didn't understand.

Now that 12.1.2 is officialy discribed as Single GUP = OK for all subnets.

Thanks to your explanation, I understand that I definitively don't need Explicit GUP as all clients of the group A must use a specific GUP machine of another subnet => As the Signle GUP is ok for multi-subnet + as LU policy on lcients specify the GUP machine => clients of all these subnets will contact the GUP and only this one.


SMLatCST's picture

Ahh, thanks for the clarification.

I'd personally be a little concerned by that response.  The Single GUP has always functioned this way, ever since it was introduced as the only GUP option back in the earlier SEP11 versions.  If the support guy is correct, then there was a huge bug in 12.1.1 that went completely undocumented and unnoticed by anyone around the world wink.  As long as it's working correctly now though, I suppose it doesn't really matter.

And yes, if everything in the group is going to be pointed at the same GUP anyway, then it's Single GUPs all the way yes

Xtof's picture

Perfect !

And I confirm that Symantec said the opposite regarding crossing subnets for Single GUP :-)

But now it's really clear !

Thanks again.

Xtof's picture

I just read this in "SEP 12.1 RU2 And Explicit Group Update Providers" :

Then it's important to know how clients decides to download contents from GUP or not

1) SEPM will generate the globalIndex.xml and globallist.xml periodically from the information clients posted.
2) Client checks whether GUP is configured by LU policy;
3) Client downloads the globalIndex from SEPM. Based on the checksum of globallist.xml included in it, client determines whether SEPM has updated globallist.xml;
4) If SEPM publishes a new globallist file, client downloads it and reset the active GUP list in local memory.
5) Client filters out the addresses of the different subnet in globallist.xml;
6) Client tries to connect the remained addresses one by one until finds an available GUP, it iterates in the order of the addresses in globallist.
7) If none of the GUPs in globallist can be used, try the pre-defined GUP in LU policy.
8) If pre-defined GUP is unavailable either, to determine whether to bypass to SEPM based on the "bypass" setting

=> Does it means that clients trie to contact all GUP in globallist.xml first, regardless of the LU policy of the client (event if set with Single GUP) ? If yes, I understand that clientsbypass the LU policy and can contact any GUP in any subnet ?!


SMLatCST's picture

As it states in step 5, everything in the globallist is treated as a Multiple GUP (i.e. only used if it is the same subnet), but yeah, even a client told to use a Single GUP will still look through the globallist first (lowest IP address first).  Clients in different subnets than any of the GUPs, will only go to the Single GUP defined in the LU Policy they receive.

This behaviour has been around for a while now as per the below article:

Xtof's picture

thanks again for your answer.

Sorry to insist on this topic but still lack of understanding :

- I have a group A with 'Gup clients' on subnet A. LU policy A is : Single GUP (criterias match with a GUP server on Subnet B and Group B)

- I have a group B with 'One GUP identified' on subnet B. LU policy A applyed on this group.

- I have a group C with 'Multiple GUP identified' on subnet C

- I have a group D with multiplie GUP identified' on subnet A

- I have a group E with Signle GUP identified' on subnet A

=> Globallist.xml will contain the Single GUP B + Multi GUP C. Right ?

=> Each group receives the Globallist.xml file and use it. Right ?

=> Clients of group A have a Single GUP policy. That means that they can only use the GUP on the LU policy A, even if in another subnet. Right ?

=> As mentionned in document, clients in group A read the XML file and will use the first GUP on their local subnet. That means that clients of group A can use the GUP defined as Single (group E) or Multiple (group D) instead of the one set on the LU policy A (on subnet B). Right ?

I understand that is several groups with GUP election on a unique Subnet, clients cannot really be managed by the LU policy as the globallist is having priority... Feel difficult to manage no ?


SMLatCST's picture

I'm afraid so. As per the article I linked, the use of GUPs does sometimes result in unexpected behaviour.

Unfortunately, I can't seem to find the "SEP 12.1 RU2 And Explicit Group Update Providers" article you mentioned.  But assuming it's correct, then a client configured to use a Single GUP on another subnet will still update from a GUP in the local subnet if one exists.

In your example, this would mean clients in GroupA on SubnetA will update from a GUP in SubnetA, despite their policy actually telling them to update from a Single GUP in SubnetB.

Of course, while this is unexpected behaviour, it will normally result in less network traffic (which is what GUPs are there for anyway).

I've not tested this particular scenario myself, so you may want to give it a go.

Xtof's picture

Ok thanks !

GUP is not so easy.. :)