Tenha um controlador de domínio que tenha participado recentemente de um teste de continuidade de negócios. Pelo que entendi o servidor (que é virtual) foi snapshot, teste realizado enquanto o link entre os dois sites estava inativo e, em seguida, revertido para o instantâneo. Agora que o link está em backup, estou vendo notificações por meio de ventos solares que o serviço do AD está com erro. Olhando para o servidor, o serviço NETLOGON está em pausa. Pelo que posso reunir dos logs de eventos, isso ocorre porque as tentativas repetidas de replicação falharam. Há também uma notificação de que o AD foi restaurado em um método não suportado (provavelmente instantâneo).
Eu tentei forçar a replicação usando o snap-in de sites e serviços, mas isso falha, afirmando que o servidor está atualmente rejeitando a replicação. Eu posso pingar o servidor embora estranhamente parece responder a partir do 10.168.3 NIC e não o 10.168.50 NIC que eu teria esperado. Ambos os IPs podem ser enviados por ping e o servidor pode ser conectado via RDP ou console via vSphere.
Execução de várias falhas no repadmin / show, mas tenho certeza de que elas ocorrem devido a alguma falha subjacente que está impedindo o início do serviço de replicação. Pouco novo para este nível de resolução de problemas, mas seria grato de qualquer ajuda que poderia ser jogado na minha direção.
EDIT: Queria saber se isso pode ter algo a ver com um USN Rollback (?) /. Link para KB aqui
Seu problema é quase definitivamente devido à reversão do USN. A reversão para um instantâneo não é um método suportado para recuperar um DC. Para resolver o problema, siga as etapas descritas no artigo da KB que você mencionou. Isso incluirá despromover o controlador de domínio, limpar os metadados e promovê-lo.
Três coisas:
Se você vir erros assim, nunca tente forçar a replicação. Há uma razão pela qual a replicação foi interrompida e geralmente é ruim.
Não use instantâneos em um controlador de domínio.
Você não quer estar em um cenário em que alguém invente uma cópia antiga de um dc e agora você está replicando objetos que devem ter desaparecido. Se você ainda não fez isso, ative a replicação estrita. A ativação dessa configuração em um controlador de domínio evita que objetos remanescentes sejam replicados de entrada de um DC ofensivo com um objeto remanescente.
Executando controladores de domínio no Hyper-V
link
Do artigo:
A consistência de replicação restrita deve ser habilitada em todos os controladores de domínio
link
Quando um controlador de domínio em seu ambiente do Active Directory é desconectado da topologia de replicação por um período prolongado, todos os objetos excluídos do AD DS em todos os outros controladores de domínio podem permanecer no controlador de domínio desconectado. Tais objetos são chamados de objetos remanescentes. Quando esse controlador de domínio é reconectado à topologia de replicação, ele atua como um parceiro de replicação de origem que possui um ou mais objetos que seus parceiros de replicação de destino não possuem mais. Ocorrem problemas quando esses objetos remanescentes no controlador de domínio de origem são atualizados e essas atualizações são enviadas por replicação para os controladores de domínio de destino. Um controlador de domínio de destino pode responder de duas maneiras:
Se o controlador de domínio de destino tiver replicação rigorosa consistência habilitada, reconhece que não pode atualizar o objeto (porque o objeto não existe) e ele pára localmente na entrada replicação da partição de diretório desse domínio de origem controlador.
Se o controlador de domínio de destino não tiver consistência de replicação ativada, solicita a réplica completa do objeto atualizado, que introduz um objeto persistente no diretório.
Um controlador de domínio desatualizado pode armazenar objetos remanescentes sem nenhum efeito perceptível, desde que um administrador, aplicativo ou serviço não atualize o objeto remanescente ou tente criar um objeto com o mesmo nome no domínio ou com o mesmo usuário principal nome (UPN) na floresta. No entanto, a existência de objetos remanescentes pode causar problemas, especialmente se o objeto for uma entidade de segurança. Os seguintes sintomas indicam que um controlador de domínio tem objetos remanescentes:
Uma conta de usuário ou grupo excluída permanece na lista de endereços global (GAL) em computadores que executam o Microsoft Exchange Server. Assim sendo, embora o nome da conta apareça na GAL, tenta enviar e-mail mensagens resultam em erros.
Várias cópias de um objeto aparecem no seletor de objetos ou GAL para um objeto que deve ser exclusivo na floresta. Objetos duplicados às vezes aparecem com nomes alterados, causando confusão no diretório pesquisas. Por exemplo, se o nome distinto relativo (também conhecido DN) de dois objetos não podem ser resolvidos, a resolução de conflitos é anexada "* CNF: GUID" para o nome, onde * representa um caractere reservado, CNF é uma constante que indica uma resolução de conflitos e GUID representa o valor do atributo objectGUID.
As mensagens de email não são entregues a um usuário cujo Active Directory conta parece estar atual. Após um controlador de domínio desatualizado ou servidor de catálogo global se reconecta, ambas as instâncias do usuário objeto aparecem no catálogo global. Porque ambos os objetos têm o mesmo endereço de e-mail, as mensagens de e-mail não podem ser entregues.
Um grupo universal que não existe mais continua a aparecer em um token de acesso do usuário. Embora o grupo não exista mais, se um usuário conta ainda tem o grupo em seu token de segurança, o usuário pode ter acesso a um recurso que você pretendia não estar disponível para esse do utilizador.
Um novo objeto ou caixa de correio do Exchange não pode ser criado, mas você não ver o objeto no AD DS. Uma mensagem de erro informa que o objeto já existe.
As pesquisas que usam os atributos de um objeto existente encontram incorretamente várias cópias de um objeto com o mesmo nome. Um objeto foi excluído do domínio, mas permanece em um catálogo global isolado servidor.