Login lento para o Terminal Server 2008 com balanceamento de carga por trás do Gateway Server

Question

Eu tenho um farm do Terminal Server 2008 com balanceamento de carga pequeno (usando o Agente de Sessão) atrás de um Servidor de Gateway que é acessado pela Internet. O problema que tenho é que há um atraso de 20 a 30 segundos se o agente da sessão trocar o usuário para outro servidor durante o login. Eu acho que isso está relacionado ao fato de que estou forçando a camada de segurança a ser RDP em vez de SSL. texto alternativo http:////www.lytzen.name/blogimages/tsstructure.png

O plano de fundo
O servidor Gateway tem um endereço IP roteavel público e nome DNS para poder ser acessado pela Internet e todos os usuários entram por essa rota (o sistema é usado para fornecer acesso a aplicativos hospedados para clientes externos). Os servidores de terminal reais possuem apenas endereços IP internos. Isso funciona muito bem, exceto que com um cliente Vista ou Windows 7, o cliente de área de trabalho remota negociará com o servidor para usar o SSL para a camada de segurança. Em seguida, isso expõe o certificado gerado automaticamente que o TS1 ou TS2 possui - mas, como eles são certificados internos gerados automaticamente, o cliente receberá um aviso severo de que o certificado não é válido. Não posso dar aos servidores um certificado devidamente autorizado, pois os servidores não têm endereço IP ou nome DNS de roteamento público. Em vez disso, estou usando a Diretiva de Grupo para forçar as conexões a serem mais de RDP em vez de SSL.

\Computer Configuration\Policies\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Security\Require use of specific security layer for remote (RDP) connections  

O usuário do Windows 7 agora recebe um aviso muito menos severo de que "a identidade do servidor não pode ser confirmada" com a qual eu possa conviver.
Eu não tenho controle suficiente sobre as máquinas do usuário final para pedir-lhes para instalar um novo certificado raiz.

O TS1 e o TS2 também são balanceados por carga usando o Agente de Sessão, que é instalado no Servidor de Gateway. Eu estou usando DNS round-robin, portanto, a conexão inicial do usuário passará pelo Gateway1 para TS1 ou TS2. O TS1 / TS2 irá, então, conversar com o agente de sessão e poderá passar o usuário para o outro servidor. Ou seja o usuário pode se conectar ao TS2, mas depois de conversar com o agente de sessão, o usuário pode ser passado para o TS1, que é onde eles executarão a sessão.

Quando esta comutação de servidores acontece, na minha configuração, a tela fica com a palavra "Welcome" por 20-30 segundos após o que pisca, Welcome é mostrado novamente e depois piscando através das telas normais de login gerente de perfil de usuário "etc). Tendo feito algumas pesquisas, acho que o que está acontecendo é que o usuário está sendo totalmente logado no TS2 (enquanto "Welcome" é mostrado) antes de ser passado para o TS1, onde eles entram novamente. É interessante que, normalmente, quando você vê a palavra "" Bem-vindo ", o pequeno círculo para a esquerda gira. No entanto, ele não gira durante esse atraso - a tela parece congelada.

Esta postagem no blog me leva a pensar que isso ocorre porque o CredSSP não está sendo usado, provavelmente porque estou proibindo o SSL e forçando o RDP.

O que tentei

• Eu habilitei o SSL novamente, o que remove o atraso de "Boas-vindas". No entanto, parece introduzir um novo atraso muito mais cedo no processo. Especificamente, quando o cliente RDP está dizendo "inicializando conexão" - isso agora é muito mais lento. Além do fato de que meu problema de certificado me impede de usar essa solução sem muita dificuldade.

• Eu tentei desabilitar o balanceamento de carga (apenas remova os servidores do farm do agente de sessão) e as conexões não têm nenhum atraso.

• O problema também é intermitente no sentido de que só acontece quando o usuário é transferido de um servidor para outro. Eu testei isso tentando conectar-me diretamente ao TS1 (através do Gateway, é claro) e então verificando em qual servidor eu realmente estava conectado.

• Só para ter certeza, eu também passei pelo DNS do round-robin para ver se ele tinha algum impacto e isso não aconteceu. A configuração está essencialmente de acordo com as recomendações do MS aqui: Etapa de Balanceamento de Carga do Agente de Sessão TS Guia Passo a Passo

• Eu tentei mudar para usar um redirecionador dedicado. Basicamente, em vez de usar um DNS round-robin, apontei meu DNS para o servidor Gateway e configurei-o para ser um redirecionador dedicado (não permitir logons, adicioná-lo ao farm). O mesmo problema, infelizmente.

Todas as ideias ou sugestões recebidas com gratidão.

    

Answer 1

Sort-of-a-answer;

1. Quando começamos a executar essa configuração na produção, o problema pareceu reduzir ou desaparecer, então parece que isso só acontece com uma pequena carga de usuário. Esse tipo de coisa faz sentido.

2. No próprio cliente RDP, na guia Avançado sob as configurações "Conectar de qualquer lugar", há uma pequena caixa de seleção inofensiva chamada "Ignorar servidor Gateway RD para endereços locais", que está marcada por padrão. Agora, na minha configuração, eu acabei de colocar "hosting" como o nome do servidor para tentar se conectar, então o cliente RDP tenta encontrar o servidor localmente antes tentando se conectar através do servidor Gateway, causando um longo atraso. Simplesmente desmarcar essa caixa tornou muito mais rápido conectar, pelo menos o bit antes de você estar realmente conectado ao servidor Gateway.

Answer 2

Para rdweb a gateway acessado externamente, use um certificado que tenha nomes amigáveis internos e registrados do DNS externo. Dessa forma, ele pode ser usado no servidor de gateway e nos servidores de terminal do farm. no meu cenário, temos rdweb registerd external address, para gateway. que, em seguida, aponta para o corretor de conexão. acesso interno é através de DNS registrado internamente alias xyzrdweb isso é registrado para ambos os servidores de terminal no farm, com efeito usando xyzrdweb traz de volta que cada registro é recuperado primeiro via dns. Usuários internos ignoram o gateway. Infelizmente, os usuários externos neste cenário têm uma conexão lenta inicial de até 1 ½ minutos antes de serem totalmente autenticados, mas uma vez totalmente autenticados, os aplicativos são executados instantaneamente, com aplicativos como o adobe photoshop etc levando de 3 a 4 segundos para iniciar. >     

Answer 3

Essencialmente, você tem dois mecanismos de balanceamento de carga competindo entre si. Você descreveu o problema exatamente como eu vejo acontecer. O DNS Round Robin envia uma conexão de entrada para um servidor e, em seguida, o Agente de Sessão envia para outro servidor causando um atraso no estabelecimento da sessão.

Minha sugestão é usar o DNS Round Robin ou o Session Broker, mas não os dois.

Pessoalmente, eu usaria o Agente de Sessão. Eu criaria um único registro DNS público que apontasse para o servidor do Agente de Sessão e permitisse o balanceamento de carga das conexões de entrada entre TS1 e TS2.

    

Answer 4

Talvez um pouco atrasado para outro tipo de resposta, mas vou jogar aqui mesmo assim. Eu também tenho outra pegadinha na minha configuração.

Acabei de encontrar exatamente o mesmo problema e segui as migalhas de logs dos quatro servidores (rdgw, ts01, ts02 e rdbroker). Eu também uso auto-certificados emitidos em todos os servidores, mas o RDGW e os avisos de popa realmente fornecem um meio para estimar onde o atraso é para além de olhar para os logs. Meu cenário é como um cartaz original que há um enorme atraso no evento de um redirecionamento. Promts de certificado mostram que o cliente está rapidamente conectado ao TS / redirecionador inicial. Se este é o TS onde a sessão reside, tudo bem. Se o cliente for redirecionado, a conexão ao TS correto leva exatamente 23 segundos. Toda vez!

Veja a explicação passo a passo da Microsoft ( link ) na etapa 6, a conexão inicial TS emite um comando de redirecionamento para o cliente e fornece o endereço IP do TS correto. Aqui está a questão do jeito que eu vejo. A conexão inicial por meio de RDGW é feita usando o FQDN interno do TS / redirecionador inicial. A conexão redirecionada é feita usando o endereço IP interno do TS correto, não o FQDN. Na verdade, posso reproduzir esse atraso usando o endereço IP interno do TS / redirecionador inicial. Ou qualquer outro stand alone TS no meu domínio e domínios filho. Nesse caso, também recebo um atraso de 23 segundos na conexão inicial.

A minha opinião sobre esta questão é que

1. O redirecionamento é feito por endereço IP, não pelo FQDN
2. A implementação do RDGW ou do cliente tem um problema de atraso usando o endereço IP
3. A pegadinha: o cliente RDP do Windows 8.1 (6.3.9600) falha ao conectar-se ao servidor redirecionado. Nenhum evento de logon é registrado no TS onde a sessão do usuário reside. O cliente RDP simplesmente fica sempre tentando se conectar - não tem tempo limite.

editar; Mas sim, o "Bypass RD Gateway Server para endereços locais" fez o truque. Tipo de idiota como o endereço IP retornado não é perto de estar em qualquer sub-rede local em meus clientes. Felizmente, eu gero arquivos RDP com um script para meus clientes, então poderei contornar esse problema com bastante facilidade.