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?

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

 

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.

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.

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.

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.

 

 

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.

 

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

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.

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

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.

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

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?

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.

 

Unfortunatily I don't know is Symantec is looking into this for a solution.

Someone else knows something??

 

Arno :-)

I believe this is fixed in MR2

 

Hi Paul,

 

Very nice.

When will MR2 be released in Europe?

 

Arno

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.

 

 

Ok, somebody any idea WHEN this MR2 will appear?

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

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