Endpoint Protection

Hi,

I have a simple setup of one SEPM admin server and one SQL Database server.  I'm trying to prove/test the standard SEPM DR recovery process ( http://service1.symantec.com/SUPPORT/ent-security.nsf/2326c6a13572aeb788257363002b62aa/a0edb796f583c886882574aa004c1f60?OpenDocument ), by re-creating the two above servers (on different hardware and closed off network).

Both the SEPM (11.0.4202.75) and SQL Server (2005) have the same OS, name and ip address as the live systems and are sitting on a hub with a Domain controller that had been created and then pulled of the live network specifically for DR.

The SQL DB side has been recovered from the SQL .BAK file and the appropriate changes (see article https://www-secure.symantec.com/connect/articles/how-change-authentication-method-sql-windows-when-configuring-sepm-database#comment-3216111 ).
had been made so I could complete the SEPM Server reconfiguration process.

The SEPM server can see the SQL server  (under admin/servers) , but none of the policy's or the structure/location details appear in the SEPM admin console.

I also tried doing a backup of the database via the live SEPM server and restoring to the test SEPM server, but after the restore everytime I started the console it errored (failed to connect) as the SEPM service (semsrv) would just stop.

The only obvious differences are the SQL server running SQL 2005 SP3 and the live is running SQL 2005 SP2.
The SQL sem5 database location is on a different partition to the original (appropriatly configured for in the SEPM install process).
The SEPM server has 3/4 of a gig of ram rather than 1024MB (minimum spec).
Subnet masking is different to counter for the hub'd network

Has anybody tried recovering both SQL Server and SEPM server and experienced similar problems?
Am I correct in thinking that restoring the databse from the .BAK sql backup file is enough and I shouldn't have to go through SEPM's own ' Databse Back Up and Restore ' tool ?

Check the tables in the databases...
Check whether you are able to find all the tables related to client..? 

when you restored the DB using symantec backup and restore tool
did u check the scm-server.log file this would give you the reason why we are getting failed to connec to the server.
you can find the logs under
C:\Program Files\Symantec\Symantec Endpoint Protection Manager\tomcat\logs
paste the logs here

Hi, apoligies for the delayed response.

shp - yes I can see some details of client information directly on the SQL server - also the size describer by the SQL Studio app describes over 5 GB with only 800 Mb free.  So all indications so imply that the data is there.

Rafeeq - below is the scm-server.log....

2009-12-01 14:46:31.032 SEVERE: ================== Server Environment ===================
2009-12-01 14:46:31.048 SEVERE: os.name = Windows 2003
2009-12-01 14:46:31.048 SEVERE: os.version = 5.2
2009-12-01 14:46:31.048 SEVERE: os.arch = x86
2009-12-01 14:46:31.048 SEVERE: java.version = 1.5.0_15
2009-12-01 14:46:31.048 SEVERE: java.vendor = Sun Microsystems Inc.
2009-12-01 14:46:31.048 SEVERE: java.vm.name = Java HotSpot(TM) Server VM
2009-12-01 14:46:31.048 SEVERE: java.vm.version = 1.5.0_15-b04
2009-12-01 14:46:31.048 SEVERE: java.home = D:\Program Files\Symantec\Symantec Endpoint Protection Manager\jdk\jre
2009-12-01 14:46:31.048 SEVERE: catalina.home = D:\Program Files\Symantec\Symantec Endpoint Protection Manager\tomcat
2009-12-01 14:46:31.048 SEVERE: java.user = null
2009-12-01 14:46:31.048 SEVERE: user.language = en
2009-12-01 14:46:31.048 SEVERE: user.country = GB
2009-12-01 14:46:31.048 SEVERE: scm.server.version = 11.0.4202.75
2009-12-01 14:46:37.314 SEVERE: ================== StartClientTransport ===================
2009-12-01 14:46:38.485 SEVERE: Schedule is started!
2009-12-01 14:47:01.079 SEVERE: Unknown Exception in: com.sygate.scm.server.consolemanager.RequestHandler
com.sygate.scm.server.util.ScmServerError: Can't read local server from database!
 at com.sygate.scm.server.consolemanager.AdminAuthenticator.authenticate(AdminAuthenticator.java:134)
 at com.sygate.scm.server.consolemanager.requesthandler.LoginHandler.doLogin(LoginHandler.java:161)
 at com.sygate.scm.server.consolemanager.requesthandler.LoginHandler.getCredential(LoginHandler.java:119)
 at com.sygate.scm.server.consolemanager.requesthandler.LoginHandler.handleRequest(LoginHandler.java:50)
 at com.sygate.scm.server.consolemanager.RequestHandler.handleRequest(RequestHandler.java:112)
 at com.sygate.scm.server.consolemanager.RequestHandler.<init>(RequestHandler.java:79)
 at com.sygate.scm.server.servlet.ConsoleServlet.doPost(ConsoleServlet.java:82)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:199)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:145)
 at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210)
 at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596)
 at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433)
 at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:955)
 at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:139)
 at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596)
 at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:198)
 at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:594)
 at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433)
 at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:955)
 at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2460)
 at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:133)
 at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596)
 at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:119)
 at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:594)
 at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
 at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:594)
 at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433)
 at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:955)
 at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:127)
 at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596)
 at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433)
 at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:955)
 at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:157)
 at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874)
 at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
 at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
 at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
 at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
 at java.lang.Thread.run(Thread.java:595)
2009-12-01 14:47:01.157 SEVERE: Shuting down server ...
 

Are you given the same IP address and host name as the original server?
If no use the same IP addresses and Host name
Check the port no of the sql whether it is same as in the original server?
Try to login to SQL by using the SQL client which is present in SEPM
 

Thanks AravindKM,

The IP Address and the Host name of both the SEPM server and the SQL server are the same.  I didn't create any customised port no.s for SQL so I am assuming that they are by default the same.

Doesn't the fact that It accepts my login credentials when confiuring the SEPM server to link to the database SQL server prove that it can communicate already?

I have a look for the SQL client on the SEPM server and get back to you.

In SQL server open registry editor and go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\<MSSQL.x>\MSSQLServer\SuperSocketNetLib\Tcp\IPAll find out the value of TCPPort .This is the port the SQL is running
Open server.xml file which is present in \Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\tomcat\conf of SEPM ,in that one you can find out the value of SQL port it is using .It will be somthing like
<value>jdbc:jtds:sqlserver://<SQL server ip>:<sql port>/sem5 .By default the value of this port is 1433

Both should be same....

Both port references are the same and all the other surrounding details in the .xml document (ip address/database name) are also the same.

Any other suggestions?

Reinstall the SQL client in the SEPM and the SQL server
Restore the database as follows
Go to Services in Administrative Tools and Stop the Symantec Endpoint Protection Manager service.

Create the directory:
\Program Files\Symantec\Symantec Endpoint Protection Manager\data\backup

Copy your database backup file into this directory.


Go to your Start menu > Programs > Symantec Endpoint Protection Manager > Database Back Up and Restore.

Click Restore > Select the time stamped backup > OK.
Restore time varies, depending on the size of your database.

When complete, OK and Exit.

Reconfigure the server and try to login
-------------------------------------------------------------------------------------------------

Also assure that when you are able to login to SQL server using the SQL client which is present in SEPM and if you login you are able to see the SEM5 database.