Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Clients Connecting to Wrong GUPs

Created: 03 Oct 2012 • Updated: 03 Oct 2012 | 9 comments
This issue has been solved. See solution.

What would cause clients to contact GUPs outside of their subnet? I thought clients locate GUPs inside their subnet fist, if none are found or available they use the SEPM. I have clients connecting to GUPs outside of their subnets all over the place.

For example:

GUP A - ip: 10.10.40.2
GUP B - ip: 10.10.50.2
GUP C - ip: 10.10.60.2

All LU Policies below us a Single GUP IP address.

I assigned LU Policy 1 to Group 1. Clients with all ip's of 10.10.40.xxx to use GUP A.
I assigned LU Policy 2 to Group 2. Clients with all ip's of 10.10.50.xxx to use GUP B.
I assigned LU Policy 3 to Group 3. Clients with all ip's of 10.10.60.xxx to use GUP C.

However, all clients are connecting to GUP A, GUP B, GUP C.  Seems like most clients are hitting GUP A though.  Perhaps because it was the first machine to become a GUP (noticed it was the first to create the SharedUpdates folder).  Clients seem like they are not using the subnet filter when searching the list of GUPs from the globallist, which does have the GUPs sorted by subnet.

Am I understanding the use of "subnets" for GUPs correctly?

I also tried configuring one LU Policy inherited down to all Groups using Multiple GUPs but the same thing happened.

Also, not sure if this matters, but all clients and GUPs in all groups use the same subnet mask (255.255.0.0) 

I am using the latest version of SEPM (12.1.1101.401 RU MP1).  Some clients are still on (12.1.1000.157).

Thank you.

Comments 9 CommentsJump to latest comment

.Brian's picture

What condition are you using in your location setup?

You need to setup location awareness so the client knows what location it is in and which GUP to contact.

Best Practices for Symantec Endpoint Protection Location Awareness

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

Location Awareness Logic 

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

More about Location Awareness in Symantec Endpoint Protection (SEP)

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

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.

pete_4u2002's picture

the client supposed to be GUP, have they reported to SEPM as GUP?

MrDaytrade's picture

Yes, all clients have reported back to SEPM as a GUP.  Verified by looking at the True statement in the Client Properties.

Location awareness is enabled.  The Default location and Remote Users location with a condition (client computer does not connect to management server. 

.Brian's picture

So you don't have any conditions for your Default Location? If so, this is the issue.

All clients will connect and automatically go to the Default Location and use only that policy.

You will need to create multiple locations, and use two conditions

Condition 1: Client computer connects to management server

Condition 2: if client computer has one of the IP addresses listed below:

From here add the subnet range and mask and assign your GUP policy to this location. Do the same for each subsequent location.

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.

MrDaytrade's picture

I was not aware that you have to create seperate locations for each group in order to restrict clients from using GUPS outside of their subnet.  I thought the Clients select the GUP that is in their subnet when they retreive the list from the SEPM's globallist (...data\outbox\agent\gup) and ignore all other GUPs on the list.

My default location: Condition 1, Client computer connects to management server.

.Brian's picture

Single Group UpdateProvider:

A single Group Update Provider is a dedicated client computer that provides content for one or more groups of clients. A single Group Update Provider can be a client computer in any group. To configure a single Group Update Provider, you specify the IP address or host name of the client computer that you want to designate as the Group Update Provider.

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.

Check this article for more details:

https://www-secure.symantec.com/connect/articles/w...

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.

MrDaytrade's picture

I read mixed comments about how the clients apply the filter to the list of GUPs. Do they filter based on the subnet mask such as my 255.255.0.0 or do they look for matching subnets in the ip address such as a GUP at 10.10.50.2 and a client at 10.10.50.8 will find and use that GUP?

Ian_C.'s picture

In SEP 11 RU5, clients "assumed" a Class C subnet mask and you could have clients contacting GUPs outside of its local subnet.

From what I understand, that has now been fixed up and subnet mask is calculated correctly. Which for you is a problem. All of your machines use 255.255.0.0 as the subnet mask. That means 10.10.x.x are all on the same subnet. That measn that all clients will contact GUPs starting at the lowest IP address. 10.10.40.xxx is lower than 10.10.50.xxx which is lower than 10.10.60.xxx. Thus all your clients will try to contact GUP A first. If GUP A is too busy and the retry time expires, clients will contact GUP B next and only seldomly GUP C.

Of all the options availabel to you, changing your network design for a new subnet mask is the most disruptive.

On the other hand, implementing Location awareness can be done with a few clicks after the proper approcal has been given and the change control process has been followed. I like using default gateway as a criteria for my location on the corporate network.

Please mark the post that best solves your problem as the answer to this thread.
SOLUTION
MrDaytrade's picture

Ian_C

enlightened Now that explanation was spot on!  That is exactly what is happening.  GUP A, heavy contact.  GUP B, little contact.  GUP C, no contact.

Perhaps there should be more focus on "Subnet Mask" in all videos and articles relating to GUPS using version 12.1.

For now, it looks like we will scrap the idea of using GUPs.  We have 5000+ clients, 20 remote locations on slow WAN's all using the same subnet throughout the State.

I will dig deeper into Location Awareness as mentioned by you and Brain81.  Perhaps a different group structure based on geographic locations will be needed. 

My Company
 - Location 1
    - Workstations
    - Servers
 - Location 2
    - Workstations
    - Servers

I must be off to eliminate my current GUPs before I crush my remote locations where GUPs are located!!!

Thanks for your input.