LAN com servidor AD: problemas recorrentes de link lento, como diagnosticar?

Question

Eu tenho um domínio do Active Directory para vários sites. Todos os controladores de domínio em todos os sites estão executando o Windows 2012 Standard R2.

Site 1 e 2: tudo funciona bem

Site 3: acabei de configurar e estou com problemas consistentes em vários computadores em que

1. O primeiro login em um computador às vezes leva muito tempo (configuração inicial da conta de um usuário do domínio em um novo computador)
2. As unidades mapeadas da política de grupo não aparecem, mesmo que gpresult relate que a política de grupo foi aplicada corretamente
3. gpupdate costuma demorar muito tempo para ser aplicado.

Confirmei que os sites estão configurados corretamente no AD e que apenas os dois servidores locais do AD estão conectados ao site local. Além disso, confirmei por meio de echo %logonserver% que minhas máquinas locais estão usando apenas os servidores AD locais para efetuar login.

Posso fazer ping nos servidores do AD de maneira consistente com o tempo de resposta de < 1ms. Todo o cabo de rede no edifício foi instalado recentemente e o CAT6, e os sintomas não parecem afetar consistentemente um computador acima dos outros: é bastante aleatório. Às vezes, as unidades mapeadas são carregadas com êxito, às vezes não. Existem apenas cerca de 15 computadores no edifício, e todos passam por um switch Cisco gigabit de 48 portas que está executando o firmware mais recente disponível.

Os próprios servidores do AD estão sendo executados em uma VM no topo de um Intel i5, RAID SSDs e cada um tem 8 GB de memória distribuídos.

A única pista comum que vejo quando estou executando gpresult é que estou recebendo um aviso slow link detected , o que parece bobo considerando que tudo está na LAN e conectado via gigabit. Em minha pesquisa, parece que é de se esperar que as unidades mapeadas não fiquem aparentes em conexões de link lentas.

Como posso diagnosticar a causa deste problema?

    

Answer 1

LogonServer ou mesmo nltest / dsgetdc podem não refletir com precisão qual controlador de domínio é usado para obter diretivas de grupo. Já vi cenários em que o controlador de domínio local está sendo usado corretamente para autenticação, mas um controlador de domínio em outro site para diretivas de grupo.

Você precisa realizar:

• uma captura de pacote netmon do logon lento em uma estação de trabalho afetada.
• confirme se nltest / dsgetdc: está usando o controlador de domínio correto e o endereço IP correto (se for multi-homed - esperançosamente não).
• ative o log de depuração do ambiente de política de grupo na estação de trabalho afetada e revise os logs por: link

Ativando o Log do UserEnv no Windows 7

No Windows 7, o processamento de GPOs é executado por um serviço chamado "Cliente de Diretiva de Grupo". Um arquivo de log pode ser gravado pelo serviço ao implementar o seguinte valor do registro:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics]  
"GPSvcDebugLevel"=dword:00030002  

O arquivo de log resultante será % WINDIR% \ debug \ usermode \ gpsvc.log

    

Answer 2

Bem, eu decidi tentar algo ... Redefinir meu Cisco Mude para os padrões de fábrica e o problema do link lento foi embora. Só por segurança, decidi então trocar o switch inteiro por um Switch de backup idêntico que possuo no local, executando também os padrões de fábrica. gpresult agora identifica o link como alta velocidade. No entanto, ainda estou com problemas em que gpupdate demora muito para aplicar (às vezes 10 segundos, às vezes 120 segundos) e também meu mapa de unidade aparece intermitentemente.

Estou pensando que talvez eu deva repassar com um título diferente, já que o sintoma slow link não parece tão crítico quanto eu pensava.