Video Screencast Help

Secars Even ID 4096 and 4097 in Event Logs SBS2003

Created: 30 Dec 2007 • Updated: 11 Jul 2010 | 22 comments
ObieOne's picture
Hi all,
 
 
But just noticed it is closed as per 6-dec.
 
I also came accross these release notes for SEPP MR1 : http://service1.symantec.com/SUPPORT/ent-security.nsf/docid_p/2007121216360648
 
But it is not showing any fixes for the Radius and IAS errors.
 
I wonder if somebody found a resolution for this issue?
 
Thanks,
Arno

Comments 22 CommentsJump to latest comment

Frank van Braak's picture
Nope... Same problem here... Was reading the same thread as you did, but for one reason it is closed at once...
 
And I still have the same problem as you do.
 
No IAS installed and no RADIUS server here.
 
Someone got a sollution?
ObieOne's picture
Hi Frank,
 
Good to now we are not the only ones still having this problem.
 
Did you install MR1 allready? I didn't.
I must say that I am a bit afraid of this product, since decend solution take so long.
Did you read through the release notes for MR1, huge list with fixes.
I am working on a virtual test environment for testing this product, before I install MR1 to our customers.
I'll keep you posted with my discovery.
 
 
Arno
 
Frank van Braak's picture
Maybe a stupid question, but how can I check if I installed MR1?
 
And where can it be downloaded if not?
 
It is some kind of a silly product... they promissed a **bleep** good piece of software. Better than everything before and faster etc... but nothing is truth so far.
 
Hope to get things fixed soon.
RedBully's picture
You can get some version information from clicking on Help and Support -> About in Symantec Endpoint Protection.
 
Also, I'm getting the same error (4096) in my event log  (running SBS2003) and I'm running SEP 11.0.1000.1375 and so presumably the same verions of SEPM.
 
To try and find some more information, I have run
C:\Program Files\Symantec\Symantec Endpoint Protection Manager\startup.bat with the following output
12-Feb-2008 15:01:38 org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-9090
12-Feb-2008 15:01:40 org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8443
Starting service SCM
Apache Tomcat/4.1.31
12-Feb-2008 15:01:42 org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-9090
12-Feb-2008 15:01:42 org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8443
StandardServer.await: create[8005]: java.net.BindException: Address already in u
se: JVM_Bind
java.net.BindException: Address already in use: JVM_Bind
        at java.net.PlainSocketImpl.socketBind(Native Method)
        at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:359)
        at java.net.ServerSocket.bind(ServerSocket.java:319)
        at java.net.ServerSocket.<init>(ServerSocket.java:185)
        at org.apache.catalina.core.StandardServer.await(StandardServer.java:463
)
        at org.apache.catalina.startup.Catalina.start(Catalina.java:472)
        at org.apache.catalina.startup.Catalina.execute(Catalina.java:350)
        at org.apache.catalina.startup.Catalina.process(Catalina.java:129)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:156)
Stopping service SCM
 
From this, I gather that port 8443 is currently in use and is stopping my SEPM from starting.
 
I'll add more info as I get it.
ObieOne's picture
Hello RedBully,
 
Your post really put some light to this issue.
I ran the same command on one of our affected boxes and found out port 8443 is not listed in our situation.
It is only trying to bind 9090. So I googled around for this port 9090 and it's specific function, but found no real info. Nothing related to the Radius or IAS issue anyway.
 
 
Here's the log:
 
12-feb-2008 16:40:31 org.apache.coyote.http11.Http11Protocol init
SEVERE: Error initializing endpoint
java.net.BindException: Address already in use: JVM_Bind:9090
 at org.apache.tomcat.util.net.PoolTcpEndpoint.initEndpoint(PoolTcpEndpoint.java:264)
 at org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:137)
 at org.apache.coyote.tomcat4.CoyoteConnector.initialize(CoyoteConnector.java:1238)
 at org.apache.catalina.core.StandardService.initialize(StandardService.java:532)
 at org.apache.catalina.core.StandardServer.initialize(StandardServer.java:2199)
 at org.apache.catalina.startup.Catalina.start(Catalina.java:462)
 at org.apache.catalina.startup.Catalina.execute(Catalina.java:350)
 at org.apache.catalina.startup.Catalina.process(Catalina.java:129)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:156)
Catalina.start: LifecycleException:  Protocol handler initialization failed: java.net.BindException: Address already in use: JVM_Bind:9090
LifecycleException:  Protocol handler initialization failed: java.net.BindException: Address already in use: JVM_Bind:9090
 at org.apache.coyote.tomcat4.CoyoteConnector.initialize(CoyoteConnector.java:1240)
 at org.apache.catalina.core.StandardService.initialize(StandardService.java:532)
 at org.apache.catalina.core.StandardServer.initialize(StandardServer.java:2199)
 at org.apache.catalina.startup.Catalina.start(Catalina.java:462)
 at org.apache.catalina.startup.Catalina.execute(Catalina.java:350)
 at org.apache.catalina.startup.Catalina.process(Catalina.java:129)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:156)
Catalina.stop: LifecycleException:  This server has not yet been started
LifecycleException:  This server has not yet been started
 at org.apache.catalina.core.StandardServer.stop(StandardServer.java:2166)
 at org.apache.catalina.startup.Catalina.start(Catalina.java:494)
 at org.apache.catalina.startup.Catalina.execute(Catalina.java:350)
 at org.apache.catalina.startup.Catalina.process(Catalina.java:129)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:156)
 
And here's what I found about 9090:
 
Port Number: 9090
TCP / UDP: UDP
Delivery: No
Protocol / Name: websm
Port Description: WebSM
Virus / Trojan: No
Explanation: UDP port 9090 uses the Datagram Protocol, a communications protocol for the Internet network layer, transport layer, and session layer. This protocol when used over PORT 9090 makes possible the transmission of a datagram message from one computer to an application running in another computer. Like TCP (Transmission Control Protocol), UDP is used with IP (the Internet Protocol) but unlike TCP on Port 9090, UDP Port 9090 is connectionless and does not guarantee reliable communication; it's up to the application that received the message on Port 9090 to process any errors and verify correct delivery.

 

Hope this will help a little further.

Arno

 

[edit]
I just noticed the management console is running on 8443, so if you close the console it will not be listed.

 



Message Edited by ObieOne on 02-12-2008 08:07 AM

RedBully's picture
I actually misread my output - it was port 8005 in my case that was blocked.
 
I've since found the following articles that were very helpful
 
 
 
and
 
 
The last of these was very helpful with information on tracking down what ports were being blocked and stopping SEPM from running.
 
In my case, it was port 8005 that was being blocked.  Looking up the PID (using netstat -ab | find "8005") I found that tomcat5.exe (apparently using its default port of 8005) was stopping SEPM from running (it uses tomcat too).
 
Further investigation has shown that it is Brightmail (using tomcat) that is causing my problem and that's because I'm running Symantec Mail Security for my exchange.  There's obviously a clash going on here and I've read another post saying that SEPM and MicrosoftExchange dont fit well together, and that SEPM requires 2GB memory to run (don't quote me).  I'm going to reconfigure my tomcat in SEPM to use another port.
 
 
RedBully's picture
This final post may be related for some readers.  Here is Symantec's Best Practices document for installing Symantec Endpoint Security 11.0 onto Microsoft Small Business Server 2003.
 
 
It includes information on running Symantec Mail Security as well as Symantec Endpoint protection and Symantec End Point Protection Manager on the same server.
 
ObieOne's picture
Hi RedBully,
 
Thanks for your troubleshooting tips.
However we seem to have a different problem.
Al the ports (8005, 8443 and 9090) are used by SymSvc (symantec epp).
Also all of our deployments are working like a charm except the to event id's in the log files every morning.
 
I also read the deployment guide allready a couple of months ago. But it is nothing stating about secars issues.
 
At least we got some lines for digging into our issue's.
 
Thanks,
Arno
RedBully's picture
Best of luck to you Arno.
 
Looks like from your log that port 9090 is being blocked so that SEPM cannot use it.  Try netstat -ab | find "9090" to find the PID of the process running on 9090 and then use task manager to find the program using that PID.  That might give you a clue.
 
As for me, I've cleared up my ports but SEPM is still not working.  The tomcat starts up ok it seems but the service is still stopping with the same 4096 error.  So I'm left investigating further.
ObieOne's picture
Hi all,
 
I've been investigating the above problem a little further and noticed the errors always pop-up at 4:00 am.
 
I tried checking what else is running at 4:00 am, but can not find anything solid.
The only guess I can make, is the update service (wsus) which is scheduled around 22:00 pm, but might still be running.
 
I am wondering if anybody has seen this as well?
 
Arno
ObieOne's picture
Hi all,
 
This is just to keep you informed.
I finaly took the dive and installed MR1 last weekend on one of our production servers.
Yesterday the eventID 4096 and 4097 did not show up in the logs, but this morning the errors were back again.
 
Also I must say the in line upgrade by pushing the new version out to the clients did not really go easy.
I had to recreate the install packages, because the applied features were not taken over by the upgrade on some of the clients.
Also there is a service left called Symantec Auto Update wich no longer exist after the upgrade. I simply disabled it for now, but will look foward on how to resolve this.
 
Good luck to you all,
Arno
 
ps Let's wait for MR2 by the end of this month. I would like to see the fix list for that one.
ObieOne's picture
Hi all,
 
Finally I got some sort of solution.
I was investigating some other problem at one of our clients sites and noticed the DefaultAppPool in IIS is refreshed at 4:00 am every morning.
This made me wonder so I set to 5:00 am on one of our troubled servers.
Guess what... The errors 4096 and 4097 now pop up at 5:00 am in stead of 4:00 am.
 
This meaning the problem is tackled, but now for the solution.
To give it a try I disabled the recycling feature, but by doing this there could be a lot of trouble in the future.
For now I will monitor and recycle by IIS by hand, but I am looking for a better solution.
e.g. set it on a memory interval.
 
Arno
Frank van Braak's picture
I am still having the same problems too.. You are right that the recycle of the application pool is the problem, but no sollution eighter here...
 
Is symantec busy solving this?
ObieOne's picture
Hi Frank,
 
Absolutly right.
I tested this very stricked.
If you set recycling to disabled the errors do not pop-up.
If you set recycling at 5:00 am the errors come up at 5.
 
I am very glad that we got at least the cause of this problem.
 
Unfortunatily I don't know is Symantec is looking into this for a solution.
Someone else knows something??
 
Arno :-)
Paul Murgatroyd's picture
I believe this is fixed in MR2
 

SEPM Process Event Log entries populated on Windows SBS Server

Fix ID: 1200391

Symptom: Event Log of SEPM Server populated with “Create Log File Error” and “Failed to start Radius Server” on a daily basis.

Solution: Added a new check for SEPM process that ensures its availability before attempting to create a log file or bind to a Radius port, thereby these event log error entries are not triggered.

Paul Murgatroyd
Principal Product Manager, Symantec Endpoint Protection
Endpoint twitter feed: http://twitter.com/symc_endpoint

ObieOne's picture
Hi Paul,
 
Very nice.
When will MR2 be released in Europe?
 
Arno
Kedar Mohile's picture

    Hello

All those facing this may like to try the following

  1. Start > All Programs > Symantec Endpoint protection Manager > Managemnt Server Configuration Wizard
  2. Run the Managemnt Server Configuration wizard and change the server port to 8440
  3. Complete the wizard
  4. Check if this resolves the issue
  5. If still not resoved
  6. Go to \Program Files\Symantec\Symantec Endpoint protection Manager\Tomcat\Conf\Server.xml
  7. Open Server.xml with a wordpad and change the tomcat port from 8005 to 8003
  8. Let me know if you still face any issues
  9. Restart IIS

Also to the best of my knowledge this issue is not related to MR1 OR MR2


Let me know if I could be of any more help regarding the same :smileytongue:



Message Edited by Kedar Mohile on 04-07-2008 12:17 AM

Sandeep Cheema's picture
Kedar says "Also to the best of my knowledge this issue is not related to MR1 OR MR2"
 
It would be fixed with MR2.
 
It's a conflict that has been discovered when the Exchange Maintaininace Cycle is started at 4 a.m. by default on a windows 2003 SBS.
 
 

De facto when AV does something, it starts jumping up and down, waving its arms, and shouting...

"Hey!  I found a virus!  Look at me!  I'm soooo goooood!"

ObieOne's picture
Hi,
 
I found this on top of the forum lists.
 
Expected early april. That is about NOW...right???
 
And I tought Microsoft was slow on fixing problems.
I am seeing this error since the release of this product in august 2007.
 
Arno
ObieOne's picture
Just for all your info.
 
MR2 really fixes this problem.
Behold however, Right now we have a new one on Mail Security.
All clients using Mail Security for Exchange (the SMB version) now get a runtime error when rebooting the server.
 
Details:
MS Virtual C++ Runtime Library
Runtime Error!
C:\Program Files\Symantec smsmse\6.0\server\savfmsesrv.exe
This application has requested the runtime to terminate it in an unusual way.
Please contact tech support.
 
Only clients where we installed MR2 have this issue.
 
Funny,
Fixing one, breaks the other.
 
Good luck
 
Alex-NetSol's picture

I have not tried Kedar Mohile solution, but I have MR4 installed and still get Secars 4097 error every morning at 4 am