Using ClientConnectionId to Correlate .NET Connection Attempts in Azure SQL
Getting Better Diagnostics with ClientConnectionId in .NET A few days ago, I was working on a customer case involving intermittent connectivity failures to Azure SQL Database from a .NET application. On the surface, nothing looked unusual. Retries were happening. In this post, I want to share a simple yet effective pattern for producing JDBC-style trace logs in .NET — specifically focusing on the ClientConnectionId property exposed by SqlConnection. This gives you a powerful correlation key that aligns with backend diagnostics and significantly speeds up root cause analysis for connection problems. Why ClientConnectionId Matters Azure SQL Database assigns a unique identifier to every connection attempt from the client. In .NET, this identifier is available through the ClientConnectionId property of SqlConnection. According to the official documentation: The ClientConnectionId property gets the connection ID of the most recent connection attempt, regardless of whether the attempt succeeded or failed. Source: https://learn.microsoft.com/en-us/dotnet/api/system.data.sqlclient.sqlconnection.clientconnectionid?view=netframework-4.8.1 This GUID is the single most useful piece of telemetry for correlating client connection attempts with server logs and support traces. What .NET Logging Doesn’t Give You by Default Unlike the JDBC driver, the .NET SQL Client does not produce rich internal logs of every connection handshake or retry. There’s no built-in switch to emit gateway and redirect details, attempt counts, or port information. What you do have is: Timestamps Connection attempt boundaries ClientConnectionId values Outcome (success or failure) If you capture and format these consistently, you end up with logs that are as actionable as the JDBC trace output — and importantly, easy to correlate with backend diagnostics and Azure support tooling. Below is a small console application in C# that produces structured logs in the same timestamped, [FINE] format you might see from a JDBC trace — but for .NET applications: using System; using Microsoft.Data.SqlClient; class Program { static int Main() { // SAMPLE connection string (SQL Authentication) // Replace this with your own connection string. // This is provided only for demonstration purposes. string connectionString = "Server=tcp:<servername>.database.windows.net,1433;" + "Database=<database_name>;" + "User ID=<sql_username>;" + "Password=<sql_password>;" + "Encrypt=True;" + "TrustServerCertificate=False;" + "Connection Timeout=30;"; int connectionId = 1; // Log connection creation Log($"ConnectionID:{connectionId} created by (SqlConnection)"); using SqlConnection connection = new SqlConnection(connectionString); try { // Log connection attempt Log($"ConnectionID:{connectionId} This attempt No: 0"); // Open the connection connection.Open(); // Log ClientConnectionId after the connection attempt Log($"ConnectionID:{connectionId} ClientConnectionId: {connection.ClientConnectionId}"); // Execute a simple test query using SqlCommand cmd = new SqlCommand("SELECT 1", connection) { Log($"SqlCommand:1 created by (ConnectionID:{connectionId})"); Log("SqlCommand:1 Executing (not server cursor) SELECT 1"); cmd.ExecuteScalar(); Log("SqlDataReader:1 created by (SqlCommand:1)"); } } catch (SqlException ex) { // ClientConnectionId is available even on failure Log($"ConnectionID:{connectionId} ClientConnectionId: {connection.ClientConnectionId} (failure)"); Log($"SqlException Number: {ex.Number}"); Log($"Message: {ex.Message}"); return 1; } return 0; } // Simple logger to match JDBC-style output format static void Log(string message) { Console.WriteLine( $"[{DateTime.Now:yyyy-MM-dd HH:mm:ss}] [FINE] {message}" ); } } Run the above application and you’ll get output like: [2025-12-31 03:38:10] [FINE] ConnectionID:1 This attempt server name: aabeaXXX.trXXXX.northeurope1-a.worker.database.windows.net port: 11002 InstanceName: null useParallel: false [2025-12-31 03:38:10] [FINE] ConnectionID:1 This attempt endtime: 1767152309272 [2025-12-31 03:38:10] [FINE] ConnectionID:1 This attempt No: 1 [2025-12-31 03:38:10] [FINE] ConnectionID:1 Connecting with server: aabeaXXX.trXXXX.northeurope1-a.worker.database.windows.net port: 11002 Timeout Full: 20 [2025-12-31 03:38:10] [FINE] ConnectionID:1 ClientConnectionID: 6387718b-150d-482a-9731-02d06383d38f Server returned major version: 12 [2025-12-31 03:38:10] [FINE] SqlCommand:1 created by (ConnectionID:1 ClientConnectionID: 6387718b-150d-482a-9731-02d06383d38f) [2025-12-31 03:38:10] [FINE] SqlCommand:1 Executing (not server cursor) select 1 [2025-12-31 03:38:10] [FINE] SqlDataReader:1 created by (SqlCommand:1) [2025-12-31 03:38:10] [FINE] ConnectionID:2 created by (SqlConnection) [2025-12-31 03:38:11] [FINE] ConnectionID:2 ClientConnectionID: 5fdd311e-a219-45bc-a4f6-7ee1cc2f96bf Server returned major version: 12 [2025-12-31 03:38:11] [FINE] sp_executesql SQL: SELECT 1 AS ID, calling sp_executesql [2025-12-31 03:38:12] [FINE] SqlDataReader:3 created by (sp_executesql SQL: SELECT 1 AS ID) Notice how each line is tagged with: A consistent local timestamp (yyyy-MM-dd HH:mm:ss) A [FINE] log level A structured identifier that mirrors what you’d see in JDBC logging If a connection fails, you’ll still get the ClientConnectionId logged, which is exactly what Azure SQL support teams will ask for when troubleshooting connectivity issues.Azure PostgreSQL Lesson Learned #3: Fix FATAL: sorry, too many clients already
We encountered a support case involving Azure Database for PostgreSQL Flexible Server where the application started failing with connection errors. This blog explains the root cause, resolution steps, and best practices to prevent similar issues.
Mobile Plans moves to the web
Windows is retiring the built-in Mobile Plans app to simplify how you connect your PC to mobile data. Instead of using Mobile Plans app to buy or manage cellular plans, you’ll use your web browser and the Windows Settings app going forward. This change means a more integrated experience: no extra app installations, just a direct link between Windows and your mobile operator’s website. In this post, we’ll outline why this change is happening, what the new experience looks like, and how it benefits both consumers and mobile operators. A more streamlined web-based experience Direct purchase on operator websites: Instead of launching an app, you’ll purchase and activate your cellular data plan directly on your mobile operator’s website. This change to a web-centric and operator-driven model better aligns with familiar experiences on other platforms. From Windows, when you want to add a mobile plan, you’ll navigate to your carrier’s web portal in your browser. Each operator will handle their own sign-up and payment flow. No separate app needed: Windows 11 has new built-in functionality to make this web-based activation seamless, meaning one less app installed on your PC. When you purchase a plan on the site of participating carriers, Windows might prompt you via the Settings app to share your device’s cellular identifiers (like EID, IMEI) with the operator. With your consent, these details are securely passed to the carrier, so they can automatically provision your eSIM without you needing to type in codes or scan QR images. You can then download and start using cellular data right away. By using industry-standard web flows, HTTPS, and confirmation steps, this system remains streamlined and secure. Timeline of the transition Windows already supports activating eSIM using the web, via QR codes, and manual entry. The new experience to share your device’s cellular identifiers is available for Windows Insiders and will release publicly in the last half of 2025. Mobile operators will be adding support throughout the next year. The You can continue using the Mobile Plans app until February 27, 2026. After that date, the app will be retired and you may uninstall it, and references to the app in Windows will be removed. If you face issues with this transition, please contact your mobile operator or visit their website to buy and manage eSIM data plans for your PC. What it means for users For most Windows users, this change should be convenient: connecting your device to a mobile network should be as easy as buying something online. If you already have an active mobile plan, you don’t need to take any action. Here are the key impacts: No loss of cellular functionality: Existing cellular features on Windows remain intact. Any eSIM profiles or data plans you’ve already activated on your PC will continue to work normally. Any plans you purchased through Mobile Plans will continue working, but you’ll need to go to the operator’s website to manage them. Other ways of activating eSIM (like scanning a QR code from a carrier or manually entering activation codes) will continue to be supported just as before. Mobile Plans app will be going away: You will see a message within the app about the end of support date. After that date, the app will be retired and may be uninstalled. The app will be removed from the Microsoft Store, and any links to open the app from within Windows will be removed. Seamless user experience: If you have a laptop or tablet with LTE/5G and eSIM support, you’ll no longer need the Mobile Plans app. Instead, you can go directly to your carrier’s online sign-up page and then follow the Windows Settings prompts to install the eSIM profile and get connected. Where to get and manage plans now: After the transition, to sign up for a new cellular plan on your PC, directly visit your mobile operator’s website and look for their section on activating an eSIM for Windows devices. After the transition, documentation will be updated to guide you through the new flow. What it means for mobile operators Microsoft has reached out to mobile operators participating in the Mobile Plans app, providing them the necessary details to transition to this new model. Operator enablement: Carriers are adapting their systems to support eSIM activation for Windows PCs via web. This involves adding an option on their websites to initiate the Windows activation flow and handle the secure sharing of device identifiers and eSIM profiles. Microsoft is providing technical guidance so that each operator’s implementation meets the necessary criteria for a seamless user experience. Information on how to download eSIM profile is available here: Use a QR code or URI link to download an eSIM profile. Trials and feedback: Starting in June 2025, selected operator partners began trialing the new flow with Microsoft. These trials allow operators to test the end-to-end process (from website to Windows device) and ensure any issues are ironed out before broad launch. All mobile operators with Windows data plan offerings are encouraged to participate in testing so that they’re ready by the time the app is retired. Please reach out to your local Microsoft representative with questions. Removal from Mobile Operator Portal and COSA profiles: Following the retirement of the app, the Mobile Operator Portal will be updated to remove "Mobile Plans" as an option when creating a new draft. The COSA definition for enabling GetBalance will also be removed from all the provider profiles. Only the two entries “SupportDataMarketPlace” and “MobilePlansIdentifier” will be removed. Updating “View My Account” links: In the current Windows UI, some carriers integrated with Mobile Plans have a “View my account” link in the network settings or Quick Settings. Those links used to point to the Mobile Plans app. Going forward, those need to point to the carrier’s own account management webpage. Operators should submit updated configurations (via COSA, the provisioning database) to ensure their customers can easily click from Windows UI to the correct web page for account info. More information is available here: Microsoft Mobile Operator Configuration Portal Guide. Continued collaboration: This change enables the operators to have more control when building and providing a great activation experience. Microsoft will continue to work in partnership with mobile operators to ensure a seamless transition. Next steps The retirement of the Mobile Plans app is a move toward a simpler, web-powered, and more streamlined future for Windows connectivity. For users, it means one less app and an easier way to get your device online. For operators, it gives them direct control of the customer purchase experience. Over the coming months, Microsoft will roll out the necessary Windows updates and work with carriers to finalize the new system. Keep an eye on the official Windows release notes and your carrier’s communications for announcements of support for the new eSIM activation flow. In the meantime, if you’re a user looking to add cellular service to your Windows PC, you can continue to use the Mobile Plans app until it’s retired or check your operator’s website for information. Many operators already allow eSIM activation via QR code or manual entry, which is what the new flow streamlines. We’re confident that moving to a web-centric solution will provide a smoother, more consistent connectivity experience for everyone. Thank you for being part of this journey to simplify Windows networking! Additional information Microsoft Mobile Operator Configuration Portal Guide Use a QR code or URI link to download an eSIM profileLesson Learned #533: Intermittent Azure SQL Database Connectivity and Authentication Issues
While working on a recent service request, we helped a customer troubleshoot intermittent connection and authentication failures when accessing Azure SQL Database using Active Directory (Entra ID) authentication from a Java-based application using HikariCP with JDBC/ODBC. They got the following error: com.zaxxer.hikari.pool.HikariPool$PoolInitializationException: Failed to initialize pool: Failed to authenticate.. Request was throttled according to instructions from STS. Retry in 29701 ms. java.sql.SQLTransientConnectionException: HikariPool-application1 - Connection is not available, request timed out after The first insight was focusing in the error message: Request was throttled according to instructions from STS. Retry in 29701 ms. This message seems it is returned by the Azure Active Directory Security Token Service (STS) when the client is sending too many token requests in a short period of time, exceeding the allowed threshold. We don't have all the details about, but, in high-concurrency environments (e.g., multiple threads, large connection pool) causes each thread to independently request a new token and we could reach a limit in this service, even, if the connection pool retries frequently or fails authentication, the number of token requests can spike. This is the reason, that HikariCP tries to initialize or refresh connections quickly, as many threads attempt to connect at once, and all trigger token requests simultaneously, STS throttling is reached. In order to avoid this situation, could be different topics, like, ensure our application caches tokens and reuses them across threads, using Managed Identity, increase the retry after delay, or perhaps, depending on HikariCP configuration, pre-warm connections gradually. Of course, discuss with your EntraID administration is other option.Lessons Learned #534: Azure SQL Database Connections with Managed Identity and Python ODBC
We worked on a service request that our customer trying to enable their Python application, hosted on Azure App Service, to connect securely to Azure SQL Database using a user-assigned managed identity. They attempted to use the Microsoft ODBC Driver for SQL Server with the managed identity for authentication. During our troubleshooting process we found several issues/error messages causing by an incorrect settings in the connection string: The initial connection string used the 'ActiveDirectoryInteractive' authentication method, which is not compatible with managed identities. The correct approach is to use 'ActiveDirectoryMsi' or 'ActiveDirectoryManagedIdentity' for system/user-assigned managed identities. Switching to 'ActiveDirectoryMsi' led to a pyodbc error: pyodbc.Error: (FA005, [FA005] [Microsoft][ODBC Driver 18 for SQL Server]Cannot use Access Token with any of the following options: Authentication, Integrated Security, User, Password. (0) (SQLDriverConnect)). The FA005 error message indicated a mismatch between the use of an access token and the connection string properties. Specifically, when passing an access token, the connection string must not include conflicting authentication parameters such as User, Password, or Integrated Security.Lesson Learned #532:Power BI Refresh Failure Due to Connection Pool Exhaustion in Azure SQL Database
We've been working on a service request that a customer experienced frequent failures when refreshing Power BI reports connected to an Azure SQL Database. The error message indicated a problem with acquiring connections from the data source pool, leading to unsuccessful report refreshes. We found the following error message: A request for a connection from the data source pool could not be granted. Retrying the evaluation may solve the issue. The exception was raised by the IDbCommand interface. Analyzing the details of the case, we found that the issue occurred regardless of whether Entra ID or SQL authentication was used, we don't have issue at Azure SQL Database level and not login error, but, we identified a high number of simultaneous connection attempts from Power BI to Azure SQL Database. We also reviewed the configuration of Power BI Desktop and noted that it loads multiple tables in parallel during refresh operations. This behavior triggers a surge of concurrent connections to the database, which in this scenario resulted in exhaustion of the connection pool at the application layer. We suggested to reduce the parallel table loading setting in Power BI Desktop, using File > Options and settings > Options > Data Load and Under Parallel loading of tables. Later adjusted the setting to a higher value to find a balance between performance and stability.Lesson Learned #359: TCP Provider: Error code 0x68 (104) (SQLExecDirectW)
Today, we got a service request that our customer faced the following error message connecting to the database: (pyodbc.OperationalError) ('08S01', '[08S01] [Microsoft][ODBC Driver 18 for SQL Server]TCP Provider: Error code 0x68 (104) (SQLExecDirectW)'). This customer is using Python in a Linux environment. Following I would like to share my lessons learned about this error message.Lesson Learned #522: Troubleshooting TLS and Cipher Suites with Python connecting to Azure SQL DB
A few days ago, we were working on a service request where our customer was experiencing several issues connecting to Azure SQL Database due to TLS version and cipher suite mismatches when using Python and ODBC Driver 18. Although we were able to get that information through a network trace, I would like to share things that I learned. Using the library SSL in Python allows to establish a TLS/SSL context where I can control the TLS version and specify or inspect the cipher suite. Here’s a small script that demonstrates how to connect to the Azure SQL Gateway over port 1433 and inspect the TLS configuration: import ssl import socket #ServerName to connect (Only Gateway) host = 'servername.database.windows.net' port = 1433 # TLS context context = ssl.create_default_context() print("Python uses:", ssl.OPENSSL_VERSION) context.minimum_version = ssl.TLSVersion.TLSv1_2 context.maximum_version = ssl.TLSVersion.TLSv1_2 context.check_hostname = True context.verify_mode = ssl.CERT_REQUIRED context.load_default_certs() # Testing the connection. with socket.create_connection((host, port)) as sock: with context.wrap_socket(sock, server_hostname=host) as ssock: print("TLS connection established.") print("TLS version:", ssock.version()) print("Cipher suite:", ssock.cipher()) # CN (Common Name) cert = ssock.getpeercert() try: cn = dict(x[0] for x in cert['subject'])['commonName'] print(f"\n Certificate CN: {cn}") except Exception as e: print(" Error extracting CN:", e) print("Valid from :", cert.get('notBefore')) print("Valid until:", cert.get('notAfter')) Using this script I was able to: Enforce a specific TLS version by setting minimum_version and maximum_version , for example, (1.2 or 1.3) Retrieve the cipher suite negotiated. Inspect the details of the certificate. Enjoy!
