About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
An availability group can fail over in seconds and still leave users seeing errors for minutes afterwards. The database is ready on the new server, but the application has not found it yet. Much of that delay can come from the client side: which address the client tries, how long it waits on a dead one, and whether the application retries sensibly.
This article explains the settings Microsoft documents for each part.
Why it matters
A failover design is judged by how long the application is unusable, not by how fast the database moves. If clients take a long time to reconnect, or if they lose work and do not retry, the high availability investment does not deliver what the business expected.
How it works
The listener
Applications connect to an availability group through its listener: a network name that points at whichever server is currently the primary. When the group fails over, the listener follows the primary. If the replicas are on different subnets, the listener has an IP address in each subnet, and only the address in the current primary's subnet answers.
MultiSubnetFailover
The MultiSubnetFailover connection string option changes how a client connects to the listener. Microsoft describes it: The client driver attempts to open up a TCP socket for each IP address in parallel associated with the availability group. The first address to answer is used.
Microsoft advises setting it even for a single subnet: The MultiSubnetFailover connection option should be set to True even if the availability group only spans a single subnet. It readies clients for a later multi-subnet design and, Microsoft says, also speeds single-subnet failover through more aggressive connection retries.
Conditions apply. Microsoft states the option only works with the TCP network protocol and is supported only for connections to a listener or virtual network name. The client's database driver must support it. Microsoft's listener configuration page notes that ADO.NET on .NET Framework 3.5 SP1 and the SQL Native Client 11.0 OLE DB provider do not.
RegisterAllProvidersIP: which addresses DNS returns
When a listener is created with SQL Server Management Studio, Transact-SQL or PowerShell, Windows clustering registers all of its IP addresses in DNS (RegisterAllProvidersIP set to 1). Clients using MultiSubnetFailover try them all at once and connect quickly.
Clients that cannot use MultiSubnetFailover are worse off with this setting. Microsoft explains they will experience high latency connections. This occurs because these clients attempt connections to all IPs sequentially. For those legacy clients Microsoft recommends setting RegisterAllProvidersIP to 0, so only the active address is registered. Microsoft also notes that a listener created through Failover Cluster Manager has this set to 0 by default.
HostRecordTTL: how long clients remember the old address
With RegisterAllProvidersIP at 0, DNS holds only the current primary's address, and after a cross-subnet failover it changes. Clients that cached the old address keep trying it until the cache expires. Microsoft states: By default, clients cache cluster DNS records for 20 minutes.
Reducing the HostRecordTTL setting shortens that wait, at the cost of more DNS traffic. Microsoft's example uses five minutes. Microsoft also warns that with RegisterAllProvidersIP at 0, client recovery after a cross-subnet failover could be 15 minutes or longer, depending on your HostRecordTTL setting and the setting of your cross-site DNS/AD replication schedule.
Retry in the application
Even with the right settings, connections open during a failover can break. Uncommitted work can be rolled back, but a connection lost during commit can leave the client unsure whether the transaction committed. A failed client call is not proof of rollback. Microsoft explains this unknown commit outcome in its connection-resiliency guidance; the principle matters beyond that particular framework. Reconnect and verify a durable operation identifier or stored status, or use a tested idempotency mechanism, before replaying a payment, invoice or other write.
Microsoft.Data.SqlClient from version 3.0 has configurable retry logic, which Microsoft lists as covering failover among the failures retried when opening a connection. The default does not retry; it must be turned on. Microsoft's guidance for a safe retry policy includes:
- Retry an entire transaction, not one statement inside it. The built-in command retry does not retry on a connection with an active transaction.
- Retry commands only when repeating them is safe, or when the application has its own protection against doing the same thing twice.
- Bound retries by number of attempts and total delay, so an outage does not turn into sustained load.
- Log retries, to tell recovered transient failures from persistent problems.
What to choose and why
| Client situation | What Microsoft's guidance points to |
|---|---|
| Driver supports MultiSubnetFailover | Set it to True, single subnet or not; keep RegisterAllProvidersIP at 1 |
| Some clients cannot use MultiSubnetFailover | RegisterAllProvidersIP 0 and a shorter HostRecordTTL; expect slower recovery after a cross-subnet failover |
| Application built on Microsoft.Data.SqlClient 3.0 or later | Agree and test bounded retry with the vendor; resolve unknown commit outcomes before whole-transaction replay |
| Packaged application you cannot change | Ask the vendor which driver and connection options it supports |
For a packaged business application, the connection string may be in a configuration file the vendor documents. Changing it without the vendor's guidance can leave the application unsupported.
Risks and limits
- Test failover with the application running. On isolated test servers with synthetic data, fail over and time how long the application takes to work again, from the user's point of view.
- Old drivers are a hidden limit. One component on an old driver can set the recovery time for the whole application.
- Retrying non-repeatable work is dangerous. Include connection loss during commit in the isolated test. Repeating an invoice post or payment without checking durable status or idempotency can duplicate it.
- TLS certificates matter. Microsoft notes that with encrypted connections, the certificate on each server needs the listener names in its subject alternative names.
- No configuration commands are given here. Microsoft's pages include examples.
Sources
- Microsoft Learn: Connection resiliency: transaction commit failure and idempotency, source updated 2022-07-26. The commit-outcome principle is cited; this article does not prescribe Entity Framework configuration.
Opened 14 November 2026.
- Microsoft Learn: Connect to an availability group listener, source updated 2026-03-26.
- Microsoft Learn: Configure availability group listener, source updated 2025-11-27.
- Microsoft Learn: Configurable retry logic in SqlClient, source updated 2026-08-25.
Related service: Cloud hosting.
Related future topics
- High availability on SQL Server Standard edition.
- Patching SQL Server availability groups.
- Testing failover for hosted business applications.
Learning notes
- Failover speed and application recovery time are different measures.
- MultiSubnetFailover makes the client try all listener addresses at once; Microsoft recommends it even on one subnet.
- Clients that cannot use it need RegisterAllProvidersIP 0 and a shorter DNS cache time.
- Default DNS caching of cluster records is 20 minutes.
- A lost commit acknowledgement can mean the write succeeded. Verify durable status or tested idempotency before bounded whole-transaction retry.
This article was originally published on .