Porque o início de sessão por VPN se arrasta: perfil, redirecionamento ou ficheiros offline
Um início de sessão remoto lento são três esperas numa. Meça em separado o carregamento do perfil, a pasta redirecionada e a cache offline antes de alterar uma política.
O portátil inicia sessão em cerca de quarenta segundos no escritório e demora minutos em casa, e ninguém alterou uma política entretanto. O que mudou foi o caminho de rede por baixo de três funcionalidades que parecem iguais e se comportam de forma diferente. Um perfil móvel carrega o estado do registo e as pastas do perfil, o redirecionamento de pastas aponta uma pasta da shell para uma partilha de servidor, e os ficheiros offline mantêm uma cache de dados de rede elegíveis. As três podem acrescentar tempo a um início de sessão, e normalmente só uma delas é responsável.
Três esperas com três responsáveis diferentes
O perfil móvel é o que faz com que as definições do utilizador sigam uma pessoa entre computadores participantes, e o carregamento ocorre cedo na sessão. O ramo do registo do utilizador e as pastas do perfil são copiados ou fundidos ao iniciar sessão, e depois escritos de volta ao terminar. Esse trabalho é síncrono, e é por isso que um caminho lento até à partilha de perfis se sente como um ambiente de trabalho lento e não como uma cópia de ficheiros lenta.
O redirecionamento de pastas é outro mecanismo. Move pastas da shell selecionadas, Documentos é o exemplo comum, para um local de rede suportado e deixa-as ficar lá. O perfil pode então continuar pequeno, porque os dados não estão dentro dele, e o custo passa para o momento em que a shell ou uma aplicação toca nessa pasta.
Os ficheiros offline acrescentam uma cache local mais sincronização para os ficheiros de rede elegíveis. Respondem a outra pergunta, que é o que acontece quando o servidor não está acessível, e podem gastar tempo a sincronizar ao iniciar e terminar sessão quando a cache está desatualizada. É tratar as três como uma única definição que produz uma política lenta numa direção e inútil na outra.
Meça qual está realmente à espera
Comece por ler onde vive o perfil e se é carregado a partir de um caminho de servidor. Depois meça o tempo de uma listagem de diretório em cada partilha que a sessão toca, porque uma partilha que responde em milissegundos na rede local pode levar segundos através de um túnel e de um servidor de ficheiros ocupado.
Estes dois factos delimitam o problema mais depressa do que qualquer auditoria de políticas, e não exigem qualquer alteração de configuração para serem recolhidos. Execute-os no portátil afetado, não num servidor que esteja ao lado da partilha.
Get-CimInstance Win32_UserProfile | Select-Object LocalPath, Loaded, SID
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\*' | Select-Object ProfileImagePath
Measure-Command { Get-ChildItem '\\fs01.corp.internal\profiles\a.singh' | Out-Null }Se o caminho do perfil for local e apenas uma pasta redirecionada apontar para um servidor, o carregamento do perfil não é a sua espera, diga o que disser o ticket de suporte. Se o caminho do perfil for remoto e a listagem demorar segundos, o início de sessão está à espera dessa partilha, e a correção diz respeito ao caminho ou ao tamanho do perfil e não ao próprio ambiente de trabalho. Leia os números nessa ordem e a discussão costuma terminar aí.
A ligação chega depois de a espera ter começado
Um túnel de utilizador que arranca a partir do ambiente de trabalho aparece muito depois de o perfil ter sido carregado, por isso não pode ajudar a fase que estava lenta. O Windows deteta o caminho indisponível, recorre a credenciais em cache e a um perfil local, e a sessão acaba por abrir. É por isso que o mesmo portátil pode demorar minutos no primeiro início de sessão em casa e segundos no segundo, quando já existe um perfil em cache. A espera é real, mas a ligação de que precisa não existe nesse momento.
Corrigir isso significa avançar a ligação, não afinar o perfil. Um túnel de máquina ou uma ligação antes do início de sessão com autenticação de computador estabelece o caminho antes de o utilizador iniciar sessão, e precisa do seu próprio ciclo de vida de certificado e das suas próprias regras de firewall. As credenciais em cache são a outra metade do desenho, e só funcionam para contas que já iniciaram sessão antes.
Teste a sequência e não os componentes. Termine sessão por completo, inicie o túnel como faria um utilizador remoto e meça o início de sessão desde o pedido de credenciais até um ambiente de trabalho utilizável.
Mantenha os documentos fora do perfil
A partilha de perfis é o local errado para grandes coleções de documentos, e o guia de implementação de perfis móveis da Microsoft mantém por esse motivo separados o armazenamento de perfis e as partilhas de pastas redirecionadas. Um perfil que transporte uma pasta Documentos de vários gigabytes será lento em cada início e termo de sessão, e o tamanho cresce em silêncio até que alguém o meça.
Redirecione as pastas que guardam dados e deixe o perfil guardar definições. Exclua as caches que podem ser reconstruídas, como as do navegador e os dados temporários de aplicações, porque transferi-las acrescenta tempo e não altera nada que o utilizador veja. Mantenha os dados da caixa de correio e outros armazenamentos de aplicações no local suportado pela aplicação, e não num caminho móvel.
Não torne a partilha de perfis disponível offline. Os ficheiros offline pertencem a partilhas de dados elegíveis, e um ramo de perfil em cache que sincroniza nos dois sentidos é um relatório de corrupção à espera de acontecer.
Teste os quatro cenários antes de o dar como resolvido
Um início de sessão rápido no escritório prova muito pouco. O desenho tem de sobreviver ao acesso a partir do escritório, ao trabalho a partir de casa através do túnel, ao trabalho sem ligação e ao regresso ao escritório, porque é no quarto caso que aparecem os conflitos de sincronização. Meça os mesmos quatro com uma conta controlada e as aplicações reais, e anote os números.
Recolha o registo do serviço de perfis e o conjunto de políticas resultante da sessão afetada, e não da sua estação de trabalho administrativa.
Get-WinEvent -LogName 'Microsoft-Windows-User Profile Service/Operational' -MaxEvents 30
gpresult /r /scope:user
Measure-Command { Get-ChildItem '\\fs01.corp.internal\users\a.singh\Documents' | Out-Null }Compare esses tempos com a linha de base do escritório e com o tamanho do que está a ser transferido. Um início de sessão que ainda leva um minuto com um perfil pequeno e uma partilha rápida não é um problema de perfil, e o local seguinte a observar é o processamento da Política de Grupo ou um script de início de sessão que espera pela rede. Se é aí que está a diferença, o perfil nunca foi o problema. Confirme que o trabalho não sincronizado é preservado antes de alterar uma política de pastas ou limpar uma cache, uma vez que a sincronização e uma cópia de segurança recuperável são garantias diferentes.