Com solucionar errors de replicació a Active Directory amb repadmin

Quan l’ Active Directory comença a fallar en la replicació, ho notes. I no perquè t’ho digui un sistema d’alertes modern i ben afinat (tant de bó), sinó perquè comencen a passar coses rares: usuaris que no apareixen en tots els controladors de domini, errors intermitents en aplicar GPOs, logins que fallen segons a quin DC es connecti el client… i aquest tipus de problemes que tenen l’habilitat d’amagar-se just quan fas un diagnòstic ràpid.

En aquell moment, acabes obrint repadmin. I si el fas servir des de fa temps, saps que no és l’eina més amable del món. Però també saps que si hi ha alguna cosa trencada en la replicació, t’ho mostrarà. I millor encara: moltes vegades et dona el primer indici de per on començar.

Diagnòstic ràpid: què revisar primer

Quan algú et diu “la replicació no funciona”, cal concretar què significa això. Falla entre tots els DCs? Entre un parell? És puntual o permanent? Hi ha errors d’autenticació, connectivitat, DNS, horaris?

El primer pas sovint és:

repadmin /replsummary

Aquest comandament et dona una visió general. Et diu quins DCs estan rebent (o no) canvis i des de quin. Si veus errors de tipus RPC Server is unavailable, Access is denied, o simplement grans quantitats de “Fails”, ja tens un punt de partida.

Compte: el resum està bé per detectar patrons, però de vegades és enganyós. Hi ha casos en què replsummary marca tot com a “bé” mentre la base de dades d’AD no reflecteix els canvis esperats. Quan això passa, tiro  directament de:

repadmin /showrepl <DC-NAME> /verbose /all

Això dona més context: qui és el partner de replicació, quan va ser l’última replicació exitosa, quins errors es van produir, etc. L’important aquí és identificar si l’error és simètric o no: de vegades un DC pot replicar des d’un altre però no a l’inrevés, i això ja t’orienta força.

Errors típics i perquè passen

1. Problemes de xarxa o DNS mal resolt

Sona bàsic, però continua sent una de les causes principals. Un DC que no pot resoldre el nom de l’altre correctament, o que té connectivitat degradada, fallarà sí o sí. Moltes vegades veig configuracions de xarxa amb adaptadors virtuals, rutes mal posades, o servidors DNS que no són per al domini.

Sempre faig una comprovació directa de resolució i connectivitat entre DCs:

nslookup <DC-NAME>
ping <DC-NAME>

I si tinc dubtes, tiro de nltest /dsgetdc:<domain> per veure què DC està sent localitzat per cada màquina. M’ha passat trobar controladors que es resolen amb IPs antigues per culpa de registres estàtics en arxius hosts (sí, encara passa).

2. Autenticació trencada: contrasenyes de màquina desincronitzades

Un clàssic quan un DC porta desconnectat molt de temps. Si en reconnectar-lo veus errors de tipus Access Denied, no sempre és un problema de permisos. De vegades és que la contrasenya del compte d’equip del DC ja no és vàlida en el domini.

Quan passa això, el més ràpid sol ser despromoure i tornar a promoure… però abans d’arribar aquí, pots intentar forçar una resincronització de contrasenyes d’equip, tot i que rara vegada resol del tot el problema. En aquests casos, toca avaluar si aquest DC està prou actualitzat com per intentar recuperar-lo sense despromoció.

3. Problemes amb el servei NTDS o base de dades corrupta

Si l’error esmenta alguna cosa com 8451 (The replication operation encountered a database error), normalment és mal senyal. Pots intentar un ntdsutil per verificar la integritat de la base de dades, però si hi ha corrupció real, probablement ja ho estàs notant també en altres símptomes: serveis que no arrenquen, esdeveniments constants en el visor, etc.

En aquests casos, cal tenir clar quin rol compleix aquest DC. Si no té FSMO rols i no és l’únic global en un lloc remot, normalment és millor treure’l de la rotació i planejar la seva reinstal·lació. Recuperar un DC malmès és possible, però no sempre és el més pràctic.

Quan tens un DCs zombi: què fer amb ell

Passa més del que volem: un DC que porta mesos sense replicar, ningú l’ ha tocat, i ara que ho necessites per a alguna cosa, veus que està en pla autista i no s’assabenta de res.

La meva rutina:

1. Comprovo si encara té connectivitat funcional.
2. Faig servir repadmin /replsummary per veure si realment no rep canvis de ningú.
3. Verifico amb repadmin /showrepl si els errors són sempre els mateixos i des de quan.
4. Reviso els rols FSMO: si no en té cap, més marge per actuar.

Si haig de treure’l, utilitzo ntdsutil per fer el “metadata cleanup” i després netejo els objectes NTDS Settings a Sites and Services.

Un error comú aquí és deixar les restes del DC a l’AD. Això de vegades genera problemes amb replicacions futures (quan intentes promoure un nou DC amb el mateix nom, per exemple). Per això sempre faig neteja manual d’objectes orfes en AD Sites and Services, Users and Computers, i de vegades fins i tot en DNS.

Repadmin per forçar i verificar

Quan sé que la xarxa està bé, l’hora està sincronitzada, i els noms es resolen correctament, o sigui, que tot està bé però la replicació no es reactiva sola, pots fer servir:

repadmin /syncall /AeD

El paràmetre A aplica a tots els partners, i estén a totes les NCs, i D obliga a mostrar errors.

És una comanda “intensa”, i no hauries de llençar-la sense entendre el que fa, però quan saps que la replicació hauria d’estar funcionant i simplement no s’està activant per si sola, això ajuda a donar-li l’empenta que necessita.

Després d’això, sempre verifico amb:

repadmin /showrepl *

I reviso el visor d’esdeveniments. És curiós quantes vegades els errors més clars són aquí, i no tant en l’output de repadmin.

El rellotge: un sospitós habitual

Sembla un detall menor, però un desfasament de rellotge de més de 5 minuts entre controladors fa que Kerberos falli. I si això passa, la replicació cau sense dir clarament per què.

El meu consell: assegura’t que tots els DCs sincronitzen contra el mateix origen confiable. En entorns virtualitzats, és fàcil que un host forci el temps sobre la VM i que això entri en conflicte amb la política de temps d’AD.

w32tm /query /status et diu contra què està sincronitzant cada DC. Si n’hi ha algun que no segueix l’esquema habitual de PDC ➝ NTP extern, i els altres ➝ PDC, és un lloc on mirar.

Quan res sembla arreglar-ho

Hi ha situacions on repadmin no et diu res de nou. L’error persisteix, els comandaments no el resolen, i ja comences a pensar en solucions destructives. Aquí algunes idees que m’han funcionat per sortir de l’embús:

1. Fes servir dcdiag amb filtres: no tots els tests són rellevants, però els de replicació (/test:replications) i DNS (/test:dns) solen donar-te pistes.
2. Comprova NTDS Settings a Sites and Services. De vegades hi ha enllaços manuals mal fets, o partners que no existeixen ja.
3. Elimina els objectes Connection innecessaris. Si has fet troubleshooting abans i has forçat enllaços de replicació manuals, assegura’t de no deixar artefactes.
4. Si promous un nou DC i no replica bé des de l’inici, revisa que no s’estigui bloquejant la replicació per polítiques (SYSVOL no replicat, etc.)

Conclusió operativa

repadmin no és l’eina més moderna, ni la més intuïtiva, però continua sent la referència per saber si un entorn AD està replicant bé. Amb el temps, un desenvolupa cert instint per interpretar els seus missatges, però continua sent fàcil passar per alt els detalls que marquen la diferència.