Restaurar un controlador de dominio puede ocasionar incoherencias entre controladores de dominio

IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.

Haga clic aquí para ver el artículo original (en inglés): 316829
Síntomas
Restaurar un controlador de dominio puede ocasionar un Id. de suceso: 1587, que indica las incoherencias entre los controladores de dominio. Si esto ocurre, algunos objetos persistentes pueden estar presentes en el controlador de dominio restaurado. Además, los nuevos objetos en el controlador de dominio restaurado no se replican.
Causa
Este problema se produce porque el controlador de dominio asigna un nuevo identificador de invocación, pero utiliza la marca de agua original.
Solución
Para resolver este problema, obtenga el service pack más reciente para Windows 2000. Para obtener información adicional, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
260910 Cómo obtener el Service Pack más reciente para Windows 2000
Para resolver este problema, obtenga la revisión que se describe en el siguiente artículo de Microsoft Knowledge Base:
299687 MS01-036: Función expuesta al utilizar LDAP sobre SSL podría permitir el cambio de contraseñas
Solución
Para evitar este problema, degradar y después promover el controlador de dominio restaurado. Antes de degradar al servidor afectado, forzar una replicación completa del servidor afectado a otro controlador de dominio. (La sincronización completa puede ser muchos recursos en dominios más grandes.) Realizar la sincronización completa en la partición de dominio y en la partición de configuración. La siguiente línea muestra la sintaxis del comando Repadmin que utilice para realizar la sincronización:
repadmin /sync <Naming context=""> <Dest dc=""> <Source dc="" guid="">[/force] [/full]</Source> </Dest> </Naming>
La línea siguiente es un ejemplo del uso de este comando:
repadmin /sync DC = dominio, DC = raíz good_DC dc1 122a5239-36b3-488a-b24c-971ed0ca8a46 /force/completa
En el ejemplo de comando
  • "DC = dominio, DC = raíz" es el contexto de nomenclatura de dominio.
  • "good_DC" es el controlador de dominio de destino. Éste es el socio buena que va a recibir las actualizaciones.
  • El GUID de DSA es el GUID de replicación para el controlador de dominio restaurado. Puede obtener esto al ejecutar Repadmin /showreps en el servidor restaurado. El GUID se muestra en la parte superior en "Guid de objeto de controlador de dominio".
Si la sincronización se realiza correctamente, recibirá el siguiente mensaje:
Sincronización de 122a5239-36b3-488a-b24c-971ed0ca8a46 a Good_DC finalizada correctamente.


Repita el proceso para el contexto de nomenclatura de configuración mediante un comando similar al siguiente:
repadmin /sync cn = configuration, DC = dominio, DC = raíz good_DC dc1 122a5239-36b3-488a-b24c-971ed0ca8a46 /force/completa
El problema no es probable que se solucionará después de hacer esto. Después de hacerlo, instale la revisión o degradar y después promover el controlador de dominio para solucionar el problema.
Estado
Microsoft ha confirmado que se trata de un problema de los productos de Microsoft enumerados al principio de este artículo. Este problema se corrigió primero en Windows 2000 Service Pack 3.
Más información
Cuando restaura un controlador de dominio, el mayor USN comprometido se deshace hasta el punto cuando se creó la copia de seguridad. Id. de invocación del controlador de dominio se retira y se asigna una nueva. Cuando un socio intenta replicar la primera vez después de la restauración, se graba el mensaje siguiente:

Tipo de evento: información
Origen del suceso: Replicación de NTDS
Categoría del suceso: (5)
Id. de suceso: 1587
Fecha: 3/16/2001
Hora: 10:52:35 AM
Usuario: CONTOSO\CO-NA-DC-01$
Equipo: CO-DC-02
Descripción:
Directory Service Agent (DSA) correspondiente a la d0a6a575-9702-4f4e-bf68-bb2a9f875188 de objectGuid ha solicitado cambios empezando por un marcador anterior de restauración más reciente de la local DSA de copia de seguridad en 94727614 de USN. El marcador se ajusta como sigue: identificador de invocación anterior: bc546028-fae7-4978-abe0-d294694da32b
Actualización de objeto anterior USN: 95853579
Actualización de la propiedad anterior USN: 95853579
Nueva ID: ae6286cb-740b-4bb3-ace7-9577efa9dc9f
Nueva actualización del objeto USN: 94727614
Actualización de la nueva propiedad USN: 94727614


Este evento es típico para un controlador de dominio restaurado. Por sí mismo, esto indica un problema. Esto es un problema si los objetos creados en el controlador de dominio restaurado "silenciosamente" no se replican fuera.

En el escenario del problema, el mayor USN se deshace. Sin embargo, durante el marcador (o restablecimiento de vector de "actualización"), el controlador de dominio de origen proporciona el valor más alto de USN que estaba presente antes de la restauración. Los objetos que tienen valores de USNchanged entre el valor del atributo superior e inferior highestCommittedUSN nunca se consideran para la replicación.

Por ejemplo: supongamos que ese controlador de dominio 1 tiene un USN mayor de 100. Su asociado de replicación, el controlador de dominio 2, tiene un vector de "actualización" de 100 para el controlador de dominio 1.

Restaurar el controlador de dominio 1 desde una copia de seguridad en el que el mayor USN es 50. Después de la siguiente replicación con el controlador de dominio 2, 1 del controlador de dominio restablece el marcador a 100 (debe ser 50). controlador de dominio 1 origina cambios 51, 52 y 53. Cuando el controlador de dominio 2 negocia replicación, nunca considera los cambios porque cree que tiene cambios a 100. controlador de dominio 1 continúa realizar cambios y finalmente llega a 101. Cambio 101 se duplica, pero no cambios 51 a 100.

En algunos casos, puede detectar este estado. Utilice Ldp o ADSI Edit para leer el atributo highestCommittedUSN actual en el objeto rootDSE en el controlador de dominio restaurado. A continuación, compárelo con el resultado de la repadmin /showreps / verbose comando en uno de sus asociados. En el resultado de Repadmin, busque el valor "/ de USN ### OU" para el controlador de dominio restaurado para cada contexto de nombres. Si el valor de Repadmin es mayor que el atributo highestCommittedUSN , el controlador de dominio restaurado está experimentando el problema.

Tenga en cuenta que si se ha originado el controlador de dominio restaurado suficiente actualizaciones que su atributo highestCommittedUSN alcanzó o superó el grado de "actualización" de vectores que se registra en los otros controladores de dominio (como en el ejemplo de este artículo), nunca se considerarán algunos cambios para la replicación. Sin embargo, los nuevos cambios se replican hacia fuera. Los cambios no replicados se conocen como "objetos persistentes".
Referencias
Para obtener información adicional acerca de los objetos persistentes, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:

317097 Los objetos persistentes impiden la replicación de Active Directory se produzca

3125191 Id. de suceso 1587 se genera en un controlador de dominio cuando hay más de dos controladores de dominio en el mismo sitio que un servidor de Lync
kbDirServices

Advertencia: este artículo se tradujo automáticamente

Propiedades

Id. de artículo: 316829 - Última revisión: 01/25/2016 22:01:00 - Revisión: 1.0

  • kbbug kbdirservices kbfix kbwin2000presp3fix kbwin2000sp3fix kbmt KB316829 KbMtes
Comentarios