リモートデスクトップサーバーファームが動作を停止する

Question

以前は正常に機能していたリモートデスクトップサーバーファームが2日前に機能しなくなりました。セットアップは次のとおりです。

DNSは、「myfarm.mydomain.local」をすべてのファームメンバーサーバーのIPに解決します
すべてのファームメンバーサーバーは、ブローカーMYBROKERのファーム "myfarm"のファームメンバーとして構成されています
すべてのファームメンバーは、MYBROKERのローカルセッションブローカーグループのメンバーです
クライアントは「myfarm」に接続するように構成されています

（関係するすべてのサーバーは仮想Windows2008R2ボックスです）。突然人々は次のエラー（ドイツ語から翻訳）を受け取り始め、接続に失敗しました。

ターミナルサーバーに接続できません。

接続しようとしているターミナルサーバーファーム "myfarm"がサーバー "farmmemberX.mydomain.local"にリダイレクトしています。リモートデスクトップは、このサーバーが同じサーバーファームに属していることを確認できません。これは、サーバーファームと同じ名前のサーバーがネットワーク上にある場合に発生する可能性があります。？両方のリモートコンピューターが同じリモートデスクトップサーバーファームに属している場合は確認できません。リモートデスクトップサーバーファームへの接続を確立する場合は、コンピューター名ではなく、ファーム名を使用する必要があります。

管理者が準備したRDP接続を使用する場合は、ネットワーク管理者にサポートを依頼してください。

特定のファームメンバーと接続する場合は、「mstsc/admin」を使用します

間違った資格情報を入力したかのように、単に拒否されたように見えることもあります（そうではなく、資格情報を保存していない場合がほとんどです）。

質問1。この背後にあるもの、特に「検証できませんでした」について説明できますか？この検証が機能する場合、どのようにして検証が行われますか？結局のところ、ブローカーによって開始されていない場合、リダイレクトは試行されません...

試した内容：クライアントが接続する名前を別の名前に置き換えるのに役立つ場合がありました（つまり、同じIPに解決されるDNSに「foo」という名前を追加し、ユーザーが「foo」に接続するようにしました）。一貫から。

その後、上記のエラーメッセージで常に同じ数台のサーバーが "farmmemberX"として表示されることに気付きました。これらをファームから（メンバー自身とDNSで）実験的に削除したため、壊れた8台のサーバーファームを機能する2台のサーバーファームに減らすことができました。これはユーザーの負荷を軽減するには十分ではないので、これらの1つを複製したいと思いました。そうするために、私は最初にそれをシャットダウンし、後でそれを再起動しました-その時点から、それは他の6つのサーバーと同じくらい悪かったです。 どうやらRDPサーバーの再起動は致命的なことでした...ログによると、この特定のサーバーは約2か月間再起動されていませんでした。したがって、過去2か月間に行われた実質的にすべての変更が関連する可能性があります。これらの中には

最初のWin2012 ADサーバーをそれ以外のWin2003 AD構造に追加しました
手作業による介入が必要となるIE10/SSL/TLS関連のセキュリティ問題のいくつかのケース（regeditなど）があったことを思い出しますが、これらが何であったかを覚えようとしています
大量のWindowsアップデート
無効な証明書のようなものが私の気になりましたが、そのようなものは見つかりませんでした

質問2。これらのいずれかがこの問題を引き起こす可能性はありますか？

現在、サーバーファームを完全に削除しました。つまり、DNSラウンドロビンによる「貧弱な人の負荷分散」しかありません（もちろん、以前のセッションへの再接続機能は特にありません）。

主な質問。どうすれば農場を再び稼働状態にすることができますか？

編集：いくつかのクライアントは幸運であり、RDPファームに問題がないことを述べたはずです：Windowsを実行しているクライアントXPとその古いRDPクライアント...

コメントの後の編集：メインの非難された更新KB3002657、KB3035017がインストールされていないか、関連するサーバーで問題が発生する数日前にインストールされていたようです（クライアント、RDPサーバー、ブローカー、DC）、とにかくそれらをアンインストールしてみます...

[〜＃〜]更新[〜＃〜]いくつかの詳細：

ブローカーのイベントロギングを拡張しました。そのログによると、すべて正常（警告なし）であり、セッションのリダイレクトは正常に完了します。 soeのタイムアウト後、ターゲットセッションが削除されるだけです。クイック接続で試行（失敗）し、その場合、ブローカーは既存のセッションを再利用しようとしたことさえ記録しました。
ターゲットのRDPサーバーが「ネゴシエート」ではなく「RDP-Sercurity」に設定されている場合、リダイレクトは機能します（予期される迷惑なエラーメッセージがクライアントに発生する場合を除く）
完全に新しいファーム（つまり、ホストが異なる別のブローカー）を試しましたが、このシステムでも問題を再現できます。これは、問題がクライアント側にあることを示唆している可能性があります。

[〜＃〜] update [〜＃〜]コメントごとに要求される情報

RDPホストでセキュリティを「ネゴシエート」ではなく「TLS 1.0」に設定すると、問題が解決しません。「RDP」に設定するとファームは機能しますが、誰もがパスワードを2回入力する必要があります。エラーの状況では、何らかの理由で、元のエラーの代わりに、「指定された資格情報では接続を確立できませんでした」と表示されることがよくあります。これには、ステータス0xc000006d、サブステータス0のログイン失敗イベント4625が伴います。質問する前に：すべてのDCのクロックは正しく同期されています。レジストリでLanMan互換性設定が構成されていません。

機能したRDPホストクライアント設定の証明書は、まだ信頼できる内部CA（GPOごとにすべてから信頼されている）によって発行され、少なくとも4か月後まで有効です。テストのために、これらを「自動」証明書に変更し、成功しませんでした。

元のドイツ語のエラーメッセージテキストは

Von Remotedesktopverbindung kann keine Verbindung mit dem Remotecomputer hergestellt werden。

Vom Remotecomputer "FARMNAME"、mit dem Sie eine Verbindung herstellenmöchten、werden Sie zum Remotecomputer "FARMMEMBER.DOMAIN" umgeleitet。 Es kann nichtüberprüftwerden、ob diebeiden Remotecomputer zur gleichen Remotedesktop-Sitzungshostserverfarmgehören。 Siemüssenden Farmnamen、nicht den COmputernamen、verwenden、wenn Sie eine Verbindung mit einer Remotedesktop-Sitzungshostserverfarm herstellenmöchten。

Wenden Sie sich an den Netzwerkadministrator、umUnterstützungzu erhalten、wenn Sie eine RDP-Verbindung verwenden、die vom Administrator bereitgestellt wurde。

Wenn Sie eine Verbindung mit einem bestimmten Fammitglied herstellenmöchten、um es zu verwalten、geben Sie "mstsc.exe/admin" an der Eingabeaufforderung ein。

最近のクレインサイドのアップデートに問題があるかどうかを確認するために、私は新しいWindows 7ボックスから始めて、一連のアップデートごとにテストを行いました。 XPよりも優れた最初のクライアントの導入により、すでに問題が発生しているようですが、最初のクライアントバージョンでは別のエラーメッセージが表示されます（意味がありません）。

Die Verbindung kann nicht hergestellt werden、da es sich bei dem erreichten Remotecomputer nicht um den angegebenen Computer handelt。 Dies kann durch einen veralteten Eintrag im DNS-Cache verursacht werden。 Verwenden Sie statt des NamensはIPアドレスのコンピュータで死ぬ。

Hagen von Eitzen · Accepted Answer

すべての提案に感謝しますが、どれも一致しませんでした。観測され、記述された誤動作のパターン（および誤動作の一時的な進展）がなぜ発生したのかはわかりませんが、犯人は私が説明したものに隠されています

大量のWindowsアップデート

KB3002567です。そのリリース直後に "breaking RDP" または実際には breaking all と呼ばれるようになったアップデート。皮肉なことに、問題が最初に発生した後の簡単な調査で、これが明らかになりました（少なくとも、RDPの問題です。これはGoogleが探していたものです）。WSUSでアンインストールするためにKB3002567（および他のいくつかの疑わしい問題）をマークしました（ cf.私の楽観的な見解はOPで終わります）、それ以外の場合は、当面は更新の同期を凍結します。私たちが気づかなかったことは、このアップデートのWindows Server 2003バージョンは、それ自体をアンインストールできないと見なしていることです。したがって、テストの更新中にパッチが正常に削除された方法に気付きましたが、 Win2008サーバーから、削除がADサーバー（Win 2003）でも一晩中正常に行われたと考えました（翌日の更新に関しては、何もしないように頼みました）。問題が続いたため、更新は問題ではなかったと想定しました（実際にrdpは完全に壊れていませんでした-ユーザーの快適性を犠牲にして問題を回避できました）。一方、Win 2012バージョンは自動的にアンインストールできました。結果として、RDPが機能するか機能しないかにかかわらず、認証に使用されたサーバーに依存していました。サーバーの再起動により、以前に「インストールされた」問題が発生したと誤って結論付けました。また、AD移行テストが問題の原因であると誤って結論付け、2012サーバーを降格して削除した後、このADの操作で発生した可能性のある問題を探し始めました。とにかく問題が着実に激しさを増しているため、2012 ADサーバーを削除したのと同じ日に常に障害が障害に変わっていることに気づいたとき、あまり疑い深くはありませんでした（接続は後から明らかです）。

検索が同じ役に立たない提案を出し続けた場合（サーバー間の時間差が5分未満であることを確認してください-ほんの数秒で確認してください。関連するすべてのグループメンバーシップが設定されていることを確認してください。時間; DNSエントリを確認する-気付かれることなく間違っている可能性があるDNSはほとんどありません; KB3002567がインストールされていないことを確認してください-ねえ、私たちのWSUSがそれを処理しましたね？）髪の毛を引き裂き始めました。その後、KB3002567に関する別のヒントが表示されたとき、Win2003 ADサーバーにインストールされている更新プログラムのリストを最後にスキャンし（驚いたことに、最新のOSでは本当にシンプルになりました）、まだそれを見つけていますインストールされています。手動でアンインストールし、再起動して、みんな幸せすぐに！

the-wabbit · Answer

ここで干し草の山から針を見つけるのはかなり難しいようですが、これはどこかでの構成エラーだと思います。これに従うと、実際のベースライン構成が得られます。

ファーム内の各セッションホストを指す_<domain>_の_<farmname.domain>_のDNSゾーンにA-RRを作成します
__<sessionhost.domain>_の Subject Alternative Name を使用して、各_<farmname.domain>_の信頼できる証明書を設定し、各セッションホストのRDサービスに対してそれらをインストール/有効化します
セットアップGPO _<farmname>_で_<connectionbroker.domain>_のファームメンバーになるようにすべてのセッションホストを構成（管理用テンプレート/ Windowsコンポーネント/リモートのすべての設定）デスクトップサービス/リモートデスクトップセッションホスト/ RD接続ブローカー）：
GPOを設定して、コネクションブローカーのコンピューターアカウントをDistributed COM Users (built-in)のメンバーとして割り当てます
セッションホストを再起動して、すべてのポリシーが適用され、有効であることを確認します
_<farmname.domain>_へのクライアント接続をテストする

幸運を！