Windows Server 2025 / Cómo verificar la replicación de AD y los propietarios de roles FSMO

Para comprobar los Servicios de dominio de Active Directory (AD DS), examine la replicación con Repadmin y consulte por separado los propietarios de los cinco roles FSMO (Flexible Single Master Operations, operaciones de maestro único flexible). La replicación distribuye cambios del directorio; los roles reservan determinadas operaciones a un controlador. Añadir DC2 o apagar DC1 no transfiere automáticamente esos roles.

Delimitar el problema de replicación

En el laboratorio, DC1 y DC2 ya deben estar promovidos en ad.example.test y utilizar DNS interno operativo. Replican las particiones de dominio, configuración y esquema, además de las particiones de aplicación DNS que correspondan a su ámbito. No todas las particiones tienen necesariamente los mismos participantes o tiempos de propagación. Los archivos de FS1 y los arrendamientos DHCP no se replican por instalar un controlador de dominio.

Si un objeto parece distinto, anote el controlador consultado, el atributo, el valor y la hora del cambio antes de concluir que existe un fallo. Puede repetir la comprobación reversible de descripción de la incorporación de DC2 seleccionando explícitamente cada controlador y restaurando el valor original. Compare esa observación con el diagnóstico de errores de replicación de Microsoft; una única consulta reciente no distingue por sí sola una propagación pendiente de una avería persistente.

Consultar replicación sin modificarla

Abra Windows PowerShell como administrador en DC1 o DC2 con una cuenta autorizada para consultar el directorio. Desde un equipo de administración, necesita las herramientas de administración remota del servidor (RSAT) de AD DS, incluido Repadmin y el módulo ActiveDirectory, acceso al dominio y DNS correcto. Ejecute las siguientes consultas de lectura; no fuerce sincronizaciones ni modifique conexiones de replicación como primer paso.

repadmin /replsummary
repadmin /showrepl DC1
repadmin /showrepl DC2
Get-ADReplicationFailure -Target 'ad.example.test' -Scope Domain

En repadmin /replsummary revise fallos frente a intentos y el mayor intervalo desde una replicación correcta; no interprete un cero sin comprobar la antigüedad y el contexto de los datos. En /showrepl DC1 y /showrepl DC2 revise cada partición, origen, último intento, último éxito y error: cada salida describe la replicación entrante de su destino. Ambas permiten examinar las dos direcciones del laboratorio. Get-ADReplicationFailure enumera fallos asociados a los controladores del dominio indicado; que no devuelva objetos sin errores de consulta no demuestra por sí solo que todos los datos ya coincidan.

Si DC2 estaba apagado por mantenimiento, registre ese hecho y compruebe de nuevo la replicación después de ponerlo en servicio; no dé por resuelto un error solo porque el servidor arranque. Para un fallo persistente, correlacione el código y la hora con DNS del socio, conectividad de llamada a procedimiento remoto (RPC), hora, autenticación, servicios y eventos de Directory Service. No desactive el cortafuegos ni conecte sin planificación un controlador que ha permanecido aislado durante mucho tiempo: su recuperación debe considerar la antigüedad y consistencia del directorio.

Entender los cinco roles FSMO

Hay dos roles por bosque y tres por dominio. Un mismo controlador puede ser propietario de varios, sin convertirse por ello en el único servidor que permite iniciar sesión. La descripción oficial de los roles FSMO explica su alcance:

La indisponibilidad del propietario no detiene todas las funciones a la vez. Por ejemplo, un controlador puede seguir creando cuentas mientras disponga de su bloque RID, pero necesitará al maestro RID para obtener otro; los cambios de esquema requieren al maestro de esquema. Que algunos usuarios sigan iniciando sesión no demuestra que los roles estén disponibles ni elimina la necesidad de recuperar el servicio.

Consultar y comparar los propietarios reales

La consulta de propiedad requiere las mismas herramientas y un contexto de dominio correcto. Netdom query utiliza el dominio del equipo si no se indica otro; Get-ADForest y Get-ADDomain permiten especificar el servidor consultado. No confunda estos comandos de lectura con una transferencia.

netdom query fsmo
Get-ADForest | Select-Object SchemaMaster,DomainNamingMaster
Get-ADDomain | Select-Object PDCEmulator,RIDMaster,InfrastructureMaster

Ejecute estas tres consultas desde el contexto del dominio del laboratorio, no desde otro dominio por accidente. netdom query fsmo muestra los cinco propietarios; Get-ADForest selecciona los dos del bosque y Get-ADDomain los tres del dominio. En un bosque nuevo creado originalmente en DC1, este suele conservarlos todos mientras no se hayan reasignado. Anote los nombres realmente obtenidos; la promoción de DC2 no reparte los roles automáticamente. Si necesita comparar las vistas de DC1 y DC2, repita las consultas de Get-ADForest y Get-ADDomain añadiendo -Server DC1 y luego -Server DC2 antes de la canalización. En Netdom utilice /domain:ad.example.test y /server:DC1, y repita con /server:DC2 antes de fsmo. Registre también la hora y los errores. Una discrepancia exige revisar la replicación y el contexto; una lista de propietarios no certifica que esos servidores estén accesibles ni autoriza a asumir sus roles por la fuerza.

Distinguir transferencia y asunción forzada

Una transferencia normal es la opción para mantenimiento planificado cuando el propietario actual funciona y puede comunicarse con el destino. La asunción forzada (seizure) corresponde a una decisión de recuperación cuando no es posible transferir y el antiguo propietario no debe volver sin un procedimiento de recuperación. Consulte el proceso de transferencia y asunción de FSMO y los requisitos de administración de cada rol antes de efectuar cambios.

• Antes de transferir, confirme el rol, su alcance, el propietario y el destino correctos, la salud de ambos controladores, la replicación y las copias de seguridad. Los permisos de consulta no equivalen a los de transferencia: los roles de dominio requieren Domain Admins; el de nombres de dominio, Enterprise Admins; para el esquema, revise los requisitos de Schema Admins y Enterprise Admins de la guía oficial.
• Después de transferir, vuelva a consultar la propiedad desde los controladores implicados, confirme la replicación de la partición correspondiente y compruebe las funciones dependientes. Un cambio en la lista no equivale por sí solo a disponibilidad operativa.
• Si cambia el emulador PDC del dominio raíz del bosque, revise qué servidor debe usar la fuente horaria externa autorizada y cómo continúa la jerarquía de tiempo; no copie una configuración de hora independiente a todos los controladores.
• Una asunción forzada exige planificar el tratamiento del propietario anterior y la limpieza de metadatos. El maestro RID tiene precauciones adicionales para evitar identificadores duplicados. No vuelva a conectar la antigua máquina ni restaure su copia sin seguir el procedimiento de recuperación aplicable.

El resultado esperado de este ejercicio es un registro del estado de replicación por controlador y partición, junto con los cinco propietarios reales y sus ámbitos. Si hay errores, conserve sus códigos y contexto para investigar antes de cambiar roles. Las consultas no alteran la configuración y no requieren deshacer cambios; no es necesario apagar controladores, forzar replicación ni ejecutar una asunción para completar esta práctica.