Video Screencast Help

Group Update PRoviders in single AD container

Created: 06 Sep 2012 • Updated: 12 Sep 2012 | 15 comments
ThaveshinP's picture
This issue has been solved. See solution.

HI All,

The AD admin guy wants to know if we can move all our 39 GUP's to a seperate AD container to keep track of all GUP servers and for easy administration/delegation purposes. Currently all the GUP's are placed in the AD container on the site where the workstations will access them.

I want to know if moving them will have any impact at all - will the workstations still get updates from the GUP even though the GUP is not in the same AD OU ? I know that previous versions stated that the GUP MUST be in the same AD OU - but what about the latest SEP 11Ru7mp2 version and SEP 12.1?

SEP 11RU7MP2 - all SEPM's and GUP's - AD integrated console.


Comments 15 CommentsJump to latest comment

Ashish-Sharma's picture

Remove old Comments


It's not impacting for updating systems

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.

.If we enabled the GUP’s, did we need to move all the GUP’s to one group?

Not required. machines that must be GUPs must get a LU policy defining them as GUPs. Clients that need to download from those GUPs must either get the same LU policy or a different LU policy wiht the same GUP definitions so that the clients know which machines must be GUPs

Check this thread

Thanks In Advance

Ashish Sharma

ThaveshinP's picture

Can anyone from Symantec confirm this please?

Mithun Sanghavi's picture


No, It wouldn't impact the Client machines.

This should work out fine provided that the systems at the new domain location are able to communicate with the systems on the original site.

SEP clients would need to be able to communicate with the SEPM on port 8014 and they would also need to be able to communicate with the GUPs on port 2967.

If you're using Windows XP as the GUP, it would be recommended to limit the amount of clients that are able to connect to update at one time because XP has a concurrent TCP connection limit of 10 & Windows 7 has a concurrent connection limit of 20.

So in summary, SEP communications do not have any dependancy on domain relationships so long as they are able to communicate with the other network.

Configuring Group Update Providers in Symantec Endpoint Protection 11.0 RU5

Understanding and Identifying the different Group Update Provider (GUP) Options in SEP 11.0.5 RU5 and Later

Best Practices with Symantec Endpoint Protection (SEP) Group Update Providers (GUP)

Similar Issue -

Hope that helps!

Mithun Sanghavi
Associate Security Architect


Don't forget to mark your thread as 'SOLVED' with the answer that best helped you.

Chetan Savade's picture


You are using Single GUP or Multiple GUP's?

It should work flawlessly if you are using Multiple Group Update Providers.

In RU5 or later (including SEP 12.1), any client that identifies itself to SEPM as a GUP will be added to the globallist.xml, regardless of whether they were initially configured as Single or Multiple GUP.

This "globallist" or "GUP List" will be presented to clients that are configured to use a GUP when the SEPM has informed them that new content updates are available. The list is applied in ascending order by the client, so if the IP Addresses are in the same subnet as the requesting client, it will use the GUP with the lowest IP Address on that list.

In this design, clients will only attempt to contact GUPs in their own local subnet. These GUPs will never cross a router or a gateway, so if there is a router or a gateway in between the two networks then clients will only use the local GUP


Chetan Savade
Sr.Technical Support Engineer, Endpoint Security
Enterprise Technical Support

Don't forget to mark your thread as 'SOLVED' with the answer that best helps you.<

ThaveshinP's picture

Using single GUP and tested it with moving a server to another AD OU. Server eventually stops being a GUP, then when it checks in again with the console , moves to the correct container and becomes a GUP after 2 days. However, in the console, the field still shows FALSE for the server that is now a GUP.

Any ideas as to why the field isnt updated inside the console, even though the server is now a GUP and working.

Chetan Savade's picture


Could you please confirm SEPM version?

Chetan Savade
Sr.Technical Support Engineer, Endpoint Security
Enterprise Technical Support

Don't forget to mark your thread as 'SOLVED' with the answer that best helps you.<

ThaveshinP's picture


Tested it with one GUP, it took almost 4 days to get the GUP port working again.

pete_4u2002's picture

is the GUP registry entries exist on the client side?

is the globallist.xml has the IP address?

ThaveshinP's picture

I can confirm that the globallist has the IP address. What is the GUP registry entry?

pete_4u2002's picture

that is it is acting GUP, since it is in the globallist.xml then it should be fine. Are you still facing the issue?

ThaveshinP's picture

The GUP we tested/moved took almost 3 days to become a GUP. Waiting now for the other 37 GUP's to take effect. Will let you know if there is any issues.

pete_4u2002's picture

can you forcefull update any client for policy? does it not get assigned to GUP?

ThaveshinP's picture

Have tried to do that and still nothing happens.

ThaveshinP's picture

Did another forceful gp policy update and policy update and then it works.

ᗺrian's picture

I would test this with one but if your moving to a group that wasn't setup correctly to identify the GUPs, the clients may not recognize the GUP and get updates from it.

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.