Há muita literatura de administração sobre como gerenciar servidores Windows de maneira adequada. Mas ao lidar com a vida real, as coisas nem sempre acontecem como você deseja. No Windows Server 2003 Administrator's Companion da Microsoft, entre mais de 1400 páginas, há apenas uma página que consegui encontrar quando se trata de configurar controladores de domínio adicionais. Eles fazem com que pareça absurdo e não revelam muito sobre o que acontece se os DCs "pares" não conseguirem replicar.
No que diz respeito ao problema específico em questão, um DC caiu há cerca de um mês devido a um controlador RAID defeituoso. Não havia nada crítico que justificasse atenção imediata, então trazê-lo de volta foi colocado em segundo plano. Um mês depois, colocamos o DC novamente em funcionamento e tudo parecia bem. No dia seguinte, ninguém consegue fazer logon reclamando que o"Usuário não existe"ou"incapaz de estabelecer uma relação de confiança". Sabendo que tinha acabado de colocar o DC desligado de volta na rede, imediatamente o retirei da rede e fiz com que todos reiniciassem as estações de trabalho. Depois disso, a troca correu bem, os compartilhamentos ficaram disponíveis e todos puderam fazer login. Depois de nadar no log de eventos, parece que tudo começou devido a problemas de replicação no SYSVOL. Eu li onde você pode forçar a replicação, mas isso significaria colocá-la novamente na rede. Tenho medo de colocar o DC de volta na rede, com medo de que algo mais possa dar errado. Então, que outros problemas alguém poderia esperar encontrar onde dois DCs não são replicados por mais de um mês?
Responder1
Dependendo de quanto tempo eles não estão sincronizados, você pode se deparar com uma situação em que alguém atinge seuVida útil da lápidedepois disso, você começa a ter problemas com objetos excluídos voltando à vida. Dito isto, o padrão mínimo é de 60 dias, então você não terá problemas se já tiver passado menos tempo.
A maneira como o AD (e o DNS e uma série de outros serviços) lida com problemas de sincronização é incrementando um número de série cada vez que alterações são feitas. Portanto, se você estiver usando PRIMARYDCe fazendo alterações, SECONDARYDCterá um número menor e irá adiar para o maior.
Se você estiver REALMENTE preocupado, você sempre pode limpar SECONDARYDC, retirá-lo manualmente do Active Directory, recriá-lo e promovê-lo normalmente para ser outro DC. Acho que você está seguro em colocá-lo online e resolver seus problemas de SYSVOL. Se você quiser ser ainda mais paranóico, faça isso depois do expediente para não obter inconsistências enquanto resolve o SYSVOL.
EDITAR O Adaptr abaixo faz uma boa observação - certifique-se de que não haja funções FSMO atribuídas SECONDARYDCantes de apagá-lo, se você optar por seguir esse caminho.