Microsoft announced Microsoft.Data.SqlClient 7.1.2, 7.0.4, and 6.1.8 on November 13, 2026. These servicing releases include dependency security updates, certificate-validation changes, and bug fixes relevant to applications connecting to Azure SQL and other supported SQL services. Microsoft announcement.
My proposed upgrade review would start with the deployed connection configuration and the networking path each application actually uses. Record the driver line, runtime, operating system, and expected connection behavior before choosing the servicing release.
Inventory Explicit Certificate Names
Microsoft says the new validation behavior uses an explicit HostNameInCertificate value as the expected certificate name. An incorrect value can therefore fail even when the connection's server name matches the certificate. Certificate-name behavior.
I would search the application's approved configuration sources for that option and ask the service owner to explain each occurrence. Preserve the intended endpoint and the reason for using an explicit certificate name without copying credentials into the review record.
For an application using an alias, the acceptance sheet should connect that alias to its approved destination and expected certificate identity. Give unclear or inherited configuration values an owner before scheduling the upgrade.
Preserve the Version and Networking Distinction
The announcement identifies a 6.1.8 exception: the stricter check applies only to managed networking there. Its published comparison shows the stricter behavior across the tested networking paths in 7.1.2 and 7.0.4. Version-specific comparison.
My pilot would record the networking mode as an explicit part of the application configuration. Have the build and runtime owners confirm that the proposed test environment represents the deployed path they intend to maintain.
Retain observations from the current release for comparison. If two environments behave differently, investigate the configuration and runtime context before accepting either result as evidence for the production rollout.
Define the Expected TLS Result
Microsoft Learn describes certificate validation as checking identity, trust chain, and expiry, and explains the expected-name option for certificate names that differ from a connection alias. Validation background.
I would define a successful connection case and a controlled rejected-name case in an approved staging environment. Use synthetic application activity and retain the observed connection result with the expected certificate identity.
Ask the reviewer to distinguish a TLS handshake failure from a later authentication or query failure. Record the relevant diagnostic evidence and the owner responsible for each stage so the operator can route an incident correctly.
Review the Resolved Package Set
The announcement asks projects with direct references to affected dependencies to meet the new minimums. For 7.0 and 7.1, referenced companion SqlClient packages should match the driver's version. Dependency and companion-package guidance.
My change review would retain the resolved dependency list and the selected driver line with the build artifact. Have a second engineer reproduce the restore and build from the recorded project configuration.
Keep the decision attached to the application change. The later operator should be able to establish which package versions reached the deployment and which configuration was used when the acceptance evidence was collected.
Test the Application Workflow After Connection
I would choose a representative read and write workflow, where applicable, and agree on its expected business result with the application owner. Preserve the synthetic input, observed outcome, and relevant diagnostics in the test record.
Rehearse the established recovery procedure using the prior artifact and approved configuration. Confirm the resulting application behavior and record the conditions that would stop a wider rollout.
Assign the final decision to the service owner. The review should account for connection validation, dependency changes, application behavior, and the team's ability to investigate a failure using the evidence it retained.
Practical Cloud Engineer Takeaway
Inventory explicit certificate-name options and their intended endpoints.
Record driver version, runtime, and networking mode together.
Verify successful and rejected TLS cases in staging.
Review resolved dependencies and companion-package alignment.
Rehearse the application workflow and established recovery path.
Who Should Care?
Azure SQL application developers, .NET platform engineers, database connectivity owners, and teams maintaining SqlClient dependencies across different runtime environments.
Bottom Line
These servicing releases deserve a configuration-aware upgrade review. A useful acceptance record demonstrates the intended certificate identity, the selected networking path, and the application's expected behavior after the package change.
No application package, connection string, SQL database, certificate, or Azure resource was changed for this article.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments