Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

GUPs not in 'True' state

Created: 01 Feb 2013 • Updated: 01 Feb 2013 | 10 comments
This issue has been solved. See solution.

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 CommentsJump to latest comment

.Brian's picture

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.

Article:TECH156558  |  Created: 2011-03-25  |  Updated: 2012-03-28  |  Article URL

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)

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.

SEP_FMI's picture

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?

.Brian's picture

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

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.

SEP_FMI's picture

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.

Mithun Sanghavi's picture


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.

Hope that helps!!

Mithun Sanghavi
Senior Consultant

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

SebastianZ's picture

Can you try remove the Liveupdate Policy assigned to these 2 GUPs - create a new ones with same settings and assign it back.

SEP_FMI's picture


I have already tried the removal of the LiveUpdate Policy and creation of a new policy.  This did not resolve the issue.

pete_4u2002's picture

are the clients communicating?
have they received the new policy?

SEP_FMI's picture

Yes, the clients are communicating and they have the most recent policy.