Video Screencast Help
Scheduled Maintenance: Symantec Connect is scheduled to be down Saturday, April 19 from 10am to 2pm Pacific Standard Time (GMT: 5pm to 9pm) for server migration and upgrades.
Please accept our apologies in advance for any inconvenience this might cause.

Servers cannot decide whether it is GUP or not

Created: 20 Nov 2012 | 11 comments

This problem has been perpetual, and I have tried troubleshooting it myself to see if there is a pattern. Just when I thought there was a solution, the problem has re-occured.

 

1. We have roughly 1000 servers that act as GUPs. For the past month, 200 servers stopped acting as GUPs even though they have the correct policy and are communicating with SEPMs.

2. All 1000 servers belong in a single group, and have the LiveUpdate policy that tells them, "If you belong to this group, you are a GUP". See the attached LU_Policy_for_GUP.zip.

3. I created another group with duplicate LiveUpdate policy that tells them, "If you belong to this group, you are a GUP". See the attached Remediate_GUPs Policy.zip

4. When I move the 200 servers from their original group, to this new group, they get the new policy, i.e. Remediate_GUPs_Policy. 150 of these 200 now show they are GUPs once again.

5. I move these 150 GUPs back into their original GUP group, where they belong.

6. Over several days, about 150 of these servers that were previously remediated and became GUPs are now, no longer GUPs again.

 

Why on Earth is this happening? What else can I do to troubleshoot and permanently resolve this issue? This makes absolutely no sense.

We have SEP RU7 MP1. Please don't say upgrade to SEP 12 angry

Comments 11 CommentsJump to latest comment

_Brian's picture

Also, if you could just test this on one of the affected clients now but in the Run prompt type smc -stop, wait 10-15 seconds and type smc -start and than check the system log to see if it became a GUP again.

I'm curious because this happens to me as well and doing this fixes it every time but I cannot figure out why. Seems to happen to me when client goes "Off Network" and comes back on but does't switch to the new location.

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.

RSASKA's picture

Holy Macaroni Brian!!!!!!!!

 

These GUP servers are actually Domain Controllers in our environment at various sites (that's just how it was decided).

 

When I log into about more than half of them, I get a pop-up asking for a reason why the server shut down.

 

Do you think that could be the reason? Or one of the reasons.

Seems to happen to me when client goes "Off Network" and comes back on but does't switch to the new location.

So Symantec, what is the workaround for this?

The Enemy's greatest fear is that you'll discover who you really are, what you're really worth, and where you're headed.

 

_Brian's picture

I've noticed this typically happens when the location switches to one where a GUP policy is not defined. ie. Off network.

If I check my logs further, I tend get "Client could not connect to SEPM" so it switches to Off network. This happens a lot in places where we have low bandwidth. Doing the smc -stop/start always fixes it or if I just leave alone they will eventually reconnect after a few hours and become a GUP again.

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.

RSASKA's picture

Brian,

 

I will define GUP policy for Off-Network ... I pray this should work because I am at my wits end with this!!!

The Enemy's greatest fear is that you'll discover who you really are, what you're really worth, and where you're headed.

 

Rafeeq's picture

can you say it happens on those who does not have explorer.exe running untill someone logs in?

RSASKA's picture

can you say it happens on those who does not have explorer.exe running untill someone logs in?

 

@ Rafeeq: Man, that's a raw deal from Symantec if that is the case. It's not feasible for a person to always log into the domain controllers, especially 1000+ domain controllers. I hope that is not the case. Right now, I am replacing sylink on the 50 or so servers that have policies from 2011 to

1 - see if they behave as GUPs

2 - see if they remain GUPs once I move them into their appropriate group where I can easily manage all our GUPs.

The Enemy's greatest fear is that you'll discover who you really are, what you're really worth, and where you're headed.

 

Mohan Babu's picture

any update on this...

Mohan Babu

moglie20@gmail.com

+91 9884382160

Your satisfaction is very important to us.If you find above information helpful or it has resolved your issue...please mark it accordingly :)

pete_4u2002's picture

check the communication between client to be GUP and SEPM and know if it is taking the policy assigned to it.

RSASKA's picture

Pete, the server takes the new policy, and initially becomes a GUP. After 24 hours, or some varied time, GUP status becomes false.

 

And in some cases, even if I give server updated policy, it reports that GUP is false.

The Enemy's greatest fear is that you'll discover who you really are, what you're really worth, and where you're headed.

 

_Brian's picture

I've noticed this for at least 2 years now so it's nothing new going all the way back to RU5 and now in 12.1 RU1

From what I've seen, it eventually re-enables itself as a GUP so I generally don't worry about it but I only have 85 GUPs.

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.

Ian_C.'s picture

I was wondering if 1000+ GUPs is not too large a number. Maybe the client can't parse the full GUP list in time to identify if it is a GUP, but at 85 that really shouldn't be a problem..

@RSASKA If you keep those 200 servers in th eGUP remediate group and don't move them back; do they remain GUPs? Do you share a policy between the two groups or are they identical policies, but still different objects in the console? Try sharing your original policy with your Remediate group?

Please mark the post that best solves your problem as the answer to this thread.