Endpoint Protection

This isn't my first rodeo with this problem, I mosltly fixed them by just follow my own Troubleshooting document:

SEPM 12.2 RU2 On windows 2008
SEPClient 12.2 RU2 on windows 7

1. Check if server is reachable from client: YES
2. Check connection status: Connected
3. What does secars says? Secar responded with OK.
4. In SEPM de computer has a green dot? YES
5. Is server updated? YES
6. Update content from run command on computer. Didn't Solve the problem.
7. Run Symhelp on server. No problem except then one we always have (diskspace 15/16gb i cleaned up to 20gb again, Not the newest version)
8. Run Symhelp on client. No problems except that we aren't using the newest version

Because there isn't a connection issue to the server i skipped other network tests that weren't related to SEP.

We use Locations, but in this case it really doesn't matter big cause we use internal, and the policy says Internal only download from SEPM. I changed something not big in the policy. The client donwload the policy and the change was there. I used a fake virus. It detected it and i saw it in SEPM to. So i'm pretty sure they are talking to each other. I only have this problem:

Another strange part. If updateis isn't catchable from SEPM it schould download from liveupdate. But they aren't even doing that.

I checked the license and its fine we are still under the maximum allowed clients.

Any one have a suggestion? I have +-600 computers with this problem. (totaal of 2200+)

Enable sylink debugging on one affected client so we can see the communication process.

I forgot to mention that i already have one running but still collecting data.

Thumbs up to .Brian, the sylink logs are definitely going to be of help here.

Something else worth looking at would be the log.lue file if you're wondering what's going with the LiveUpdates (and if they're even being attempted).

This log is in the below location on clients:

C:\ProgramData\Symantec\Symantec Endpoint Protection\CurrentVersion\Data\Lue\Logs

We have 2 GUPS but clients with location internal will never connect to them casue they have a policy without a GUP configuration.

Our GUPS are only used on sites where their connection can't handle the traffic. And the GUP station is one of thise that aren't updating .(The GUP itsself it didn't receive any new package since monday. (We discovered this problem yesterday.)

Normally liveupdate is disable on the client when they aren't external. (External location policy kicks in when SEPM is reachable after x time. In the first 24 hours they need to start liveupdate manual after 24 its start automatic.

We will check the log but i'm pretty sure liveupdate worlks cause my laptops has the new definitions now but i'm home so its use my home network and it automatically download the new definities from te net.

By the by, does the Intelligent updater (from the below page) work on these clients?

http://www.symantec.com/security_response/definitions/download/detail.jsp?gid=sep

As communications are seemingly fine, it might be worth checking if a representative client is even capable of updating...

You mentioned that your policy was configured so that the clients would LiveUpdate at some point.  I was wondering if the thresholds had been breached and if a LiveUpdate actually worked.

The tresholds are breached after 10 days intern. We fixed it before it was breached.

Last week i was on holiday so i wasn't focussed to solve this problem. A colleague tried to investigate further and we saw that the client communicated with the server and de server communicated with the client but they were just talking but they didn't get response from each other. Like they were talking next to each other.

Client asked update server didn't reponse, Server sended new policy, client accpted policy but didn't tell the server he received it, etc.

In the end we restarted the server again and it fixed our problem.

We got the same problem back, we restarted the server again and the problem was solved. So i did a deeper search to look at the real problem and i found in the sylink:

12/01 12:49:32.080 [5144] 12:49:32=>Send HTTP REQUEST
12/01 12:49:33.160 [5144] 12:49:33=>HTTP REQUEST sent
12/01 12:49:33.160 [5144] 12:49:33=>QUERY return code
12/01 12:49:33.160 [5144] 12:49:33=>QUERY return code completed
12/01 12:49:33.160 [5144] <SendRegistrationRequest:>SMS return=500
12/01 12:49:33.160 [5144] <ParseHTTPStatusCode:>500=>500 INTERNAL SERVER ERROR
12/01 12:49:33.160 [5144] <SendRegistrationRequest:>Content Lenght => 538
12/01 12:49:33.160 [5144] HTTP returns status code=500
12/01 12:49:33.160 [5144] <SendRegistrationRequest:>RECEIVE STAGE COMPLETED
12/01 12:49:33.160 [5144] <SendRegistrationRequest:>COMPLETED, returned 5
12/01 12:49:33.165 [5144] HEARTBEAT: Check Point 5.1
12/01 12:49:33.165 [5144] NextProxySetting: Will now use proxy setting 2
12/01 12:49:33.165 [5144] HEARTBEAT: Check Point 8
12/01 12:49:33.165 [5144] <PostEvent>going to post event=EVENT_SERVER_DISCONNECTED
12/01 12:49:33.165 [5144] <PostEvent>done post event=EVENT_SERVER_DISCONNECTED, return=0
12/01 12:49:33.665 [5144] HEARTBEAT: Check Point 1
12/01 12:49:33.665 [5144] HEARTBEAT: Check Point 2
12/01 12:49:33.665 [5144] <PostEvent>going to post event=EVENT_SERVER_CONNECTING
12/01 12:49:33.665 [5144] <PostEvent>done post event=EVENT_SERVER_CONNECTING, return=0
12/01 12:49:33.665 [5144] HEARTBEAT: Check Point 3
12/01 12:49:33.665 [5144] <RegHeartbeatProc>Setting the session timeout on Profile Session (Registration) to 30000
12/01 12:49:33.670 [5144] HEARTBEAT: Check Point 4

Can someone point me out what the most possibles causes are for 500 INTERNAL SERVER ERROR?

have you check replace sylink.xml ?

Does this client are upgraded for SEP 11 to SEP 12.x ?

After migration to 11.0 RU7 clients are not updating or connecting - Sylink.log 500 internal server error

run symhelp tool and check problem

Download the Symantec Help (SymHelp) diagnostic tool to detect Symantec product issues

They are new installations, so no upgrade from 11.xx, After restarting the server it resolves the problem but only for a while (around 3 weeks - 1 month) I don't think this is a clients issue. i'm more thinking its a problem with the webserver.

Run Symhelp on server. Not the newest version

Has nothing to do with clients, it's an issue on the SEPM side. I assume the service is started and running?

Upgrading to 12.1.5 would be only option to get rid of this issue.

Why? Cause it it worked for almost 2 years. So why shouldn't it work now? 

Yes cause around 700 clienst are still connected from 2200+. Around 1500 clienst aren't connected anymore. If we restart SEPM. They are connecting again.

When we have the problem i still can get into the SEPM console and do everything. Secars still say OK back.

SQL or embedded DB?

We use an SQL server.

Run management server configuration wizard. And in server name if you have IP, use the server name instead and completly the wizard. 

Glenn,

Your SEPM is not accepting connections from client, thats why you are getting 500. I dont know why but a restart seems to clear all the cache and it starts accepting connections again. One day or the other you need to upgrade to the latest version so was wondering if you can do it now. I know its not that easy for 22,000 plus clients. But the problem seems to be on SEPM and we dont have any options left

Apologies if I missed it but was a support case opened?

Not yet. Will probally do it today, the reason we didn't do it was cause till yesterday we weren't sure if we gonna stay with SEP for another year. And I was hoping i could fix this problem myself with the help of this forum.

I know but next year the chance is high that we will be using another Antivirus. I'm not sure if its a good idea to start an project for upgrading SEPM.

You have to know that our workflow for upgrading serversoftware is long (atleast a few weeks).

And if we do this i need to go with an new SQLDB cause the SQLDB it is on now is will be phased out in the next year. On top of it have some corrupted DB data (cause someone delete the old client packages from de de disk withour properly deleting them in SEPM first now i can't delete them in SEPM cause it can't find the package on the disk. the corrupted DB data has nothing to do with the problems i have now cause the data thats corrupted is already there almost from SEP11...