Cómo simularía la caída de un controlador de dominio (y cómo mediría cuánto tarda en volver)

Tener dos controladores de dominio da tranquilidad, pero esa tranquilidad no vale nada hasta que apagas uno y miras qué pasa. ¿Siguen entrando los usuarios? ¿Resuelve el DNS? ¿Cuánto tarda en volver el que has tirado? Si me tocara organizarlo, haría una prueba de continuidad pequeña, planificada y medida. Aquí te cuento cómo, con los comandos de antes y después, un script para cronometrar el corte desde un puesto y lo que apuntaría al acabar.

Es una propuesta genérica: dominio, nombres e IPs son de ejemplo. En casa no tengo Windows Server (al portátil de Proxmox no le da la RAM), así que no te cuento una prueba concreta, sino cómo la plantearía.

1. Decide qué quieres saber antes de apagar nada

Una prueba sin preguntas acaba en «parece que va». Yo escribiría tres antes de empezar:

1. ¿Los clientes encuentran el otro DC? Inicios de sesión, GPO, DNS y acceso a recursos compartidos.
2. ¿Cuánto dura el corte que nota un usuario? No el que crees, el que se mide.
3. ¿Cuánto tarda en volver el DC caído y en ponerse al día con la replicación?

Y un objetivo de tiempo para comparar. En la parte 3 de la serie de Proxmox conté que una VM con Windows tardó 5 minutos y 31 segundos en volver a dar servicio tras reiniciar su nodo, cuando el objetivo eran 2. El objetivo estaba mal planteado, y eso solo se supo midiendo.

2. Comprueba que el dominio está sano

Si la replicación ya va mal antes de la prueba, no sabrás qué rompió la prueba y qué estaba roto. Desde una consola con permisos de administrador del dominio:

dcdiag /q                    # solo muestra errores; vacío es buena señal
repadmin /replsummary        # fallos de replicación entre DC
netdom query fsmo            # qué DC tiene cada rol FSMO
Get-ADDomainController -Filter * | Select-Object Name, IPv4Address, IsGlobalCatalog

Tres cosas que revisaría con calma:

• Que los dos DC sean catálogo global y los dos tengan DNS. Si el que se cae era el único catálogo global, los inicios de sesión fallan aunque el otro DC esté encendido.
• El DNS que reciben los clientes. El fallo más típico: el DHCP solo reparte la IP de un DC. Si ese cae, los equipos no encuentran el dominio aunque el otro esté perfecto. Cada cliente necesita los dos servidores DNS.
• El DNS de los propios DC. Lo recomendable es que cada DC apunte primero al otro y después a sí mismo (127.0.0.1 como secundario, no como único).

Anota también quién tiene el emulador de PDC: es el que da la hora al dominio y el que procesa los bloqueos de cuenta. Si es el que vas a tirar, sabrás qué mirar.

3. Elige cómo tirarlo

No es lo mismo un apagado ordenado que un corte de luz. De más suave a más bruto:

Escenario	Cómo	Qué prueba
Aislarlo de la red	Desconectar la tarjeta virtual	Que los clientes cambien de DC. Reversible al momento
Parar solo el directorio	Stop-Service NTDS -Force	Que los clientes no se queden pegados a un servidor que responde al ping pero no autentica
Apagado ordenado	Stop-Computer	Un mantenimiento planificado
Corte duro	Parar la VM a lo bruto	Una caída real, y cuánto tarda en volver

Yo empezaría por aislarlo de la red: si algo va mal, lo vuelves a conectar y en segundos está como antes. En Proxmox es la casilla Disconnect del dispositivo de red de la VM (Hardware > Network Device). Por consola, copia la línea net0 que te da qm config <id> y añádele ,link_down=1. Si no repites la MAC, Proxmox se inventa una nueva:

qm config 101 | grep net0
# net0: virtio=BC:24:11:AA:BB:CC,bridge=vmbr0
qm set 101 --net0 virtio=BC:24:11:AA:BB:CC,bridge=vmbr0,link_down=1   # cortar
qm set 101 --net0 virtio=BC:24:11:AA:BB:CC,bridge=vmbr0                # volver

El corte duro (qm stop 101) lo dejaría para una segunda prueba, cuando la primera haya salido limpia.

4. Cronometra desde un puesto, no desde el servidor

Que la VM arranque no significa que el dominio funcione. Un DC puede contestar al ping minutos antes de servir LDAP y Kerberos. Por eso mediría desde un equipo cliente, con un bucle que cada 5 segundos apunta qué ve:

$Dominio = 'tu-dominio.local'
$DCs     = [ordered]@{ dc01 = '10.0.0.11'; dc02 = '10.0.0.12' }
$Csv     = "$env:USERPROFILE\Desktop\prueba-dc.csv"

function Test-Puerto($Ip, $Puerto) {
    $c = New-Object Net.Sockets.TcpClient
    try { $c.ConnectAsync($Ip, $Puerto).Wait(1000) } catch { $false } finally { $c.Dispose() }
}

while ($true) {
    $fila = [ordered]@{ Hora = Get-Date -Format s }
    $fila.DNS = [bool](Resolve-DnsName $Dominio -DnsOnly -ErrorAction SilentlyContinue)
    $linea = nltest /dsgetdc:$Dominio /force 2>$null | Select-String 'DC: \\\\'
    $fila.DC = if ($linea) { ($linea.Line -split '\\\\')[-1] } else { 'NINGUNO' }
    foreach ($n in $DCs.Keys) {
        $fila["$n-LDAP"]     = Test-Puerto $DCs[$n] 389
        $fila["$n-Kerberos"] = Test-Puerto $DCs[$n] 88
    }
    [pscustomobject]$fila | Export-Csv $Csv -Append -NoTypeInformation
    Start-Sleep 5
}

• nltest /dsgetdc ... /force pregunta qué DC elegiría ahora mismo el equipo, sin usar la caché. Es justo lo que quieres ver cambiar.
• Los puertos se prueban con un TcpClient y un segundo de espera. Test-NetConnection tarda demasiado en rendirse cuando el puerto no contesta y te estropea la medición.
• Las IPs van fijas en el script a propósito: si el DNS falla, quieres seguir midiendo.

Arráncalo unos minutos antes de cortar y páralo (Ctrl+C) cuando todo haya vuelto. Para sacar los tiempos:

$f = Import-Csv "$env:USERPROFILE\Desktop\prueba-dc.csv"
$caido = $f | Where-Object { $_.'dc01-LDAP' -eq 'False' }
"dc01 sin LDAP de $($caido[0].Hora) a $($caido[-1].Hora)"
New-TimeSpan ([datetime]$caido[0].Hora) ([datetime]$caido[-1].Hora)
$f | Where-Object DC -eq 'NINGUNO' | Measure-Object   # filas sin ningún DC

Si la última línea da 0, ningún momento se quedó el cliente sin DC, que es lo que buscas.

5. Qué probar mientras está caído

Con el bucle corriendo, de pie delante de otro equipo:

• Inicio de sesión con un usuario que nunca haya entrado en ese equipo. Es la prueba de verdad. Con un usuario habitual, Windows tira de las credenciales en caché y entra aunque no haya ningún DC, así que no demuestra nada.
• Un recurso compartido nuevo. Los que ya estaban abiertos siguen funcionando con el ticket de Kerberos que tenía el usuario (dura 10 horas por defecto).
• gpupdate /force y gpresult /r, para ver que las directivas se leen del DC que queda.
• Cambiar una contraseña, sobre todo si el caído era el emulador de PDC.
• Resolver nombres internos con Resolve-DnsName.

Apunta la hora de cada prueba y lo que pasa. Luego cuadrarás con el CSV.

6. La vuelta también se mide

Al reconectar (o encender) el DC, la prueba no ha terminado. Comprobaría:

repadmin /showrepl dc01          # que las últimas replicaciones sean correctas
repadmin /syncall dc01 /AdeP     # forzar la replicación si tienes prisa
dcdiag /s:dc01 /q

Y en el Visor de eventos, el registro Directory Service del DC que vuelve: los avisos de replicación en los primeros minutos son normales, pero no deberían seguir apareciendo al cabo de un rato. El tiempo que apuntaría es desde el corte hasta que repadmin no muestra errores, no hasta que la VM contesta al ping.

Los roles FSMO se quedan quietos

Si el DC caído tenía roles, en una prueba no se tocan. Si sabes que una parada va a ser larga, se transfieren antes, con los dos DC encendidos:

Move-ADDirectoryServerOperationMasterRole -Identity dc02 -OperationMasterRole PDCEmulator

Capturarlos (-Force con el dueño apagado) es para cuando un DC no va a volver nunca. Ese DC ya no se puede volver a encender tal cual: hay que limpiarlo del directorio y reinstalarlo.

7. Apúntalo

Un informe de una página basta:

Campo	Ejemplo
Fecha y escenario	20/10, dc01 aislado de la red
Corte visto por el cliente	0 s sin DC; 12 s hasta cambiar a dc02
Vuelta de dc01	1 min 40 s hasta replicar sin errores
Qué falló	La impresora de recepción tenía un DNS fijo apuntando solo a dc01
Acciones	Corregir el DNS de los equipos con IP fija; repetir en 6 meses

La fila más útil es «qué falló». Siempre sale algo: un equipo con IP fija y un solo DNS, una aplicación que tiene escrito el nombre de un DC concreto, un servicio que autentica contra una IP. Para eso se hace la prueba.

Lo que no hay que hacer

• Restaurar un DC desde una instantánea para «deshacer» la prueba. Puede provocar un USN rollback y dejar la replicación rota sin avisar. Windows Server 2012 y posteriores se protegen con VM-GenerationID (Proxmox lo soporta), pero no lo conviertas en tu plan.
• Hacerla un lunes a las nueve. Avisa, elige una hora tranquila y ten a alguien delante de un puesto.
• Probar solo con tu usuario. Las credenciales en caché te dirán que todo va bien.
• Capturar roles FSMO durante una prueba.
• Dar el tiempo por bueno sin medirlo. «Ha vuelto rápido» no es un dato.

Resumen

1. Escribe antes qué quieres saber y un objetivo de tiempo.
2. Revisa la salud del dominio y, sobre todo, el DNS que reciben los clientes.
3. Empieza aislando el DC de la red: es reversible al momento.
4. Mide desde un puesto con un bucle y un CSV, no mirando la consola del servidor.
5. Prueba con un usuario que nunca haya entrado en ese equipo, mide la vuelta hasta que la replicación esté limpia y apunta lo que falle.

Dos controladores de dominio son una promesa. La prueba es lo que la convierte en un dato, y casi siempre descubre algo que nadie sabía.