Endpoint Protection

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

Attachment(s)

LU_Policy_for_GUP.zip   1 KB 1 version

Remediate_GUPs Policy.zip   1 KB 1 version

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.

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?

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

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.

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.

any update on this...

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

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.

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.

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?

Brian,

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