Lesson Learned #433:Azure SQL Pre-login Handshake Error 64:”The specified network name is no longer”

This post has been republished via RSS; it originally appeared at: Microsoft Tech Community - Latest Blogs - .

Encountering error code 64 while connecting to an Azure SQL Database can be a frustrating experience for both DBAs and developers. The error often looks like this: A Connection was sucessfully establish with the server, but then an error occurred during the pre-login handshake (Provider: TCP Provider, Error:0 - The specified network name is no longer available) (Micorosoft SQL Server, Error: 64) - This article aims to clarify the potential causes of this specific error message and offers targeted solutions. Special attention is given to transitions from public to private endpoints within Azure SQL Database, which may trigger this issue.


What is Error Code 64?

This error suggests that although a connection to the SQL Server was initially successful, it failed during the pre-login handshake. This phase is vital in the SQL Server connection process, and failures here commonly indicate network-related issues, incorrect configurations, or software incompatibilities.

Common Causes and Solutions


1. Firewall Settings

Check that both the client and server have firewall rules allowing traffic through the SQL Server port, usually TCP 1433.

2. Network Reachability

Test the server's reachability from the client using utilities like ping or telnet.

3. SQL Server Configuration

Ensure SQL Server is set up to allow remote connections.

4. Protocol Mismatch

The server and client must be configured to use compatible network protocols, such as TCP/IP.

5. VPN and Network Drives

VPNs or disconnected network drives may interfere with database connections.

6. Logging and Monitoring

Examine SQL Server logs and the Windows Event Viewer for additional clues.

7. Software Updates

Update all systems, including the operating system and SQL Server service packs.

8. Timeout Settings

Adjust timeout settings to accommodate any network latency.


Special Case: Transitioning from Public to Private Endpoints

Switching between public and private endpoints in Azure SQL Database can lead to new challenges:

  1. New IP Address: Changing to a private endpoint assigns a new IP address to the SQL Database. Update firewalls and DNS settings accordingly.

  2. Azure Peering: Verify that Azure Peering is correctly configured to support the new private endpoint.

  3. Network Isolation: Increased network isolation could disrupt existing data flows and integrations.

  4. Connection Strings: Update application connection strings to reflect the new endpoint.

  5. DNS Propagation: DNS changes may take time to propagate, potentially causing interim connectivity issues.


In this specific scenario using a private endpoint as we explained before the peering networking of our customer has was not correctly configured with this new configuration. Once the fix was complete our customer was able to connect to their Azure SQL Database.



Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.