locked
Backend database connectivity issue RRS feed

  • Question

  • I've just migrated my OCS to R2 and I've been fighting this one for some hours now and can't get to the bottom of if.

    I have an Enterprise pool with one server and a SQL Backend database in its own instance, (SQLSERVERNAME\OCS).

    The setup and deployment wizards of OCS worked fine and all the SQL databases were created ok. It also seems that the relevanct RTC accounts and groups were given permissions on the SQL database.

    The symptons, (and there may be more), are that it's not possible to conduct multi-party IM or conferencing and it's not possible to initiate Live Meeting. P2P IM is fine.

    I've checked all the obvious SQL server connectivity issues, permissions, instance network and protocol configuration, connectivity. OCS must have had full access to the SQL instance to build the databases in the first place. Can anyone help?

    In the OCS log I get these every 10 minutes;

    Event 30989 OCS User services
    Sending C3P request timed out. Conferencing functionality will be affected if C3P messages are failing consistently.
    Sending the message to https://poolr2.mydomainname:444/LiveServer/MCUFactory/ timed out. Error code is 2EE2.
    Cause: Check the eventlog description.
    Resolution:
    This can happen if the destination server above is overloaded and cannot process messages.

    Event 30988 OCS User Services
    Sending C3P request failed. Conferencing functionality will be affected if C3P messages are failing consistently.
    Sending the message to https://poolr2.mydomainname:444/LiveServer/MCUFactory/ failed. Error code is 2EF1.
    Cause: Network connectivity issues or an incorrectly configured certificate on the destination server. Check the eventlog description for more information.
    Resolution:
    Check the destination server to see that it is listening on the same URI and it has certificate configured for MTLS. Other reasons might be network connectivity issues between the two servers.


    Event 32065 OCS User Services

    Failed to send Http application request to service. Requests for this service will be retried but if this error continues to occur functionality will be affected.
    Url: https://poolr2.mydomainname:444/LiveServer/MCUFactory/
    Cause
    : Network related error or destination service being non-functional.
    Resolution:
    Ensure that the service is provisioned and functioning correctly. If any network related errors are reported by the service ensure that they are resolved.

    Event 51011 OCS MCU Factory
    Database connection failure.
    The MCU factory failed to connect to the rtc database located on the SQLSERVERNAME\OCS sever. Failure occurrences: 330, since 30/03/2009 09:42:32.
    Cause: Backend SQL server is not running.
    Resolution:
    Verify that there are no connectivity issues between the Front End and database.

    Event 21045 OCS Address Book Server
    Address Book Server was unable to perform its heartbeat function against the back-end database after 3 attempts.
    SQL Connection String: Data Source=VENUS\OCS;Initial Catalog=rtc;Integrated Security=SSPI
    Exception: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)
    Exception type: SqlException
    Cause: SQL Connectivity issues.
    Resolution:
    Verify that the RTCService account has access to the database and that the machine running the RTCSRV service has connectivity to the back-end server.

    Event 31147 OCS REsponse Group Service
    Cannot update active Match Making server because SQL Server does not respond.
    The service failed to register an active Match Making because of a failure to connect to the SQL Server.
    Exception: System.Data.SqlClient.SqlException - A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)
    Inner Exception: ~
    Cause: The server lost the connection to the backend database.
    Resolution:
    Make sure the machine has connectivity to the backend SQL Server.

    Monday, March 30, 2009 11:05 AM

Answers

  • Not sure what the problem was, I removed the instance from the SQL server, reinstalled a new instance and reconfigured the pool. All is well now.
    • Marked as answer by Tim Chapman Tuesday, March 31, 2009 11:17 AM
    Tuesday, March 31, 2009 11:16 AM

All replies

  • Not sure what the problem was, I removed the instance from the SQL server, reinstalled a new instance and reconfigured the pool. All is well now.
    • Marked as answer by Tim Chapman Tuesday, March 31, 2009 11:17 AM
    Tuesday, March 31, 2009 11:16 AM
  • We had the exact same problem (our back end was clustered and we have four front end servers) in our R1 environment with most of the same error messages - it took me a while, but here's what I figured out:

    As we have worked on the issue, we have determined that when the back end resources fail over, and the resources are not available when the front end responsible for the address book has a heartbeat, then there are problems that the system does not appear to be able to overcome.  We have found that timing is critical.  If an error is thrown by the front end, then the following ordered steps must be accomplished to get the system back:
    1. On a front end server, run the "dbanalyze.exe /report:diag" command from a command prompt - it is an OCS resource kit utility.  The output of the command will identify the front end responsible for the address book server.
    2. Shut down the front end service for the front end identified in step #1.
    3. Give the system several minutes - usually around 5 minutes - to allow it to select another front end server to be responsible for the address book.  Running the "dbanalyze.exe /report:diag" again will confirm that the role has changed.
    4. Once the role has changed, the address book can be regenerated manually or wait until the automatic cycle starts at 1:30am.
      Start the front end service for the front end identified in step #1.

    Note: Just "restarting" the front end service isn't enough - we've never been successful doing this.

    Thursday, May 28, 2009 9:48 PM