RDP lento após o servidor ingressar no domínio

Question

Estamos a ter problemas de RDP com servidores de nuvem da Amazon que aderimos recentemente a um domínio do Active Directory. A configuração é:

• Uma rede de escritório local
• Uma nuvem privada virtual na Amazon
• Um túnel IPSec entre as duas redes
• Vários servidores Windows 2008 R2 em ambas as redes
• Um domínio do AD (chame-o abc.net), com um controlador de domínio em cada rede.

Os controladores de domínio são instalações novas e novas. Antes de configurar o domínio, tínhamos contas locais para os computadores em nuvem que eram usados para acesso RDP. Nossa idéia era colocar todos os servidores no domínio para que pudéssemos usar logins de domínio em vez de logins locais por servidor.

Antes dos servidores em nuvem estarem no domínio, o RDP (da rede do escritório ou através de uma VPN para a nuvem) funcionava muito bem. Depois que nos associamos aos servidores em nuvem para o domínio, o RDP do escritório ficou muito lento - alguns minutos para fazer login, pausas frequentes quando a interface não responde, geralmente apenas uma experiência lenta e frustrante. Este é um problema, independentemente de um domínio ou login local ser usado para o RDP.

Estranhamente, quando fora da rede do escritório e se conectando à nuvem diretamente com a VPN, o RDP ainda é muito responsivo.

Alguma idéia do motivo pelo qual o RDP do escritório para a nuvem está muito lento depois que os servidores da nuvem ingressam no domínio? O que posso ver em nossa configuração para resolver isso? Qualquer ajuda é muito apreciada.

    

Answer 1

Joeqwerty deu as dicas que levaram a uma solução em um comentário, então vou repetir a solução aqui.

A configuração dos sites e sub-redes resolveu o problema corretamente. Se alguém mais estiver analisando uma configuração semelhante, configuramos isso para ter dois sites do AD, cada um com uma sub-rede relevante (um para o escritório local e outro para a nuvem). Um controlador de domínio é atribuído a cada site e a replicação é configurada por meio de um link de site contendo os dois sites.

Obrigado novamente a joeqwerty pela ajuda.

    

Answer 2

Você pode experimentar o link

Eu tentaria com as seguintes opções:

/ dsgetdc (e observe onde estão os GCs para o site / domínio)

/ dsgetsitecov

/ whowill também é uma opção para ver onde uma determinada conta de usuário está.

Isso pode fornecer pistas suficientes para descobrir por que ...

    

Answer 3

Este é um problema de tamanho de MTU definitivamente. Devido ao túnel IPSEC, você deve reduzir o NIC MTU para evitar a fragmentação de pacotes do padrão para 1400. Use o comando netsh para mostrar sua MTU real:

netsh interface ipv4 show interfaces

Anote sua ID da NIC (primeira coluna, exemplo Idx = 10) e, em seguida, altere a MTU:

netsh interface ipv4 set subinterface "10" mtu=1400 store=persistent