Endpoint Protection

Hello All,

I'm using SEP 12.1, Windows 2003 domain,  have one SEPM and about 550 clients. I want to use Group Update Providers (GUP) because I have about 15 to 20 LAN's at any given time in various parts of the US mainland. The problem is many laptop users go to a different LAN, some on a weekly basis, which would cause problems with the GUP delivering Defs to a client in another LAN.  Does anyone have a way around this problem? I was hoping I could find a way to automatically assign clients to groups based on the client IP address, but I don't see a good way to do that.  Any other ideas on how to get around the problem of making travelling SEP clients use the GUP in their local LAN, when that LAN might change on a weekly basis? 

--IT Monkey Boy

are these in different locations or same location with different subnet. You can think of LUA if it is same location.

Assign multiple GUP could also be thought of.

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

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

How To Optimize Endpoint Protection for Branch Offices using GUPs, Load Balancing, and Location Awareness

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

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

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

Hi,

in the LiveUpdate policy for those clients, set multiple GUPs, one per each subnet and the client will automatically pick up the GUP in the same subnet they are.

If the subnetting is not a valid criteria for you, you then need to use locations:

- create a group only for the laptops

- under this group, create the locations you need (according to your branches)

- per each location, set the proper criteria to recognized it (there are several location criteria that can be combined with logical operators)

- per each location, create a different LU policy to set the GUP for that location

More info can be find in the manual and in the help in-line.

Using multiple defined GUPs in one policy should do the trick for you, providing those locations are a single Class C IP subnet.

If not, using location awareness works very well for us. For us, I use the default gateway of the network as a criteria to assign the local GUPs.

Thanks for the suggestion.  For a variety of reasons and not within my power to change, we use subnetting so that a computer in subnet  A could access resources in subnet B,  or subnet C, etc.; so defining multiple GUPS in one policy seems to not be quite enough to force the client use the one in the local subnet because they would be able talk to any GUP in any subnet.

I'll think about your other suggestion, since it would require a total change in my SEPM group structure.

-IT Monkey Boy

Thank you for the comment about the Class C subnet. For a variety of reasons, we use an IP address scheme and subnetting so that any subnet has the potential to communicate with any other subnet. Any restriction to that is handled through the hardware firewall at each LAN. So using multiple definied GUPs in one policy would not work to force a client to use a particular GUP, because the client would most likely be able to communicate with the GUP in any other subnet.  I need to structure my SEPM groups and policies without the need to make any hardware firewall changes for the LAN's.

Now using location awareness as you suggest, using the default gateway as criteria.... that is interesting.  What comes to mind is how many "Locations" can be configured for a single group. Do you know if there is a limit on the number of locations one can configure on a single group?  

I have 15 to 20 subnets at any given time and all of them together comprise my corporate WAN. To use your location awareness suggestion in combination with the default gateway as criteria, would require in my envirionment the creation of 15 to 20 separate locations per group, wouldn't it? .  I think this is accurate, because to define a GUP and require a default gateway for a particular GUP to be used, would necessitate creating a separate location for each subnet that has a GUP. Right?  That is how it seems to me anyway.  Does this seem right to you in concept?

Something more for you. I recently restructured my SEPM groups in order to use location awareness for three reasons: Use a GUP in each subnet - secondarily to block wireless communications when a laptop is in the WAN - and thirdly to use a different SEP firewall policy when the laptop is not in the corporate WAN.  So, I restructured groups to have three levels: State Name as level 1.  City name as level 2 and Desktop and Laptop groups as level 3. The city name, or level 2, is the unique subnet level. To make a GUP function in this scenario I had to allow level 3 to inherit Level 2 policies and place the GUP at level 2. I found that putting the GUP at level 2 was required after looking at my testing results.  However, now that I have run into the problem of just how do I force a client to use a GUP in the LAN is it in, well.... this presented new challenges.  And that is why I posted here.

I wonder if it's better to restruction my groups into something different that I currently have, in order to obtain the functionality I need as described here.

Any further thoughts?

-IT Monkey Boy

around the Multiple GUP option that has been suggested by several people above.

When using the Multiple GUP option, the GUPs are only contacted if a SEP client determines it is in the same subnet as that GUP.  Use of the Multiple GUP option does not allow a SEP client to contact a GUP in a different subnet (unless it is the BackUP GUP).  No matter how open your network is, a SEP client will not contact a 'Multiple' GUP in a different subnet (this is part of the logic processes SEP uses to decide where to go for updates).

Only the "Single GUP" or "Backup GUP" can be contacted by SEP clients in different subnets.

That said, it does sound as if Multiple GUPs is best suited for your environment.

Hi,

I am not aware that multiple GUPs works only with class C subnet, I believe the subnet mask is used instead, it would make more sense.

By the way, as explained in other posts, the SEP clients are automatically picking the GUP in the same subnet, you don't have to configure your network to do it.

 would require in my envirionment the creation of 15 to 20 separate locations per group, wouldn't it?

Yes, unfortunately it would.

to define a GUP and require a default gateway for a particular GUP to be used, would necessitate creating a separate location for each subnet that has a GUP. Right? That is how it seems to me anyway. Does this seem right to you in concept?

Yes, again.

However, now that I have run into the problem of just how do I force a client to use a GUP in the LAN is it in, well.... this presented new challenges

See SMLatCST comment below. I have to agree with him, in your scenario, setting up multiple GUPs seems to be the easier / preferred method.

I wonder if it's better to restruction my groups into something different

Why do you have your Level 1 (State) & Level 2 (City) groups? Is it to make locating the client easier? Remember that the clients won't automatically change groups when they move to a different subnet. Also, even with Policy inheritence turned off, you can still share policies across different groups. You do not need / want to create a new policy for every new group. Trust me, keep your policies to a minimum.

All that being said, why not have one big flat group?

• Increase your view filter from the default 30 to 500+ & get all clients displayed on one page?
• Display networking info for clients & sort on IP address to get similar functionality of viewing your clients in their city groups.
• Use a multi GUP definition in your LiveUpdate policy.
• Your desktops will always be wired & therefore can share the same policy with laptops to have wireless disabled. It won't have any affect on them.
•