Group Update PRoviders in single AD container
Created: 06 Sep 2012 | Updated: 12 Sep 2012 | 15 comments
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.
Thanks
Discussion Filed Under:
Group Ownership:
Comments 15 Comments • Jump to latest comment
Remove old Comments
No,
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
http://www.symantec.com/connect/forums/gups-1
Thanks In Advance
Ashish Sharma
SEPM Knowledgebase Documents
Can anyone from Symantec confirm this please?
Hello,
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
https://www-secure.symantec.com/connect/articles/configuring-group-update-providers-symantec-endpoint-protection-110-ru5
Understanding and Identifying the different Group Update Provider (GUP) Options in SEP 11.0.5 RU5 and Later
http://www.symantec.com/docs/TECH139867
Best Practices with Symantec Endpoint Protection (SEP) Group Update Providers (GUP)
http://www.symantec.com/docs/TECH93813
Similar Issue - https://www-secure.symantec.com/connect/forums/can-gup-update-sep-clients-joined-another-domain
Hope that helps!
Mithun Sanghavi
Symantec Technical Support Engineer, SEP
MIM | MCSA | MCTS | STS | ITIL v3
Twitter: @mithun_sanghavi
Don't forget to mark your thread as 'SOLVED' with the answer that best helps you.<&a
Hi,
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.
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
Reference: http://www.symantec.com/docs/TECH139867
Chetan Savade
Technical Support Engineer, Endpoint Security
Enterprise Technical Support
CCNA | CCNP | MCSE | SCTS |
Don't forget to mark your thread as 'SOLVED' with the answer that best helps you.&
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.
Hi,
Could you please confirm SEPM version?
Chetan Savade
Technical Support Engineer, Endpoint Security
Enterprise Technical Support
CCNA | CCNP | MCSE | SCTS |
Don't forget to mark your thread as 'SOLVED' with the answer that best helps you.&
SEP 11RU7MP2.
Tested it with one GUP, it took almost 4 days to get the GUP port working again.
is the GUP registry entries exist on the client side?
is the globallist.xml has the IP address?
Cheers!
Pete
Help Link: http://www.symantec.com/business/support/overview.jsp?pid=54619
I can confirm that the globallist has the IP address. What is the GUP registry entry?
that is it is acting GUP, since it is in the globallist.xml then it should be fine. Are you still facing the issue?
Cheers!
Pete
Help Link: http://www.symantec.com/business/support/overview.jsp?pid=54619
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.
can you forcefull update any client for policy? does it not get assigned to GUP?
Cheers!
Pete
Help Link: http://www.symantec.com/business/support/overview.jsp?pid=54619
Have tried to do that and still nothing happens.
Did another forceful gp policy update and policy update and then it works.
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.
SEP Knowledge Base
Endpoint SWAT
Would you like to reply?
Login or Register to post your comment.