Endpoint Protection

Here is the error message. I have another thread, but this has been so frustrating that I want to start fresh.

GUP = Server 2008 64 BIT

Clients - WIndows 7 64 BIT

SEP 12

Application Event Viewer for gupdate:

The description for Event ID ( 0 ) in Source ( gupdate ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: Service stopped.

This is more related to MS Windows than anything. Is the machine fully patched?

What was going on again?You're GUP wasn't acting as a GUP?

It is, but the clients are not updating, ever since the 12 upgrade problems have become more extensive and much more complicated to fix :-(

I assume a client will update normally if you run LiveUpdate manually on it?

Is the correct policy applied to the clients? Seems like they don't know to get their updates from the GUP.

"Is the correct policy applied to the clients?"

It was fine up until January 30th

And you verified with the GUP monitor that it is acting as a GUP?

This is a tough one cause I can't see the policy.

Yes, with those files you sent me, I saw it was a GUP it is in fact missing a ton of updates, I am patching it now.

Generally it will come down to a lack of communication issue. Can you run sylink logging on a client? You will want to let it run so it picks up conversation with the GUP. This article goes into pretty good detail on GUP troubleshooting and sylink logging;

Troubleshooting the Group Update Provider (GUP) in Symantec Endpoint Protection (SEP)

OK, it will be morning reading.

Thanks man

I wonder if I should just re install SEP on the GUP.

Would that even make a difference?

I wouldn't. It became a GUP so you know it is working. I would run some logging on it per the above article and check that out first.

Check your GUP policy. Make sure the name of the GUP wasn't mistyped or if you do it by IP that the IP is still the same. Also check to make sure clients are bypassing the GUP in the policy for some reason.

28 updates were just installed. It was unpatched, still not in favor of re installaton? ;-)

I would troubleshoot communication first but if you can easily reinstall and reboot a server than give it a shot.

Let's see what the clients show in the morning. Then I will make the decision.

Hi,

Agreed with Brian81, Please check below link.

Check this Article these link should help you..

How to confirm if SEP Clients are receiving LiveUpdate content from Group Update Providers (GUPs)

http://www.symantec.com/docs/TECH97190

I would also suggest you to check the Articles below which may interest you:

Troubleshooting the Group Update Provider (GUP) in Symantec Endpoint Protection (SEP)

http://www.symantec.com/docs/TECH104539

Group Update Provider(GUP): Sizing and Scaling Guidelines

http://www.symantec.com/business/support/index?page=content&id=TECH95353&locale=en_US

SEP Content Distribution Monitor / GUP monitoring tool

http://www.symantec.com/business/support/index?page=content&id=TECH156558

Can you share with us the sylink log from one of clients that are supposed to get updates from this gup?

http://www.symantec.com/docs/TECH104758

Hi,

Check this article

Test SEP to GUP and GUP to SEPM communication

http://www.symantec.com/docs/TECH153328

Troubleshooting the Group Update Provider (GUP) in Symantec Endpoint Protection (SEP)

http://www.symantec.com/docs/TECH104539

Please attach sylink log from one of clients who is configured to take updates from GUP.

Can you please tell me where the file is???

Soon as I went to change the value, I got an error and could not change it.

Did you disable tamper protection before changing the value? That is likely why it wouldn't let you

Which log? sylink or debug?

Usually found at c:\

I am really confused about this whole thing. I don't understand any of the articles being sent to me and tamper protection has been off since SEP 11. It has never been on.

When I try to follow through with some, I get errors.

Please attach sylink log from one of clients who is configured to take updates from GUP.

I tried searching, but did not find it.

If you enable sylink logging, it will show the communication between client and GUP and from here we can see if it is even talking to the GUP or if it is, than why it is not receiving the updates.

When are you getting the error and what does it say? When trying to enable logging?

I tried to change the value from 0 to 1 in the registry and an error popped up.

The sylink file is located on root of C

it will be called sylink.log

Looked on the root of a client and of the GUP, I do not see that file on the C.

Sylink.log will be located on the path as set in registry during you have enabled logging:

http://www.symantec.com/docs/TECH104758

Step 5 is where it errors out

Enabling Sylink debug logging via the Windows Registry:

1. Click Start > Run
2. Type in: regedit and click OK
3. Navigate to: HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Symantec Endpoint Protection\SMC
4. Double-click smc_debuglog_on
5. Change the Value data to 1 and click OK

What's the error message? "Access Denied" ?

Yes.

You will get the access denied for registry changes if the Tamper Protection is enabled.

It isn't.

That's the only thing it could be..tamper protection prevents this reg change in 12.1

Check the tamper protection tab in the SEP client

Change Settings >> Select Configure Settings next to Client Management

Than see if it is enabled. Disable if so

I have checked on each client and the one common bond they all had was that the administrator account was disabled. I believe and HOPE that is why this has happened. I really don't know what else to do outside of opening a new case.

It is not Tamper protection, I have checked at the folder level and the top level, and Tamper protection is off.

I am guessing that since the clients had the administrator account disabled, that may have been what was preventing the updates.

Was it just recently disabled?

Tamper protection is a location based policy, so if you have inheritance unchecked for that group, it will no longer inherit from the top group so it could potentially be on even if top group has it disabled. I can't see any other reason why you can't make the reg change. Unless you have some GPO in place to stop reg changes (doubt it :))

Tamper protection is down from the top level and every sublevel.

Beats me than. Perhaps it than has something to with not being admin.

Here's a new twist, the machines that do NOT report current definitions are all 12. 2015 2015 clients

The ONLY one getting updated is the 11.x client.

Ok, so we at least know it works and policy is not somehow messed up, sort of

Other than having a different SEP version, is it the same as the others?

Can you confirm it wasn't updated manually?

I still think we need to see some sylink logs to verify communication.

I opened a ticket with Symantec, because I can't find Sylink logs