我有一个小的负载均衡（使用会话代理）terminal服务器2008场后的网关服务器是从互联网访问。 我遇到的问题是，如果会话代理在login期间将用户切换到另一个服务器，则会有20-30秒的延迟。 我认为这与我强制安全层是RDP而不是SSL有关。
替代文字http://www.lytzen.name/blogimages/tsstructure.png
的背景
网关服务器具有公共的可路由的IP地址和DNS名称，因此可以从互联网访问，所有用户都通过此路由进入（系统用于向外部客户提供对托pipe应用程序的访问）。 实际的terminal服务器只有内部IP地址。 除了Vista或Windows 7客户端以外，远程桌面客户端将与服务器协商使用SSL来实现安全层。 然后公开自动生成的TS1或TS2所具有的证书 – 但是由于它们是内部自动生成的证书，因此客户端将收到严重警告，certificate证书无效。 由于服务器没有公共的可路由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，因此用户的初始连接将通过Gateway1到达TS1或TS2。 然后，TS1 / TS2将与会话中介交谈，并可能将用户传递给其他服务器。 即用户可能会连接到TS2，但是在与会话中介交谈之后，用户可能会被传递到TS1，这是他们将运行会话的地方。
当发生这种服务器切换时，在我的设置中，屏幕以20-30秒的时间与“欢迎”一起坐下，然后闪烁，再次显示欢迎，然后在正常的login屏幕中闪烁（即“等待用户configuration文件pipe理器“等）。 在做了一些研究之后，我认为正在发生的事情是用户在被传递到TS1之前被完全login到TS2（虽然显示“Welcome”），然后再次login。 有趣的是，通常当你看到“欢迎”字样时，左边的小圆圈会旋转，但是在这个延迟期间它不会旋转 – 屏幕看起来就像是冻结了。
这个博客引导我认为这是因为CredSSP没有被使用，可能是因为我禁止SSL和强制RDP。
我曾经尝试过
我再次启用了SSL，消除了“欢迎”延迟。 不过，在这个过程中，似乎更早地引入了新的延迟。 具体来说，当RDP客户端正在说“初始化连接”时 – 现在这个速度要慢很多。 除了这个事实，我的证书问题排除了我使用该解决scheme没有很大困难。
我尝试禁用负载平衡（只是从会话代理服务器场中删除服务器），连接没有任何延迟。
这个问题也是间歇性的， 只有当用户从一台服务器碰到另一台时才会发生。 我试图直接连接到TS1（当然是通过网关），然后检查我实际连接到的服务器。
可以肯定的是，我也绕过了循环赛DNS，看它是否有任何影响，而不是。 该设置基本上符合MSbuild议： TS会话代理负载平衡分步指南
我试图改变使用专用的redirect器。 基本上，我没有使用循环DNS，而是将DNS指向网关服务器，并将其configuration为专用redirect器（禁止login，将其添加到服务器场）。 同样的问题，唉。
任何想法或build议感激地收到。
对于外部访问的rdweb到网关，使用具有外部dns注册和内部友好名称的证书。 这样它可以在网关服务器和服务器场中的terminal服务器上使用。 在我的情况下，我们有rdweb注册的外部地址，到网关。 然后指向连接代理。 内部访问是通过内部注册的DNS别名xyzrdweb这是注册到场中的两个terminal服务器，实际上使用xyzrdweb带回哪个logging首先通过DNS检索。 内部用户绕过网关。 不幸的是，在这种情况下，外部用户在进行完全authentication之前最初只能连接1.5分钟，但是一旦完全authentication，应用程序即时运行，Adobe Photoshop等应用程序需要3-4秒才能启动。
基本上你有两个相互竞争的负载平衡机制。 你完全按照我看到的那样来描述问题。 DNS Round Robin将传入连接发送到一台服务器，然后Session Broker将其发送到另一台服务器，导致会话build立延迟。
我的build议是使用DNS Round Robin或Session Broker，但不能同时使用。
我个人会使用Session Broker。 我将创build一个指向Session Broker服务器的公共DNSlogging，并让它处理负载平衡TS1和TS2之间的传入连接。
sorting的-的回答;
当我们开始在生产环境中运行这个设置时，问题似乎在减less或消失，所以它看起来只发生在一个小的用户负载上。 这种 – 有道理。
在RDP客户端本身的“从任何地方连接”设置下的“高级”选项卡上，有一个叫做“本地地址旁路RD网关服务器”的无用的小checkbox，缺省情况下会打勾。 现在，在我的设置中，我只是把“主机”作为服务器名称来尝试连接，所以RDP客户端试图在通过网关服务器连接之前在本地find该服务器，导致很长的延迟。 只要取消这个盒子，连接起来要快得多，至less在你真正连接到网关服务器之前。
也许晚点再来一个答案，但我会把它扔在这里。 我的设置中还有另外一个问题。
我刚刚遇到完全相同的问题，并在所有四台服务器（rdgw，ts01，ts02和rdbroker）上跟踪日志的面包屑。 我也在所有的服务器上使用自己颁发的证书，但是RDGW和严格的警告实际上提供了一种估计延迟远离日志的方法。 我的情况是作为原始的海报，redirect的事件有一个大的延迟。 证书提示表明客户端快速连接到最初的TS /redirect器。 如果这是会话所在的TS，那么一切正常。 如果客户端redirect连接到正确的TS需要23秒。 每次！
从Microsoft（ http://technet.microsoft.com/en-us/library/cc772418%28WS.10%29.aspx ）在步骤6中逐步解释，初始连接TS发出一个redirect命令到客户端并提供正确TS的IP地址 。 这就是我看到的问题。 通过RDGW的初始连接是使用初始TS /redirect器的内部FQDN完成的。 redirect连接使用正确TS的内部IP地址完成，而不是FQDN。 我实际上可以通过使用初始TS /redirect器的内部IP地址来重现此延迟。 或者在我的域和子域中的任何其他独立的TS。 在这种情况下，我最初的连接也会延迟23秒。
我对这个问题的看法是这样的
编辑; 但是，是“本地地址绕道RD网关服务器”伎俩。 有点愚蠢，因为返回的IP地址不在我的客户端的任何本地子网上。 幸运的是，我为我的客户端生成了一个脚本的RDP文件，所以我可以很容易地绕过这个问题。