Video Screencast Help

GUP Limits

Created: 11 Feb 2013 | 16 comments

I am running SEP 12.1.2 and have a question about the amount of managed locations I can have for each group.  I am currently using AD sync to pull in all workstations into a single group.  However, we have more than 20 individual locations in the US region and many more in the EU.  Previously I was told that we should limit the amount of locations per group to 7.  Does anyone know if that is still the case with the latest release of SEPM?  I'd like to create a GUP in each site but would need to create a new location for each site as per previous conversations with Symantec support.

Comments 16 CommentsJump to latest comment

.Brian's picture

It is still the case. From the KB articles

Best Practices for Symantec Endpoint Protection Location Awareness

Article:TECH98211  |  Created: 2009-01-20  |  Updated: 2012-06-07  |  Article URL http://www.symantec.com/docs/TECH98211

 

Symantec does not recommend more than seven (7) locations per group when using Location Awareness as this can affect the execution time on how long it takes the SEP client to process and ultimately connect to a valid location where all conditions have been met.

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.

conofray's picture

Think I have any other options if I want to keep my AD sync in place?  Each individual group at this point uses their own GUP with some remote sites checking back into our main hub.  If see there are options for adding multiple GUPs per LiveUpdate policy but is the client smart enough to know to go to the "closest" GUP?

.Brian's picture

Did you check the new GUP feature for 12.1.2?

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 http://www.symantec.com/docs/TECH198640

 

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.

SebastianZ's picture

Exactly - take a look at the explicit gup configuration - with this you can get rid of the limitation "GUP per group" - instead you can specify gup per client subnet and assign all machines only one LU policy. As for the prioritization - SEP client goes always for the GUP in his own subnet.

conofray's picture

I have a test policy in place with an explicit GUP list specified.  I'll post an update when I have some results.

conofray's picture

Unfortunately it doesn't look like the test policy is working correctly as the machines are pulling updates from the main SEPM instead of the GUPs.  Attached is my test client policy.  The two GUP machines have already been configured as GUPs previously.

AttachmentSize
GUP Setup.docx 36.47 KB
SebastianZ's picture

On the screenshot I see the "maximum time that the clients try to download from GUP before trying the default management server" is set to never -> according to this the clients that cannot reach any GUP will never go to SEPM - not sure how is it happening you see clients with this policy still getting updates from SEPM.

Can you confirm that the GUPs can be reached from your test machines without issues on port 2967?

James-x's picture

Hello,

Can you please run the SymHelp utility on one of the computers which should be using the GUP (but is going to the SEPM instead) and attach it to a reply? I'd like to look it over.

Please checkmark the "Full data collection for support" box when running the utility.

The utility can be downloaded here: http://www.symantec.com/docs/TECH170752

James

The Symantec Endpoint Protection Knowledgebase

Please remember to mark the post which resolved your issue as the solution!

Vikram Kumar-SAV to SEP's picture

I have seen around 3000 GUPs configured in single liveupdate policy as multiple GUPs and they are working fine.

Clients will find the GUP in its subnet.

If you want you can create explicit GUPs if you have thr requirement or as backup GUPs , however multiple GUPs will work fine and clients will know which GUP to pick up,it just should have the policy applied.

Vikram Kumar

Symantec Consultant

The most helpful part of entire Symantec connect is the Search button..do use it.

conofray's picture

Here is my scenario.  My sites have at least 3 subnets per location and the workstations are never on the same subnet at the GUP.  All of my workstations are in the same group as they are tied to AD.  The goal would be to have one LiveUpdate policy that uses a server at each of our distinct locations.

Example
Site 1 has a server subnet of 10.2.1.0 and a workstation subnet of 10.2.2.0.  It's GUP has a name of site_1_server and is on the server subnet.

Site 2 has a server subnet of 10.10.1.1 and a workstation subnet of 10.10.2.0.  It's GUP has a name of site_2_server and is on the server subnet.

If my new LiveUpdate policy looks similar to attached, will the clients be smart enough to pick the correct GUP?

2-12-2013 2-40-30 PM.png
James-x's picture

GUPs defined by using Multiple Group Update Providers will go to any GUP machine which is in their current subnet. If no GUPs are in their subnet, they will go to any GUP.

GUPs defined by using Explicit Group Update providers offer more flexibility. They allow you to specify what clients go where, based on the client's IP address. Unfortunately, having a client listed in the Explicit GUP list is not sufficient to tell the client to turn on the GUP functionality. The client must be listed in either the Multiple GUP list or the Single GUP field to enable GUP functionality.

So, what you'll want to do is this:

- List your client which you want to be a GUP in the Multiple GUP list.

- Go to the client and confirm it is listening on port 2967 (the default port) to confirm GUP functionality is enabled. You can use the following command: netstat -ab | findstr /i 2967

- Once the GUP is listening on this port, configure the Explicit GUP list as follows.

Client Subnet: <the subnet network address of your client machines>

Type: IP Address

IP Address: <ip address of the GUP>

Port: <the port the GUP is listening on. Default is 2967>

Try to get this working for one site at first. Once you've got that working, you can move out to the other sites.

James

The Symantec Endpoint Protection Knowledgebase

Please remember to mark the post which resolved your issue as the solution!

Vikram Kumar-SAV to SEP's picture

You will need to have 2 policies,1 with GUP and 1 for local NAm clients.

Vikram Kumar

Symantec Consultant

The most helpful part of entire Symantec connect is the Search button..do use it.

conofray's picture

Unfortunately my updated setup does not seem to work.  Attached are my client and server policies (both use the same LiveUpdate policy).  Machines in my TN site are not updating from the TN server.   The workstations are on the 10.2.2.0 subnet.

client1.JPG client2.JPG
James-x's picture

Hello,

Can you please run the SymHelp tool on the TN server and attach the output here so I can review it? This should allow me to determine if that machine is functioning as a GUP or, if not, hopefully give me some idea why.

You can download the tool here: http://www.symantec.com/docs/TECH170752

Please checkmark the box "Full data collection for support" when running the tool.

James

The Symantec Endpoint Protection Knowledgebase

Please remember to mark the post which resolved your issue as the solution!