O Terminal Server 2008 (32 bits) falha ao carregar o perfil (às vezes)

2

Estou tendo um problema com um Terminal Server virtualizado que executa o Windows Server 2008 (32 bits). Não parece estar afetando nenhum usuário que esteja se conectando com o HP Thin-Clients, somente com minhas contas de teste que são contas de usuários do AD e todos os membros de Usuários do Domínio. Além dessas contas de usuário de teste, também estou tendo o mesmo problema ao fazer login com uma conta de administrador de domínio.

A mensagem que recebo é:

Your user profile was not loaded correctly! You have been logged on with a temporary profile. Changes you make to this profile will be lost when you log off. Please see the event log for details or contact your administrator.

A correção temporária é:

  • faça logon no Terminal Server com uma conta de administrador
  • inicie o regedit
  • goto: "HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ ProfileList \ SIDoftheuseraccount" onde você vê o nome de usuário real ao clicar na entrada da pasta
  • depois de encontrar a pasta (que deve ter um .bak anexado a ela), localize a pasta correspondente que não possui um .bak. Esta pasta terá o nome de usuário definido como "Temp.MYDOMAIN" ou algo semelhante a isso. Excluir esta pasta inteira
  • remova o arquivo .bak da pasta de perfil do usuário real
  • efetue login novamente como usuário e o perfil é carregado corretamente

Existem vários erros registrados:

  • ID do Evento 1515: o Windows fez backup desse perfil de usuário. O Windows tentará usar automaticamente o perfil de backup na próxima vez que esse usuário fizer logon.

  • ID do evento 1511: O Windows não pode encontrar o perfil local e está fazendo logon com um perfil temporário. As alterações feitas nesse perfil serão perdidas quando você fizer logoff.

  • ID do Evento 1508: o Windows não pôde carregar o registro. Esse problema geralmente é causado por memória insuficiente ou direitos de segurança insuficientes. DETALHE - O processo não pode acessar o arquivo porque está sendo usado por outro processo. para C: \ Users \ Administrator.MYDOMAIN.000 \ ntuser.dat

  • ID do evento 1502: o Windows não pode carregar o perfil armazenado localmente. Possíveis causas desse erro incluem direitos de segurança insuficientes ou um perfil local corrompido. DETALHE - O processo não pode acessar o arquivo porque está sendo usado por outro processo.

Mais detalhes sobre minha configuração:

Este é um padrão do Windows Server 2008. Servidor de Terminal virtual SP2 (32 bits) com 32 GB de RAM em execução no Hyper-V em um servidor Windows Server 2008 R2 EE SP1 com 72 GB de RAM. O motivo para a execução de um TS virtual de 32 bits é devido a vários aplicativos herdados de 16 bits que são essenciais para nossos negócios. Esses aplicativos também não são candidatos à implantação via RemoteApp por diversos motivos (foi tentado).

Eu estou querendo saber se esse problema tem a ver com como a memória está configurada para o Terminal Server. É incorreto criar um TS com 32 GB de memória e permitir que os usuários façam logon (embora com GPOs adequados)? Assim, para todos os usuários conectados, eles veriam que eles têm acesso a um total de 32 GB de memória. Se isso estiver incorreto, por favor, deixe-me saber qual é a prática geral.

Atualmente, no servidor, há 19 GB de memória livre com 6 usuários ativos conectados.

    
por JohnyD 16.09.2011 / 13:59

1 resposta

0

Eu tenho exatamente o mesmo problema. Apenas minha configuração é um win2008r2 x64 no Vmware Esxi. Toda vez que o número de usuários logados chega a 40, qualquer usuário que esteja conectado a partir daquele momento recebe um perfil temporário.

Solução alternativa:
Mova alguns dos usuários para outras instâncias virtualizadas do Terminal Server.

Causa e correção: O registro no nosso servidor foi inchado para mais de 2GB. Alguns drivers de impressora (Kyocera, Sharp) não estão funcionando corretamente e copiam algumas chaves do Registro sempre que um usuário faz logon no Terminal Server inchando-o no processo. Depois que limpamos o registro, o servidor voltou ao normal.

    
por 20.01.2014 / 10:42