locked
OCS 2007 address book error - Address Book Server was unable to perform its heartbeat function against the back-end database after 3 attempts. RRS feed

  • Question

  • Hi all,
            We are having an issue with our OCS 2007 (r1) environment.

    There are load-balanced front end servers and previously a standard edition server (this was originally a test implementation)

    Users were migrated to the production cluster and the test box de-ccommisioned.

    It was after the decommissioning of the test box we noticed that clients were not able to get their address books.

    When running a abserver -sync or -regenUR, the following event is logged in the application event log

    Event Type:        Error

    Event Source:    OCS Address Book Server

    Event Category:                (1008)

    Event ID:              21045

    Date:                     3/24/2009

    Time:                     12:55:02 PM

    User:                     N/A

    Computer:          OCS1

    Description:

    Address Book Server was unable to perform its heartbeat function against the back-end database after 3 attempts.

     

    SQL Connection String: Data Source=(local)\rtc;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.

    so my primary concern is that the sql connection string is pointing to a local rtc database - when the database is actually located on a seperate SQL cluster.

    Does anyone know
    1) How to verify where the address book service is actually trying to build its address book from? (ir which SQL server it's really looking at? - Trying to work out if local is a furfie or it actually is looking locally)
    2) Have any other info on this issue and how best to troubleshoot it? Info on this error seems to be very thin on the web!
    3) I have already run abserver -validateDB, to no avail. (so its no use pointing me to the one article with an answer that google does find for it)

    Tuesday, March 24, 2009 10:54 AM

All replies

  • We've started getting the exact same issue.  We noticed that it started happening after we installed the April security fixes and rebooted.  Unfortunately, even after removing the hotfixes, the error doesn't go away (we think something may have been tattooed.)  Also, the users can not download the address book (which has not been regenerated since the hotfixes and reboot.)

    Any suggestions?
    • Proposed as answer by Veerakishore Friday, July 3, 2009 8:23 AM
    Wednesday, May 6, 2009 9:40 PM
  • We are also facing same issue any solution please
    Tuesday, June 16, 2009 2:53 PM
  • 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.

    Tuesday, June 16, 2009 3:23 PM
  • @ Sick....

    Thanks for update.
    In the process you mentioned in step number two do we need to shut down the front end or is it enough if stop OCS services on first front end.


    Friday, July 3, 2009 8:22 AM
  • Just shut down the service - you can do this via the OCS MMC.  Make sure you're only stopping the FE service in the FE that is responsible for the Address Book.  Don't stop the FE service on the other FE.
    Monday, July 6, 2009 3:02 PM
  • I logged in this morning and had the exact same issue. I found out through the OCS log files that all my RTC service accounts passwords had expired. I reset the passwords and set them to never expire. Then I restarted the services and address book error vanished.
    Monday, July 6, 2009 8:12 PM