遠端桌面伺服器場停止工作
一個以前執行良好的遠端桌面伺服器場 ahs 兩天前停止工作。設置如下：
- DNS 將“myfarm.mydomain.local”解析為所有場成員伺服器的 IP
- 所有場成員伺服器都配置為代理 MYBROKER 上場“myfarm”的場成員
- 所有場成員都是 MYBROKER 上本地會話代理組的成員
- 客戶端配置為連接到“myfarm”
（所有涉及的伺服器都是虛擬的 Windows2008R2 機器）。突然，人們開始收到以下錯誤（翻譯自德語）並且無法連接。
無法連接到終端伺服器。
您嘗試連接的終端伺服器場“myfarm”將您重定向到伺服器“farmmemberX.mydomain.local”。遠端桌面無法驗證此伺服器是否屬於同一個伺服器場。如果您的網路上存在與伺服器場同名的伺服器，則可能會發生這種情況。?無法驗證兩台遠端電腦是否屬於同一個遠端桌面伺服器場。如果要與遠端桌面伺服器場建立連接，則必須使用場名稱，而不是電腦名稱。
如果您使用管理員準備的 RDP 連接，請聯繫網路管理員以獲得支持。
如果您想與特定場成員連接，請使用“mstsc /admin”
有時他們似乎也被簡單地拒絕了，好像輸入了錯誤的憑據（他們沒有，大多數人都保存了他們的憑據）
**問題 1.**你能解釋一下這背後的原因，特別是關於“無法驗證”：如果驗證有效，如何進行驗證？畢竟，如果不是由經紀人發起，甚至不會嘗試重定向……
我們嘗試了什麼：有時它有助於將客戶端連接的名稱替換為其他名稱（即，我們向 DNS 添加了一個名稱“foo”，該名稱解析為相同的 IP，並讓使用者連接到“foo”），但這還遠遠不夠從一致。
後來我們注意到，在上述錯誤消息中，總是有相同的幾台伺服器顯示為“farmmemberX”。我們實驗性地從場中刪除了這些（在成員本身和 DNS 中），因此能夠將損壞的八台伺服器場減少為功能正常的兩台伺服器場。由於這不足以消除使用者負載，我想複製其中一個；為了做到這一點，我首先關閉了它，然後又重新啟動了它——從那一刻起，它就和其他六台伺服器一樣糟糕。顯然，重新啟動 RDP 伺服器是致命的事情……根據日誌，這個特定的伺服器已經有兩個月沒有重新啟動了。因此，幾乎過去兩個月所做的任何改變都可能是相關的。其中有
- 我們將我們的第一個 Win2012 AD 伺服器添加到我們原本的 Win2003 AD 結構中
- 我記得有一些與 IE10/SSL/TLS 相關的安全問題需要手動干預（regedit 和其他東西）的案例，但我仍在努力記住這些可能是什麼
- 大量的 Windows 更新
- 諸如無效證書之類的東西出現在我的 mnd 中，但我沒有發現這樣的東西
**問題 2.**這些事情中的任何一個都會導致這個問題嗎？
目前，我們完全放棄了伺服器群，即我們只有通過 DNS 循環的“窮人的負載平衡”（當然，我們尤其錯過了重新連接到上一個會話的功能）
**主要問題。**我怎樣才能讓我的農場再次進入工作狀態？
*編輯：*我應該提到一些客戶很幸運，並且對 RDP 農場沒有問題：那些仍在執行 Windows XP 及其舊 RDP 客戶端的客戶……
評論後編輯： 似乎主要歸咎於更新 KB3002657、KB3035017 要麼未安裝，要麼已在相關伺服器（客戶端、RDP 伺服器、代理、DC）上出現問題前幾天安裝，但我會嘗試解除安裝反正他們…
更新 更多資訊：
- 我增強了代理上的事件記錄。根據該日誌，一切都很好（沒有警告）並且會話重定向正常完成。只是在 soe 超時後，目標會話被刪除。我嘗試（失敗）快速連接，在這種情況下，代理甚至記錄它試圖重用現有會話。
- 如果目標 RDP 伺服器設置為“RDP-Sercurity”而不是“negotiate”，則重定向有效（除了客戶端出現可預期的煩人錯誤消息）
- 我嘗試了一個全新的農場（即具有不同主機的不同代理），並且該問題也可以在該系統中重現。這可能表明問題出在客戶端。
根據評論要求更新資訊
如果我在 RDP 主機上將安全設置為“TLS 1.0”（而不是“協商”），問題仍然存在。如果我設置為“RDP”，農場可以工作——但每個人都必須輸入兩次密碼。在錯誤情況下，由於某種原因，我現在經常簡單地得到“無法使用給定的憑據建立連接”而不是原始錯誤。這伴隨著登錄失敗事件 4625，狀態為 0xc000006d，子狀態 0。系統資料庫中沒有配置 LanMan 兼容性設置。
有效的 RDP 主機客戶端設置上的證書由仍然值得信賴的內部 CA（根據 GPO 受所有人信任）頒發，並且在未來至少四個月內有效。為了測試，我將這些更改為“自動”證書並返回，但沒有成功。
原始德語錯誤消息文本為
遠端桌面連接無法連接到遠端電腦。
從您嘗試連接的遠端電腦“FARMNAME”，您將被重定向到遠端電腦“FARMMEMBER.DOMAIN”。無法驗證兩台遠端電腦是否屬於同一個 RD 會話主機伺服器場。如果要連接到 RD 會話主機伺服器場，則必須使用場名稱，而不是電腦名稱。
使用管理員提供的 RDP 連接時，請聯繫網路管理員尋求幫助。
如果要連接到特定的家庭成員來管理他們，請在命令提示符處鍵入“mstsc.exe /admin”。
為了找出最近的某些客戶端更新是否有問題，我從一個新的 Windows 7 盒子開始，並在每組更新後進行了測試。似乎第一個比 XP 更好的客戶端的引入現在已經引起了問題 - 但是第一個這樣的客戶端版本給出了不同的錯誤消息（不是有意義的）：
無法建立連接，因為到達的遠端電腦不是指定的電腦。這可能是由 DNS 記憶體中的過時條目引起的。使用電腦的 IP 地址代替名稱。
感謝所有建議，但沒有一個匹配。我不知道為什麼會發生觀察到和描述的故障模式（以及故障的時間發展），但罪魁禍首隱藏在我所描述的
- 大量的 Windows 更新
它是 KB3002567。發布後不久的更新被稱為“破壞 RDP” - 或者實際上破壞了一切. 具有諷刺意味的是，在我們第一次遇到問題後的快速研究已經揭示了這一點（至少是 RDP 問題，因為這是我們在Google上搜尋的），所以我們在 WSUS 上將 KB3002567（和其他一些可疑的）標記為解除安裝（參見我在 OP 中對此的樂觀評論），否則暫時凍結更新同步。我們沒有註意到的是，此更新的 Windows Server 2003 版本認為自己不可解除安裝。因此，雖然我們在測試更新期間注意到更新檔是如何成功刪除的，例如從 Win2008 伺服器中刪除，但我們認為刪除已經成功地發生在我們的 AD 伺服器（Win 2003）上（因為他們一無所獲，更新明智， 下一天）。由於問題持續存在，完全崩潰了——我們設法以犧牲使用者舒適度為代價解決了這個問題）。另一方面，Win 2012 版本是可自動解除安裝。因此，RDP 是否有效取決於用於身份驗證的伺服器。我們錯誤地得出結論，伺服器重啟導致了之前“安裝”的問題出現——事實上，重啟恰好是為了切換身份驗證伺服器優先級。我們還錯誤地認為我們的 AD 遷移測試是導致問題的原因，因此降級並刪除了 2012 伺服器，然後開始尋找玩 AD 可能遇到的任何問題。由於無論如何這個問題的強度一直在穩步增加，當我們注意到失敗經常在我們擺脫 2012 AD 伺服器的同一天變成失敗時，我們並沒有太懷疑（儘管事後看來這種聯繫是顯而易見的）。
當我們的搜尋不斷提出相同的無用建議時（檢查伺服器之間的時間差異是否小於 5 分鐘 - 檢查，它只是幾分之一秒；檢查所有相關的組成員資格是否已設置 - 這樣做真的很無聊時間；檢查 DNS 條目 - DNS 中幾乎沒有什麼錯誤可能被忽視；檢查 KB3002567 是否未安裝 - 嘿，我們的 WSUS 已經處理好了，不是嗎？）我們開始扯頭髮了。當另一個關於 KB3002567 的提示出現時，我們終於掃描了 Win2003 AD 伺服器上已安裝更新的列表（哎呀，現代作業系統真的變得更簡單了），令人驚訝地仍然發現它已安裝。手動解除安裝，重啟，大家立馬開心！
在這里大海撈針似乎相當困難，但我相信這是某個地方的配置錯誤。接下來應該為您提供一個工作基線配置：
- 在 DNS 區域中創建 A-RR 以
<domain>指向<farmname.domain>場中的每個會話主機<sessionhost.domain>為每個會話主機上的主題備用名稱設置受信任的證書，並<farmname.domain>為 RD 服務安裝/啟用它們- 設置一個 GPO，將所有會話主機配置為
<farmname>at<connectionbroker.domain>（Administrative Templates/Windows Components/Remote Desktop Services/Remote Desktop Session Host/RD Connection Broker中的所有設置）：- 設置 GPO 以將連接代理的電腦帳戶分配為
Distributed COM Users (built-in)- 重新啟動會話主機以確保所有策略均已應用且有效
- 測試客戶端連接到
<farmname.domain>祝你好運！
