SQL Server 1433 へ到達できてもログイン／アプリが失敗する場合の次の確認項目

SQL インスタンスと実ポート、認証方式、ログイン状態、既定 DB、ドライバー、TLS、別名、接続文字列を確認します。

1. 結論と対象範囲

クライアント／サーバーのバージョン、ドメイン参加状況、DNS とゲートウェイ、ネットワーク場所、完全なエラー文、イベント時刻、直近の変更を準備します。例では予約済みの corp.example を使用し、実在する顧客のドメイン、IP、アカウント、機器番号は掲載していません。

本件は「SQL Server、ERP、レガシーシステム」に分類されます。ログと設定はリモートで収集できる場合がありますが、権限の一括変更、スイッチ経路、本番切替、復元テストは計画した作業枠で実施します。

2. 主な症状と環境確認

• 口頭説明だけで判断せず、完全なエラー文、イベントログの時刻、失敗した操作を保存します。
• 影響範囲、初回発生時刻、再現性、別セグメントでも同じ結果になるかを記録します。
• データベースポートへの TCP 接続成功は到達性だけを示します。ERP にはインスタンス名、ドライバー、TLS、DB、アプリサービス、ライセンス、クライアント設定も必要です。

3. 推奨する切り分け順序

1. 対象 SQL インスタンスと実リッスンポートを確認します。名前付きインスタンス、動的ポート、SQL Browser、クライアント別名により 1433 到達でもアプリが失敗することがあります。
2. Windows 認証、SQL ログイン、混合モードを区別し、ログイン無効、既定 DB 利用不可、サーバー権限不足を確認します。
3. 旧 ODBC／OLE DB ドライバーはサーバー側 TLS／証明書要件に対応しない場合があります。バージョンを記録し、テスト端末で更新を検証します。
4. クライアント別名、インスタンス名、TCP/IP、Named Pipes、サーバー名変更、固定ポートを確認し、1つの設定ファイルだけを変更しないようにします。
5. データベースポートへの TCP 接続成功は到達性だけを示します。ERP にはインスタンス名、ドライバー、TLS、DB、アプリサービス、ライセンス、クライアント設定も必要です。
6. 口頭説明だけで判断せず、完全なエラー文、イベントログの時刻、失敗した操作を保存します。

Test-NetConnection sql01.corp.example -Port 1433
netstat -ano | findstr 1433
sqlcmd -S sql01.corp.example -E -Q "SELECT @@SERVERNAME, @@VERSION"

4. 安全な修復と一括展開

読み取り専用の確認、設定エクスポート、単一システムでの検証を優先します。原因を確認してから対象範囲、作業時間、ロールバック方法を決めます。移行は棚卸し、互換性試験、並行稼働、利用者受入、ロールバック訓練を行い、本番サーバーだけをテスト環境にしないようにします。

• クライアント別名、インスタンス名、TCP/IP、Named Pipes、サーバー名変更、固定ポートを確認し、1つの設定ファイルだけを変更しないようにします。
• データベースポートへの TCP 接続成功は到達性だけを示します。ERP にはインスタンス名、ドライバー、TLS、DB、アプリサービス、ライセンス、クライアント設定も必要です。
• 口頭説明だけで判断せず、完全なエラー文、イベントログの時刻、失敗した操作を保存します。

5. 確認方法・ロールバック・注意点

一度動作しただけで完了としません。利用者操作、ログ、再起動／再ログイン、必要に応じて別ネットワーク場所、次回のポリシー／バックアップ周期で再確認します。

確認とロールバック

• 一度に変更する条件は1つにし、変更前に設定をエクスポートするか現状を記録します。
• レガシーサーバー移行前に、役割、サービス、ポート、DB、タスク、共有、証明書、ドライバー、ライセンス、クライアント依存関係を棚卸しします。
• 新環境を並行検証し、旧環境とバックアップを保持し、ロールバック条件を明確化してから、切替後に業務機能を順番に受入確認します。

避けるべき一般的な誤り

• TCP ポート到達だけでアプリが正常と判断すること。
• SQL ログファイルを削除したり、本番 DB を繰り返し縮小すること。
• 切替当日にライセンス、タスク、旧クライアント依存が判明すること。