The documentation on GUPs, doesn't use any illustration examples, hence I guess I am having a super hard time with it.

Not to mention things with GUPs never seem to be working as they should, I appoint a GUP for a machine then check the debug log on the machine and there's no mention of the GUP IP in there anywhere.

I have some questions below, appreciate if one can answer.

1. When the gup and the client are in different groups but same subnet? (using single GUP)
2. When the gup and client are in the same group but different subnet? (And the routing is avaliable and ports are open.)
3. If multiple gups are created in the same group then will the clients use them on the avalaibility basis or will they all just use 1 gup? Can there be any load balancing here?
4. What if I appoint the same machine as the GUP for 2 different groups using "single GUP" in both the group policies?

Please check this article and let us know if you still have questions

Symantec Endpoint Protection (SEP) Group Update Providers (GUPs) Selection Examples

https://support.symantec.com/en_US/article.TECH198702.html

1. When the gup and the client are in different groups but same subnet? (using single GUP)

No problem, but of course GUP must be registered in the LU policy of the client. You can also create a shared LU policy with the GUP and assign it to different groups.

2. When the gup and client are in the same group but different subnet? (And the routing is avaliable and ports are open.)

 See 1.

3. If multiple gups are created in the same group then will the clients use them on the avalaibility basis or will they all just use 1 gup? Can there be any load balancing here?

If clients are detecting more than one GUP in their subnet (multiple GUP), they will use the GUP with the lowest IP address. If this GUP does not answer, the client will try the next one etc. No load balancing, only failover.

4. What if I appoint the same machine as the GUP for 2 different groups using "single GUP" in both the group policies?

No problem.

To create more refined GUP scenarios, you can use the Explicit GUP.

About the types of Group Update Providers

Also, just to mention, client/GUP communication is shown in the sylink log.

How to enable Sylink debugging for Endpoint Protection clients

How to confirm if SEP Clients are receiving LiveUpdate content from Group Update Providers (GUPs)

Is the "sylink" log different from the debug one at help > troubleshooting > debug ?
 

Is there any time estimation on how long it takes to update say about 20-40 computers from the GUP?

I have GUPs and clients on the same subnet and yet still the clients won't update on time or seem to take lot of time.

How do you mean on time?

Definition distribution via GUPs is still dependent upon Heartbeats (exactly the same as direct from the SEPM), the GUP just reduces the bandwidth required for delivery.

Therefore, you're typically looking at a heartbeat or two, plus download randomisation windows, after a SEPM updates, that the clients will then update.

No its the same , earlier version you have to make registry changes, with new version you can enable via Troubleshooting page

HI

Thanks for the answers.

When does the GUP know it is a GUP?

The group in which the GUP sits, that group should have a policy calling it the GUP right?

Yup, a SEP client is only told to be a GUP when it receives a policy telling it so.  Similarly, the remaining SEP clients need to be told about which machines are acting as GUPs.  In this way, the LU policy serves 2 purposes regarding GUPs:

• Telling a SEP Client it's a GUP
• Telling everything else which machines are GUPs, and how to connect to them

How you assign those LU policies (i.e. the group setup) is up to you as long as the above criteria are met.  They can all be in same group, they can be in separate groups with the same policy, they can even be in separate groups with different polcies, as long the above rules are met.

As an aside, the client details from the SEPM clearly state if a SEP client believes it should be a GUP, but from a more comprehensive view, you can also take a look at either of the below:

• GUP Monitor (http://www.symantec.com/docs/TECH156558) - Preferred option
• globallist.xml found under \Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\data\outbox\agent\gup\ - This gets populated when a client reports into the SEPM to say it's enabled GUP functionality from what I recall.

My heartbeat is set to 3 hours in some group communication policies, that's too high i am thinking now. And I think the reason why clients do not seem to be updating for hours to the latest defnitions.

3 hour heartbeats would certainly be a contributing factor to the perception of very slow updates.  As mentioned, see what you have set as the randomisation window as well, as this adds to potential amount of time taken to grabs defs.

Symantec typically recommend 1 hour heartbeats, but it really depends on your estate.  Perhaps take a look at the below article for more granular recommendations on heartbeat intervals:

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

Page 10 to 12 should be of most use to you.

Found this:

You can improve network performance by modifying the following client-server
communication settings in each group:
■ Use pull mode instead of push mode to control when clients use network
resources to download policies and content updates.
■ Increase the heartbeat interval. For fewer than 100 clients per server, increase
the heartbeat to 15-30 minutes. For 100 to 1,000 clients, increase the heartbeat
to 30-60 minutes. Larger environments might need a longer heartbeat interval.
Symantec recommends that you leave Let clients upload critical events
immediately checked.
■ Increase the download randomization to between one and three times the
heartbeat interval.
See “Randomizing content

How is randomization used here? My idea is that, when more than a single machine hits the 1hr HB, the sepm just waits a random time and caters to one and then to the next?

Is there a chance of a bottleneck or network congestion if I keep the same HB for multiple groups with upto 10-20 machines per group?

The download randomisation is done by the client, and just tells the client to wait up to 5 minutes (for example, when configured with a 5 min randomisation window) before grabbing defs after a heartbeat.  When mixed with GUPs, it just means the client will wait up to 5 mins before asking the GUP for the defs.

As its random, it could be anytime up to the randomisation window threshold.  Also, as it's random, it is possible (though very unlikely) that all clients end up grabbing defs simultaneously.  That said, as you're using GUPs, the network bottleneck concern should have already been largely alleviated (unless you have limited bandwidth between your clients and GUPs as well!)

2. When the gup and client are in the same group but different subnet? (And the routing is avaliable and ports are open.)

 See 1.

So client and gup can be on different subnets entirely?

Isn't them being on the same subnet a requirement?

I am not sure but i think the documentation says they need to be in the same subnet.

Just confirming.

Thanks.

Only the Multiple GUP option requires the GUP and Client to be on the same subnet.  Both the Single and Explicit GUP options allow the GUP and Client to be on difference subnets.

HI

Should the top checkbox to use the default server should be checked if using the GUP?

I have both that and the gup checked as you can see here:

And in the LU policy, i have never set as the option as shown below:

As per the doc recommendation of 1hr HB the randomization time should be up to 3hours, would't that just cause the same delays in clients getting the updates?

Yup, both the "Use default management server" and a GUP option need to be ticked in order to use GUPs.

If you set a 3 hour randomisation window, then you will encounter the same situation where it will take up to 4 hours for clients to update their defs (Heartbeat + Randomisation window).

You're going to have to make an executive decision on whether to follow the article (I'm guessing its http://www.symantec.com/docs/HOWTO80988) or not.

For bandwidth-saving purposes alone, the use of GUPs usually reduces the network load enough to allow shorter randomisation windows, but only you know your environment well enough to make that judgement call.  It is also your judgement call to say whether the risk to your estate (of waiting up to 4 hours for the latest defs) is worth whatever bandwidth saving you make.

Taking a practical view, perhaps just start off with the 3 hour randomisation, and slowly shorten it every week until you see increased bandwith load?

But then I want to clients to only use the GUP and never the SEPM.

In fact I am seeing this crazy stuff where the GUP is not even updated to the latest defs but 1 client is and the policy is set to the never inside the GUP policy settings, how'd that happened?

It helps if you think of the SEP client and the GUP functionality as separate bits of software running on the same host.

In a normal scenario, the update process works like this:

1. SEPM is updated
2. SEP Client checks in and is made aware of newer defs
3. SEP Client waits randomisation window
4. SEP Client asks GUP for update file (it is told which file to ask for by the SEPM)
5. GUP asks SEPM for the file, and hosts it locally
6. SEP Client asks GUP again for file, and successfully downloads it now that the GUP has it
7. Any other SEP Client needing the same file and usign this GUP will get it whenever they ask for it, as the GUP already has it (it doesn't need to proxy the request again)

In the above sequence the SEP client can be any SEP client, even the one that is also a GUP.  It is entirely possible that a SEP client that is NOT the GUP happened to heartbeat before the SEP Client that is the GUP, and updated first.

If in doubt, just have a look at the SEPM's logs to see where your clients are updating from (ie. if they're using the GUP or not).  See the attached screenie for details on how to get these logs from the SEPM.

Thanks for the detailed answers man, much appreciated.

It is entirely possible that a SEP client that is NOT the GUP happened to heartbeat before the SEP Client that is the GUP, and updated first.

The doubt here is.. like i said the GUP policy says that the client never updates from the SEPM(or anywhere else) even if it cannot find the GUP, and still the client has updated.

See the never I circle in the 2nd screencap i posted in the previous comment.

Client waiting for randomization window? The window is set to 3 hrs for 1hr HB as per the doc, will it wait for 3 full hrs then?

And here below i see the GUP chooses itself as its own GUP and the defs get mangled (as per my understanding). The machine itself is 10.80.85.80.

2016/09/28 13:30:10.227 [5748:2284] GUProxy: Current GUP 10.80.85.80 staus is 1
2016/09/28 13:30:10.227 [5748:2284] GUProxy: GUP 10.80.85.80 chosen
2016/09/28 13:30:10.289 [5748:2284] AH: Setting the Browser Session end option & Resetting the URL session ..
2016/09/28 13:30:10.305 [5748:4548] GUProxy: accepted socket 7368 for 10.80.85.80 port 58527
2016/09/28 13:30:10.305 [5748:7712] GUProxy: Begin to handle accepted socket 7368
2016/09/28 13:30:10.305 [5748:7712] GUPROXY - GUProxy HTTP in - GET /content/{535CB6A4-441F-4e8a-A897-804CD859100E}/160927020/Full.zip
2016/09/28 13:30:10.305 [5748:7712] GUPROXY - GUProxy File - /content/{535CB6A4-441F-4e8a-A897-804CD859100E}/160927020/Full.zip
2016/09/28 13:30:10.305 [5748:7712] GUPROXY - GUProxy mangled file - #content#{535CB6A4-441F-4e8a-A897-804CD859100E}#160927020#Full!zip
2016/09/28 13:30:10.305 [5748:7712] GUProxy - Add request into download queue.
2016/09/28 13:30:10.305 [5748:3888] GUProxy - Throttle changed to [0X00003E80] BPS since Thread Count added to [1]
2016/09/28 13:30:10.305 [5748:3888] GUPROXY - GUProxy - TARGET_IP: - 10.25.248.12;
2016/09/28 13:30:10.305 [5748:3888] GUProxy - GET SEPM info from SYLINK(1) ,GET /content/{535CB6A4-441F-4e8a-A897-804CD859100E}/160927020/Full.zip  BEGIN with 0,total with 

You're forgetting the separation of GUP function from the SEP client.

What this means is that the GUP can have different defs from the SEP Client that's acting as the GUP.  They are not the same.  The SEP client reports on what has been processed into its own repository.  The GUP component merely keeps a cache somewhere and has no idea what it holds.

I'd suggest you take a look at the update logs from the SEP Client that updated first.  If the policies and whatnot are correctly configuired, you should see that it grabbed defs from the GUP.

The mangled file bit just means the GUP didn't have the requested file in its cache, as is to be expected as it appeared to ask for the full defs instead of a delta update

Again, if you think there is a problem, you can always look even deeper into the process and follow the below article:

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

Right the next minute after posting that I did think of the same thing.

That clients just keep defs in cache in the shareddefs to become GUPs but their own defs are a different thing and get corrupted.. boom!

Thanks again for all the answers.

No worries, it's taken us a few posts in getting there :), but I hope the info has been useful.

As always, please mark any/all relevant posts as the Solution, to aid others that may have the same question.