SQL Server Always on AG group failing to failover to secondary

Narasimha G 45 Reputation points
2026-04-14T10:43:25.8733333+00:00

We are experiencing SQL Server Availability Group failover issues. The same problem is occurring across multiple Availability Groups on the same server. We identified that the ODBC drivers were uninstalled and have since reinstalled the drivers and rebooted the servers. However, we are still encountering the ODBC connection errors shown below. We have not been able to find any documentation or articles that reference or resolve these specific errors.

Please let us know if anyone experience

[Verbose] 0000187c.00002628::2026/04/14-08:49:42.663 INFO [RES] SQL Server Availability Group <testAG>: [hadrag] The PendingTimeout property has a value of 180000

[Verbose] 0000187c.00002628::2026/04/14-08:49:42.665 INFO [RES] SQL Server Availability Group <testAG>: [hadrag] Connect to SQL Server ...

[Verbose] 0000187c.00002628::2026/04/14-08:49:42.665 ERR [RES] SQL Server Availability Group <testAG>: [hadrag] ODBC Error: [IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified (0)

[Verbose] 0000187c.00002628::2026/04/14-08:49:42.665 INFO [RES] SQL Server Availability Group <testAG>: [hadrag] Could not connect to SQL Server (rc -1)

[Verbose] 0000187c.00002628::2026/04/14-08:49:42.665 INFO [RES] SQL Server Availability Group <testAG>: [hadrag] SQLDisconnect returns following information

[Verbose] 0000187c.00002628::2026/04/14-08:49:42.665 ERR [RES] SQL Server Availability Group <testAG>: [hadrag] ODBC Error: [08003] [Microsoft][ODBC Driver Manager] Connection not open (0)

[Verbose] 0000187c.00002628::2026/04/14-08:49:42.665 ERR [RES] SQL Server Availability Group <testAG>: [hadrag] Failed to connect to SQL Server

[Verbose] 0000187c.00002628::2026/04/14-08:49:42.665 DBG [RHS] Resource testAG called SetResourceStatusEx: checkpoint 1. Old state OnlinePending, new state Failed, AppSpErrorCode 0, Flags 0, nores=false

SQL Server Database Engine
0 comments
Answer recommended by moderator
Anonymous
2026-04-15T07:15:00.7333333+00:00

Hi @Anonymous ,

This error indicates the cluster resource cannot find the expected ODBC driver (IM002). Since the drivers were uninstalled/reinstalled, the driver name likely changed. Always On AG uses an internal ODBC connection, not application connectivity.

Fix: Install the same ODBC driver version (or install ODBC Driver 17/18), validate with Test-OdbcConnection or sqlcmd locally on each node, and ensure the driver name matches what the cluster expects. Once ODBC connectivity works locally, failover should succeed.

Thanks,
Akhil.

Was this answer helpful?

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-04-14T10:43:55.17+00:00

    The errors indicate that the Windows Failover Cluster’s Always On resource DLL cannot create its internal ODBC connection to the local SQL Server instance. This is independent of application client connections and must succeed for the AG resource to come online and fail over.

    Key points from the log:

    • [IM002] ... Data source name not found and no default driver specified means the cluster resource cannot find the ODBC driver or DSN it expects.
    • [08003] ... Connection not open is a follow‑up error because the initial ODBC connect failed.
    • As a result, the AG resource goes from OnlinePending to Failed and automatic failover cannot complete.

    Actionable checks and fixes:

    1. Verify the correct SQL Server ODBC driver is installed
      • On each AG node, open ODBC Data Source Administrator (both 32‑bit and 64‑bit if applicable) and confirm that the expected Microsoft ODBC Driver for SQL Server version is present.
      • Ensure the driver version matches what the AG helper/cluster resource expects. If the driver was removed and reinstalled with a different major version, the resource may be referencing a driver name that no longer exists.
    2. Check DSN/connection configuration used by the AG helper
      • The Always On health monitoring uses a local ODBC connection to the SQL Server instance when a replica becomes primary. If that connection string references a DSN or driver name that no longer exists (for example, a DSN removed when drivers were uninstalled), the cluster will log IM002 and fail the AG resource.
      • Recreate any required DSN(s) with the same name and driver as before the uninstall, or adjust the configuration so the AG helper uses a valid driver and server name.
    3. Confirm SQL Server is reachable locally via ODBC
      • From each node, use a simple ODBC client (for example, sqlcmd or an ODBC test tool) to connect to the local SQL instance using the same driver that the cluster uses. This validates that:
        • The driver is correctly installed.
        • The instance is reachable.
        • Authentication works.
      • If this test fails with the same IM002 error, fix the driver/DSN configuration until a local ODBC connection succeeds.
    4. Review for health‑check timeouts and related AG issues
      • Always On uses a health check mechanism that establishes a local ODBC connection when a replica transitions to primary. If SQL Server does not respond within the health check timeout, a health event is triggered and the AG can move to the Resolving role and fail over.
      • After fixing the ODBC driver/DSN issue, monitor the SQL Server error log, Windows Failover Clustering logs, and the Always On dashboard for:
        • Health check timeout events.
        • Replicas stuck in Resolving or Not Synchronizing states.
      • Use the guidance in the health‑check and failover troubleshooting articles to investigate any remaining failover problems.
    5. If using Linux/Pacemaker AGs (for reference)
      • On Linux with Pacemaker, the AG helper also uses ODBC to connect to SQL Server. Misconfigured connection interval/timeout or driver issues can cause intermittent failovers. Ensure the ODBC driver and connection parameters in the Pacemaker resource configuration are valid and consistent across nodes.

    Once the ODBC driver and DSN/connection configuration are corrected and a local ODBC connection to the SQL instance works on every node, the AG resource should be able to come online and automatic failover should resume functioning.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.