Como resolver problemas de replicación de Active

Directory
blogs.technet.microsoft.com/latam/2010/04/22/como-resolver-problemas-de-replicacin-de-active-directory/

Juan Carlos Albert (msft) April 22, 2010

Por: Juan Carlos Albert y Martin Kirtchayan

Que ocurre cuando tenemos un ambiente en el cual, nos encontramos con que la replicación
está fallando, revisamos la replicación, ya sea a través de repadmin, replmon, visor de
sucesos, etc. y nos encontramos con diferentes tipos de errores y advertencias, todos
relacionados a fallas en la replicación de la base de datos de Active Directory, o bien,
aparecen como consecuencia de fallas en la replicación. Bien, en base a la cantidad de
errores, (también podríamos tomar como parámetro la envergadura del ambiente, con algunos
pocos controladores de dominio distribuidos en algunos sites, como cientos de controladores
de dominios, distribuidos en decenas de sites) el proceso para encontrar la causa o causas
por la cual se están generando el o los problemas pueden ser demasiado complicado.

¿Por dónde empezar?

Pues bien, supongamos que tenemos varios sites, y nuestro problema de replicación está
afectando todo el ambiente, nuestra topología lógica es en estrella, básicamente todos los
sites replican contra uno central.
La clave aquí es simplificar el ambiente en el cual se encuentra el problema, si bien el mismo
afecta a todo el ambiente, centrémonos solamente en dos sitios, tomemos al sitio central, y
algún partner de replicación. En nuestro caso tomaremos al sitio central, en el cual radica un
controlador de dominio que maneja todos los roles FSMO, como también tomaremos a su
partner de replicación (un sitio remoto), sitio que cuenta con un solo controlador de dominio.
Pongamos los siguientes nombres, como ejemplo:

Nombre del dominio: ejemplo.lab

Nombre del sitio central: Central
Controlador de dominio en el sitio central: DC01 (con todos los roles FSMO)
Nombre del sitio remoto: Sucursal
Controlador de dominio en el sitio remoto: DC10
Subred utilizada 192.168.0.0/24

(Lo sé.. no me puse muy creativo con los nombres ?)

Una vez que tenemos definidos nuestros sitios, comenzaremos a aplicar el siguiente plan de
acción, de manera secuencial, para ir resolviendo los diferentes problemas que se nos
presentan, hasta poder lograr que el ambiente pueda converger y por ende poder llevar a
cabo la replicación de las particiones de Active Directory de manera exitosa.
1/10
Este plan va a estar compuesto por los siguientes pasos:
1. Topología
2. Resolución de nombres
3. Interfaz RPC
4. Seguridad

1. Topología
Aquí la herramienta de diagnóstico básica es repadmin.exe.
En el servidor de la sucursal, ejecutar:

c:\>repadmin.exe showreps

En el reporte podemos ver cuáles son los partners de replicación definidos para el server de
la Sucursal
Como la replicación es inbound (el server inicia la replicación y se trae los cambios del
partner) nos interesa sobre todo la sección del reporte que se llama INBOUND NEIGHBORS

En el caso de Sucursal, el reporte muestra:

==== INBOUND NEIGHBORS ======================================

DC=ejemplo,DC=lab
Central\DC01 via RPC
DC object GUID: de11d929-55f9-4dc6-b702-xxxxxxxxxxx
Last attempt @ 2010-03-03 01:21:50 failed, result -2146893022 (0x80090322):
Can't retrieve message string -2146893022 (0x80090322), error 1815.
200 consecutive failure(s).
Last success @ (never).

CN=Configuration,DC=ejemplo,DC=lab
Central\DC01 via RPC
DC object GUID: de11d929-55f9-4dc6-b702-xxxxxxxxxxx
Last attempt @ 2010-03-03 01:21:50 failed, result -2146893022 (0x80090322):
Can't retrieve message string -2146893022 (0x80090322), error 1815.
99 consecutive failure(s).
Last success @ 2009-11-25 06:23:05.

CN=Schema,CN=Configuration, DC=ejemplo,DC=lab
Central\DC01 via RPC
DC object GUID: de11d929-55f9-4dc6-b702-xxxxxxxxxxx
Last attempt @ 2010-03-03 01:21:50 failed, result -2146893022 (0x80090322):
Can't retrieve message string -2146893022 (0x80090322), error 1815.
99 consecutive failure(s).
Last success @ 2009-11-25 06:23:07.
2/10
DC=DomainDnsZones, DC=ejemplo,DC=lab
Central\DC01 via RPC
DC object GUID: de11d929-55f9-4dc6-b702-xxxxxxxxxxx
Last attempt @ 2010-03-03 01:21:50 failed, result 1256 (0x4e8):
Can't retrieve message string 1256 (0x4e8), error 1815.
99 consecutive failure(s).
Last success @ 2009-11-25 06:23:08.

DC=ForestDnsZones, DC=ejemplo,DC=lab
Central\DC01 via RPC
DC object GUID: de11d929-55f9-4dc6-b702-xxxxxxxxxxx
Last attempt @ 2010-03-03 01:21:50 failed, result 1256 (0x4e8):
Can't retrieve message string 1256 (0x4e8), error 1815.
99 consecutive failure(s).
Last success @ 2009-11-25 06:23:09.

Este reporte nos muestra el partner para cada uno de los contenedores del AD, y por los
general (a menos que tengamos alguna configuración particularmente macabra) el partner de
replicación maneja todos los contenedores.
En nuestro caso, tenemos el partner que es: Central\DC01.

El servidor es el que se encuentra en la central, que es consistente con nuestro modelo de

replicación en estrella.
Si en algún otro sitio remoto (otra “sucursal”) vemos que los inbound partner no es el servidor
de Central, entonces tendríamos que revisar la definición de ese site y sus enlaces en el “AD
Sites and Services” y forzar la regeneración de la topología.
En este caso podemos ver que la replicación inbound ha fallado desde el 25 de nov. del 2009
en ambos servidores.

Last success @ 2009-11-25 06:23:09.

La causa de la falla viene después:

failed, result 1256 (0x4e8):

El error 1256 se traduce como:

Error Code 1256
System error code 1256 means "The remote system is not available. For information about
network troubleshooting see Windows Help." This error code may also display as
"ERROR_HOST_DOWN" or as the value 0x4E8. System Error Codes: Code 1200 to Code
1299

2. Resolución de nombres

3/10
Tenemos que verificar que el servidor de la Sucursal puede resolver correctamente el nombre
y el GUID del partner de replicación.
Para ello podemos ejecutar, en el server de la Sucursal, el comando Nslookup
Del reporte de repadmin podemos ver los GUIDs de los servidores:
Central\DC01
DC object GUID: de11d929-55f9-4dc6-b702-xxxxxxxxxxx

En este caso, las pruebas serian:

c:\>Nslookup dc01.ejemplo.lab
c:\>Nslookup de11d929-55f9-4dc6-b702-xxxxxxxxxxx._msdcs.ejemplo.lab

El resultado del primer query debe ser la IP actual del server, el resultado del segundo query
debe ser el alias y la IP del server:

C:\> Nslookup de11d929-55f9-4dc6-b702-xxxxxxxxxxx._msdcs.ejemplo.lab

Server: DNSServer.ejemplo.lab
Address: 192.168.0.1
Name: dc01.ejemplo.lab
Address: 192.168.0.1
Aliases: de11d929-55f9-4dc6-b702-xxxxxxxxxxx._msdcs.ejemplo.lab

Si alguna de estas pruebas retorna la dirección incorrecta, entonces tenemos que verificar la
configuración del DNS primario en el server remoto y corregir el problema.
Posiblemente sea una buena práctica configurar el DNS primario del servidor remoto a dc01
mientras ponemos a funcionar la replicación.

Tengamos en cuenta que si cambias la configuración del DNS en el servidor remoto, lo

recomendable es reiniciar el server o, al menos, ejecutar los comandos:

c:\>Ipconfig /registerdns
c:\>Net stop netlogon
c:\>Net start netlogon

De esta forma estamos asegurando que el server se está registrando en el DNS.

3. Puertos RPC
Cuando estemos seguros que la resolución esta OK, podemos pasar a probar los puertos
RPC, la mejor herramienta para esto es RPCdump.exe

En el server remoto, ejecuta el comando

c:\>rpcdump /s <partner_dc> /v /i > endpoints.txt

luego

c:\>notepad endpoints.txt
4/10
En este caso, el comando seria:

c:\>rpcdump /s dc01.ejemplo.local /v /i > endpoints.txt

En el archivo endpoints.txt, buscamos el UUID e3514235-4b06-11d1-ab04-00c04fc2dcd2

El resultado debe ser igual a:

ProtSeq:ncacn_ip_tcp
Endpoint:1025
NetOpt:
Annotation:MS NT Directory DRS Interface
IsListening:YES
StringBinding:ncacn_ip_tcp:xx.xx.xx.xx[1025]
UUID:e3514235-4b06-11d1-ab04-00c04fc2dcd2
ComTimeOutValue:RPC_C_BINDING_DEFAULT_TIMEOUT
VersMajor 4 VersMinor 0

Si el valor de IsListening es YES, entonces los puertos 135 y 1025 están escuchando.
Si el valor de IsListening es NO, tienes un problema de puertos cerrados, bien sea por un FW
intermedio, o por el FW de alguno de los dos servidores.
Si el archivo no tiene ningún endpoint reportado, entonces el puerto que probablemente está
bloqueado es el 135.

4. Seguridad
Lo primero que hay que hacer es verificar los grupos que tienen derecho a contactar el
servidor por la red (User Rights: Access this computer from the network)
La mejor manera de ver estos derechos es ejecutando

C:\>Rsop.msc

Expandimos: Computer Configuration->Windows Settings->Security Settings->Local Policies-

>User Right Assignment

Doble click en el derecho llamado “Access this computer from the network” y verifica que,
como mínimo, los siguientes grupos tienen este derecho:

Everyone
Authenticated Users
Enterprise Domain Controllers

Si este derecho no está otorgado a estos grupos, tendríamos que verificar las políticas
aplicadas al dominio (Default Domain Policy) o a los controladores de dominio (Default
Domain Controller Policy).

Verifiquemos que los relojes este sincronizados entre el servidor de la agencia y el PDC del
dominio.
5/10
Si los relojes no están sincronizados y sabes cuál es el PDC, puedes usar el comando:

C:\>net time \\pdc /set /y

Si no recordamos el nombre del PDC, tenemos que averiguarlo ? y podemos hacerlo con la
herramienta “netdom”, entre otras, como sigue:

C:\>netdom query fsmo

Posterior a ellos, deberíamos verificar que el servicio KDC está funcionando

En la consola de “Active Directory Users and Computers” buscamos el objeto del controlador
de domino de la sucursal y verificamos, en la pestaña General, que el check de “Trust this
computer for delegation” está marcada.

Usando adsiedit.msc expandimos el contenedor “Domain”, expandimos el objeto del dominio

“DC=ejemplo, dc=lab”, expandimos la “OU=Domain Controllers”, y hacemos un click derecho
en el objeto del controlador de dominio “CN=dc10”, por ejemplo.
Seleccionar Properties y buscar userAccountControl. EL valor de este atributo debe ser
532480. Hacemos esta misma prueba tanto en la maquina remota como en la maquina del
sitio central. La idea aquí es verificar que el valor de este atributo del objeto dc10 sea 532480
en las dos copias del AD.

En el servidor de la agencia, instala el tool klist.exe y ejecuta los siguientes comandos:

C:\>net stop kdc

C:\>at system_time /interactive cmd.exe

(donde system_time debe ser la hora local más uno o dos minutos)

Cuando abramos el command prompt (Esta ventana NO se va a abrir si estas conectado vía
TS al servidor. Este paso tienes que hacerlo directo en la consola del server. A menos que
agreguemos el switch “/console” cuando ejecutas el comando mstsc), ejecuta los comandos

c:\>klist purge
c:\>ipconfig /flushdns
c:\>nbtstat -R

Los siguientes pasos son para el reset del secure channel entre los DCs. Este paso es el que
probablemente arregle el problema entre DC01 y DC10. Esto debemos hacerlo en el servidor
que está fallando en traerse la replicación, en este caso, en los servidores de la sucursal. El
servicio del KDC debe seguir detenido.

Ejecuta el comando

c:\>netdom resetpwd /server:PDCe /userd:ejemplo\Administrator /password:*

En este comando, el server PDCe es el partner de replicación (que tiene el KDC funcionando,
y que no necesariamente es el KDC del dominio)
6/10
En este caso, el procedimiento lo vas a realizar en dc10 y el comando es:

c:\>netdom resetpwd /server:dc01 /userd:ejemplo\Administrator /password:*

Una vez resincronizado el password y desde el server de la sucursal, accedemos al servidor

central con su FQDN para conseguir nuevos tickets Kerberos, por ejemplo:

c:\>net use \\dc01.ejemplo.lab\IPC$

inicia el servicio del KDC

c:\>net start kdc

Los pasos siguientes solo deben hacerse en el servidor DC01

Abrir AD Sites and Services, seleccionar el servidor dc01, y luego NTDS Settings.
Eliminar las conexiones inbound del controlador de dominio con problemas (DC10) y luego
ejecuta

c:\>repadmin /kcc

Para forzar la replicación con el servidor de la central, ejecutamos el comando:

c:\>repadmin /syncall /d /e dc10 “DC=ejemplo,DC=lab”

Verificar los SPN registrados. Podemos utilizar el siguiente artículo: KB 308111

En el servidor de la sucursal, ejecutamos el comando:

ldifde –s nombre-server-de-central -f spndump.txt -p base -l servicePrincipalName -d

“cn=dc01,ou=Domain Controllers,dc=ejemplo,dc=lab”

para exportar de la base de datos local los SPNs que están registrados del servidor central.
Si en el archivo spndump.txt falta alguno de los 4 SPN del tipo host/*
HOST/dc01
HOST/dc01.ejemplo.lab
HOST/dc01.ejemplo.lab/ejemplo.lab
HOST/dc01.ejemplo.lab/EJEMPLO

Ejecuta el comando:

C:\>setspn –a SPN-faltante nombre-server-de-sucursal, por ejemplo:

C:\>setspn –a HOST/dc01.ejemplo.lab dc10

Verificar que la fragmentación de la red no está dañando la autenticación de Kerberos.

Podemos utilizar el siguiente artículo: KB 244474
Desde el server de la sucursal, verifica que el comando:

Ping dc01.ejemplo.lab –f –l 1472.

Si el resultado del comando es el mensaje “Packet needs to be fragmented but DF set.”

7/10
Entonces es posible que exista un problema de fragmentación del trafico UDP en la red. Este
problema puede causar las fallas de Kerberos.
La opción aquí es configurar Kerberos para utilizar solo TCP, como se explica en el artículo de
la KB 244474.

Nota: De forma predeterminada, Windows Server 2008 y Windows Vista intentará TCP primero
para Kerberos.

Una vez aplicado el plan de acción, intentamos una replicación entre los dos sites designados,
obteniendo el siguiente resultado:

DC=ejemplo,DC=lab, Replication failed!

CN=Configuration,DC=ejemplo,DC=lab, replicada con éxito @ 2010-03-12 05:21:59.
CN=Schema,CN=Configuration,DC=ejemplo,DC=lab, replicada con éxito @ 2010-03-12
05:22:00
DC=DomainDnsZones,DC=ejemplo,DC=lab, replicada con éxito @ 2010-03-12 05:22:00
DC=ForestDnsZones,DC=ejemplo,DC=lab, replicada con éxito @ 2010-03-12 05:22:01.

En resumen, todas las particiones menos la partición de dominio replicaron esta mañana a las
5:20.

Lingering Objects
La partición de dominio falló en su intento de replicación ya que existen lingering objects.
Este, así como también problemas de objetos en estado de tombstone, son problemas que de
seguro encontraremos a lo largo del proceso de troubleshooting de la replicación de Active
Directory. Dichos problemas iremos solucionándolos a medida que avanzamos sobre el plan
aquí enunciado. Continuando con el problema de lingering objects, lo validamos y
solucionamos de la siguiente manera:

Cuando investigamos el log de Directory Services, encontramos errores de lingering objects

que están bloqueando la replicación de la partición de dominio.

El evento es el 1988:

“Active Directory Replication encountered the existence of objects in the following partition
that have been deleted from the local domain controllers (DCs) Active Directory database.
Not all direct or transitive replication partners replicated in the deletion before the tombstone
lifetime number of days passed. Objects that have been deleted and garbage collected from
an Active Directory partition but still exist in the writable partitions of other DCs in the same
domain, or read-only partitions of global catalog servers in other domains in the forest are
known as 'lingering objects'.

This event is being logged because the source DC contains a lingering object which does not
exist on the local DCs Active Directory database. This replication attempt has been
blocked.
8/10
The best solution to this problem is to identify and remove all lingering objects in the forest.
Source DC (Transport-specific network address): de11d929-55f9-4dc6-b702-
b63e380f6d91._msdcs.ejemplo.lab Object: CN=CD075003-Xerox WorkCentre
PE16ADEL:f2343d56-3bc3-44fb-8b3c-52ea1ecc038d,CN=Deleted
Objects,DC=ejemplo,DC=lab Object GUID: f2343d56-3bc3-44fb-8b3c-52ea1ecc038d

User Action: Remove Lingering Objects: The action plan to recover from this error can be
found at http://support.microsoft.com/id=314282

If both the source and destination DCs are Windows Server 2003 DCs, then install the support
tools included on the installation CD. To see which objects would be deleted without actually
performing the deletion run 'repadmin /removelingeringobjects <Source DC> <Destination DC
DSA GUID> <NC> /ADVISORY_MODE'. The event logs on the source DC will enumerate all
lingering objects. To remove lingering objects from a source domain controller run 'repadmin
/removelingeringobjects <Source DC> <Destination DC DSA GUID> <NC>'. If either source or
destination DC is a Windows 2000 Server DC, then more information on how to remove
lingering objects on the source DC can be found at http://support.microsoft.com/?id=314282 or
from your Microsoft support personnel. If you need Active Directory replication to function
immediately at all costs and don't have time to remove lingering objects, enable loose
replication consistency by unsetting the following registry key: Registry Key:
HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Strict Replication Consistency.
Replication errors between DCs sharing a common partition can prevent user and computer
accounts, trust relationships, their passwords, security groups, security group memberships
and other Active Directory configuration data to vary between DCs, affecting the ability to log
on, find objects of interest and perform other critical operations. These inconsistencies are
resolved once replication errors are resolved. DCs that fail to inbound replicate deleted objects
within tombstone lifetime number of days will remain inconsistent until lingering objects are
manually removed by an administrator from each local DC. Lingering objects may be
prevented by ensuring that all domain controllers in the forest are running Active Directory, are
connected by a spanning tree connection topology and perform inbound replication before
Tombstone Live number of days pass.”

Este error indica que el objeto CD075003-Xerox WorkCentre fue borrado en el servidor de la
Sucursal, pero todavía existe en el AD del dc01.

Lo que tenemos que hacer es lo siguiente:

En el servidor dc01 ejecuta el comando:

C:\repadmin /removelingeringobjects dc01.ejemplo.lab 19d40098-6fba-44ae-a8a8-

4dd35916b89c DC=ejemplo,DC=lab /ADVISORY_MODE

Este comando va a generar la lista de lingering objects (desde el punto de vista de dc10) que
existen en dc01

Si todo está bien, y conseguimos el objeto, entonces ejecutamos:

9/10
C:\repadmin /removelingeringobjects dc01.ejemplo.lab 19d40098-6fba-44ae-a8a8-
4dd35916b89c DC=ejemplo,DC=lab

Una vez realizado la remoción del objeto en estado de lingering, la replicación de todas las
particiones de Active Directory se realizaron de manera satisfactoria.

Una vez que tenemos la replicación funcionando entre los dos sites, el central y la sucursal,
deberíamos ir tomando las siguientes sucursales, e ir aplicando este plan de acción, repito que
es posible que nos encontremos con problemas adicionales, como ser algún servidor que se
encuentre en estado de tombstone (adjuntamos un artículo sobre cómo tratar este
inconveniente) o algún problema de conectividad, en tales casos deberemos proceder a
resolverlos y continuar con nuestro plan de acción.

Referencias
How Active Directory Replication Topology Works
How to remove data in Active Directory after an unsuccessful domain controller
demotion
Clean that Active Directory forest of lingering objects
Troubleshooting replication with repadmin
A Guide to Active Directory Replication

Esperamos que esta guía les sea de utilidad.

Saludos y hasta pronto!

10/10