Endpoint Protection

Hi there,

Our infrastructure is a centrally managed SEPM instance, with client sites connecting to our SEPM management server.

One of our sites has been having issues with the multiple GUP providers. It's looking for GUP's which do not belong to the same network (domain). I know that the GUP's are calculated by the networks netmask and this makes a few of the other client GUP's serve as a GUP to this one particular site.

I have setup a new Live Update policy for this particular site and set it so that it is only using a Single GUP and multiple GUP's have been turned off. The policy serial number has been reflected on our clients but they are still looking for the GUP's that are calculated with the multiple GUP's option.

Has anyone seen this issue before and is there a resolution to this? It doesn't impact client functionality but it's concerning that it's looking for other GUP's through the multiple group update provider setting which isn't enabled for this site.

Thanks

Can you tell me what is the exact version of SEP on the clients that are exhibiting this behavior? A mix of various 12.1 versions or a specific version?

Hi Brian,

Our client site has SEP 12.1 RU3. I have also updated some of our client machines to SEP 12.1 RU5 and they also exhibit the same behaviour.

Our SEPM instance is 12.1 RU4 MP1a.

I have similar weird issues with GUP's affecting subnets it's not suppose to. For instance if you have a LiveUpdate policy setup for GUP's, there is an option called "Maximum time clients try to download updates from a GUP before trying management server". If you do not have a GUP setup for a subnet it will still use this rule. Which  means if you have this policy for your whole group, any subnet that does not have a GUP will never receive updates, it will just keep delaying it waiting for a GUP to show up (even though the server knows full well there is no GUP for that subnet). I'm not sure this is proper behaviour but I just learned this the hard way. Maybe it's a similar problem with the way your LiveUpdate policies are? I had to set up a separate LiveUpdate policy for each GUP.

We have a custom LiveUpdate policy for this particular group. Only the Single Group Update Provider has been set with the FQDN of our GUP server for this site. Multiple and Explicit are unchecked. Also the 'Maximum time clients...' setting is set to Never so it will only be allowed to download content from the GUP server.

In the registry settings on client computers the MasterClientHost string is correctly set to this defined GUP in our policy. However, the guplist generated from the globallist.xml from the SEPM is still making our clients look for multiple GUP's due to the matching netmask.

I thought that the Single Group Update Provider should be adhered to and not the calculated one that the SEPM generates (even though we have no Multiple Group Update Providers defined).

So I'm wondering if SEPM always generates a default list of GUP's (by having them enabled as GUP's by policy) and if the netmask matches, it will give this list of GUPs to the clients to use no matter what is set in policy.

check the globallist.xml file, the SEPM provides this list to clients so they can determine where to go...

See these:

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

https://www-secure.symantec.com/connect/forums/how-rebuild-globallistxml

I have checked this and the GUP is present. The netmask of the network that the clients sit on also encompass a few other GUPs so they get included in the GUP list generation for this site. 

I only want the clients to use the Single GUP that is defined in the LiveUpdate policy though, not the multiple GUPs that get generated from the globallist.xml.

As I believe this is expected behaviour. See here (Brian sent the link as well):

So, all of the Group Update Providers that are configured in any of the policies on a Symantec Endpoint Protection Manager are potentially available for clients' use.

 You could try to use Explicit GUPs to prevent this (explained in the same KB).

Thanks, missed that link as I was in a hurry and was caught up with other things.

I'll test this with the Single GUP and Explicit GUP rules defined. Hopefully this will show us the behaviour we want. Will let you know the result after some monitoring for a few days.

Hi all,

The explicit group mapping did not work. I read through the documentation again and it appears as though this is by design and we cannot individually set GUP's as long as we have different types of GUP's defined.

Thanks for the assistance.