Video Screencast Help

Update Distribution Point for Multiple Subnets

Created: 14 Jun 2012 • Updated: 08 Aug 2012 | 12 comments
indromojo's picture
This issue has been solved. See solution.

Hi Team,

I got some issue at my customer that using SEP 11 RU 6, currently they have many sites, and for each of their sites, there are more than 4 subnets, currently they are using GUP for the update distribution point, the challenges are:

 

The user at sites, are NOT ALLOWED to update the definition to the SEPM at HQ or to the INTERNET directly, so that we have to fully utilized the distributed update points (SEPM version upgrade are not an option in this case)

 

1. As we know, GUP only serving 1 subnet, so that to handle multiple subnet, we have to deploy multiple GUP

 

The operational team only want to establish maximum up to 2 distribution update point (which mean, if there are 4 subnets, it is not possible to cover the rest of the subnets)

 

2. we are looking for another option, LUA

 

But as we know, LUA is downloading an enormous product updates which is contain not only SEPM content, which can cause a huge amount of downloading traffic, any info how to modified LUA so that it can download only SEPM content (incrementally)?

 

3. or we have to deploy additional SEPM to facilitate this issue?

 

Need your advice on the best distribution update scenario for this issue :)

Comments 12 CommentsJump to latest comment

Mithun Sanghavi's picture

Hello,

In your case, I would request you to check this 2 Articles:

Managing LiveUpdate Administrator 2.x Space Usage

https://www-secure.symantec.com/connect/articles/managing-liveupdate-administrator-2x-space-usage

A Helpful LiveUpdate Administrator 2.x Analogy

https://www-secure.symantec.com/connect/articles/helpful-liveupdate-administrator-2x-analogy

Hope that helps!!

 

 

Mithun Sanghavi
Senior Consultant
MIM | MCSA | MCTS | STS | SSE | SSE+ | ITIL v3

Don't forget to mark your thread as 'SOLVED' with the answer that best helped you.

indromojo's picture

Hi Mithun,

 

Thanks for your reply, 

 

What is Taking Up So Much Space?

LUA 2.x can locally mirror everything that is on Internet-based LiveUpdate source servers.  That is an enormous amount of materials.  A common misconfiguration is just to "check" the entire product family when determining what LUA will download and distribute. 

The good news is that LUA allows excellent granularity.  If, for example, a company only uses the AntiVirus capabilities of SEP in their organization, LUA can be configured to download just the AV contents- saving many, many GB worth of materials that would never be used.  Here is an illustration of what to check (and leave unchecked!) in an organization of 32-bit SEP clients which retrieve their AV defs directly from the LUA server:

 
So at that point, now it is possible to make LUA only downloading SEP clients content update only?
is that confirmed?

Mithun Sanghavi's picture

Hello,

That is confirmed.

The following resources can help admins to determine how best to configure their LUA:

LiveUpdate Administrator 2.x: What product selections are needed for specific versions of Symantec Endpoint Protection?
Article URL http://www.symantec.com/docs/TECH139618

LiveUpdate Administrator: Product Selection Guide
https://www-secure.symantec.com/connect/articles/liveupdate-administrator-product-selection-guide

Hope that helps!!

Mithun Sanghavi
Senior Consultant
MIM | MCSA | MCTS | STS | SSE | SSE+ | ITIL v3

Don't forget to mark your thread as 'SOLVED' with the answer that best helped you.

indromojo's picture

Hi Mithun,

 

thanks, if possible i will communicate to you directly through email to avoid long list of thread reply :)

greg12's picture

1. As we know, GUP only serving 1 subnet, so that to handle multiple subnet, we have to deploy multiple GUP

A GUP can provide content to more than one subnet. Either you have to use a Single GUP, defined by IP address or hostname, or (if you are using multiple GUPs) you define a backup GUP which can accessed by all clients.

See this document:

Understanding and Identifying the different Group Update Provider (GUP) Options in SEP 11.0.5 RU5 and Later

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

The crucial point:

However, there are two situations where a GUP in a different subnet may be contacted:
  • If you have configured a "Backup" Group Update Provider on a different subnet (if Group Update Providers on the local subnet are unavailable). 
  • If you have configured a GUP from a different Subnet as a Single Group Update Provider.

So I think using two GUPs for four subnets should work flawlessly.

indromojo's picture

Hi Greg,

 

thanks for the info, i will try whether your / mithun solution will be applicable,

 

but if i may put a comment, the multiple GUP is defined as a fallback right? from my understanding,

the scenario will be (for eg the subnets will be : 10.1.1.x, 10.1.2.x, 10.1.3.x, 10.1.4.x) :

1. i will create new live update policy that will be applied to the client at one of the site (with multiple subnets)

2. i will choose the multiple GUP providers

3. i will assign one of the GUP (for example the ip 10.1.1.1)

4. i will put the OPTIONAL GUP (for example the ip 10.1.2.1) - different subnet with the first one

5. the client with the subnet other than subnet 10.1.1.x will able to download the update from the OPTIONAL GUP at 10.1.2.1 

 

 

CMIIW

Ian_C.'s picture

Do you really want a LiveUpdate server per site? That's Mithuns suggestion if you don't want clients getting updates across the WAN.

Greg's suggestion above doesn't really help because backup GUPs will get updates across the WAN if you only use ONE LiveUpdate policy.

Rather look at his later suggestion.

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

the scenario will be (for eg the subnets will be : 10.1.1.x, 10.1.2.x, 10.1.3.x, 10.1.4.x) :

1. i will create new live update policy that will be applied to the client at one of the site (with multiple subnets)

2. i will choose the multiple GUP providers

3. i will assign one of the GUP (for example the ip 10.1.1.1)

4. i will put the OPTIONAL GUP (for example the ip 10.1.2.1) - different subnet with the first one

5. the client with the subnet other than subnet 10.1.1.x will able to download the update from the OPTIONAL GUP at 10.1.2.1

Exactly. That should work.

(Small?) drawback is that clients in three subnets first try to find a GUP in their subnet (and fail) and then use the backup GUP.

Another solution (don't know if it fits better in your environment):

  • Define two Single GUPs, A and B.
  • Then create the four groups, G1, G2, G3, and G4 (one for each subnet).
  • Assign the LU policy with GUP A to the groups G1 and G2.
  • Assign the LU policy with GUP B to the groups G3 and G4.

Additionally, you can establish GUP B as backup GUP for G1 and G2 by defining an additional location for G1 and G2. If the regular GUP A is down (can be checked by the ICMP request condition), the clients in G1 and G2 will change their location and then use a LU policy with GUP B.

Of course, the same should be done with GUP A and groups G3 and G4.

 

SOLUTION
indromojo's picture

Hi Greg,

 

Understand, your new idea is for cross site update reference, i will try your solution, and will update you later on in this thread!

 

Thanks a bunch!

Ian_C.'s picture

As an alternative, have a look at my solution posted here: https://www-secure.symantec.com/connect/forums/multiple-sitesubnet-client-update-options#comment-7237411

 

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

SEP 11 RU 6

Any network using GUPs should upgrade to SEP 11 RU7 at an absolute minimum.  There are known issues with GUP in RU6.

Thumbs up to the suggestions about LUA - it is possible to download just the SEP client materials, and do so in small jobs. 

Hope thsi helps!!

With thanks and best regards,

Mick

indromojo's picture

hi all, thanks, forgot to update finally i updated the SEP to 12.1 and using multiple gup as i marked in the comment from greg above, thanks all