Endpoint SWAT: Protect the Endpoint Community

Hi,

Is there a way to configure a LU policy that states - when GUP A1 is offline, it must start obtaining updates from GUP A as a failover and when GUP A1 comes back online- client stop getting updates from GUP A and start getting updates again from GUP A1. I don't want the clients to bypass the GUP and get updates from the SEPM.

Thanks in advance for any assistance.

Multiple Group Update Providers can function as a failover mechanism. Multiple Group Update Providers ensure a higher probability that at least one Group Update Provider is available in each subnet.

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

SEP Client to automatically locate its closest GUP

https://www-secure.symantec.com/connect/ideas/sep-client-automatically-locate-its-closest-gup

See here:

About configuring rules for multiple Group Update Providers

So does it mean that I use the explicit GUP option. When GUP A1 is offline - the client will default then to GUP A as long I setup the IP of the GUP A (different subnet). Both would be not be used - ? And does it also mean that when GUP A1 comes back the clients can see it - and not use the explicit GUP?

Mutliple GUPs are not what you are looking for. What you need is two LU policies with explicit GUPs (main & backup) applied to two locations (main & backup). The trick is to define the location switching criteria. The best option is on client side to run a scheduled scipt to see if its GUP is online or not and based on that modify registry key's value and change location according to it.

SEP clients work through the GUP options as listed in the LU Policy, so:

1. Multiple GUP first
2. If Multiple GUP is not available, use Explicit GUP
3. if Explicit GUP is not available, use Single GUP

As documented in the below article:
http://www.symantec.com/docs/HOWTO81148

And they should always try the above order each time they are told to grab defs (although not explicitly stated in the article)

Incidentally, if you have sufficient candidates in each subnet, you can also attain GUP failover behaviour by nominating more than one machine as a Mulitple GUP in each subnet.

What happens then is the one with the lowest numercial IP address is used as the GUP by everything in the subnet, and the other GUP (with the hiher IP address) is only used if the first is unavailable.  This behaviour is even true of the higher IP addressed GUP (i.e. it will update via the lower Ip addressed GUP instead of itself).

If only changing LiveUpdate options, there's usually no need to mess with the locations 

Will give it a go and test it using the Explicit GUP option(Primary) together with the Single GUP option(Backup)

What happens if I already have a GUP that is servicing other clients in another GROUP and I specify this GUP as the SINGLE GUP - will there be a clash when the single GUP is already in use or will it just provide updates until the explicit GUP is working?

You mean having a machine that is both a Single and Multiple GUP, correct?  That should just work (in the way that you hope it would).

The GUPs themselves are fairly simple, so the opportunity for conflicts is minimal.  Most of the decision making is done by the SEP clients themselves.

When I add the explicit GUP - what happens if I leave the client subnet empty? Do I have to enter a client subnet?

Without anything to match, that GUP just won't be used.

It's also worth noting that only specifying a GUP via the "Explicit" section won't actually enable the GUP functionality.  A client must be specified as a GUP via the "Multiple" or "Single" sections (and receive the policy) to know that it should be a GUP.

The 1 secondary GUP is already active for another group. Does this mean that I can't use this as a secondary and need to configure the Multiple GUP with the primary GUP and then the Single GUP with the secondary.
Problem I have is that there are 2 subnet's used in the same group -....

The way it is configured now:

Explicit GUP - has the entry for primary GUP

Single GUP - has the entry for the seconday GUP

Or should I rather configure it like this>

Multiple GUP - entry for Primary GUP

Single GUP - entry for Secondary.

If I understand correctly - the LU policy uses a top-down approach.

Just to clarify, you have 2 GUPs, Primary and Secondary.  And you have a group that contains clients in 2 separate subnets, and that neither of the GUPs are in the same subnets as the clients.  Is this correct?

If so, then (as long as the GUPs themselves are being told to be GUPs by a separate policy elsewhere) then what you have now is correct.

1. Explicit GUP entries tell the two listed subnets to use the same Primary GUP
2. Single GUP entry tells all clients to use the Secondary GUP

And the clients will move through them in that order (according to the article).

OK, thanks for the assistance.