一个以前运行良好的远程桌面服务器场 ahs 两天前停止工作。设置如下:
- DNS 将“myfarm.mydomain.local”解析为所有场成员服务器的 IP
- 所有场成员服务器都配置为代理 MYBROKER 上场“myfarm”的场成员
- 所有场成员都是 MYBROKER 上本地会话代理组的成员
- 客户端配置为连接到“myfarm”
(所有涉及的服务器都是虚拟的 Windows2008R2 机器)。突然,人们开始收到以下错误(翻译自德语)并且无法连接。
无法连接到终端服务器。
您尝试连接的终端服务器场“myfarm”将您重定向到服务器“farmmemberX.mydomain.local”。远程桌面无法验证此服务器是否属于同一个服务器场。如果您的网络上存在与服务器场同名的服务器,则可能会发生这种情况。?无法验证两台远程计算机是否属于同一个远程桌面服务器场。如果要与远程桌面服务器场建立连接,则必须使用场名称,而不是计算机名称。
如果您使用管理员准备的 RDP 连接,请联系网络管理员以获得支持。
如果您想与特定场成员连接,请使用“mstsc /admin”
有时他们似乎也被简单地拒绝了,好像输入了错误的凭据(他们没有,大多数人都保存了他们的凭据)
问题 1.你能解释一下这背后的原因,特别是关于“无法验证”:如果验证有效,如何进行验证?毕竟,如果不是由经纪人发起,甚至不会尝试重定向......
我们尝试了什么:有时它有助于将客户端连接到的名称替换为其他名称(即,我们向解析到相同 IP 的 DNS 中添加了一个名称“foo”,并让用户连接到“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 受所有人信任)颁发,并且在未来至少四个月内有效。为了测试,我将这些更改为“自动”证书并返回,但没有成功。
原始德语错误消息文本为
Von Remotedesktopverbindung kann keine Verbindung mit dem Remotecomputer hergestellt werden。
Vom Remotecomputer "FARMNAME", mit dem Sie eine Verbindung herstellen möchten, werden Sie zum Remotecomputer "FARMMEMBER.DOMAIN" umgeleitet。Es kann nicht überprüft werden, ob diebeiden Remotecomputer zur gleichen Remotedesktop-Sitzungshostserverfarm gehören。Sie müssen den Farmnamen, nicht den COMpputernamen, verwenden, wenn Sie eine Verbindung mit einer Remotedesktop-Sitzungshostserverfarm herstellen möchten。
Wenden Sie sich an den Netzwerkadministrator, um Unterstützung zu erhalten, wenn Sie eine RDP-Verbindung verwenden, die vom Administrator bereitgestellt wurde。
Wenn Sie eine Verbindung mit einem bestimmten Fammitglied herstellen mö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 die IP-Adresse es Computers。
在这里大海捞针似乎相当困难,但我相信这是某个地方的配置错误。接下来应该为您提供一个工作基线配置:
<domain>
指向<farmname.domain>
场中的每个会话主机<sessionhost.domain>
为每个会话主机上的主题备用名称设置受信任的证书,并<farmname.domain>
为 RD 服务安装/启用它们<farmname>
at<connectionbroker.domain>
(Administrative Templates/Windows Components/Remote Desktop Services/Remote Desktop Session Host/RD Connection Broker中的所有设置):Distributed COM Users (built-in)
<farmname.domain>
祝你好运!
感谢所有建议,但没有一个匹配。我不知道为什么会发生观察到和描述的故障模式(以及故障的时间发展),但罪魁祸首隐藏在我所描述的
它是 KB3002567。发布后不久的更新被称为“破坏 RDP” - 或者实际上破坏了一切. 具有讽刺意味的是,在我们第一次遇到问题后的快速研究已经揭示了这一点(至少是 RDP 问题,因为这是我们搜索过的问题),所以我们在 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 服务器上已安装更新的列表(哎呀,现代操作系统真的变得更简单了),令人惊讶地仍然发现它已安装。手动卸载,重启,大家立马开心!