Endpoint Protection

Per Anikets post "A few things to consider about GUPS" in this article www-secure.symantec.com/connect/articles/troubleshooting-liveupdate-issues-symantec-endpoint-protection 

I checked the registry setting and found that MasterClientHost is blank. Shouldn't SEP be adding the GUP that is closest to the client to that reg key? I have never been able to verify that the SEP clients are getting updates from GUPs.

Something else I noticed in his post is that the GUP needs to be in the same group as client. Is it really required to have one client in each group be a GUP for the others to receive updates from it?

masterlclinethost should have the name of your gup
this article should clear you doubts.


https://www-secure.symantec.com/connect/forums/do-gups-have-be-same-folder-clients-they-are-updating

https://www-secure.symantec.com/connect/articles/configuring-group-update-providers-symantec-endpoint-protection-110-ru5

Something else I noticed in his post is that the GUP needs to be in the same group as client. Is it really required to have one client in each group be a GUP for the others to receive updates from it?

Prior to RU5 the GUP would only update the Clients in its GROUP or Sub Group. Now in SEP RU5 the GUP is NO MORE GROUP dependent. The GUP is depended on the SUBNET. One GUP can update client in the same subnet irrespective of the Group they are in,..



On the client, look in the registry under

■

If this key is set to 1, the client uses an internal LiveUpdate server or Symantec

LiveUpdate directly.

UseLiveUpdateServer

■

If this key is set to 1, the client uses the management server.

UseManagementServer

■

If this key is set to 1, the client uses a group update provider

UseMasterClient

HKEY_LOCAL_MACHINE\Software\Symantec\Symantec EndpointProtection\LiveUpdate.

Check the settings for the following keys:

Regarding your mention "I have never been able to verify that the SEP clients are getting updates from GUPs." you can check syslog file as depicted below.



Regarding "...the others to receive updates from it?" you can build LiveUpdate Administrator for your environment. Regards, KS Choi

Hi,

Please refer to the article that I have create for the same purpose:

https://www-secure.symantec.com/connect/articles/how-analyze-debug-logs-gup-determine-which-clients-are-taking-definitions-gup-0
Aniket

Prachand, thanks for the info about GUPs not needing to be in groups or sub groups and going by subnet address. What happens if a client ends up on a subnet that doesn't have a GUP currently serving but they're in the same domain?

 KS Choi, I checked the log and don't see anything about Start Using GUP and that is what prompted my last post. I would have figured that if a client ended up on a subnet without a GUP that it would at least attempt to seek one out and attach to it but that does not appear to be the case.

If a client is in a subnet where no GUP is present, it can not get the definitions. However, if you have setup the policy that SEP clients can bypass SEPM, then they can get the definitions.

Aniket

Did you check the debug.log from the GUP client.

I am sure it contains what you are looking for.

Cheers,
Aniket

 Where is the debug.log?

You can enable debug logging from the SEP client interface:  

Help & Support -> Troubleshooting -> Debug Logs-> Edit Debug Logs Setting -> Check the box for Debug On

Then you need to go to start-> run

type smc -stop -> Ok

smc -start -> Ok

Give it some time to generate the logs. Probably a few hours. You can increase the size of the debug logs to accomodate more info.

https://www-secure.symantec.com/connect/articles/how-analyze-debug-logs-gup-determine-which-clients-are-taking-definitions-gup-0


Cheers,
Aniket

Does Symantec have plans to make it so that clients will seek out a GUP if it doesn't find one on it's own subnet? I find it rather ridiculous that clients can't do that already. We have numerous subnets in our corporate headquarters and only have servers on two of those subnets. It would be a lot of extra work to make sure multiple desktop computers designated as GUPs are turned on all day.

Nobody knows if Symantec is going to fix the GUP issue?

Hi,

It would create a lot of traffic if the SEP clients start to "look" for GUPs across subnets. If the other subnet is across a WAN link, and there are 1000 clients in your network, the everybody will start using that bandwidth to start looking for GUPs across the WAN link.

The main intention of creating a GUP is to provide a local point of definition distribution.

All you need to do is to provide at least 1 IP address from every subnet in the Liveupdate Settings policy.

And make sure that the clients have received that policy.

Aniket

Hi,

As the SEP clients have an ability to contact more than one GUP in the GUPlist, the registry key mentioned in your original post no longer saves the name of the GUP. Because there could be more than one GUP.

One thing that has remained unchanged in the registry is the following key:

UseMasterClient

GUP no longer needs to be in the same GROUP as the client in RU5. It should be in the same subnet.

This has changed since RU5.

Aniket

I guess I didn't make it clear that we some times have multiple subnets in one building, and multiple buildings that are configured this way.

It would increase our workload to ensure that every single subnet has a machine that is turned on and receiving updates when Symantec could have just added the subnet feature to the existing way of the GUP having to be in the group for them to receive updates. For instance, if the client doesn't see a GUP on it's subnet then it defaults to the GUP assigned to that group. I don't understand why Symantec has trouble doing things logically.

Symantec needs to intigrate with Windows BranchCache.   Windows has the feature where the client can act as BranchCaches without the need of a server.  The Windows 7 EE/PRO clients act as a psuedo server utilizing P2P between them.

Until that time, we've began deploying caching servers (Citrix BranchRepeaters) to resolve this issue.  Good bye all my GUPS!  It will all happen transparently now, no complex setup.    We have many products that do this same thing.  eSet, Novell, WSUS.   All those nasty configs go away and it simply becomes cached in this Citrix device.  I point everything at my one SEPM server, and Citrix transparently caches it.

The BranchCache would offer that without having to have 3rd party solutions, granted you are on Win7 EE or another supported OS.