Reporting component not working
I've been working on this issue for a couple of weeks now with no luck. Our instance of SEP got corrupted so I'm doing a reinstall. However, I can't seem to get it working. I'm trying to install version 11.0.4202 MR4 MP2, but have also tried 11.0.4000 MR4 with the same result. Note that the server this is being installed on is a DC and also has Symantec Backup Exec on it (we don't have a lot of Windows machines, so we can't have a dedicated machine for this).
Originally, the SEP was SQL Server based (though on SQL Server Express - the person who installed it missed the fact that it's not supported). I've tried with SQL Server and Sybase Embedded options and am focusing on the Sybase option as that seems to be closer to working.
After a fresh install (not even trying to get the old data in), when it launches the SEPM, it errors out complaining that it can't communicate with the reporting component. Since I installed on our D drive instead of C, I added IUSR_SERVERNAME permissions to the \PHP directory, but that didn't do the trick. I've tried setting the DefaulAppPool Identity to Local System with no luck. I've also tried creating a separate App Pool and assigning the Symantec Web Server (a separate site, of course) to that, but same issue.
Eventually, I started looking at the PHP on the box. I modified the php.ini to set display_errors = on and got the following when I tried to log in via http://localhost:8014/reporting/login/login.php
Fatal error: Uncaught exception 'com_exception' with message '<b>Source:</b> ASAProv.90<br/><b>Description:</b> Specified database file already in use' in D:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\Inetpub\Reporting\Common\ado.php:40 Stack trace: #0 D:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\Inetpub\Reporting\Common\ado.php(40): com->Open('Provider=ASAPro...', 'DBA', 'xxxxxxxxxx') #1 D:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\Inetpub\Reporting\Common\connectdb.php(46): ado_connect(Object(com), 'SymantecEndpoin...', 'DBA', 'xxxxxxxxx', NULL, NULL) #2 D:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\Inetpub\Reporting\Resources\datetimejs.php(13): connectnav(Object(com)) #3 D:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\Inetpub\Reporting\Resources\includejs.php(33): include_once('D:\Program File...') #4 D:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\Inetpub\Reporting\Login\Login.php(20): in D:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\Inetpub\Reporting\Common\ado.php on line 40
Doing some troubleshooting, it seemed to not like the Symantec Embedded Database service running. So, I stopped that and now when trying to log into the Reporting site, I get:
Fatal error: Uncaught exception 'com_exception' with message '<b>Source:</b> ASAProv.90<br/><b>Description:</b> Database page size too big' in D:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\Inetpub\Reporting\Common\ado.php:40 Stack trace: #0 D:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\Inetpub\Reporting\Common\ado.php(40): com->Open('Provider=ASAPro...', 'DBA', 'xxxxxxxx') #1 D:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\Inetpub\Reporting\Common\connectdb.php(46): ado_connect(Object(com), 'SymantecEndpoin...', 'DBA', 'xxxxxxxxx', NULL, NULL) #2 D:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\Inetpub\Reporting\Resources\datetimejs.php(13): connectnav(Object(com)) #3 D:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\Inetpub\Reporting\Resources\includejs.php(33): include_once('D:\Program File...') #4 D:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\Inetpub\Reporting\Login\Login_verify.php(11): requi in D:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\Inetpub\Reporting\Common\ado.php on line 40
This seems to me like a database (or client access to database) issue, but I can't seem to figure out how to fix it without going through every PHP file, which would not be a fun time.
In addition, the scm-server-0.log file shows the following:
2009-07-14 17:06:09.033 SEVERE: Unknown Exception
java.sql.SQLException: JZ006: Caught IOException: java.net.ConnectException: Connection refused: connect
at com.sybase.jdbc2.jdbc.ErrorMessage.raiseError(ErrorMessage.java:557)
at com.sybase.jdbc2.jdbc.ErrorMessage.raiseErrorCheckDead(ErrorMessage.java:861)
at com.sybase.jdbc2.tds.Tds.handleIOE(Tds.java:3967)
at com.sybase.jdbc2.tds.Tds.handleIOE(Tds.java:3912)
at com.sybase.jdbc2.tds.Tds.login(Tds.java:440)
at com.sybase.jdbc2.jdbc.SybConnection.tryLogin(SybConnection.java:254)
at com.sybase.jdbc2.jdbc.SybConnection.regularConnect(SybConnection.java:230)
at com.sybase.jdbc2.jdbc.SybConnection.<init>(SybConnection.java:200)
at com.sybase.jdbc2.jdbc.SybConnection.<init>(SybConnection.java:134)
at com.sybase.jdbc2.jdbc.SybDriver.connect(SybDriver.java:179)
at org.apache.commons.dbcp.DriverConnectionFactory.createConnection(DriverConnectionFactory.java:37)
at org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)
at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:771)
at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:95)
at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:540)
at com.sygate.scm.server.db.util.DatabaseUtilities.getDefaultDatabaseConnection(DatabaseUtilities.java:215)
at com.sygate.scm.server.db.util.DatabaseUtilities.getDefaultDatabaseConnection(DatabaseUtilities.java:206)
at com.sygate.scm.server.metadata.MetadataManager.getConnectionNoCheckRequireTransactionId(MetadataManager.java:703)
at com.sygate.scm.server.metadata.MetadataManager.getConnection(MetadataManager.java:676)
at com.sygate.scm.server.metadata.MetadataManager.getConnection(MetadataManager.java:711)
at com.sygate.scm.server.db.util.DbHelper.getInstance(DbHelper.java:40)
at com.sygate.scm.server.db.util.DbHelper.getInstance(DbHelper.java:35)
at com.sygate.scm.server.task.AgentLogCollector.run(AgentLogCollector.java:69)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
Does anyone have any suggestions? I'm at the end of my rope here.
Comments
Unable to communicate...
Have you tested the ODBC connection ?
This looks lik e a 64 bit server so go to The 32-bit version of the Odbcad32.exe file is located in the %systemdrive%\Windows\SysWoW64 folder.
Test it and configure it using this document ...if still it not working..Clear out each entry and make everything blank..last admin might have made some changes in order for it to work may be..
http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2008042212582048?Open&seg=ent
You can also follow the other steps given in this doc and see if it helps resolving your issue.
VMWARE-- SEP 12.1 vs McAfee vs Trend Micro
Yeah, the ODBC tests complete
Yeah, the ODBC tests complete successfully, as long as I have the Symantec Embedded Database service running and choose TCP/IP as an option. However, the installer does not create a DSN for me and the app doesn't seem to use one when I create one manually (with the appropriate parameters). I get the same results whether the DSN exists or not. It's only whether or not the database service is running that will change the behavior.
I've already tried out everything in that document and everything responds as it should. PHP is working just fine, the app pool changes don't make a difference and there does not seem to be any permission issues.
What is the OS of your Server
What is the OS of your Server is it windows 2008?
Windows Server 2003 64-bit
Windows Server 2003 64-bit
check your communication
check your communication issue
Seems like this is a x64 / 64
Seems like this is a x64 / 64 bit OS.....
Also, since Internet Explorer Enhanced Security configuration may be anabled by default, try removing the same from the Add/Remove programs > Add/Remove Windows Components snap in and check if this resolves the issue.
Let us know what happens.
Abhishek Pradhan, PMP, MCT
Consultant | Microsoft Corp.
Blog: http://blog.abhishekpradhan.net | SIG Lead - Pune IT Pro (Microsoft Pune User Group) | http://www.puneusergroup.org
I'm testing with Firefox.
I'm testing with Firefox. I've tested with IE as well and gotten the same result.
Seems like a permission issue
Hello Hriley,
I speculate that this isse is because of a permission or database connectivity isssue, from the logs, i see that your password for DBA is xxxxxx, it would be good if u can test the db connectivity by checking the document vikram has sent, by setting the app pool to local system most of the times the issues get resolved, but it would be a security issue again, so never do that !
Check if u have any different version of PHP on the box , go to reporting virutal directory in IIS , right clik and try browsing it,let me know if it gives you a log in screen. ( i gues it would), try loggin in and u would see the log the same like what you got before, I would like to mention that these two log in methods are actually different( read in a document when I was working in Symantec :) ) please post those logs , let us know the results.
Rafeeq
Please don't forget to mark your thread solved with whatever answer helped you : ) Rafeeq
Just to be clear, that's not
Just to be clear, that's not actually the password. I changed it for this post. I've tested database connectivity via ODBC and I've also started up the Interactive SQL utility and am able to query the database that way.
The AppPool change didn't make any difference.
When I browse the Reporting site (http://localhost:8014/reporting), I get a login page, but when I log in, I get the errors. Either "Specified database file already in use" if the Symantec Embedded Database service is running or "Database page size too big" if it isn't.
What two log in methods are you talking about. Also, which logs are you looking for? If the output of when I try and log in to the reporting site, I posted that in the original message.
Thanks,
Hugh
ODBC
Are making changes in ODBC that opens up from Administrative tools or you are making changes on the Odbcad32.exe file is located in the %systemdrive%\Windows\SysWoW64 folder.???
If you have created one DSN or have made changes on the one that opens from Administrative tools then you are doing a mistake you have to use the other one.
VMWARE-- SEP 12.1 vs McAfee vs Trend Micro
That did it! SEP really isn't
That did it! SEP really isn't 64-bit ready in any way, shape or form, is it?
Many thanks for your help.
Hugh
Would you like to reply?
Login or Register to post your comment.