之前运行良好的远程桌面服务器场两天前停止工作。设置如下：
- DNS 将“myfarm.mydomain.local”解析为所有场成员服务器的 IP
- 所有农场成员服务器均在 Broker 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 相关的安全问题需要手动干预（注册表编辑等），但我仍在努力回忆这些可能是什么
- 大量 Windows 更新
- 我想到过证书无效之类的事情，但我没有找到这样的事情
问题2。这些因素都可能导致这个问题吗？
目前，我们完全放弃了服务器场，也就是说，我们只通过 DNS 循环进行“穷人的负载平衡”（当然，我们特别怀念重新连接到上一个会话的功能）
主要问题。我怎样才能让我的农场恢复正常运转？
编辑：我应该提到，一些客户很幸运，没有遇到 RDP 场的问题：那些仍然运行 Windows XP 及其旧版 RDP 客户端的客户......
评论后编辑： 看来主要被指控的更新 KB3002657、KB3035017 要么没有安装，要么在问题出现前几天就在相关服务器（客户端、RDP 服务器、代理、DC）上安装了，但无论如何我都会尝试卸载它们...
更新 更多信息：
- 我增强了代理上的事件日志记录。根据该日志，一切正常（没有警告），会话重定向正常完成。只是在某个超时后，目标会话被删除。我尝试（失败）快速连接，在这种情况下，代理甚至记录了它试图重用现有会话。
- 如果目标 RDP 服务器设置为“RDP-Sercurity”而不是“negotiate”，则重定向有效（除了客户端会出现可预料的恼人错误消息）
- 我尝试了一个全新的服务器场（即，具有不同主机的不同代理），问题也可以在此系统中重现。这可能表明问题出在客户端。
更新根据评论要求提供的信息
如果我在 RDP 主机上将安全性设置为“TLS 1.0”（而不是“协商”），问题仍然存在。如果我设置为“RDP”，农场就可以工作了 - 但每个人都必须输入两次密码。在错误情况下，出于某种原因，我现在经常只收到“无法使用给定的凭据建立连接”而不是原始错误。这伴随着登录失败事件 4625，状态为 0xc000006d，子状态为 0。在您询问之前：所有 DC 的时钟都同步良好；注册表中未配置 LanMan 兼容性设置。
RDP 主机客户端设置中有效的证书由仍然值得信赖的内部 CA（根据 GPO 受到所有人的信任）颁发，有效期至少为四个月。为了进行测试，我将这些证书更改为“自动”证书，然后又改回原样，但没有成功。
原始的德文错误信息文本如下
通过远程桌面连接，您可以与远程计算机建立非连接。
从远程计算机“FARMNAME”，通过您设置的绑定选项，您将被添加到远程计算机“FARMMEMBER.DOMAIN”。无法对远程计算机和远程桌面服务器进行交叉检查。当您与远程桌面服务器建立绑定时，您必须使用计算机名，而不是计算机名。
如果您联系网络管理员，作为获得支持的一方，当您使用 RDP 联盟时，将由管理员负责处理。
当您与指定家庭组建立关联时，为了管理它，请在输入框中输入“mstsc.exe /admin”。
为了查明最近的客户端更新是否导致问题，我从一个全新的 Windows 7 机器开始，并在每次更新后进行测试。似乎引入第一个优于 XP 的客户端现在已经导致问题 - 但第一个这样的客户端版本给出了不同的错误消息（这没有意义）：
该绑定无法被实现，因为所连接的远程计算机无法与手持计算机通信。可以通过将经过验证的条目添加到 DNS-Cache 中来创建。您使用计算机的 IP 地址名称。
答案1
看起来大海捞针似乎很难，但我相信这是某个地方的配置错误。按照这个应该会给你一个有效的基准配置：
- 在 DNS 区域中创建 A-RR以
<domain>指向<farmname.domain>每位会议主持人在农场 <sessionhost.domain>为每个设置受信任的证书主题备用名称并在每个会话主机上安装<farmname.domain>/启用 RD 服务- 设置一个 GPO，将所有会话主机配置为场成员
<farmname>（<connectionbroker.domain>所有设置管理模板/Windows 组件/远程桌面服务/远程桌面会话主机/RD 连接代理)：
- 设置 GPO，将连接代理的计算机帐户指定为
Distributed COM Users (built-in) - 重新启动会话主机以确保所有策略均已应用并生效
- 测试客户端连接
<farmname.domain>
祝你好运！
答案2
感谢大家的建议，但没有一个符合要求。我不知道为什么会出现这种观察到和描述的故障模式（以及故障的时间发展），但罪魁祸首隐藏在我所描述的
- 大量 Windows 更新
这是 KB3002567。该更新在发布后不久被称为“破坏 RDP”或者事实上打破一切具有讽刺意味的是，在第一次遇到问题后，我们进行了快速研究，发现了这个问题（至少是 RDP 问题，因为这是我们在 Google 上搜索的），因此我们在 WSUS 上将 KB3002567（以及其他一些可疑问题）标记为卸载（参见我在 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 服务器上已安装更新的列表（哎呀，现代操作系统确实变得更简单了），令人惊讶的是，它仍然安装成功。手动卸载，重启，每个人都很开心立即地！