Video Screencast Help

Configure SEPM so that Mobile SEP Client can look for Local GUP

Created: 14 Feb 2012 | 14 comments

We have approximately 1000 subnets.

Configure these 3 Regional SEPM sites so that:

 

1.       If Users are moving between sites… direct SEP client to just “look” for local GUP from where ever they access the network (any IP subnet)?

2.       Next, if there is no “Local GUP”, then point them to Live Update.

Comments 14 CommentsJump to latest comment

SMLatCST's picture

Is there going to be 1 GUP per subnet, or are you after a single GUP per regional site, kind of thing?

rjacobsii's picture

Yes, there will be a single GUP per subnet, unless the site has less that say fifteen users (no GUP).  If there is no GUP the plan is just direct the SEP client to Live Update.

rjacobsii's picture

Just want to direct SEP client to “look” for local GUP from where ever they access the network (any IP subnet)?

Is this possible?

rjacobsii's picture

"The page you requested was not found" reply on your second and third link?

Just want to direct SEP client to “look” for local GUP from where ever they access the network (any IP subnet)?

Is this possible?

rjacobsii's picture

"The page you requested was not found" reply on your second and third link?

Just want to direct SEP client to “look” for local GUP from where ever they access the network (any IP subnet)?

Is this possible?

pete_4u2002's picture

in any case to get the updates from GUP, the client should be able to connect to SEPM

rjacobsii's picture

Just want to direct SEP client to “look” for local GUP from where ever they access the network (any IP subnet)? Not Live Update...

Can this be done?

From your suggested url...

Solution

Setting up this feature requires the following steps:
Create a new "Location"

  1. Configure the criteria for "Location switching"
  2. Configure the LiveUpdate policy to "Use a LiveUpdate server"
  3. Configure LiveUpdate scheduling

About Policy Inheritance

Policy Inheritance can be used to centrally manage the custom location and apply it to several groups. If it is created in a parent group (for instance the default My_Company group), then all subgroups will also inherit the location switching policy.

Configure a new Location

    1. Click Clients in the left navigation bar.
    2. Under "View Clients" select the parent group you would like to apply the new location to.
    3. Select the "Policies" tab.
    4. Under Tasks, click "Manage Locations".
    5. Near the bottom of the "Locations:" section, click Add.
    6. Enter a Name for your location, a Description (if desired), and click OK.
    7. Ensure that the "Enable this location" option is checked.
    8. At the "Switch to this location when:" section, click Add.
    9. In the "Specify Location Criteria" window, select a desired criteria type in the drop down menu.
        1. Select "Management Server Connection" and select "If the computer cannot connect to the management server"
        2. Add any additional conditions using the AND/OR criteria (if desired).
    10. Click OK.
    11. Adjust the location check interval (if desired).
    12. Check the Enable location change notification box, if you wish a notification message to be displayed when the criteria for location change has been met.
    13. Click OK to complete the process. Your new Location appears under the Policies tab.
Jason1222's picture

Using location awareness, the clients will "know" where they are - by IP or subnet and communicate with the closest SEPM / GUP.

There are many links to different articles in the one.

This should do what you are looking to do.

SMLatCST's picture

First off, there's no inate ability for a SEP client to actively search a subnet for a GUP.  All SEP Clients receive a list of the GUPs (if you're using the Multiple GUP implementation) and it picks the GUP from that list that is on the same subnet.  If it can't find one, then it will go to the Backup GUP or SEPM.

Also, there is no way of getting a client to do a LiveUpdate from Symantec if it cannot locate a GUP.  The closest thing you're looking at is the LiveUpdate Schedule skipping options within the LU policy.  These options can tell a client to do LiveUpdate from Symantec if it's defs are too old (2days?) or hasn't contacted a SEPM in a while.

This is all further complicated by the fact you have three replicating SEP Sites.

In theory, you should be able to create a single LU policy that uses the Multiple GUP option to list all your GUPs (dunno if there is a limit to the number of GUPs that can be defined).  This will sort out the "Use a GUP if there is one" requirement.

The bit that complicates this is how your SEP Sites work (i.e. in the event of a SEPM failure, can the SEP Clients from Site A contact the SEPM in site B?  If so, then you will also need to enable  Location Awareness for your mobile clients to ensure they use the closest SEPM.  Each location will have a different Management Server List to idenfiy the SEPM for that site as the highest priority.

The reason this is required is because without it, you could end up in a scenario where a client from Site A is heartbeating to the SEPM ins Site A, but contacting a GUP in Site B.  In which case it'll likely fail.

NRaj's picture

Configuring multiple GUP is a simple solution. The machines will look for a GUP in the same subnet failing which they will contact the failover GUP. You can also configure them to get the updates from SEPM if they are unable to get the definitions after a period of time.

Using location awareness is a little complicated, but is efficient. You can create a location for every GUP and the locations conditions should be the IPrange which should correspond to that GUP. Then create an LU policy with the specific GUP and assign to the location.

Both the option works, we have tested.

dsmith1954's picture

Location awareness and a LiveUpdate policy for each location are the way to go.

You can create a location for a range of subnets, create a LiveUpdate policy for that location with that GUP (or multiple GUPS) designated, and then assign the policy to that location.

You have to carefully plan where to manage your locations. If you have multiple or nested groups, manage your locations at the top level. That way if a PC goes to a different location, those location policies will apply. You have to be mindful about groups that do not inherit policies. You'll see that when you go to assign the new policies.