Cómo eliminar controladores de dominio fallidos en Active Directory

MundoWin » General » Cómo eliminar controladores de dominio fallidos en Active Directory

Perder un controlador de dominio sin poder degradarlo con normalidad es una de esas situaciones que tarde o temprano acaban apareciendo en cualquier infraestructura con Active Directory: una máquina virtual que alguien borra a lo bruto, un servidor físico que muere sin copia válida, un DCPROMO que falla a medias… y en el Directorio quedan restos que siguen creyendo que ese DC está vivo.

Cuando esto ocurre, el bosque y el dominio pueden quedar llenos de metadatos huérfanos, conexiones de replicación rotas, objetos NTDS colgando, roles FSMO en el limbo y registros DNS que ya no apuntan a ningún sitio. Todo esto se traduce en errores de replicación, alertas constantes y, en el peor de los casos, en un Active Directory incoherente que puede dar muchos dolores de cabeza si no se limpia correctamente.

Por eso el proceso estándar tras una eliminación forzada o un fallo catastrófico es realizar una limpieza de metadatos (metadata cleanup) y, si procede, reasignar los roles FSMO y revisar DNS y objetos de equipo. El procedimiento no es complicado, pero hay que ser muy meticuloso para no cargarse el DC que sí está vivo.

Qué es un controlador de dominio fallido y por qué hay que eliminarlo bien

Hablamos de controlador de dominio fallido cuando el servidor ya no puede degradarse con el asistente de Servicios de dominio de Active Directory (AD DS), normalmente porque ha desaparecido (borrado de la VM, fallo de hardware, desastre sin backup…) o porque el intento de dcpromo se quedó a medias y el equipo no arranca o no replica.

En estos escenarios el resto de DC siguen teniendo referencias a ese servidor: su objeto de equipo en la OU “Controladores de dominio”, su objeto de servidor y NTDS Settings en “Sitios y servicios de Active Directory”, sus conexiones de replicación FRS/DFS, sus registros DNS, e incluso uno o varios roles FSMO asignados.

Si no se eliminan correctamente todos esos rastros, nos podemos encontrar con errores como controladores “fantasma” en la consola, replicación bloqueada, mensajes indicando que un DC con rol maestro no responde o advertencias de que el último servidor DNS para una zona ha dejado de estar disponible.

Por eso el proceso estándar tras una eliminación forzada o un fallo catastrófico es realizar una limpieza de metadatos (metadata cleanup) y, si procede, reasignar los roles FSMO y revisar DNS y objetos de equipo. El procedimiento no es complicado, pero hay que ser muy meticuloso para no cargarse el DC que sí está vivo.

Flujo de trabajo general para quitar AD DS o un DC que ya no existe

Cuando hablamos de “eliminar un controlador de dominio” hay dos grandes escenarios: la degradación controlada (el DC está operativo y lo bajamos de nivel) y la limpieza tras una caída o eliminación incorrecta (el DC ya no responde).

En una degradación normal de un DC adicional usaremos el Administrador del servidor o PowerShell para ejecutar la degradación (Uninstall-ADDSDomainController) y, después, quitar el rol AD DS con Uninstall-WindowsFeature/Remove-WindowsFeature si queremos eliminar también los binarios y herramientas de gestión.

En un escenario de controlador fallido o desaparecido el flujo cambia: no podemos entrar al DC, así que debemos trabajar desde otro controlador funcional del mismo dominio. Primero revisamos y, si hace falta, asumimos o movemos los roles FSMO a un DC sano. Después limpiamos los metadatos por GUI (RSAT) o con ntdsutil, y finalmente revisamos DNS y eliminamos cualquier objeto de equipo o servidor que quede.

Microsoft describe este flujo en varias fases claras: comprobación de roles, degradación (cuando es posible), opciones de eliminación, configuración de credenciales y contraseñas locales, confirmación de la operación, proceso de degradación y reinicio, y por último revisión de resultados y registros.

Degradar correctamente un controlador de dominio con Administrador del servidor

Si el controlador de dominio todavía está en línea y responde, lo más limpio es degradarlo usando el Administrador del servidor en Windows Server 2012/2016 o superior, en lugar de ir directamente a limpiar metadatos.

Desde el DC que queremos bajar de nivel abrimos el Administrador del servidor y usamos una de estas dos rutas para iniciar la eliminación del rol de AD DS:

• Administrar > Quitar roles y características en el panel principal.
• Botón derecho sobre “Active Directory Domain Services” en la sección de Roles y características (vista de “AD DS” o “Todos los servidores”) y opción “Quitar roles o características”, que se salta la página de selección de servidor.

Al desmarcar “Servicios de dominio de Active Directory” en el asistente, si el servidor es un controlador de dominio, no se desinstalan directamente los binarios, sino que aparece un cuadro de “Resultados de validación” que nos ofrece degradar el DC. Es ahí donde arranca realmente el proceso de despromoción.

Conviene no quitar otros roles y características relacionadas (DNS, GPMC, RSAT…) si existe la posibilidad de volver a promocionar más adelante ese mismo servidor como DC. Si la degradación es definitiva, podemos aprovechar para dejar solo lo imprescindible, desmarcando lo que no vayamos a necesitar.

En este asistente de degradación encontraremos las mismas secciones clave que veremos luego equivalentes en PowerShell: credenciales, advertencias, opciones de eliminación (DNS, particiones de aplicación, delegaciones), nueva contraseña de administrador local, confirmación y ejecución.

Degradar y eliminar roles mediante PowerShell (Uninstall-ADDSDomainController)

Para automatizar o tener más control fino sobre la degradación, el módulo ADDSDeployment de PowerShell ofrece el cmdlet Uninstall-ADDSDomainController, que se encarga de bajar de nivel al DC y, si queremos, dejarlo como miembro del dominio o en grupo de trabajo, un proceso que puede complementarse con guías de gestión de usuarios desde PowerShell.

Este cmdlet acepta una serie de parámetros que reproducen las opciones del asistente gráfico:

• -Credential: credenciales con permisos suficientes (Administrador de dominio o de empresa). Solo es obligatorio si no estamos conectados ya con una cuenta adecuada.
• -DemoteOperationMasterRole: permite asumir roles FSMO que aloja el DC durante la degradación.
• -ForceRemoval: degradación forzada, sin tocar metadatos en el resto del Directorio (requiere limpieza posterior).
• -LastDomainControllerInDomain: indica que es el último DC del dominio; al usarlo, el dominio (e incluso el bosque, si es el único) se elimina.
• -RemoveApplicationPartitions y -RemoveDNSDelegation: controlan la eliminación de particiones de aplicación y delegaciones DNS asociadas.
• -IgnoreLastDNSServerForZone: fuerza la operación aunque sea el último servidor DNS de alguna zona.
• -LocalAdministratorPassword: establece la contraseña de la cuenta Administrador local cuando el equipo deje de ser DC.
• -SkipPreChecks, -Force, -Confirm, -WhatIf, -NoRebootOnCompletion: parámetros de control típicos de PowerShell para validación previa, forzado, confirmación y reinicio.

En paralelo, para eliminar el rol AD DS y sus herramientas después de la degradación, se utilizan los cmdlets Uninstall-WindowsFeature o Remove-WindowsFeature, con parámetros como -Name, -IncludeManagementTools, -Restart o -Remove para limpiar también los binarios.

Un detalle importante de seguridad es el parámetro -LocalAdministratorPassword. Si lo dejamos sin especificar, el propio cmdlet nos pedirá la contraseña de forma enmascarada, lo más recomendable en uso interactivo. Si lo pasamos como valor, debe ser una cadena segura (SecureString), generada con, por ejemplo, Read-Host -AsSecureString. No es buena idea usar ConvertTo-SecureString "Password1" -AsPlainText -Force salvo en laboratorios, porque la clave queda expuesta.

Durante la ejecución real, la fase de “Confirmación” en el asistente gráfico o el uso de Enter en PowerShell marca el punto de no retorno: el proceso se vuelve irreversible y el servidor se reinicia al terminar, salvo que hayamos usado opciones específicas para suprimir el reinicio automático.

Despromocionar un controlador de dominio adicional paso a paso

Cuando se trata de un controlador de dominio secundario o adicional (no el último del dominio), la operación es bastante segura siempre que el resto de DC estén en buen estado y la replicación funcione correctamente.

Desde el propio DC adicional abrimos el Administrador del servidor, vamos a “Administrar > Quitar roles y características” y seleccionamos el servidor que queremos modificar. En la página de roles, desmarcamos “Servicios de dominio de Active Directory”, y al aparecer el mensaje de que hay que disminuir el nivel del controlador de dominio, pulsamos en “Disminuir el nivel de este controlador de dominio”.

El asistente de degradación nos pedirá credenciales de un administrador de dominio. En DC adicionales no veremos la casilla “Último controlador de dominio en el dominio”, ya que no estamos eliminando el dominio entero, solo un DC. Es fundamental validar que seleccionamos la cuenta adecuada, ya que será la responsable de los cambios en AD.

Durante el asistente veremos varias pantallas críticas:

• Advertencias: hay que marcar “Continuar con la eliminación” tras revisar las posibles consecuencias (pérdida de catálogo global, afectación a servicios dependientes, etc.).
• Opciones de eliminación: aquí decidimos si queremos quitar la delegación DNS, marcar “Ignorar último servidor DNS para zona” si aplica y, cuando corresponda, eliminar particiones de aplicación usadas por DNS.
• Nueva contraseña de administrador: establecerá la contraseña de la cuenta Administrador local una vez que el servidor deje de ser DC.

Al pulsar “Disminuir nivel” se inicia el proceso de despromoción. El servidor eliminará la base de datos de AD DS, actualizará la pertenencia al dominio (como equipo miembro, si así lo hemos configurado) y se reiniciará al finalizar. A nivel de Directorio, su objeto de DC pasará a ser un equipo normal dentro del dominio.

Si queremos además quitar todos los componentes de AD DS y DNS de ese servidor, después del reinicio volvemos a “Quitar roles y características” y desmarcamos tanto “Servicios de dominio de Active Directory” como “Servidor DNS”, aceptando las características asociadas que se proponga eliminar. Marcamos la opción de reinicio automático si es necesario y dejamos que el asistente limpie los binarios.

Gestión y transferencia de roles FSMO antes de eliminar un DC

Antes de tocar un controlador de dominio que haya dejado de funcionar es imprescindible comprobar dónde residen los roles FSMO (PDC Emulator, RID Master, Infrastructure Master, Schema Master y Domain Naming Master). Si el DC caído tiene alguno de estos roles, tendremos que transferirlos o “seizarlos” a un DC vivo.

Podemos usar PowerShell para revisar rápidamente los roles:

• Roles de bosque (Esquema y Nombres de dominio): Get-ADForest | Select SchemaMaster, DomainNamingMaster
• Roles de dominio (PDC Emulator, RIDMaster, InfrastructureMaster): Get-ADDomain | Select PDCEmulator, RIDMaster, InfrastructureMaster

Si el DC que tiene los roles sigue vivo, podemos hacer una transferencia ordenada con PowerShell desde un controlador con privilegios de Administrador de empresa, usando:

Ejemplo PowerShell: Move-ADDirectoryServerOperationMasterRole -Identity "SERVIDORDESTINO" -OperationMasterRole 0,1,2,3,4

Los valores numéricos simplifican el comando (0=PDCEmulator, 1=RIDMaster, 2=InfrastructureMaster, 3=SchemaMaster, 4=DomainNamingMaster). También podríamos indicar los nombres de los roles separados por comas si solo queremos mover algunos de ellos.

Cuando el controlador que aloja los FSMO ya no existe o es irrecuperable, hablamos de “seizure” de roles. En ese caso, podemos recurrir a ntdsutil para forzar la asunción de cada rol desde un DC sano, sabiendo que una vez hecho esto el DC antiguo no debe volver nunca a la red.

Uso de NTDSUTIL para transferencia y “seizure” de roles

NTDSUTIL es la herramienta clásica de línea de comandos para tareas avanzadas sobre el Directorio: gestión de roles FSMO, copias instantáneas, limpieza de metadatos, etc. No tiene interfaz gráfica; funciona como intérprete de comandos.

Para trabajar con roles abrimos una consola (CMD o PowerShell) como administrador en un controlador vivo y ejecutamos:

Inicio NTDSUTIL: ntdsutil
roles

Dentro del menú de roles primero establecemos conexión con el DC de trabajo (el que va a recibir los roles):

Conexión a servidor: connections
connect to server SERVIDORVIVO
quit

A continuación seleccionamos el destino con “select operation target”, indicando sitio, dominio y servidor usando los comandos de listado:

• list sites y luego select site <número>
• list domains y luego select domain <número>
• list servers for domain in site y luego select server <número>

Después de seleccionar el servidor adecuado volvemos al menú de roles con “quit” y ya podemos ejecutar las operaciones sobre FSMO. Si el servidor origen aún está disponible, usaríamos los comandos de transferencia normal:

Transferencia FSMO (comandos): transfer schema master
transfer naming master
transfer PDC
transfer RID master
transfer infrastructure master

Si el DC que tenía los roles ya ha desaparecido, debemos forzar la asunción de estos roles desde el servidor vivo mediante “seize”:

Seize (forzado): seize schema master
seize naming master
seize PDC
seize RID master
seize infrastructure master

Es esencial asegurarse de que el DC antiguo no regresará jamás a la red, porque si lo hace con una copia obsoleta de la base de datos podría provocar conflictos graves en el Directorio. Por eso esta operación se reserva para casos donde el servidor está definitivamente muerto o destruido.

Limpieza de metadatos de controladores de dominio que ya no existen

Una vez que los roles FSMO están a salvo en un DC vivo, llega el momento de quitar del Directorio toda referencia al controlador que ha desaparecido. Esta parte se conoce como “limpieza de metadatos” (metadata cleanup).

La meticulosa limpieza evita que AD DS, FRS o DFS sigan intentando replicar con un servidor inexistente o mantengan conexiones de replicación huérfanas. También ayuda a que las consolas de administración reflejen fielmente la topología real.

Podemos realizar esta limpieza de tres formas principales:

• Desde Usuarios y equipos de Active Directory (Dsa.msc), eliminando el objeto de equipo del DC en la OU “Controladores de dominio”.
• Desde Sitios y servicios de Active Directory (Dssite.msc), eliminando primero el objeto de configuración NTDS del servidor y luego, si procede, el propio objeto de servidor.
• Con la utilidad ntdsutil, usando el contexto metadata cleanup para borrar el servidor y sus metadatos de forma controlada.

A partir de Windows Server 2008 y con RSAT actualizada, borrar el DC desde Dsa.msc o Dssite.msc ya activa automáticamente la limpieza de metadatos en la mayoría de los casos, incluso si el controlador que se quita ejecutaba versiones anteriores del sistema operativo.

Si trabajamos en entornos mixtos antiguos o queremos control total desde consola, ntdsutil sigue siendo la herramienta de referencia, especialmente cuando necesitamos especificar con detalle el servidor a eliminar o cuando GUI no ofrece toda la información que buscamos.

Limpieza de metadatos con Usuarios y equipos / Sitios y servicios

Si disponemos al menos de un DC con Windows Server 2008/2008 R2 o superior, el proceso “moderno” es bastante directo. Partimos de la premisa de que el DC que vamos a borrar ya no volverá.

Primero abrimos Usuarios y equipos de Active Directory (Dsa.msc), nos conectamos, si hace falta, a un DC que sea replicador del que queremos eliminar (menú “Cambiar controlador de dominio”) y expandimos el dominio hasta la OU “Controladores de dominio”.

Localizamos el objeto de equipo del DC que ya no existe, hacemos clic derecho sobre él y seleccionamos “Eliminar”. Aparecerá un cuadro de diálogo de AD DS mostrando el nombre del controlador que estamos eliminando y solicitando confirmación.

El siguiente cuadro pregunta explícitamente si el DC está permanentemente sin conexión y no puede disminuirse de nivel con DCPROMO. Marcamos esa opción y confirmamos. Si era catálogo global, el sistema pedirá una confirmación adicional; si albergaba uno o más roles FSMO, informará de que dichos roles serán movidos a un controlador concreto.

Después pasamos a Sitios y servicios de Active Directory (Dssite.msc). Nos conectamos al DC apropiado si es necesario, expandimos el sitio correspondiente, luego “Servidores”, y localizamos el servidor que representaba al DC retirado.

Dentro del servidor, hacemos clic derecho sobre el objeto “NTDS Settings” y lo eliminamos. De nuevo, aparecerá un cuadro advirtiendo de que vamos a quitar un controlador permanentemente fuera de línea, con confirmaciones similares a las anteriores. Tras hacerlo, el objeto de configuración NTDS y sus conexiones quedan eliminados.

Si, una vez eliminado NTDS Settings, el objeto servidor no tiene objetos secundarios, podemos borrar también el objeto de servidor. Si hubiera otros elementos colgando, significaría que otra aplicación lo utiliza, en cuyo caso conviene investigar antes de borrarlo.

Limpieza de metadatos con NTDSUTIL (metadata cleanup)

Cuando queremos intervenir de forma más quirúrgica o trabajamos desde línea de comandos, usamos ntdsutil para limpiar metadatos. El procedimiento estándar requiere conectarse a un DC vivo (habitualmente un replicador directo del DC desaparecido).

Los pasos básicos son los siguientes (siempre ejecutando la consola como administrador y con una cuenta miembro de “Administradores de dominio”, como mínimo):

1. Iniciar ntdsutil:
   ntdsutil
2. Entrar en el contexto de limpieza de metadatos:
   metadata cleanup
3. Configurar las conexiones de servidor:
   connections
connect to server SERVIDORVIVO
quit
   Aquí SERVIDORVIVO es el DC funcional desde el que vamos a ejecutar la limpieza.
4. Usar selección de objetivo de operación para identificar el DC muerto:
   select operation target
   Después listamos dominios, sitios y servidores:

Selección de objetivo: list domains
select domain <númeroDominio>
list sites
select site <númeroSitio>
list servers in site
select server <númeroServidorMuerto>
quit

Es crítico comprobar que el número de servidor que seleccionamos corresponde realmente al DC caído y no al que está en producción. Más vale revisar dos veces que borrar un DC sano por error.

Con el servidor muerto seleccionado volvemos al contexto de metadata cleanup y ejecutamos el borrado:

Eliminar servidor seleccionado: remove selected server

El sistema mostrará un mensaje de advertencia con el nombre LDAP del servidor (CN=NombreServidor, CN=Servers, CN=Sitio…) y pedirá confirmación. Si todo es correcto, aceptamos. Ntdsutil eliminará el objeto de servidor, sus configuraciones de replicación y los metadatos asociados.

Para un borrado directo sin el paso de “select operation target” también podemos usar una sintaxis más corta:
remove selected server <NombreServidor>, tras haber configurado correctamente las conexiones; pero suele ser más seguro ver el listado completo y seleccionar por número.

Al finalizar, salimos de los contextos escribiendo “quit” hasta volver al símbolo de sistema. Es buena costumbre abrir luego Usuarios y equipos y Sitios y servicios para verificar que el DC ya no aparece ni como objeto de equipo ni como servidor con NTDS Settings.

Revisión y limpieza de registros DNS asociados al controlador

Aunque la limpieza de metadatos elimina buena parte de las referencias al controlador, suele quedar trabajo pendiente en DNS, especialmente si el DC actuaba como servidor DNS para el dominio.

Desde la consola DNS del DC vivo expandimos la zona del dominio al que pertenecía el controlador retirado y revisamos los registros relacionados. En particular, conviene mirar la zona _msdcs del bosque, donde se almacenan CNAME asociadas a los GUID de los controladores.

Se recomienda eliminar el registro CNAME del DC eliminado en _msdcs, así como los registros A (HOST) y cualquier otro registro SRV o registro de servicio que haga referencia a su FQDN. Si tenemos zonas de búsqueda inversa, también debemos borrar su registro PTR correspondiente.

De esta forma evitamos que clientes o servicios intenten todavía resolver el nombre del DC antiguo y se encuentren con un host inexistente, lo que podría provocar retrasos en autenticación, errores en servicios LDAP o fallos en localización de controladores.

En infraestructuras con múltiples controladores y sitios, es útil combinar la limpieza DNS con una revisión de la topología de replicación en “Sitios y servicios” para garantizar que no queden conexiones de replicación que apunten a elementos borrados.

Credenciales, advertencias y opciones avanzadas durante la degradación

Tanto en el asistente gráfico como en los cmdlets de PowerShell, la elección correcta de credenciales y opciones es clave para una degradación limpia y sin sustos.

La página de “Credenciales” en el asistente de degradación nos exige una cuenta con permisos adecuados. Para un DC adicional bastará con un administrador de dominio; si es el último DC de un dominio, necesitamos pertenecer a “Administradores de empresa”, ya que se va a borrar todo el dominio (y, si es el último del bosque, todo el bosque).

En esa misma página suele aparecer la opción de “Forzar la eliminación de este controlador de dominio”. Al marcarla, degradamos el DC sin limpiar automáticamente sus metadatos en el Directorio, lo que nos obliga posteriormente a hacer la limpieza con ntdsutil o RSAT. Es una salida de emergencia que conviene usar solo cuando la degradación normal no es posible.

La página de “Advertencias” lista las posibles consecuencias de quitar el DC: pérdida de catálogo global, eliminación de servicios dependientes, necesidad de mover FSMO, etc. En caso de forzar la eliminación, muestra además qué roles FSMO se van a ver afectados, de manera que podamos asumirlos en otro DC en cuanto termine la operación.

Las “Opciones de eliminación” aparecen si hemos marcado “Último controlador de dominio en el dominio”. Desde ahí podemos activar “Ignorar último servidor DNS para zona”, “Quitar particiones de aplicación” y “Quitar delegación DNS”, además de proporcionar credenciales administrativas DNS alternativas si hace falta.

Por último, la página de “Nueva contraseña de administrador” y la de “Confirmación” cierran el ciclo: definimos la contraseña local y revisamos el plan antes de pulsar “Disminuir nivel / Demote”, que dispara el comando equivalente Uninstall-ADDSDomainController con los parámetros seleccionados.

Monitorización del proceso y comprobaciones finales

Durante la fase de “Degradación” en el asistente, las operaciones detalladas se van registrando en los archivos %systemroot%\debug\dcpromo.log y %systemroot%\debug\dcpromoui.log, que son la referencia para diagnosticar cualquier fallo en el proceso.

Una vez completada la degradación o la limpieza de metadatos, suele producirse un reinicio automático del servidor si estamos degradando un DC vivo. En cambio, cuando limpiamos metadatos de un DC ya caído, el impacto se limita al Directorio y a la replicación.

Después de cualquier operación de este tipo hay varias comprobaciones recomendables:

• Verificar en Dsa.msc que el DC retirado ya no aparece en la OU “Controladores de dominio”.
• Revisar en Dssite.msc que su objeto de servidor ya no contiene “NTDS Settings”, o que se ha borrado completamente si no tiene objetos secundarios.
• Comprobar los registros de eventos de los controladores restantes para asegurarse de que no aparecen nuevos errores de replicación.
• Ejecutar herramientas de diagnóstico como dcdiag y repadmin para validar la salud del Directorio y la replicación.

Si todo está en orden y no se registran errores persistentes, podemos dar por cerrado el proceso de eliminación del controlador fallido y la limpieza de su rastro en Active Directory.

Mantener el Active Directory libre de controladores obsoletos y metadatos huérfanos es una de esas tareas de higiene que no brillan, pero que evitan muchos problemas futuros: menos errores de replicación, topologías más claras, diagnósticos más sencillos y una base más sólida para futuras migraciones o ampliaciones del entorno.