Endpoint Protection

 View Only

What's new in Group Update Providers in RU5 release of Symantec Endpoint Protection 11.0 

Sep 22, 2009 11:05 AM

Group Update Providers: 


The Group Update Provider was a feature request to support designating a particular client to serve as a computer that will get content updates and publish them.
The computer that is downloading and publishing the content is referred to as the “Group Update Provider.” The computers in the client group will use the designated “Group Update Provider” as a local proxy for content updates. You use a LiveUpdate Settings Policy to configure the type of Group Update Provider.

In the latest release of Symantec Endpoint Protection 11.0 RU5, there are major enhancements to this technology. These enhancements expand the scope of functionality of a GUP by a large extent.

There are 3 new features added to the GUP mechanism:

1. Tagging
     The way this works is that you can define a system to be a GUP based on parameters such as: Operating System type, Computer IP address/Hostname, Registry Key – or a combination of any of those listed.

2. Roaming

-The systems that become GUPs, send that data to the SEPM to let them know that they are now a GUP. The GUP then populates a single list of all known GUPs. This list is provided to all SEP clients that are configured to use the GUP. The way this will work is that when a client talks to SEPM, and realizes it is time to update content, the SEPM tells the client to speak to the GUP, and the client looks at the GUP list to find the GUP on the same subnet as the client. If there is no GUP on that subnet, the client (optionally) can speak directly to SEPM, or another GUP.

3. Bandwidth Throtteling

This specifies to the GUP to not use x amount of Kbps, Mbps, or Gbps when speaking to the SEPM and pulling down content updates. This will help in the event that a system has been off the network for some time, and requires as an example, a full definition set. That is a 30-50MB download, so this setting will ensure that the network does not become saturated during this file transfer. Bandwidth throtteling is between GUP & SEPM, not the SEP clients and SEPM.

About the Types of Group Update Providers: You can configure two types of Group Update Providers

Single Group UpdateProvider:

A single Group Update Provider is a dedicated client computer that provides content for one or more groups of clients. A single Group Update Provider can
be a client computer in any group. To configure a single Group Update Provider, you specify the IP address or host name of the client computer that you want
to designate as the Group Update Provider.

Multiple Group Update Provider

Multiple Group Update Providers use a set of rules, or criteria, to elect themselves to serve groups of clients across subnets. To configure multiple
Group Update Providers, you specify the criteria that client computers must meet to qualify as a Group Update Provider. If a client computer meets the
criteria, the Symantec Endpoint Protection Manager adds the client to its list of Group Update Providers. Symantec Endpoint Protection Manager then
makes the list available to all the clients in your network. Clients check the list and choose the Group Update Provider that is located in their subnet. You
can also configure a single, dedicated Group Update Provider to distribute content to clients when the local Group Update Provider is not available.
You use a LiveUpdate Settings Policy to configure the type of Group Update Provider. The type you configure depends on how your network is set up and
whether or not your network includes legacy clients.

In other words, here are the steps we should take to confugre Group Update Providers:

  1. We define the conditions for a computer to be a GUP

  2. All the computers that fulfill that requirement, will report to SEPM that I can be a GUP

  3. SEPM will populate a list of all the GUPs

  4. When a client that is supposed to get updates from GUP, it will receive the list of GUPs from SEPM and choose the appropriate based on subnet

  5. If GUP is unavailable, client can optionally speak to SEPM and get definitions 

    Clients will receive list of GUPs is populated in a file called as globallist.xml.

GUP List is stored in C:\Program Files\Symantec\Symantec Endpoint Protection Manager\data\outbox\agent\gup

The file globalindex.xml contains information about the globallist.xml .


Note: It's applicable for SEP 12.1 Also.



0 Favorited
0 Files

Tags and Keywords


Jan 28, 2010 11:45 AM


This may help someone else... I found that my LiveUpdate policy listed my SEPM (RU5) server as a GUP (but it wasn't configured to be a GUP, that would be pointless).

Some of the clients had connectivity to SEPM but would attempt to use it as a GUP and not download any updates.

It's too bad that SEPM couldn't tell me that my LiveUpdate policy had a bad GUP listed or the clients could not report that the GUP they were attempting to use wasn't listening on the GUP port of 2967.  I only found that by using the SylinkMonitor and wondering why the client thought SEPM was a GUP.  Then, I found the problem (GUP) in the LU policy.

The fix was to uncheck the use a GUP option in the LU policy.

I have two questions on this situation:
  1. When I updated the LU policy to not use a GUP and clicked OK, it did not completely save the policy.  I say this because I opened the policy again and the checkbox for using a GUP was checked again but, this time, no GUP was listed.  Why would it do that?
  2. Why would some of the clients update from SEPM and some would not when they all had the same LU policy with the bad GUP listing (pointing to the SEPM as a GUP)?  Approximately 44% would not update until I unchecked the "use a GUP"  checkbox.
Thank you for the insightful information!

Nov 21, 2009 05:00 AM


An amazing Information on the GUP...

However, Just to add we would find few articles on the Symantec Knowledgebase as well... but I woudl say it does not explain in such vast details...

I found the following KB:

1) New features and functionality in Symantec Endpoint Protection Release Update 5 (SEP RU 5) Group Update Provider (GUP)


2) Configuring the Group Update Provider (GUP) in Symantec Endpoint Protection 11.0 RU5


3) How to locate the Group Update Provider (GUP) list in Symantec Endpoint Protection 11.0 RU5


I would says thanks to Aniket for putting so much effort on the above Topic...

Greatly Appreciated....

Nov 15, 2009 04:17 PM


I'm still a bit confused, I've started a separate thread asking how to setup GUP with 2 groups one for the servers and one for the workstations


Nov 13, 2009 01:06 PM

this really cool article, very explanatory.

Nov 12, 2009 11:24 AM

"...If there is no GUP in the same subnet, then the client will contact SEPM...."   this is what I wanted to know. Thanks!

Nov 12, 2009 09:50 AM


GUP list is sorted at the SEPM itself. When the client receives the GUP list, it will apply the subnet filter and will have a new list of GUPs in the same subnet. That is the list client will always be reading.

If there is no GUP in the same subnet, then the client will contact SEPM, IF IT IS SPECIFIED IN THE POLICY THAT IT CAN CONTACT SEPM. If SEPM is not to be contacted, then another option you can specify from the policy is to contact internet for the definitons.

If you do not want the clients to contact internet, or SEPM, and the client does not have any GUPs in the local subnet, then as you can understand, there is no source for the definitions to be provided.

Coming to your second question, about the load balancing, you can specify the maximum concurrent connection to a GUP from the Liveupdate policy. So, if you specify the limit to be 50, in that case, 51'st request will be denied, and the client will move to the next GUP in the list [ by "list", I am referring to the list created after the subnet filter is applied ].


Nov 12, 2009 08:37 AM

Aniket, sorry  for bringing up this again but if I got it corectly the "GUP list" will be read as sorted, no mater the location. So for the client, who has no GUP in same subnet will pick up the first available GUP , starting from the top. If no GUP online among those , it will go for the (Optional) GUP. No ping , no latency compare, no tracert , no nothing right. Just simple list reading.  So the client , having no GUP in their subnet, will contact the first one. What is the availibilty limit, do we have load balancing here?
Can we end up with 1000 client in the first GUP and none in the rest?

Nov 11, 2009 11:58 AM

I have about 150 clients out of 1500 that are still on mr4.  Each group that has a GUP is updated to RU5.  All mr4 clients are updating directly from the SEPM.

Nov 11, 2009 11:57 AM

I have about 150 clients out of 1500 that are still on mr4.  Each group that has a GUP is updated to RU5.  All mr4 clients are updating directly from the SEPM.

Nov 11, 2009 11:00 AM

Did you upgrade all the clients to RU5?

Nov 10, 2009 09:19 AM

I was running MR4 with a total of 1500 users.  800 of them are connected directly to the SEPM while the others are connected to about 160 GUPS.  Each GUP is located in the subnet that the users are connected to and no GUP has more than 15 users attached.  All was working well until I upgraded to RU5 and now all of my GUPS are not working.  

After i upgrade I noticed that the settings for my live update policies had been cleared out.  I have reconfigured all sites to have the same GUPS defined as before but now no one updates until the expired time runs and it gets its definitions directly from the SEPM.  I have done a client search and checked the XML file and it shows all of my GUPS as being active.  Has any one else experienced this problem? Thanks

Nov 09, 2009 12:53 PM

HI Andrey,

The client will receive a GUP list from SEPM. It will sort the list in an ascending way. It will contact the first IP in the list. If it is unable to contact that IP, it will contact the next GUP in the list, and this continues till the last IP in the list.

If none of the GUPs can be contacted, as you can see in the screenshot, you can specify one IP out of the subnet that can be contacted:
GUP other subnet.JPG

 then if allowed from policy, client will contact SEPM if that IP can not be contacted as well.

Let me know if this answers your question.


Nov 09, 2009 12:52 PM

HI Andrey,

The client will receive a GUP list from SEPM. It will sort the list in an ascending way. It will contact the first IP in the list. If it is unable to contact that IP, it will contact the next GUP in the list, and this continues till the last IP in the list.

If none of the GUPs can be contacted, as you can see in the screenshot, you can specify one IP out of the subnet that can be contacted:
GUP other subnet.JPG

 then if allowed from policy, client will contact SEPM if that IP can not be contacted as well.

Let me know if this answers your question.

Nov 07, 2009 02:32 PM

How exactly the client pick up a GUP , which is not in the same subnet?  Let's imagine it has to pick up among 20 GUPs from other subnets?
What does it use- ICMP ping to determine the fastest, or counts the hops for the nearest?
....If there is no GUP on that subnet, the client (optionally) can speak directly to SEPM, or another GUP.
End of Quote.
This is unclear. How exactly the client chooses to which GUP to speak to?

Oct 26, 2009 03:55 PM


In conf.properties, you need to put a new line:


This is how you can change the interval.


Oct 26, 2009 03:28 PM

We have a ~250 location bandwidth contsrained network with a server at every location.  We currently SAV  10.x  setup in a Primary/Secondary server setup.  Some locations {~5} are office buildings with multiple subnets but with one server.  Can I get the server to act as a GUP for all the subnets at the location by adding an IP address to the server for each subnet?


Oct 26, 2009 03:17 PM

From a previous post.

If you want, you can saggregate the entire configuration for GUPs for multiple sites in a single policy and make it working.

In the SEPM console, go to  clients tab-> search clients, and then you have to search for Group Update Provider = true.

1 minute interval is almost real-time update [ considering we dont change the configurations that often ].


How did you determine this 1 minute interval?    Are GUPs checking with SEPM every minute.  If so, how can we make this longer?


Oct 21, 2009 10:55 AM

Absolutely correct for the first point.

As far as the failover GUP field is concerned, you can enter that IP in a Liveupdate policy. That policy could be the one applied to the group in which GUP are created, or a saperate policy that has just that one IP address.

If you look at my previous answer :

" On the group that contains the clients that are intended to use GUPs, it is not necessary to apply the same policy which is applied to the group in which you want to create  GUPs."

I was referring to that scenario and hence mentioned about a new policy.

So, if you want to apply the same policy to the Groups that are creating GUPs as well as the group which are using GUPs then you are Correct.


Oct 21, 2009 10:44 AM

Aniket, thanks for your reply.

1. So the sentence in your article that says, "This list is provided to all SEP clients that are configured to use the GUP" should really say, "This list is provided to all SEP clients." Because all SEP clients automatically use GUPs, if on their subnet, or if the failover GUP on another subnet is specified. No other configuration is required. Correct?

2. And the last sentence in the message to which I am directly replying should say, "Because if clients are not in the same subnet (not Group) as the GUPs, then you need to specify the IP of a GUP in the Mulitple Group Update Provider List that applies to the Group that will use the GUPs." There's no need for a separate Policy for that Group, according to the Help file...just use the failover GUP field provided at the bottom of the Multiple GUP List dialog box. Correct?

Sorry if I seem like I'm splitting hairs, here...just trying to get some much-needed clarity.

Oct 21, 2009 10:13 AM

Hi Jeff & Kris,

On the group that contains the clients that are intended to use GUPs, it is not necessary to apply the same policy which is applied to the group in which you want to create  GUPs.

But the main thing is, the clients that intend to use the GUP must be in the same subnet as the GUPs for above statement to be true.

Because if clients are not in the same group as GUPs, then you need to manually specify the IP of GUP in a new policy and apply it to the group that intends to use the GUPs.


Oct 16, 2009 09:31 AM

Aniket, can you confirm Kris's understanding that it's necessary to have a GUP policy in place on the Group that contains the clients that are intended to use GUPs, and not just on the Group in which you want to create GUPs?

He and I are both trying to get some clarity on that. It's a nuisance to him, but it would be a deal-breaker for us, as described here: https://www-secure.symantec.com/connect/articles/whats-new-group-update-providers-ru5-release-symantec-endpoint-protection-110#comment-3092271

Oct 16, 2009 08:33 AM


As I have mentioned above, when the clients receive the GUP list, they will apply a subnet filter. As a result, they will get a list of GUPs in the same subnet. GUP can update the group it is configured for and its subgroups too.

Can you confirm that the machines you have configured to be GUPs have accepted the role and you are able to search for them using "SEPM->Clients->Search Clients-> group update provider = true" filter.

If the machines are acting as GUPs, then you can look into the VLAN configurations to confirm that the clients are able to contact the GUP on port 2967.


Oct 15, 2009 10:43 PM

Not sure if this matters... which I think it does.  These servers are different VLANS.  I have had to enable Telnet services on all three.  From the server itself I can telnet to the default telnet port of 23.  I get an Access Denied..... but I can at least hit the box from the box.  If I try to telnet from the server to port 2967 it hangs for a few secs then does the default could not open connection to host., on port 2967.

I will check with my cisco guy and see if our VLANS are passing through port 2967.  Could this be the issue?  If that port is blocked would that keep the Mangement server from creating the directories to store the GUP updates?



Oct 15, 2009 10:07 PM

Ok, I am still struggling with the GUP setup in RU5 and only having one GUP policy now.  Here are some screen shots of our current test/production system.  :)

This is a view of our clients... as you can see.  I am testing GUPS out on the 3 sites under School Sites called CSDES, LUKE, and WPTES.  These are three of our sites that have major bandwidth issues over our network.  The policies right now are all generic and are assigned at the School Sites level.


Just a screen shot of the policies assigned to the School Sites:


Basic LiveUpdate Server Settings I have set:


Getting into the GUP Settings. 


Now here is where I am either getting lost or something is not working right:


The above screen shot is what I now am testing.  The three IP's are at each site.  These are each DC's.  These are the only systems at each site that have a static IP address.

None of those servers even show that they are GUP's.  None of the clients are even connecting to those servers.  In fact, even with the policy set to only update from the GUP, they are still going to the SEPM to get updates.

The servers are in a different group then the clients.  The servers are on a different VLAN then the clients.  I have been told that I needed GUPS located within the same group that I am trying to assign a GUP.  Howerver, that is almost impossible or will be a lot of time.  I have also been told that the clients should look for these GUPs if they are on the same subnet?????

Can anyone help with this issue?  Any ideas?????



Oct 15, 2009 09:43 AM

I think, when a client will send an update request to GUP, it will download that definition from SEPM and create the folder SharedDefs to store it. I would suggest to have at lease 1 machine that does not have latest definitions to be in the same group as a GUP.

All the clients will always report to the SEPM only. Its just that the definitions will be provided by GUP.


Oct 15, 2009 09:19 AM

I have tried this but none of the systems that I have definded as GUP's are getting the directory where the files are stored and all my clients are still reporting back to the management server.

Oct 12, 2009 09:00 AM


Here's what I understand about the procedure for the GUPs to take the definitions:

1. Client contacts SEPM to get the latest content. Receives the latest index file.
2. From index file, it comes to know that the definitions are different from the manager. So it will send a request to create delta definitions.
3. After receiving this request, SEPM will start preparing the delta definitions.
4. When SEPM completes the delta creation, it will make those deltas available in IIS [ Inetpub\content\ ] folder.
5. SEPM will send the URL for this delta to the client.
6. Now, the client will contact the GUP configured to provide that delta. It also sends the URL for delta definition.
7. GUP realizes that it does not have that delta, so, it uses the same URL, and downloads the delta in its own cache.
8. As the delta is available at GUP, client will receive from the GUP.

So, to answer your question, a GUP will have the definitions from SEPM, only when it receives a definition request from a client.

Which GUP to  select, has been discussed in the earlier comments.

Let us know if you have any questions. This discussion is really getting interesting as we are discussing all the details about the GUP configuration.


Oct 12, 2009 08:20 AM

Could be wrong, not trying to come across as arogant, just searching for fact and want to learn how it works.

Oct 12, 2009 04:27 AM

We have 2 good people at Symantec looking and testing this today, so will psot feedback.  They will be checking with the EU lead on RU5 as well..

Initially he is under the impression and on the same wavelength as me that ONLY the elected GUP will get the def update from SEPM, NOT all on list!!!

I guess as RU5 and multple GUP's are still pretty new, myabe no one knows for sure??

Jeff, wil reply probably tomorrow, may shed some light on your pronlem.  I find a lot of theory answers and how it should/might work are posted, but need real-life stuff as well!

Oct 09, 2009 11:02 AM

Re-reading the passage you're referring to, I get a different take, and I hope it's not correct because if it is, my GUPs are being ignored (emphasis mine):

"This list is provided to all SEP clients that are configured to use the GUP."

I had thought that you use LU Policy only to designate which clients become GUPs, and that once a GUP was on the GUP list, clients would automatically use it.

Does the LU Policy for Groups in which you want clients to use GUPs need to have the "Use a GUP" setting turned on, but without designating the GUP?

What I have found, unfortunately, is that pre-RU5 clients get NO UPDATES AT ALL if an RU5 Multiple GUP LU Policy is applied to the Group that contains them. I will have pre-RU5 clients for at least a year. So I can't define the GUP on Groups that contain pre-RU5 clients. I had thought I had found a solution by defining GUPs in one group that contains only RU5 clients. But if the article is correct, and I have to enable GUP usage by non-GUPs, I may no longer have a solution, and my GUPs are unused.

I probably need to go back to the product documentation and re-read it there; hopefully that's where I formed my impression, and if so, equally hopefully, the product documentation is correct.

Oct 09, 2009 09:28 AM

Thank You very much Jeff,

So even if not elected to provide the update to clients, but qualifying to be a GUP in the first place, it actually becomes one and will download update anyway

I think Symantec expalined the election bit wrong to me, but thanks for clearing up1  They said qualifiying for a rule mputsthem on the GUP list, but they do not download an update until SEPM picks one from the list.

I think they meant to say, the eelction is between which GUP the clients connect to for its update, not which GUP downloads the update from SEPM - hope you can see what I am saying?  So all qualifiying GUP gets update from SEP regardless - I also agree with you, if that was the chance, no point in GUPs :-)


Bottom line - So it is not possible to specify a rule that says ANY pc can become a GUP, without them all becoming a GUP and nullifiying the need to configure the setting in the first place.

Oct 08, 2009 12:05 PM

It doesn't matter which machine is a GUP as long as it has the disk space, connectivity and spare CPU cycles to serve the role. And you can make any machine a GUP.

But you will not want to make every machine a GUP, which is what you appear to be proposing.

You want some small percentage of machines on each site, likely one or two machines, to be a GUP. I use DCs. You want to use print servers. That sounds like a winner.

If every machine is a GUP--

1. Every machine will be getting updates from a SEPM. So there's no point in having GUPs.

2. Every machine will be making content updates available to all non-GUPs. But there won't be any non-GUPs because you made them all GUPs. So there's no point in having GUPs.

Oct 08, 2009 11:27 AM

I still dont get it :-)

Why does it matter which machine is a GUP at any time it updates as long as one does it?

When I say SITE - I dont mean AD site, I mean branch office/users - we have 2 AD sites - we dont have DC's in user's office with the exception of head office (500 staf)

Would be more inclined to use print srvers or other proxies, but I would like (if possible) a blakc and white answer, to why it matters or not if you can make ANY Pc on site become a GUP??

Oct 08, 2009 10:54 AM

I have at least 1 DC at each site, and no more than 4 DCs at any site. So for this system, it has worked well to automatically make all DCs into GUPs by using this rule:


The danger is that if someone creates a share named SYSVOL on a workstation, it will become a GUP. But it would have to be an IT person, because all non-IT users here are standard users and can't create shares, so it's pretty unlikely. There's probably a more strategic entry to use that's guaranteed to exist only on DCs...this was just the one that occurred to me.


Oct 08, 2009 07:02 AM

Thanks for the reply - I understnad that.

From a best practice point of view, would you never specifiy ANY PC (i.e rule 1 = operating system = XP) - that is the only rule?  If I set this example  in THEORY any PC at site could become the GUP - now this make admin and config easier, but will having so many GUP's produce a performance hit?  Network util up?

I need to undersand the implication of the multpl GUP rules and wont you shouldn;t allow any PC to become one.

Hope I am making sense? :-)

Would save a hell of a lot of config to setup if can do the above, as all machines are from the same build/image.


Oct 08, 2009 06:56 AM

Reading your last comment I am now confused again :-)

I thought the whole thing around the multple GUP riules was to allow clients to be elected to be a GUP when a defintion request is processed?  i.e none are static/dedicated??

So now you seem to be saying (I apologise If I am wrong) all machine that qualifies to be a GUP downloads the defs from SEPm when an update is required?  I thought this action only happens by the elected GUP not all thise that qualiify - this seems a bit of a pointless setting (multple GUPs) apart from having a fancy way to define from i.e reg flag...

Just to resolve my confusion, can you maybe tell me the best way to configure the use of GUP across 250 sites?  Can I now not use muktple GUPs and have to go back to a policy/group per site stating the IP address of the GUP?

I hope you understand what I am saying/trying to explain :-)

Please correct me! 

Oct 07, 2009 10:30 AM


The main reason behind providing multiple rules in a ruleset is to seggregate the machines that you want to be a GUP from the others.
Its no ANY, but EVERY machine that satisfies a complete rule set will be a GUP. For that purpose, you need to identify the factors that saperate the machines acting as a GUP from other machines in the network.

e.g. In my network of 1000 XP machines, only those machiens will be a UP who have a particular registry key AND have pc-mrktg in their name etc..


Step 1 will be to identify the machines that you want to be GUP.
Step 2: see how they are different from the others.
Step 3: Determine how you can translate your requirement in terms of a rule set
Step 4:Apply the policy and make sure that only the intended machines are being shown as GUP.

To answer your question: [ what if all of my machines will become a GUP?: In that case all of them will get their definitions frpm the SEPM. Which defy the whole purpose of GUPs].


Oct 07, 2009 07:13 AM

For testing I have said ANY XP machine can be a GUP - that means ANY PC at sit, which will mean any client (6000) can be a GUP at 200 sites.

What issue could this config produce?  Whats best practive?  Want to avoid creating a group and polciy for every subnet manually!!

I know the list in the directory on the SEPM server will show all that can become a GUP, but how can I search/view the GUP that last performed the update or was the last ACTIVE (i.e past the defintion on)  - see all that can qualify as a GUP seems pointless.  Need to know or see which one if actually do the update!

Sep 29, 2009 10:50 AM

They would all become a GUP. Thats is the reason why its crucial to plan every detail of your deployment plan to avoid an infrastructure with 100 GUPs. One more thing, you CAN use windcard in computer names. [ e.g. comp1* ]

So, any computer that begins with Comp1 will be a GUP.


Sep 29, 2009 10:44 AM

What if I make a policy telling that XP's client's should be a GUP, would they first check the server to see if there is another one in the same subnet before becomming a GUP or would they all become a GUP then.

Sep 29, 2009 10:40 AM


Yep - thanks, that solved my AD sync issue :-)).

But the client is still listed in the GUP file, how often is this updated?

<?xml version="1.0" encoding="UTF-8"?>
<GupList NameSpace="rpc">
  <GupItem Address="" Port="2967" />

Sep 29, 2009 10:33 AM

Thanks again,

So, to summize.

If you want a GUP at 200 sites, you create and configure the rules in the GUP List and apply this to all locations, then machines matching these rules/conditions are vlaid for election and when other clients at site need to update, they are directed to local GUP.

i.e I only need to set this once and all clients will get an elected GUP based on local subnet?

Sounds really useful, now I think I understand it!

Sep 29, 2009 09:22 AM


Please use this command to remove any duplicate entries:


Sep 29, 2009 09:07 AM

Yes - this is also what I'm seeing - no matter what I do, I can't get this client deleted as a GUP.

I'm also having problems getting the client to migrate to the AD imported group, now it just stays under the default group. I have tried to delete it, with no luck.

If I search for the client, I will see it both in the AD group and under the default group where is stand as active.


If I look under the general tab for the client in the AD group, it has the Group Update Provider marked as TRUE.


Sep 29, 2009 07:31 AM

If you want, you can saggregate the entire configuration for GUPs for multiple sites in a single policy and make it working.

In the SEPM console, go to  clients tab-> search clients, and then you have to search for Group Update Provider = true.

1 minute interval is almost real-time update [ considering we dont change the configurations that often ].


Sep 29, 2009 07:24 AM

So do you still need a policy per site (old way of defining single GUP's) - or is this a single, standard policy that applies to all (or what clients you assign to) locations/subnets (obviously plus setting your criteria/rules for election)..

Just trying to get around if this still involved a lot of administration to set up.

I also presume in the conosle you can view what is a GUP at any given time (1 miniute check) and is real-time/uptodate?

Sep 29, 2009 06:18 AM


When the clients receive the list of Group Update providers, they will apply a subnet filter.
After the filter is applied, they will get the list of the servers in their own network.

So, I would suggest that you do the following:

Rule Set 1:

Rule: IP Address=
Rule: OS=Windows Server 2003 Enterprise Edition

Rule Set 2

Rule: IP Address:
OS: Windows XP Professional

IP Address of a GUP in a different Subnet if GUP on local subnet are unavailable:

sample policy.JPG

Let me know your thoughts on this.


Sep 29, 2009 05:52 AM


Anyone have idea in what the best approach would be here..

The case is that I have around 100 locations, where the network is split in three subnets on etch location - one for servers - sub1, one for clients- sub2 and one for network eq - sub 3.

Would the best GUP policy for this be, to appoint a known server in subnet 1 as GUP and then make a entry with this in multi gup optional for sub2, so when servers in sub 1 need updates, they would contact the server appointed in sub1 and if clients would need update they would choose the optional server in sub1 because they can't find any in there own subnet?

Anyone with another idea ?


Sep 29, 2009 04:58 AM


a GUP is defined by the conditions specified in the Liveupdate Policy. So, if you dont want a client to be a GUP, either modify the policy so that particular client machine will not pass the conditions, or make sure to change something at the client so that it will not comply with the conditions.


Sep 28, 2009 10:43 AM

You have to delete a client in order to remove it from the GUP list?? That's unfortunate.

If you're using GUPs with SEPM Groups imported from AD, you can't delete a client. Does that mean once a GUP, always a GUP?

Sep 28, 2009 10:06 AM

If a client is deleted from SEPM, it will be deleted from the GP List as well.

Also, SEPM keeps looking for status messages from GUPs every 1 minute.


Sep 28, 2009 08:43 AM

I have now install a client - promoted this to a GUP.

This worked fine and the clients was listed in the globallist.xml file.

After the test, I reinstall this client and removed the GUP settings in the liveupdate policies, but the client are still listed in the xml file.

Is there some sort of cleanup running on the GUP list?

Sep 27, 2009 11:44 PM

Hi Jeff,

You are right! The new clients will not be able to process the globallist.xml file which has the list of all the GUPs.

That is the reason I removed my previous comment to avoid posting inaccurate info.


Sep 27, 2009 11:41 PM

Cable, unfortunately, RU5 GUP features are not backward-compatible. RU5 clients (GUPs & non-GUPs) and RU5 SEPMs are required in order to take advantage of them.

Definitely worth the upgrade...this is the first GUP that really does what I want: To automatically turn all DCs into GUPs. Though I have to configure a registry query to do it, at least it works.


Aniket...thought I read in the documentation that legacy clients had to use the old-style single GUP setitngs. Do legacy clients know how to process the new GUP XML file?

Sep 27, 2009 11:23 PM

If at a location the PCs are MR3 and one PC acting as a GUP is RU5 will this still work?

Sep 25, 2009 07:46 PM



Sep 25, 2009 03:08 PM

The client on site A that has IP address will choose the GUP with IP, because it's on the same subnet (10.65.x.x)

The client on site B that has IP address will choose the GUP with IP, because it's on the same subnet (10.60.x.x)

If Site C has a GUP, its clients will use it. Likewise Site D. If C & D don't have GUPs, then they'll fail over to a 1st Priority SEPM, unless you've included the setting in the LiveUpdate policy that specifies a failover GUP.

Sep 25, 2009 12:23 PM

This release contains a new build of the Symantec Endpoint Protection Manager (SEPM version 11.0.5) and the latest version of the Client binaries (version 11.0.5). This version of the SEPM and Client binaries can be installed as a new install or as an upgrade to an existing 11.x installation.

With this MR5 release, SEP 11.0 now also supports Windows Server 2008 R2 and Windows 7.



Sep 25, 2009 12:17 PM

I am still a little confused....  still trying to figure out how to get the following done...

Site A (10.65.x.x)
Server (GUP)
Clients (Example) 10.65.31.x-10.65.34.x (DHCP Scope)

Site B (10.60.x.x)
Server (GUP)
Clients DHCP same as above...

Site C

Site D

So according to what I have seen I can add these 4 GUP's.  However, since my clients are all on different subnets how will they know what gup to use?

Sep 24, 2009 07:04 AM

GUP will be the centre of attraction from MR5 onwards

Related Entries and Links

No Related Resource entered.