Aguardando o serviço de perfil de usuário - para sempre

1

Eu tenho dois servidores AD separados por um T1.

O local A, que hospeda o servidor principal de AD / DNS / Roaming Profiles, é a sub-rede 192.168.0

O local B, que é o servidor AD secundário (estou tentando configurar, mas ...) está na sub-rede 192.168.1

Entendo que isso pode ser um problema de DNS. O único servidor DNS que atribuí a essa sub-rede via DHCP em um Sonicwall é o servidor AD no Local A. Eu obtive resultados positivos dos testes DNS em ping e nslookup.

Eu uni-me, desconectei e reingrei o domínio.

Todo o Visualizador de Eventos está me dizendo que o login está demorando muito, demorou 931 segundos, está demorando para fazer logoff, e não há um recurso csc que possa ser carregado ...

É simplesmente que o perfil é muito grande em tamanho para o T1? Eu habilitei o Redirecionamento de Pasta - ainda demorando para sempre, preso em "esperando pelo serviço de perfil de usuário".

Observe que isso acontece tanto no Win2k8R2 quanto no Windows 7 regular no Local B.

Agora também está no Local A ... [Possivelmente corrigido - pode ser apenas o tamanho do perfil bruto, mesmo com o redirecionamento de pastas]

Qual é a melhor maneira de solucionar esse problema?

    
por Earls 23.06.2011 / 04:48

1 resposta

2

Eu não faria nenhuma suposição sobre a causa até que você obtenha mais detalhes sobre o que realmente está acontecendo. Se você está vendo logons lentos em ambos os locais, é difícil responsabilizar totalmente a infraestrutura da WAN (embora eu tenha certeza que isso é um pouco culpado ... o T1 costumava se sentir tão rápido ... agora eles são apenas dolorosos para mim).

Qualquer um que me conhecer poderá cantar junto aqui: Pegue um farejador e observe o que está sendo enviado pelo fio. Ver o quanto o tráfego está se movendo durante esses cenários de logon lento (não importa qual é a composição do tráfego - apenas a quantidade bruta) vai lhe dizer muito sobre o problema. Se você vir um pouco de tráfego, poderá começar a investigar por que você está vendo apenas uma gota. Se você vir uma inundação, poderá começar a descobrir como dimensionar os dados que estão sendo enviados. Até que você saiba o que está acontecendo nos bastidores, no entanto, você está apenas tomando facadas no escuro. Os logs de eventos no cliente e no servidor não são particularmente úteis neste cenário, na minha opinião.

Não está claro para mim se o servidor que hospeda o compartilhamento de perfis móveis está executando o W2K8 (ou mais recente) ou não. Se for o seu Windows 7 / W2K8R2, os clientes devem usar o SMB2 e fazer um trabalho decente de operações de pipelining para melhor utilização do T1. Dito isto, os perfis de roaming de qualquer tamanho (particularmente se o diretório AppData for preenchido com o tipo de lixo que o Flash Player e o Java Runtime Environment gostam de acumular lá) serão dolorosos para sincronizar um T1. Você pode redirecionar as coisas para fora do perfil e reduzi-lo bastante, mas ainda pode ser doloroso.

Pegue uma cópia do Wireshark, porta-espelhe a porta do switch onde um cliente de teste está conectado e chegue a farejar. Você deve ser capaz de obter alguns detalhes imediatamente sobre a quantidade bruta de tráfego. Então você pode começar a detalhar os detalhes.

    
por 23.06.2011 / 05:33