Use this procedure on a self-managed Windows Server where you administer the SQL Server instance. Have an existing authorized administrative connection and the application owner available. Record the incident time, affected application, destination server and database. Keep connection passwords and complete connection strings out of support messages.

1. Separate authentication from reachability. Capture the complete error number and provider message. A timeout, certificate trust failure or connection refusal may occur before authentication and needs a different investigation. Confirm that the configured hostname, instance or TCP port points to the intended SQL Server.
2. Find the server-side reason. In SQL Server Management Studio, connect through the authorized administration route and open Management, SQL Server Logs. Match the failed-login event by time, login and client address. Read its state and reason text; do not infer the cause solely from the generic client error.
3. Identify the actual authentication method. Windows authentication uses the process or delegated Windows identity, which can differ between an interactive test and an IIS application. SQL authentication uses a SQL login and requires the instance to allow that authentication mode. Confirm the design before changing a server-wide setting.
4. Repair the specific account problem. Check whether the intended login exists, is enabled and is subject to a password or expiry problem. Coordinate any necessary secret rotation with all dependent applications. Do not enable the sa account or grant sysadmin merely to make the test succeed.
5. Check database access. Confirm the requested database is online, the login has the intended database user mapping, and its roles grant only required operations. An unavailable default database can also reject a connection. A database restored from another instance may need an authorized user-to-login remapping.
6. Retest from the application environment. Update the approved secret store if credentials changed, then recycle only the relevant connection pool or application process as required. Test the application operation that failed and observe new SQL log entries. Record the configuration change without recording the password.

The successful SSMS test may use a different login, Windows identity, default database, network route or saved credential. Compare these settings explicitly and test under the application identity. If only one application remains affected, inspect its active configuration and secret version before changing the database server again.

Give the responsible database administrator the timestamp, error state, sanitized login name, target database and changes already tested. Preserve a working administrative route. Restore an unsuccessful application configuration change if necessary, while retaining the diagnostic evidence.

• Configuring encrypted SQL Server client connections
• Investigating a Windows service failure with Event Viewer
• Choosing and securing an IIS application-pool identity
• Responding to unexpected SQL Server transaction-log growth

• SQL Server error 18456
• Authentication connectivity troubleshooting
• View the SQL Server error log