Endpoint Protection

I'm new to administrating SEP RU7 and have a question about configuring GUPs in an environment. I apologize if this has been answered elsewhere...

Here's the story:

We have a remote site whose bandwidth is getting eaten away by SEP updates (yes, very small data pipe) and we wanted to prevent this from happening by designating a client to be a GUP. So we found a test subject who was willing to do this and configured a single GUP live-update policy on that particular group. The remote machines are in a separate subnet from the rest of machines in the group (all of our groups are LDAP synched by the way). To paint a better picture, all the machines are apart of the same AD OU. We don't have this remote site in it's own OU.
From my understanding, machines that exist in the same subnet of the GUP should be the only machines checking in to the GUP. Other machines should go elsewhere depending on their subnet.
What we saw happen was that all machines in that group, regardless of what subnet they were in, started to check in with that single GUP. Obviously that machine got slammed and machines started to simply not update. We then removed the GUP and all machines besides that remote site's started to behave normally again.

Now, we have other groups that are set up with multiple GUP live-update policies that are not experiencing this issue. Another thing to note is that these other groups are in their own OU container in AD. So, technically, each OU has 2+ GUPs assigned to it.
 
Is this just something native to the single GUP live-update policy or did we just configure something wrong? Should we break out that small remote site into it's own OU?


Thanks for any help and let me know if clarification is needed.

Hi C8205 ,

How many machine in Total with Sepm's configured ?

Is Replication set ?

And how many GUP were configured in total ?

Telnet port for Gup machine to Sepm which is configured , might have to create exception in firewall configured if any .

It is working as expected. If you use multiple GUP option in LU policy, clients will receive updates from the GUP which is present in the same subnet. If you use single GUP option in LU policy, all the members of the group(s) which you applied will receive updates from that GUP irrespective of its subnet.

Agree with AravindKM. Additionally, have a look at 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

Most important for your issue are these statements:

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.

Firstly, the OU's in AD do not matter. What matters are the Groups you have defined in SEP. Obviously, if you sync with AD, then AD OU's influence your SEP Group. No matter what, ultimately you are concerned about your SEP Groups.

For your LiveUpdate policy which option for the 'Group Update Provider Selection for Client' did you choose in the following screenshot (ignore the numbers & arrows. I am re-using this screenshot)

If you chose the single GUP option, then all your clients would slam that one GUP.

Either add that remotes site GUP to the Multiple GUP list like everybody else

Or use location awareness and target different LiveUpdate policies at the various clients.

Thanks for the advice and sorry for the delay in response.

We were able to change the live update policy to be a multi-GUP one (however, there is still only one machine in the policy). We then forced a update on all the clients in that group (approximately 2000) so that they would then receive the new live update policy.

So far, 7 days later, no change. All machines are still slamming that GUP enabled device. The GUP itself is in a subnet with only 40 other clients, yet other subnets are checking in with it (even thought the live update policy isn't set up to allow clients to check in with a "Backup" GUP or the core SEP server).

This is very troubling to say the least and I'm starting to think something on our core SEP may be misconfigured. Is the policy just switching over to single GUP mode since the multi-GUP configuration only has one machine configured in it?

Again, thanks for any help on this!

After updating your policy, have the clients received the new policy? Compare the policy for the group in the SEPM console

with the policy displayed on the client under Help and Support -> Troubleshooting

If you have defined a single GUP in your LiveUpdate policy, all SEP clients should have a value of the GUP hostname in 'MasterClientHost' DWORD value in the Registry as per this document: http://www.symantec.com/docs/TECH104539

If both these criteria are correct, then I see no reason why your incorrect GUP is getting slammed.

Thanks for the responce! Yes, all the machines in that group have the same policy serial number (well, they are not all the same as there are sub-groups under the main one, but the dates all match up).

Here's the catch. It's a multi-GUP policy, however, only one system is assigned as a GUP. I wouldn't expect or want all machines in the group/sub-groups to have that GUP's machine in that registry key, only the machines that are on the same subnet of that GUP.

This is why I'm thinking that even though the policy is set up to be a multi-GUP policy, it's defaulting to single-GUP mode because only one machine is defined as a GUP currently.

We have other sites running multi-GUP policies that are working fine. There are a two differences however:

1. The other sites are in separate OUs in our AD structure

2. The other sites actually have multiple machines assigned as GUPs in their multi-GUP policy

Would it be worth breaking out that small remote site in AD and placing it in it's own OU? I'm thinking it wouldn't make much of a difference as there is no documentation specifically stating the environment needs to be set up that way.

Anything else I could try before contacting our Symantec Rep? Again, I appreciate the help with this!

I was able to get this going without needing a support call (which could use some work to begin with...). 

Instead of creating a new group in SEP, I simply created a new location in a existing group. Specified the IP address range and all the machines in that range recognized the new location. Then I applied the same LiveUpdate policy I had created before to the new location. The policy itself is still a multi-GUP policy with only one machine applied.