3月10日のパッチ火曜日にSQL Serverクライアント接続の問題が発生するようです
SQL 7.1を実行するWin 7.1 ProデスクトップとWindows 2012 R2 Datacenter Azureサーバーにパッチのフルセットを適用するため、SQL Management Studio（2008および2014バージョン）はSQL 2014 Azureサーバーに接続しません。クライアント接続の試行がタイムアウトし、SQLサーバーエラー5で失敗します。
SQLサーバーのトランザクションレプリケーションは、ローカルのSQL 2008インスタンスとリモートのSQL 2014インスタンス間で正常に機能し続けます。また、リモート（Azure）サーバー上のSQL Management Studio 2014は、ローカル（オンサイト）SQL 2008インスタンスとリモート（Azure）SQL 2014サーバーに問題なく接続できます。双方向のDNS解決とIP接続は正常です。リモートSQL 2014インスタンスが起動時にSPNを正しく作成していることがわかります。 NTLMフォールバックが一部のクライアントで使用されているというSQL 2014の警告があります。
SQL 2014のローカルインスタンスもSQL 2008のリモートインスタンスもありません。そのため、サーバーがリモートであるか、Azure上で、VPN経由であるか、または同じように表示されるかがわかりません。パッチが適用されたローカルクライアントとパッチが適用されたローカルSQLサーバーの問題。
リモートSQL 2014サーバーのSQLブラウザーサービスが停止して無効になっています。これがパッチ前のケースだったかどうかはわかりません。ただし、名前付きインスタンスではなく、デフォルトのポートで1つのインスタンスを実行しているので、SQLブラウザーサービスは必要ないのでしょうか。
このパッチ火曜日には、Server 2003ネットワークファイル共有に関連する認証の問題が報告されています。 ADの認証に関する一般的な問題やSQL Serverの認証に関する問題の報告を見たことはありません。他の誰かがこの問題または同様の問題を抱えていますか？ロールバックしようとするKBの提案はありますか？ Kerberos構成アナライザーを実行する必要がありますか？無効にしたSQLブラウザサービスを開始する必要がありますか？
助けてくれてありがとう。
サーバーからMS15-027（KB3002657）を削除してサーバーを再起動しても、問題は解決しません。
クライアントでKB 3046049を削除してクライアントを再起動しても、問題は解決しません。サーバー上のKB 3046049を削除してサーバーを再起動しても問題は解決しませんが、エラーコードが5から53（より一般的なエラーコード）に変更されました。
編集：これは 今夜のセキュリティ更新後にSQL Server Windows認証が失敗する：ログインは信頼されていないドメインからのものです と同じ問題ではありませんが、同じ根本原因がある可能性があります。 （火曜日のパッチ以降、さまざまな認証関連の問題の報告が増えているようです。）特に、私の場合、Windows認証は正常に機能しています。パッチを適用したマシンにRDPを適用し、パッチを適用したマシンとADベースのログインの間で問題なく機能します。
編集：同じ問題がSQL認証（AD以外）に影響します。同一のエラーメッセージ。これは接続の問題であり、認証の問題ではないことを示唆しています。
影響を受けるWindows 2003サーバーはありません。したがって、発生している問題はWindows Server 2003に限定されません（他のいくつかの同様の3月のパッチの問題で報告されているように）。
水曜日の朝2015-03-11 3月のWindows更新後、ODBCおよびSpotlightソフトウェアの2005、2008 SQLインスタンスへの接続で問題が発生し始めました。Windowsドメイン資格情報を使用していました。SQL認証は引き続き機能しました。エラー：ユーザー ''のログインに失敗しました。ユーザーは信頼されたSQL Server接続に関連付けられていません。（Microsoft SQL Server、エラー：18452）
私たちのドメインレベルは、Windows 2003 SP2サーバーの複数のサイトで2003です。 Windows 2003ドメインコントローラーでは、以下にリストされているすべての更新をバックアウトしました： https://technet.Microsoft.com/library/security/ms15-Mar これSQLデータベース接続をすべて復元し、オペレーションが夜間システム処理を正常に完了できるようにしました。
イントラネットドメイン上のすべてのサーバーに対する次の2つのWindows更新プログラムのWSUS（Windows Update Server）によるインストールを拒否しました：MS15-027（KB3002657）およびMS15-031（KB3046049）
これらのアップデートで報告された問題に関する以下の記事をお読みください： http://www.infoworld.com/article/2895022/security/problems-reported-with-Microsoft-patch-kb-3002657-and -a-warning-on-kb-3046049.html＃tk.rss_security
support.Microsoft.com/en-us/kb/3002657（既知の問題のセクションをお読みください）
現時点では、今後の問題を監視しているため、現在の2003ドメインコントローラには更新をインストールしません。
MS15-27 KB3002657これは、Windows 2003、またはMicrosoftによって報告されたEMC Epislonに限定されません。
私の経験は：
ドライブをマッピングするか、Windows 7ワークステーションから複数のWindows 2008ファイルサーバー（ドメインコントローラーではない）へのuncパスを使用すると、正しくないユーザー名メッセージで失敗します。
問題は、Windows 7ワークステーションがWindows 2008ファイルサーバーとは異なるActive Directoryドメインにあることでした。 Windows 7ワークステーションが参加するDNSゾーンに静的DNSエントリを追加して、Windows 2008サーバーのIPアドレスを解決しました。そのため、ユーザーは短いコンピューター名を使用してファイル共有にアクセスできます（短い名前=\servername\sharename FQDN長い名前=\servername.serverdomain.com\sharename）このプロセスにより、ワークステーションは\ servernameのワークステーションdnsサフィックスに接続します。 workstationdomain.com\sharename。これによりパッチがトリガーされ、サーバー名のfqdnが間違っているため、コンピューター名が偽装されていると考えられます。
問題を修正するには：
1-ワークステーションのDNSゾーンからサーバーのDNSエントリを削除します。
2-ワークステーションのdnsサフィックスとサーバーのdnsサフィックスの両方を含むdnsサフィックス検索リストをグループポリシー経由でワークステーションに展開します
これで、ワークステーションは短いuncパス名を引き続き使用でき、dns検索サフィックスリストを通過した後、正しいfqdn名を見つけます。
このようにしていたのはおそらく私たちだけではありません。