我在网关服务器后面有一个小型负载平衡（使用会话代理）终端服务器 2008 场，可以从 Internet 访问。我遇到的问题是，如果会话代理在登录期间将用户切换到另一台服务器，则会出现 20-30 秒的延迟。我认为这与我强制将安全层设置为 RDP 而不是 SSL 有关。
替代文本 http://www.lytzen.name/blogimages/tsstructure.png
的背景
网关服务器具有公共可路由 IP 地址和 DNS 名称，因此可以从 Internet 访问它，并且所有用户都通过此路由进入（系统用于向外部客户提供对托管应用程序的访问）。实际的终端服务器只有内部 IP 地址。这确实很有效，但对于 Vista 或 Windows 7 客户端，远程桌面客户端将与服务器协商使用 SSL 作为安全层。然后，这会公开 TS1 或 TS2 具有的自动生成的证书 - 但由于它们是内部的自动生成的证书，因此客户端将收到证书无效的严厉警告。我无法为服务器提供正确授权的证书，因为服务器没有公共可路由 IP 地址或 DNS 名称。相反，我使用组策略强制通过 RDP 而不是 SSL 进行连接。
\Computer Configuration\Policies\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Security\Require use of specific security layer for remote (RDP) connections
Windows 7 用户现在收到的警告不那么严厉了，即“无法确认服务器身份”，我可以接受。
我对最终用户的机器没有足够的控制权，无法要求他们安装新的根证书。
TS1 和 TS2 也使用安装在网关服务器上的会话代理进行负载平衡。我使用的是循环 DNS，因此用户的初始连接将通过网关 1 转到 TS1 或 TS2。然后，TS1/TS2 将与会话代理进行通信，并可能将用户传递给另一台服务器。也就是说，用户可能会连接到 TS2，但在与会话代理进行通信后，用户可能会被传递给 TS1，他们将在那里运行会话。
在我的设置中，当服务器切换时，屏幕上会显示“欢迎”一词 20-30 秒，然后闪烁，再次显示“欢迎”，然后在正常登录屏幕（即“等待用户配置文件管理器”等）中闪烁。经过一番研究，我认为正在发生的事情是用户完全登录到 TS2（同时显示“欢迎”），然后被传递到 TS1，然后他们再次登录。有趣的是，通常当您看到“欢迎”一词时，左侧的小圆圈会旋转。但是，在此延迟期间它不会旋转 - 屏幕看起来只是冻结了。
这篇博文这让我认为这是因为没有使用 CredSSP，可能是因为我不允许 SSL 并强制使用 RDP。
我尝试过
我再次启用了 SSL，这消除了“欢迎”延迟。但是，它似乎在过程的早期就引入了新的延迟。具体来说，当 RDP 客户端说“初始化连接”时 - 现在速度要慢得多。更不用说我的证书问题使我无法毫不费力地使用该解决方案。
我尝试禁用负载平衡（只需从会话代理场中删除服务器）并且连接没有任何延迟。
这个问题也是间歇性的，因为它仅有的当用户从一台服务器转移到另一台服务器时，就会发生这种情况。我通过尝试直接连接到 TS1（当然是通过网关）然后检查我使用的服务器实际上已连接到。
为了确保万无一失，我还绕过了循环 DNS，看看它是否有任何影响，但事实并非如此。该设置基本上符合 MS 的建议：TS Session Broker 负载平衡分步指南
我尝试改用专用重定向器。基本上，我没有使用循环 DNS，而是将 DNS 指向网关服务器并将其配置为专用重定向器（禁止登录，将其添加到服务器场）。唉，问题还是一样。
任何想法或建议都非常感谢。
答案1
对于从外部访问的 rdweb 到网关，请使用具有外部 DNS 注册和内部友好名称的证书。这样，它就可以在网关服务器和场中的终端服务器上使用。在我的场景中，我们有 rdweb 注册的外部地址到网关。然后指向连接代理。内部访问是通过内部注册的 DNS 别名 xyzrdweb 进行的，它注册到场中的两个终端服务器，实际上使用 xyzrdweb 会带回首先通过 DNS 检索到的记录。内部用户绕过网关。不幸的是，在这种情况下，外部用户在完全身份验证之前最初的连接速度最慢，最多需要 1 分半钟，但一旦完全身份验证，应用程序就会立即运行，Adobe Photoshop 等应用程序大约需要 3-4 秒才能启动。
答案2
本质上，您有两种相互竞争的负载平衡机制。您描述的问题与我看到的完全一样。DNS 循环将传入连接发送到一台服务器，然后会话代理将其发送到另一台服务器，导致会话建立延迟。
我的建议是使用 DNS Round Robin 或 Session Broker，但不要同时使用两者。
就我个人而言，我会使用 Session Broker。我会创建一个指向 Session Broker 服务器的公共 DNS 记录，并让它处理 TS1 和 TS2 之间的传入连接的负载平衡。
答案3
有点像答案；
当我们开始在生产中运行此设置时，问题似乎有所减少或消失，因此看起来它只发生在用户负载较少的情况下。这有点道理。
在 RDP 客户端本身中，在“从任意位置连接”设置下的“高级”选项卡上，有一个无害的小复选框，称为“绕过本地地址的 RD 网关服务器”，默认情况下会勾选。现在，在我的设置中，我只需将“托管”作为要尝试连接的服务器名称，因此 RDP 客户端会尝试在本地找到该服务器前尝试通过网关服务器进行连接，导致长时间延迟。只需取消选中该框即可使连接速度大大加快，至少在您实际连接到网关服务器之前是如此。
答案4
也许现在再回答这个问题有点晚了，但我还是会在这里提出来。我的设置中还有另一个问题。
我刚刚遇到了完全相同的问题，并跟踪了所有四台服务器（rdgw、ts01、ts02 和 rdbroker）上的日志线索。我也在所有服务器上使用自颁发的证书，但 RDGW 和严厉警告实际上提供了一种除了查看日志之外估计延迟位置的方法。我的情况与原始发帖者一样，重定向事件的延迟很大。证书提示显示客户端快速连接到初始 TS/重定向器。如果这是会话所在的 TS，则一切正常。如果客户端被重定向，则连接到正确的 TS 需要 23 秒。每次都是这样！
查看 Microsoft 的分步说明（http://technet.microsoft.com/en-us/library/cc772418%28WS.10%29.aspx）在步骤6中，初始连接TS向客户端发出重定向命令，并提供IP地址正确的 TS。在我看来，问题就在这里。通过 RDGW 的初始连接是使用初始 TS/重定向器的内部 FQDN 完成的。重定向连接是使用正确 TS 的内部 IP 地址而不是 FQDN 完成的。我实际上可以使用初始 TS/重定向器的内部 IP 地址重现此延迟。或者我的域和子域中的任何其他独立 TS。在这种情况下，我的初始连接也会延迟 23 秒。
我对这个问题的看法是
- 重定向是通过 IP 地址而不是 FQDN 完成的
- RDGW 或客户端实现在使用 IP 地址时存在延迟问题
- 问题：Windows 8.1 (6.3.9600) 的 RDP 客户端根本无法连接到重定向服务器。用户会话所在的 TS 上没有记录任何登录事件。RDP 客户端在尝试连接时一直挂起 - 甚至没有超时。
编辑；但是，“绕过本地地址的 RD 网关服务器”确实成功了。有点愚蠢，因为返回的 IP 地址根本不在我的客户端的任何本地子网上。幸运的是，我使用脚本为我的客户端生成了 RDP 文件，因此我可以相当轻松地绕过这个问题。