Hi,
So there isn't much here to see (I believe the CPU and memory counter errors are not important). But I do noticed the bind failure for the Radius port. I'm not sure if this is causing the issue or not.
In anycase, we still need to find the source of the HTTP 500 error. Here is the next set of steps I would recommend.
1) Look in the IIS Access logs (or Apache Access logs, for anyone reading who has 12.1+). The access logs WILL have the HTTP 500 -- although the access logs aren't likely to have a whole lot of information about "why", we should get every datapoint possible -- it might help.
2) Let's try solving the RADIUS port issue. Here is a command that will disable the Radius port in 12.1, I forget if this works in 11.6 or not. I don't think it does, but try it (It can't hurt):
a) Open your sepm\tomcat\etc\conf.properties file.
b) add the line: scm.radius.enabled=0
c) Save the file
d) Restart SEPM.
e) See if the error is the SecReg-0.log goes way.
On Windows 2008 SBS, I believe the RADIUS port is used by some "Remote Desktop Gateway" serivce. It's a service that allows you to RDP into the box remotely, I forget the excat name. This conflicts with the RADUIS port that SEPM setup incase you have SNAC. If you don't use SNAC, you don't need this port. In 12.1 I personally worked with making sure this port is disabled by default unless you actually have SNAC so you don't get this conflict issue.
3) If 2 didn't work, try disabling the Remote Desktop Gateway service just to test things out (that is, if your not using it to connect remotely.) Just to see if getting rid of the port conflict fixes the issue. If it does, and you need the Remote Desktop Gateway serivec, we'll troubleshoot that later.
4) If nothing has worked so far, let's turn up the log level in Secars to help us track down the error. One of two things is going to happen:
a) You will see the error is Secars.log, and it is likely to be helpful.
b) You will not see the error is Secars.log.
If you do NOT see the error is Secars.log after you turn on the debug mesages, it means the request is NOT getting to Secars.dll. This means that the request is getting stopped by IIS itself.
The flow is: Client > IIS > Secars > Tomcat > (Tomcat talks to database) > Send reply back to Secars > Send reply back to IIS > Send reply back to Client.
So first we'll start at Secars. Normally this is where you can find the error if it's anything to do with SEPM. If there is no error, then it's an issue with IIS and you've got to hunt down the IIS access logs -- you may have to enable the.
So, to enable Secars debugging logs do the following:
Open the regstry and browse to:
HKLM\SOFTWARE\Wow6432Node\Symantec\Symantec Endpoint Protection\SEPM\
(Note, since you're on 64 bit, you have to browse to the Wow6432Node key)Find the key "DebugLevel"
Set it to 4 (Decimal).
Open the SEPM\tomcat\etc\conf.properties.
Find the line scm.log.loglevel=
(If it's not there, create it.)
Set it to scm.log.loglevel=FINE
Save the file, restart the server.
Now, have you client attempt to log it. It should get the Error 500.
Note: Secars.Log does not write "live". It writes it batches, so after you get the error you have to wait a few minutes for the logs to be written to the disk. Or you can just stop IIS to flush the logs immediently.
Check the logs for the error. Again, if it's not there, you've got to troubleshoot IIS. If it is there, then we should have something to work with.
Debug logging takes a lot of space, and can hinder performance. So you'll want to remove it when you're done troubleshooting.