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.