Restaurar um controlador de domínio pode causar inconsistências entre controladores de domínio

IMPORTANTE: Este artigo foi traduzido pelo software de tradução automática da Microsoft e eventualmente pode ter sido editado pela Microsoft Community através da tecnologia Community Translation Framework (CTF) ou por um tradutor profissional. A Microsoft oferece artigos traduzidos automaticamente por software, por tradutores profissionais e editados pela comunidade para que você tenha acesso a todos os artigos de nossa Base de Conhecimento em diversos idiomas. No entanto, um artigo traduzido pode conter erros de vocabulário, sintaxe e/ou gramática. A Microsoft não é responsável por qualquer inexatidão, erro ou dano causado por qualquer tradução imprecisa do conteúdo ou por seu uso pelos nossos clientes.

Clique aqui para ver a versão em Inglês deste artigo: 316829
Sintomas
Restaurar um controlador de domínio pode causar uma identificação de evento: 1587, indicando as inconsistências entre os controladores de domínio. Se isso ocorrer, alguns objetos remanescentes podem estar presentes no controlador de domínio restaurado. Além disso, novos objetos no controlador de domínio restaurado não são replicados.
Causa
Esse problema ocorre porque o controlador de domínio atribui uma nova identificação de chamada, mas usa a marca highwater original.
Resolução
Para resolver esse problema, obtenha o service pack mais recente para o Windows 2000. Para obter informações adicionais, clique no número abaixo para ler o artigo na Base de Conhecimento Microsoft:
260910 Como obter o Service Pack mais recente do Windows 2000
Para resolver esse problema, obtenha o hotfix descrito no seguinte artigo da Base de Conhecimento Microsoft:
299687 MS01-036: Função exposta usando LDAP sobre SSL poderia permitir que as senhas sejam alteradas
Como Contornar
Para contornar esse problema, rebaixar e promover o controlador de domínio restaurado. Antes de rebaixar o servidor afetado, força uma replicação completa do servidor afetado para outro controlador de domínio. (Sincronização completa pode usar recursos para domínios maiores.) Execute a sincronização completa na partição do domínio e na partição de configuração. A linha a seguir mostra a sintaxe do comando Repadmin que você usa para executar a sincronização:
Repadmin /sync <Naming context=""> <Dest dc=""> <Source dc="" guid="">[/force] [/full]</Source> </Dest> </Naming>
A linha a seguir é um exemplo de uso deste comando:
Repadmin /sync DC = domain, DC = raiz good_DC dc1 122a5239-36b3-488a-b24c-971ed0ca8a46 /force/completo
No exemplo de comando,
  • "DC = domain, DC = root" é o contexto de nomeação de domínio.
  • "good_DC" é o controlador de domínio de destino. Isso é bom parceiro que receberá as atualizações.
  • O DSA GUID é a GUID de replicação para o controlador de domínio restaurado. Você pode obter isso executando Repadmin /showreps no servidor restaurado. O GUID é listado na parte superior em "Guid do objeto de controlador de domínio".
Se a sincronização for bem-sucedida, você recebe a seguinte mensagem:
Sincronização de 122a5239-36b3-488a-b24c-971ed0ca8a46 para Good_DC foi concluída com êxito.


Repita o processo para o contexto de nomeação de configuração usando um comando similar à seguinte:
Repadmin /sync cn = configuration, DC = domain, DC = raiz good_DC dc1 122a5239-36b3-488a-b24c-971ed0ca8a46 /force/completo
O problema não é provável de ser resolvido após você fazer isso. Após fazer isso, instale o hotfix ou rebaixar e promover o controlador de domínio para resolver o problema.
Situação
A Microsoft confirmou que este é um problema nos produtos Microsoft que estão listados no início deste artigo. Esse problema foi corrigido primeiro no Windows 2000 Service Pack 3.
Mais Informações
Quando você restaurar um controlador de domínio, o USN mais alto de compromisso é revertido para o ponto de quando o backup foi criado. Identificação de chamada do controlador de domínio for retirada e uma nova é atribuída. Quando um parceiro tenta replicar na primeira vez após a restauração, a mensagem a seguir é registrada:

Tipo de evento: informações
Origem do Evento: Duplicação de NTDS
Categoria do evento: (5)
Identificação do evento: 1587
Data: 16/3/2001
Tempo: 10:52:35 AM
Usuário: CONTOSO\CO-NA-DC-01$
Computador: CO-DC-02
Descrição:
O agente de serviço de diretório (DSA) correspondente ao d0a6a575-9702-4f4e-bf68-bb2a9f875188 objectGuid pediu para alterações começando em um indicador que precede a restauração mais recente do DSA local do backup em 94727614 de USN. O indicador está sendo ajustado da seguinte forma: identificação da invocação anterior: bc546028-fae7-4978-abe0-d294694da32b
Atualização de objeto anterior USN: 95853579
Atualização de propriedade anterior USN: 95853579
Nova identificação de chamada: ae6286cb-740b-4bb3-ace7-9577efa9dc9f
Nova atualização do objeto USN: 94727614
Nova atualização de propriedade USN: 94727614


Este evento é típico para um controlador de domínio restaurado. Por si só, isso não indica um problema. Este é um problema se não duplicar objetos criados no controlador de domínio restaurado "silenciosamente" check-out.

No cenário de problema, o USN mais alto é revertido. No entanto, durante o indicador (ou redefinição de vetor "UTDV"), o controlador de domínio de origem fornece o valor USN mais alto que existia antes da restauração. Objetos que possuem valores de USNchanged entre o valor do atributo superior e inferior highestCommittedUSN nunca são considerados para replicação.

Por exemplo: suponha que esse controlador de domínio 1 tem o USN mais alto de 100. Seu parceiro de replicação, o controlador de domínio 2, tem um vetor de "UTDV" de 100 para o controlador de domínio 1.

Restaure 1 do controlador de domínio de backup no qual o USN mais alto é 50. Após a próxima replicação com o controlador de domínio 2, 1 do controlador de domínio redefine o indicador para 100 (deve ser 50). controlador de domínio 1 se origina alterações 51, 52 e 53. Quando o controlador de domínio 2 negocia a replicação, ele nunca considera as alterações porque acredita que há alterações a 100. controlador de domínio 1 continua a fazer alterações e eventualmente atinge 101. Alteração 101 é replicada, mas não as alterações de 51 a 100.

Em alguns casos, você pode detectar esse estado. Use Ldp ou ADSI Edit para ler o atributo highestCommittedUSN atual no objeto rootDSE do controlador de domínio restaurado. Em seguida, compare isso com a saída do repadmin /showreps /verbose comando em um de seus parceiros. Na saída do Repadmin, procure o valor "USN # # # /OU" para o controlador de domínio restaurado para cada contexto de nomeação. Se o valor do Repadmin for maior do que o atributo highestCommittedUSN , o controlador de domínio restaurado está tendo o problema.

Observe que se originou no controlador de domínio restaurado suficiente atualizações que seu atributo highestCommittedUSN atingiu ou excedeu o UTDV"" de vetor que é registrado em outros controladores de domínio (como no exemplo neste artigo), algumas alterações nunca serão consideradas para replicação. No entanto, as novas alterações são replicadas fora. As alterações não-duplicadas são conhecidas como "objetos remanescentes."
Referências
Para obter informações adicionais sobre objetos remanescentes, clique no número abaixo para ler o artigo na Base de Conhecimento da Microsoft:

317097 Objetos remanescentes impede que ocorra a replicação do Active Directory

3125191 Identificação de evento 1587 é gerada em um controlador de domínio quando houver mais de dois controladores de domínio no mesmo site como um servidor de Lync
kbDirServices

Aviso: este artigo foi traduzido automaticamente

Propriedades

ID do Artigo: 316829 - Última Revisão: 01/25/2016 22:05:00 - Revisão: 1.0

  • kbbug kbdirservices kbfix kbwin2000presp3fix kbwin2000sp3fix kbmt KB316829 KbMtpt
Comentários