Endpoint Protection

I've been having trouble getting a GUP working on any of our smaller offices with SEP 11. I think I've identified the problem, but I don't how how to get around it.

We have many small offices. Each of those offices has a server that stands as both a domain controller and file server for the office. Since that server is always on, we thought it would make sense to also use it as a GUP for the office -- more reliable than using a client desktop that may not always be on, and puts the work on a server instead of a user's computer.

From some other posts I've read that the GUP needs to have the same LiveUpdate policy as all the other computers in that area, presumably to tell it that it's supposed to be playing the role of the GUP.

However, for other reasons we've already used groups to split up servers and clients, because servers are treated differently from all the other clients. We've got a lengthy exclusion list of database files, for instance, and of course we're using a different installer that provides antivirus and antispyware but not some of the other components, which aren't supported on servers.

Because there are a lot of clients, we have them broken down into groups/subfolders by office. For servers, since there aren't nearly as many of them, we had them all in a single folder/group.

But that's where I'm getting stuck. I was hoping I could apply the right LiveUpdate policy to specific servers, but it looks like I have to apply a policy to a folder/group, rather than to an individual computer. I can't move the servers into the same groups as the clients, because we'd lose the important exclusions. I guess what I may be left with is having to also break down the servers into various subgroups. It seems kind of silly to have to make 20 folders for 30 servers (one per office, plus a few extras at headquarters) with just one server per group in almost all cases. Is that really the way I need to go, or is there some other trick I'm missing?

Create a group for the servers and create a liveupdate policy for them with "localhost"  as the servername.
See this post my post in that thread.
https://www-secure.symantec.com/connect/forums/managing-hundres-gups

we have a much better solution coming soon, but for now as bjohn says, create a policy that sets the GUP to be "localhost" and apply it to your servers, then create policies for each site, pointing them to the appropriate GUP servername, it will work fine.

Open your SEPM go to Policy tab on the left.
Create liveupdate policy for each branch & under the GUP put in the IP Address of the server which you want to act as GUP for each branch policy.
Now for each branch make two group's server and client unchekc the policy inheritance.
Assign your liveupdate policy to the server and client group hence you will get same liveupdate policy. & you can keep all other policies defferent. That will give you what you want. 
This has worked for me several times. 
 

bjohn and paul: thanks. Using localhost is a trick that hadn't occurred to me. Crafty. I'll give that a shot.

kavishbakshi: that's roughly what I thought I was going to have to do, but I had been trying to avoid creating multiple server folders/groups, since we don't have that many servers and other than the GUP settings they all use identical policy. I think the localhost trick may be the more efficient answer here, but thanks for the suggestion.

Just confirming that this has done the trick for us. All the servers use localhost, the clients point to the servers, and everybody has stayed up to date over the course of the last week. It's a weird way to have to do it, but it works, and it's better than splitting the servers up into 20 different subgroups.

So, will this issue have a true fix on MR5?

Apparently not, kristopher.

Just wanted to give a warning that this technique apparently no longer works with MR5. Looks like now it's required that one subgroup/folder is required per independent GUP site, with a policy that explicitly identifies the GUP by name or IP. We had to switch over to something basically like how Kavin describes above to keep ours working when we upgraded.

Hi patty.

This is what I am going round and round with Symantec at the moment.

There should be NO need to create a group per site just to set the GUP anymore (you can indeed do this), but use the mutple GUP feature.

In older versions that was the only way, but reading and speaking toe veryone, you need to use the multple GUP options and create your rules.

Here are 2 things I am playing with that may provoke some thought:

1.  Create a dummy reg file.  Deploy this reg file to the machines out there you wish to be a GUP.  Create a rule referencing to this reg file.  Will mean machines with that reg file become GUP, so only need one group and 1 set of policies (no need for one per site and then trying to manage the monster!).

2. Choose multple GUP option again, but inputachines you wish to become GUP in the rule set.  Havent tested this yet, but the default behaviour is the client will only use a GUP on its own subnet (unless you configure other settings), so listing one machine from all sites into the Rule Set (choose Hostname/IP and type all hostanmes) SHOULD mean the clients all have a local GUP on SEPM#s GUP list.


I hope soemone from Syamntec can support/validate the above 2 options or even recommend a soltuion?

Multiple GUPs would be fine as long as they were pretty sensible about sticking to the right subnet. I'm a little skeptical, though. How would I be able to tell if the right computers are talking to the right GUPs? Is there a way to verify that?

Right now I'm having all kinds of trouble with all of my GUPs--none of the computers in the SEPM are reporting themselves as a GUP. (I've done the client search for GUP = TRUE, and I've just opened the details on all of the servers that are supposed to be GUPs, and they all report false.) I've configured the policy with the supervision of tech support, but policy seemed to spread slowly, so I let tech support go while we waited. Even over the weekend no server became aware that it's supposed to be a GUP, though.

I think my problem has been solved. Tech support had requested I change the policies for all of the GUPs, but I hadn't yet upgraded the client on those servers to MR5 (due to other issues with the way GUP policy had been handled). As soon as I remembered to upgrade the GUPs to MR5, they immediately started acting as a proper GUP. No reboot required, even -- despite the fact in other places I've seen documentation saying the reboot is required.

In an ideal world I'd mess around with the multi-GUP policy as Davinci suggests, but since I've already split up all the groups and already have 15 separate policies for 15 separate locations, I'd rather just leave it than take my chances that SEP is going to correctly identify subnets if I lump them all in together.