GUPs not in 'True' state
I am in the process of enabling approximately 50 GUPs across 50 LiveUpdate Policies. At the moment I have only 2 left that are not choosing to switch to a 'True' state. Working with Symantec Tech Support they have walked me through making sure that the GUP and SEPM are on the same AV version(which they are) and that both the group that the GUP resides in and the SEP clients reside in have the same Location available. Initially this appeared to be the issue and I assumed that after I added the same location my problem would cease but at the moment it still lingers.
Does anyone know of any other Tip or Tricks I should be using to get these remaining two GUPs enabled?
I am currently running 12.1 RU2 on both the SEPM and GUPs. My LiveUpdate Policy is currently configured in a Single GUP state.
Comments 10 Comments • Jump to latest comment
Did you use you the GUP monitor to verify? Some times the SEPM can be buggy with this.
SEP Content Distribution Monitor / GUP monitoring tool.
Or you can try this, go to the GUP. Start >> Run >> type smc -stop
Wait 10-15 seconds
Than do an smc -start
Check the System log on the client and it should say it is now acting as proxy (GUP)
SEP Knowledge Base
Endpoint SWAT
I did not have the GUP Monitor configured for SEP 12 but I've gone ahead and got it setup per the link you provided. Thank you.
After reviewing the GUP Monitor it is showing those two servers with green check marks by them. So I assume first if they are showing up in the list they are considered an active GUP and second if they have a green check mark by them they are in a good state.
So the next question is should I trust the GUP Monitor over what the SEPM shows?
Another question about the GUP Monitor, what is the yellow triangle next to the GUPs mean?
You can also verify on the GUP in the System log it will show it configured as a GUP.
Yellow means it is offline/not acting as a GUP
Do the smc -stop / smc -start and see if it comes back. Verify in the System log
SEP Knowledge Base
Endpoint SWAT
I decided to just telnet the GUPs that were reporting as good in the GUP Monitor but had been previously showing as 'False' in the SEPM and all of them repsonded on port 2967 like they are listening as they should now. So I went back and checked the SEPM to see the state of those GUPs and now they show 'True', It's strange, it seriously seems like once they were getting their status pulled by the GUP Monitor they started working.
Brian, as always thank you for your help.
Hello,
Could you try restarting the SEP client machines (which you are trying to assign GUP) and also make sure they have enough disk space on them.
You could also try the SEP Content Distribution Monitor / GUP monitoring tool.
http://www.symantec.com/docs/TECH156558
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
Can you try remove the Liveupdate Policy assigned to these 2 GUPs - create a new ones with same settings and assign it back.
SebastianZ
I have already tried the removal of the LiveUpdate Policy and creation of a new policy. This did not resolve the issue.
are the clients communicating?
have they received the new policy?
Cheers!
Pete
Help Link: http://www.symantec.com/business/support/overview.jsp?pid=54619
Yes, the clients are communicating and they have the most recent policy.
create a test group and apply the policy.
Cheers!
Pete
Help Link: http://www.symantec.com/business/support/overview.jsp?pid=54619
Would you like to reply?
Login or Register to post your comment.