Você examinou os logs do Serviço de Replicação de Arquivo / DFSR para ver se há erros lá? Já vi casos em que corrupções / erros no USNJournal causam esses tipos de problemas.
Problema: Nos últimos 3 anos, encontrei o problema "A relação de confiança entre esta estação de trabalho e o domínio principal falhou" menos de três vezes. Esses casos eram todos os laptops que não estavam conectados à rede há muito tempo. Agora, nos últimos 3 meses, tive 6 incidentes, 1 em um desktop sempre conectado à rede e 1 em um servidor virtual nosso.
Geralmente, a correção é desunida e voltada para o domínio. Se esse problema se tornar mais predominante, a correção será inconveniente, na melhor das hipóteses, e quase impossível se você tiver que percorrer alguém remotamente, sem saber de tecnologia. Eu gostaria de sair na frente desta questão, se possível.
A causa, eu li, é quando uma das senhas da conta da máquina (no computador) (2 são armazenadas) não corresponde à senha armazenada para a conta da máquina no AD. Posso ver isso acontecendo se a máquina não estiver na rede há algum tempo, mas isso está acontecendo com computadores e servidores que estão conectados à rede 100% do tempo ou sem fio por curtos períodos de tempo.
Estou tentando diagnosticar se há um problema com a maneira como nossas máquinas e servidores estão conversando entre si, causando esse erro em pop-ups em máquinas que estão sempre conectadas à rede ou conectadas com freqüência suficiente para que as senhas entre a máquina e o servidor não deve estar fora de sincronia.
Plano de fundo: servidores mistos 2003 e 2008 R2, máquinas mistas XP e Windows 7. 3 locais físicos divididos em UOs separadas.
Pesquisa: Novas máquinas não são clonadas de uma imagem que poderia causar conflitos de "mesmo nome" na rede. Isso não é específico para uma OU ou outra. Isso não é específico para um sistema operacional ou outro.
Eu mergulhei em logs de eventos do sistema e ativei a depuração de logon de rede sem itens específicos aparecerem no meu, mas meu conhecimento de Log do Windows Server é bastante limitado.
Qualquer ajuda é apreciada.
Você examinou os logs do Serviço de Replicação de Arquivo / DFSR para ver se há erros lá? Já vi casos em que corrupções / erros no USNJournal causam esses tipos de problemas.
Eu já vi isso com bastante frequência quando alguém desliga o computador incorretamente (mantém pressionado o botão liga / desliga) depois que a senha da máquina é redefinida. O reparo de inicialização é executado na próxima inicialização e restaura o computador para um estado anterior (antes da alteração da senha) causando esse erro. A maneira mais fácil de corrigir isso que eu encontrei é logar ou remotamente como administrador local e executar o seguinte no powershell. A credencial deve ser uma conta com permissões apropriadas no domínio.
Reset-ComputerMachinePassword -Credential (Get-Credential)
Consulte a documentação para obter detalhes.