Endpoint Protection

Hello,

I have a question about GUPs on SEP 12.4.  We have over 1000 machines including servers, laptops, workstations across our state.  We have 27 districts made up of multiple counties.  A single District Server supports all the counties within that district.  Each county has its own subnet.

Initialy we set up our GUP list within LiveUpdate policy using IP addresses of our Remote District Servers.  Thus, the only GUPs we had were the 27 District Servers.  I had forgotten that clients ONLY talk to a GUP if it is in that client's subnet.  Thus, the outlying counties in a district did not talk to the District Server\GUP.  Any updates those clients needed came directly from our SEPM server.  A single server.

We've had problems with tens of thousands of SEP sessions overloading our firewall at our main office where our SEPM server resides.

We chose to add an OS check to our GUP list, so that any machine with an OS of "XP" or "win7x64" could now become a GUP in addition to our District Servers.  We now have nearly 800 GUPs.  That's out of a total of just over 1000 machines.

Questions:

1) Is there a way to limit the number of GUPs created?

2) When GUPs request updates, do they get the delta from SEPM, or do they also check the GUP list like clients do?

Where did you see clients only talk to GUPs if in their subnet? If you setup a condition and add the necessary subnets, any client in those subnets will get updates from the GUP.

They will get a full and the deltas so they can hand out whichever the client needs

#Edit

Hi,

Thank you for posting in Symantec community.

I would be glad to answer your query.

1) Is there a way to limit the number of GUPs created?

--> I believe there is not a way to limit the number of GUP's created

2) When GUPs request updates, do they get the delta from SEPM, or do they also check the GUP list like clients do?

--> It depends upon how old definitions/data is requested, if SEPM holding that data then it will forward delta updates if SEPM doesn't have requested data it will download and forward full.zip.

To avoid this situation it's recommended to follow best practices:

• ensure the GUP’s local SEP Client is running the latest available Maintenance Release (MR), so all available optimisations and fixes are leveraged.
• When running 5000 or more connected clients to a GUP it is recommended that a dedicated system is used so that resource utilization is not saturated when the IPS/Firewall is enabled.
• Configure connected SEP Clients with at least two locations so they retrieve content updates via public Liveupdate when not connected to the corporate network. This will ensure there is a higher likelihood of their content remaining relatively recent when they do connect to the corporate network (so filesize of content that gets transferred from the GUP is minimised).
• Configure the SEPM to retain at least 42 content revisions (this will ensure the GUP can provide an incremental content update for connecting SEP Clients, even if they are out of date on content by up to 2 weeks), preferably more. This will help minimise impact on local network bandwidth. Note though, it will also mean additional disk space will be utilised on the SEPM and Database machines.
• When SEP Clients are first installed, by default, they will initially attempt to download a full content update. Keep this in mind when enabling a GUP. If a large number of SEP Clients (5000+) are being installed within the same short time window and are configured to connect to the same local GUP, this local GUP may experience unusually high and sustained resource utilisation until the connected SEP Clients are updated to a relatively recent content update version.

Reference: http://www.symantec.com/docs/TECH95353

According to Symanctec, clients only talk to GUPs that are in their subnets.  So, if a subnet does not have a GUP, then the client will only talk to the SEPM.  Is this wrong?

I could add in the necessary subnets, but that would mean adding in over 80 subnet entries in to the GUP list - and then, SEPM would still claim a large number of machines as GUPs within that subnet.

My question is, how can I limit the number of GUPs created?

And, do GUPs get the deltas from other GUPs or from SEPM?  If GUPs get deltas from SEPM, then it does not save any network traffic for the SEPM.

If GUPs can get their deltas from other GUPs in the GUP list, then why wouldn't we make all machines GUPs?

Yea if you don't add the subnets in than this will happen.

What type of GUP are you using, multiple? Sounds like thats the case. For multiple, depending on what criteria you use is what they use to turn into a GUP so if it meets the criteria, it will become a GUP. No way to limit this. It's all or nothing.

GUPs get all their content from the SEPM. GUPs do not share with other GUPs.

Thanks for replying Chetan,

However that doesn't address my problem.  Each district has about 50 machines spread across 2-5 subnets.  Those subnets are serviced by one district server.  These district servers were originally our only GUPs.  But, it turns out that since there were many subnets not serviced by these GUPs, that the clients were contacting SEPM directly for updates.

We are trying to limit the amount of sessions and traffic to and from SEPM.  Which is the point of GUPs.  Yet, we also don't want to flood our network with GUPs if those GUPs only talk to SEPM for their own updates.

Do GUPs get and read the GUP list?  Do they use the GUP list to download their updates like the clients do?

So, if GUPs can talk to and get their updates (deltas) from other GUPs, then why wouldn't we turn all machines in to GUPs?

If GUPs only talk to SEPM for their updates, then I need a way to limit who is a GUP.  Earlier, our GUPs were identified by IP address and only the district servers. That left out alot of subnets.

We don't really want to put in by hand a few random workstations IP addresses in each subnet in to the GUP policy list.  That would be over 200 entries.

Hello Brian, I appreciate your help again as in the past.

Yes, using multiple - as we have over 2 dozen districts and over 80 subnets.

GUPs get all their content from the SEPM. GUPs do not share with other GUPs.

Grrrrrr.  and double Grrrrrr.

So, in order to limit the number of GUPs we have (which will also limit the amount of traffic to SEPM), I have to manually choose some random IP addresses in each of our +80 subnets?? and manually enter them in to the GUP policy list.

That is so not fun.

Is there a way to manually enter all these IP addresses in to the GUP list (the globallist.xml)?  I hear that it is created from a database, where the database is created by the GUP policy editor.  If I can enter manually, that will save alot of time.

You could always use a reg key condition, perhaps if your GUPs are on a different version from the rest, you could use the version key..or you could add a reg key which is only specific to the GUPs

Hello Brian, our machines are seperated by District Number in our AD.  so WAN is root in AD, then Agency Name, then all of our districts by number.  Each district's machines are in that district OU.

If I add a add-registry-entry GPO to each OU, then all those machines in their respective district OUs will get the registry key.  Then when the GUP policy is looking for that registry key, ....... ... all 1000 of my machines will be GUPs.

Adding the "XP" or "Win7x64" Operating System check to our GUP Policy list, so that machines with those OS types are now capable of being a GUP, gave us this:

~of the 14 machines in one *.73.0 subnet, SEPM chose 13 of those to be GUPs

~of the couple hundred machines in our main office *.0.0 subnet, SEPM chose 62 to be GUPs.

Why doesn't the IP address entry field on the GUP list creation gui, allow for wildcards?  This would simplify matter enormously.  I could add in *.*.*.6, *.*.*.7, *.*.*.8, etc, to *.*.*.15, to allow for limiting my GUPs and hitting all subnets.

PLEASE allow wildcards in GUP list creation.

This would need to be submitted as a product suggestion:

How to submit a suggestion for a Symantec security product

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

Hi,

Thanks for your reply.

Q. Do GUPs get and read the GUP list?  Do they use the GUP list to download their updates like the clients do?

--> No, GUP'S can't read the GUP list.

Q. So, if GUPs can talk to and get their updates (deltas) from other GUPs, then why wouldn't we turn all machines in to GUPs?

--> GUP can not get their updates either detlas or full updates from other GUP's.

First of all you need to make here a solid distinction in terms of LU functionality between:

1) SEP Client on the machine that is assigned to be a GUP

2) let's call it GUP functionality on the same machine

...both those elements (hovewer bundled they are) in terms of liveupdate and definitions download are completely separate. Both those elements will have the definitions as well stored in different locations on the drive. An example:

Client A request definition set from GUP B -> GUP B request this definition from SEPM, downloads it, stores locally and provides it as requested to Client A. Does it mean that after GUP downloaded this particular set of definitions the Client B is already updated with it? No. They stay separate, if Client B wants to update this definition it needs as well to request it from GUP B - even if this is the same machine.

Taking the above into consideration answers to your questions:

Q: Do GUPs get and read the GUP list?  Do they use the GUP list to download their updates like the clients do?

A: SEP Client itself (point 1) reads the GUP list and can take the update from GUP on the same machine or it may even happen that it contacts GUP on another machine. GUP (point 2) cannot get any updates from other GUPs.

Q: So, if GUPs can talk to and get their updates (deltas) from other GUPs, then why wouldn't we turn all machines in to GUPs?

A: No, this is only the SEP client talking to other GUPs. GUP feature itself talks only! to SEPM for updates - no exception to that.

------------

On the general note - having 800 GUPs in 1000 clients environment seems to be an overkill - not sure if you spare here any network bandwith in that configuration. Have you considered Explicit GUP configuration - its a new feature introduced in SEP 12.1 RU2 that allows the sep clients to roam outside the scope of their own subnet for GUP communication. In the end effect you set up clients from different subnets to connect to particular GUP in other subnet. Have a look at some docus:

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

SEP 12.1 RU2 And Explicit Group Update Providers

https://www-secure.symantec.com/connect/articles/sep-121ru2-and-explicit-group-update-provider

How To Save Time Entering Multiple Explicit Group Update Providers (GUPs)

https://www-secure.symantec.com/connect/forums/how-save-time-entering-multiple-explicit-group-update-providers-gups

Here are the Best Practices and Troubleshooting articles which are related to GUP.

Group Update Provider: Sizing and Scaling Guidelines

http://www.symantec.com/business/support/index?page=content&id=TECH95353

Best Practices with Symantec Endpoint Protection (SEP) Group Update Providers (GUP)

http://www.symantec.com/business/support/index?page=content&id=TECH93813

Configuring the Group Update Provider (GUP) in Symantec Endpoint Protection 11.0 RU5

http://www.symantec.com/business/support/index?page=content&id=TECH96419&locale=en_US

Guide to create the GUP for remote location

https://www-secure.symantec.com/connect/downloads/create-gup-symantec-can-help-conserve-bandwidth-clients-remote-location

How to Setup a Group Update Provider (GUP)

http://www.symantec.com/business/support/index?page=content&id=TECH105005&locale=en_US

Tips For Installing SEP In A Low Bandwidth Environment

https://www-secure.symantec.com/connect/articles/tips-installing-sep-low-bandwidth-environment

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

https://www.symantec.com/business/support/index?page=content&id=TECH198702

Troubleshooting the Group Update Provider (GUP) in Symantec Endpoint Protection (SEP)

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

How can we check which content SEP 12.1 clients are downloading from GUP?

https://www-secure.symantec.com/connect/articles/how-can-we-check-which-content-sep-121-clients-are-downloading-gup

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

http://www.symantec.com/business/support/index?page=content&id=TECH97190

SEP Content Distribution Monitor (for GUP health-checking)

https://www-secure.symantec.com/connect/downloads/sep-content-distribution-monitor

How to analyze Debug logs from GUP to determine which clients are taking definitions from GUP

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

Video’s created on Group Update Provider on the Symantec Connect website.

 https://www-secure.symantec.com/connect/videos/group-update-providers-part-1

https://www-secure.symantec.com/connect/videos/group-update-providers-part-2

GUP content monitoring tool video

https://www-secure.symantec.com/connect/videos/sep-content-distribution-monitor-introduction

Hope it helps.

My 2 pence worth 

I'm not sure if anyone has mentioned it yet on this thread, but you should still be seeing the bandwidth savings even with the 800 GUPs.  The reason for this is that when using the Multiple GUP option, SEP Clients will always connect to the GUP with the lowest IP address in their subnet.  Therefore in any particular subnet, regardless of how many GUPs are present in the subnet, only the GUP with the lowest IP address grabs the defs from the SEPM (i.e. just the one GUP per subnet downloads the defs).  The GUP component on the clients with higher IP addresses just sit there twiddling their thumbs as they do not receive any defs requests.

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

Also, as you're using SEP12.1RU4, have you considered using the Explicit GUP option?  This would allow you to use your District servers as GUPs for the corresponding Country IP Subnets (as, it sounds, you originally intended)

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

Hello all,

Thank you for your responses and suggestions.

As for "have you considered using the Explicit GUP option?  This would allow you to use your District servers as GUPs" question .....  Yes, we did.  however, a bug in the latest release causes certain of our district servers that are Windows 2008R2 - Read Only Domain Controllers to stop the SMC service.  This then would block ODBC traffic to that server.  (we are working with Symantec on identifying issue - even when the RODC server is not a GUP, if we disable SMC using "smc -stop", the ODBC connections are blocked)

We are not experiencing this issue with our Windows 2003 x32bit district servers.

However, as we have about 80 subnets, I do not want to manually enter nearly 300 IP address entries in to the GUP in order to have an explicit GUP list across all subnets.  Also, there is no assurance that those machines I select will be on.

So, I left the selection of GUPs up to SEPM to do so automatically.  I guess we'll live with it for now.

Thank you all again.  I will peruse all of your links.