Login de domínio muito lento por mais de 10 minutos

16

Estamos destruindo nossos cérebros tentando descobrir esse problema e estamos presos no momento!

Basicamente, estamos tendo problemas com alguns usuários que levam idades para fazer login todas as manhãs, algumas vezes até 20 minutos, tentamos corrigir esse problema observando uma variedade de métodos, verificamos o DNS (parece estar bem, embora não seja o meu ponto forte: aceito sugestões), velocidade de rede verificada (parece boa), os usuários em questão não estão usando perfis de roaming e não há políticas que apontem para unidades de rede mapeadas indisponíveis.

Agora, esse é um grande problema, pois muitos usuários reclamam que podem fazer uma xícara de café antes que o computador faça logon.

— Daryl Liney
fonte

3

Vocês têm um servidor ntp e sincronizam todos os seus relógios com esse servidor ntp? Eu quase enlouqueci porque não tínhamos um servidor ntp e todos os nossos AD Maschines onde estavam um pouco fora de sincronia e isso causa tráfego de rede insano e tempos de autenticação muito longos.

— Harrys Kavan

11

embora você tenha mencionado o DNS, verifique se seus clientes estão apontando para os serviços DNS e WINS do servidor Windows. Você também pode tentar configurar as entradas DNS em um sistema local. veja o link para detalhes.

— Striker_84

6

Mark Russinovich possui ótimos links para solucionar problemas de logons lentos . Você pode começar por aí para obter mais informações sobre o seu problema específico.

— Jscott

Tenho duas perguntas sobre o problema: Tem certeza de que não faz o download de todo o diretório do usuário no logon (arquivos, documentos, músicas etc.) do controlador de domínio, e não apenas dos arquivos de configuração? O logout também está lento?

— Str82DHeaD

Verifique tráfego de rede. Objeto móvel + Gigabytes de dados = logon lento.

— TomTom

3

Tivemos um problema semelhante em que as estações de trabalho demoravam cerca de 10 minutos para efetuar o login. No entanto, se o cabo de rede estivesse desconectado e o PC reiniciado, eles se conectariam imediatamente.

Descobrimos que os logons lentos foram causados por um driver de impressora que estava sendo instalado, mas que exigia entrada do usuário, o que obviamente não pôde ser fornecido porque o usuário ainda não estava conectado.

Tente ativar a tela de boas-vindas detalhada no GPO. Isso pode mostrar onde o PC está ficando preso.

— user239341
fonte

Como uma pequena variação dessa solução, resolvi o mesmo problema que o OP tinha ao remover um item de preferência do GP que tentava instalar uma impressora que não existia mais (em vez de exigir a entrada do usuário).

— Eu digo Restabelecer Monica

2

Convém testar a configuração do Registro "BufferPolicyReads". Essa configuração é ativada por padrão no Windows 7, mas precisa ser especificada para o Windows XP.

http://support.microsoft.com/kb/319440

Chave: HKLM \ Software \ Microsoft \ Windows NT \ CurrentVersion \ Winlogon

Valor: BufferPolicyReads
Tipo: DWORD
Valor: 1

— Greg Askew
fonte

1

Para adicionar ao que os outros postaram, eu já vi isso algumas vezes quando o DNS das máquinas clientes está definido como algo diferente de um servidor AD (ou servidor DNS interno), isso é especialmente verdadeiro se o seu domínio local estiver usando .com ou. net ou algo que esteja no domínio DNS público.

— OrganizedChaos
fonte

5

"this is especially true if your local domain is using a .com or .net or something that is in the Public DNS domain."- Não. Isso está errado. Você deve usar o subdomínio em um domínio registrado que você possui para o seu AD. Portanto, se o seu site for, example.comvocê deve usar algo parecido ad.example.comcom o seu Active Directory. Desde que os clientes estejam configurados para usar os controladores de domínio no DNS, não há motivo para desencorajar alguém de usar um .net, .com, .edu ou qualquer outro TLD registrado. Sob nenhuma circunstância você deve sempre usar um TLD falso como .local, .lan, ou .corp.

— precisa saber é

2

@MDMarra so .... Fui procurar sua resposta para provar que você estava errado, porque no passado isso era amplamente considerado uma prática recomendada. Vejo que agora, é recomendável usar um nome DNS público e usar o subdomínio como você mencionou, porque é único. Se a sua empresa fosse para merge, você não terá quaisquer problemas com a fusão de duas AD de com o mesmo nome etc ...

— OrganizedChaos

-3

Tente netsh int ipv4 reset e netsh winsock reset e ipconfig / flushdns, isso foi feito no meu caso

— gonzo
fonte

11

Ajudaria se você fornecesse um motivo para ele executar seu script.

— John aka hot2use