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

IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine translation ou MT), não tendo sido portanto revisto ou traduzido por humanos. A Microsoft tem artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais. O objectivo é simples: oferecer em Português a totalidade dos artigos existentes na base de dados do suporte. Sabemos no entanto que a tradução automática não é sempre perfeita. Esta pode conter erros de vocabulário, sintaxe ou gramática… erros semelhantes aos que um estrangeiro realiza ao falar em Português. A Microsoft não é responsável por incoerências, erros ou estragos realizados na sequência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza actualizações frequentes ao software de tradução automática (MT). Obrigado.

Clique aqui para ver a versão em Inglês deste artigo: 316829
Sintomas
Restaurar um controlador de domínio pode causar um ID de evento: 1587, indicando as inconsistências entre controladores de domínio. Se isto ocorrer, alguns objectos lentos podem estar presentes no controlador de domínio restaurados. Além disso, os novos objectos no controlador de domínio restaurado não são replicados.
Causa
Este problema ocorre porque o controlador de domínio atribui um novo ID de invocação, mas utiliza a marca de níveis original.
Resolução
Para resolver este problema, obtenha o service pack mais recente do Windows 2000. Para obter informações adicionais, clique no número de artigo seguinte para visualizar o artigo na Microsoft Knowledge Base:
260910 Como obter o Service Pack mais recente do Windows 2000
Para resolver este problema, obtenha a correcção descrita no seguinte artigo da Base de dados de conhecimento da Microsoft:
299687 MS01-036: Uma função exposta utilizando LDAP sobre SSL poderia activar palavras-passe a ser alterado
Como contornar
Para contornar este problema, despromover e, em seguida, promover o controlador de domínio restaurados. Antes de despromover o servidor afectado, força uma replicação total de servidor afectado para outro controlador de domínio. (A sincronização completa pode ser recursos para domínios maiores.) Efectue a sincronização completa da partição de domínio e na partição de configuração. A seguinte linha mostra a sintaxe do comando Repadmin que utiliza para efectuar a sincronização:
repadmin /sync <Naming context=""> <Dest dc=""> <Source dc="" guid="">[/force] [/full]</Source> </Dest> </Naming>
A linha seguinte é um exemplo de utilização deste comando:
repadmin /sync DC = domain, DC = raiz good_DC dc1 122a5239-36b3-488a-b24c-971ed0ca8a46 /force /Full
No comando de exemplo,
  • "DC = domain, DC = raiz" é o contexto de atribuição de nomes de domínio.
  • "good_DC" é o DC de destino. Este é o parceiro de bom que irão receber as actualizações.
  • O GUID de DSA é a GUID de replicação para o DC restaurado. Pode obter este executando Repadmin /showreps sobre o servidor restaurado. O GUID é listado na parte superior em "Guid de objecto de DC".
Se a sincronização tiver êxito, receberá a seguinte mensagem:
Sincronizar a partir de 122a5239-36b3-488a-b24c-971ed0ca8a46 para Good_DC foi concluída com êxito.


Repita o processo para o contexto de nomenclatura de configuração utilizando um comando semelhante à seguinte:
repadmin /sync cn = configuration, DC = domain, DC = raiz good_DC dc1 122a5239-36b3-488a-b24c-971ed0ca8a46 /force /Full
O problema não é susceptível de ser resolvido depois de efectuar este procedimento. Depois de efectuar este procedimento, instale a correcção ou despromover e, em seguida, promover o controlador de domínio para resolver o problema.
Ponto Da Situação
A Microsoft confirmou que este é um problema nos produtos da Microsoft listados no início deste artigo. Este problema foi primeiro corrigido no Windows 2000 Service Pack 3.
Mais Informação
Quando restaurar um controlador de domínio, o USN mais alto consolidado é revertido para o ponto de quando foi criada a cópia de segurança. Identificação de invocação do controlador de domínio é retirada e é atribuído um novo. Quando um parceiro tenta replicar pela primeira vez depois do restauro, é registada a seguinte mensagem:

Tipo de evento: Informações
Origem do evento: Replicação de NTDS
Categoria do evento: (5)
ID do evento: 1587
Data: 3/16/2001
Hora: 10:52:35 AM
Utilizador: CONTOSO\CO-THE-DC-01$
Computador: CO-DC-02
Descrição:
O agente de serviço de directório (DSA) correspondente a d0a6a575-9702-4f4e-bf68-bb2a9f875188 do objectGuid solicitou que as alterações a partir de um marcador anterior restauro mais recente do DSA local de cópia de segurança no 94727614 de USN. O marcador está a ser ajustado do seguinte modo: identificação de invocação anterior: bc546028-fae7-4978-abe0-d294694da32b
Actualização de objecto anterior USN: 95853579
Actualização de propriedade anterior USN: 95853579
Novo ID de invocação: ae6286cb-740b-4bb3-ace7-9577efa9dc9f
Nova actualização de objecto USN: 94727614
Nova propriedade actualização USN: 94727614


Este evento é típico para um controlador de domínio restaurados. Por si só, isto não indica um problema. Este é um problema se objectos que são criados no controlador de domínio restaurados "silenciosamente" não são replicadas fora.

O cenário do problema, o USN mais alto é revertido. No entanto, durante o marcador (ou a reposição do vector de "up-to-dateness"), o controlador de domínio de origem fornece o valor de USN mais alto que existia antes do restauro. Objectos que têm valores de USNchanged entre o valor do atributo superior e inferior highestCommittedUSN nunca são considerados para replicação.

Por exemplo: suponha esse controlador de domínio 1 tem um USN mais alto de 100. Parceiro de replicação, o controlador de domínio 2 tem um vector de "up-to-dateness" de 100 para o controlador de domínio 1.

Restaurar o controlador de domínio 1 a partir de uma cópia de segurança no qual o USN mais alto é 50. Após a próxima replicação com o controlador de domínio 2, o controlador de domínio 1 repõe o marcador para 100 (deve ser 50). controlador de domínio 1 tem origem alterações 51, 52 e 53. Quando o controlador de domínio 2 negoceia a replicação, nunca considera as alterações porque que julgue que tem alterações a 100. controlador de domínio 1 continua a efectuar alterações e acaba por atinge 101. Alteração 101 é replicada, mas não são alterações 51 a 100.

Em alguns casos, conseguirá detectar a este estado. Utilize Ldp ou ADSI Edit para ler o atributo highestCommittedUSN actual no objecto rootDSE no controlador de domínio restaurados. Em seguida, comparar que para a saída a partir do repadmin /showreps /verbose dos seus parceiros. Na saída Repadmin, procure o valor de "USN # # # /OU" para o controlador de domínio restaurados para cada contexto de atribuição de nomes. Se o valor Repadmin é mais elevado do que o atributo highestCommittedUSN , o controlador de domínio restaurados está com problemas.

Tenha em atenção que, se o controlador de domínio restaurados teve suficiente actualizações que o atributo highestCommittedUSN atingiu ou excedeu o "up-to-dateness" vector que é registado nos 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 demoradas são referidas como "objectos lentos."
Referências
Para obter informações adicionais sobre objectos lentos, clique no número de artigo seguinte para visualizar o artigo na Microsoft Knowledge Base:

317097 Objectos lentos impedir a replicação do Active Directory ocorra

3125191 ID de evento 1587 é gerado num controlador de domínio quando existem mais de dois controladores de domínio no mesmo local como um servidor de Lync
kbDirServices

Aviso: Este artigo foi traduzido automaticamente

Propriedades

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

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