🌐 También en: English · Deutsch · Français
En el artículo anterior, tres máquinas HP se convirtieron en un dominio de Windows Server 2025: AD, DNS, conmutación por error de DHCP, directivas de grupo, BitLocker, Storage Spaces. Ese fue el día uno: todo instalado, todo en verde, todo «funciona».
Este artículo trata del día dos, la parte en la que dejas de admirar las marcas verdes y empiezas a hacer preguntas incómodas. ¿Qué hora es y quién lo dice? ¿Qué servicios están funcionando sin que nadie los pidiera? ¿Qué pasa si mañana un servidor simplemente no arranca? Spoiler: una de esas preguntas tenía una respuesta muy graciosa.
Mismo planteamiento que antes: yo decido, y mi coadministrador de IA (Claude, manejando PowerShell por WinRM) hace el inventario, aplica los cambios y comprueba el resultado tras cada paso. Primero leer, después cambiar, al final verificar. Aburrido a propósito.
🔍 Paso cero: inventario antes que opiniones
Antes de tocar nada, una pasada de solo lectura por los tres DC: build del sistema operativo, RAM, plan de energía, roles instalados, servicios en ejecución, configuración SMB, protección LSA, firma LDAP, fuente de hora, Defender, tamaño de los registros de eventos, orden DNS de la tarjeta de red, archivo de paginación, discos, perfiles del cortafuegos. Y además el propio dominio: directiva de contraseñas, nivel funcional, esquema LAPS, limpieza de DNS, lista de GPO.
Dato curioso: la primera versión de ese script de inventario no devolvió absolutamente nada. Ni error, ni salida, solo silencio. WinRM (a través de pywinrm) envía PowerShell como una línea de comandos UTF-16 codificada en Base64, y Windows limita las líneas de comandos a 8191 caracteres. Un script de 3,5 KB se convierte en ~9,5 KB por el cable y simplemente… se esfuma. Lo partes en tres y, de repente, los servidores tienen mucho que contar.
🕰️ El reloj que no respondía ante nadie
Mi hallazgo favorito del día:
PS> w32tm /query /source
Free-running System ClockEso era en HP1, el emulador de PDC, el único controlador de dominio cuyo trabajo en la jerarquía de tiempo consiste precisamente en ser el reloj de referencia del dominio. Cada miembro del dominio se sincroniza con un DC, cada DC se sincroniza con el PDC… y el PDC se sincronizaba con su propio cristal de cuarzo y sus buenas intenciones. Todo el dominio mantenía una hora perfectamente coherente y perfectamente desanclada.
Por qué importa: Kerberos tolera por defecto 5 minutos de desfase de reloj. Si se pasa de ahí, los inicios de sesión empiezan a fallar con errores que parecen cualquier cosa excepto «tu reloj va mal». La solución son tres líneas, solo en el PDC:
w32tm /config /manualpeerlist:"ptbtime1.ptb.de,0x8 ptbtime2.ptb.de,0x8 ptbtime3.ptb.de,0x8" `
/syncfromflags:manual /reliable:yes /update
Restart-Service w32time
w32tm /resync /rediscoverEl PTB es el instituto nacional de metrología de Alemania, así que el dominio ahora toma la hora de la gente que, literalmente, define el segundo en este país. HP1 informa de estrato 2 y los otros dos DC siguen a HP1. Jerarquía restaurada. Los iLO recibieron el mismo tratamiento más tarde: no tenían NTP en absoluto y dos de ellos creían vivir en «Eastern Europe (DST disabled)».
🌐 Orden DNS del cliente: por qué HP2 entró en pánico cuando HP1 se reinició
¿Recuerdas la nota de la última vez, que HP2 rechazó inicios de sesión durante unos siete minutos mientras HP1 se reiniciaba? El inventario lo explicó: la tarjeta de red de HP2 tenía configurado exactamente un servidor DNS, HP1. Sin HP1, no hay DNS, no hay registros SRV, no se encuentra ningún DC, no hay Kerberos. El propio HP1 solo apuntaba a 127.0.0.1.
El orden recomendado para la tarjeta de red de un DC es: primero un DC compañero, después otro compañero, el loopback al final. El compañero primero, para que un DC recién arrancado no espere a su propio servicio DNS, que aún no ha arrancado. El loopback al final, para que siga resolviendo cuando todos los demás estén caídos. HP3 ya lo tenía así, y ahora los tres también.
🗺️ Sitios de AD: renombrar «Default-First-Site-Name»
Todo bosque empieza con un sitio llamado Default-First-Site-Name y sin subredes. Con tres DC en un mismo rack, un solo sitio es exactamente lo correcto. La replicación dentro del sitio usa notificación de cambios (~15 segundos), y añadir más sitios solo haría las cosas más lentas.
Aun así, dos pequeños cambios: el sitio se renombró a Homelab (renombrar, nunca borrar y volver a crear; AD lo sigue por su GUID y Netlogon vuelve a registrar por sí solo los registros SRV de _sites), y se le asignó 192.168.10.0/24. Ahora cada cliente puede asociar su IP a un sitio, lo que evita los eventos 5807 de Netlogon por subredes desconocidas. Como verás más abajo, también tiene que ver con cómo funciona Windows Update después de WSUS.
🖨️ Servicios que nadie pidió
Windows Server con Experiencia de escritorio trae un número sorprendente de servicios que tienen sentido en un portátil y ninguno en un controlador de dominio dentro de un rack. Desactivados en los tres:
- Cola de impresión: el gordo. PrintNightmare y el «printer bug», que permite a un atacante obligar a un DC a autenticarse en otro sitio. La propia Microsoft recomienda desactivarla en los DC. Nadie imprime desde un controlador de dominio. Nadie.
- Audio (
Audiosrv,AudioEndpointBuilder): mis DC no cantan. - Geolocalización (
lfsvc): además saben perfectamente dónde están. En el rack. - Administración de radio (
RmSvc), notificaciones push (WpnService), telemetría (DiagTrack), publicación de detección de redes (FDResPub,fdPHost).
Aviso honesto: esto no hace que los servidores sean apreciablemente más rápidos. HP1 tiene 64 GB de RAM con 60 GB libres, así que un puñado de servicios ociosos no es ningún cuello de botella. Se trata de reducir superficie de ataque y ruido, no de un botón turbo. Quien te venda «desactiva 40 servicios para un 30 % más de rendimiento» en un servidor moderno te está vendiendo un placebo.
🔐 Bastionado, la lista sin glamour
- Directiva de contraseñas y bloqueo: la longitud mínima era 7 (un valor por defecto sacado directamente de 2003). Ahora 12, y bloqueo de cuenta tras 10 intentos fallidos durante 15 minutos, cuando antes no había nunca. Ojo: la plantilla de seguridad de la Default Domain Policy y el objeto de dominio tienen que coincidir. Si cambias solo el objeto de dominio, el PDC lo revierte en silencio en la siguiente actualización de directivas.
- Windows LAPS: esquema ampliado, la OU de clientes autorizada a escribir sus propios atributos de contraseña, GPO vinculada. Ahora cada cliente tiene su propia contraseña de administrador local aleatoria de 16 caracteres, que rota cada 30 días y se guarda cifrada en AD, legible solo por los administradores del dominio. Ya viene integrado en Windows, sin MSI aparte como el LAPS antiguo.
- LDAP: enlace de canal obligatorio. El interruptor completo de «requerir firma» es el siguiente paso, tras revisar los registros en busca de enlaces sin firmar (no había ninguno).
- Protección LSA (
RunAsPPL): LSASS se ejecuta como proceso protegido, lo que complica bastante el clásico volcado de credenciales al estilo Mimikatz. Configurada en los tres y activada después con un reinicio escalonado, un DC cada vez y nunca en paralelo (lección aprendida la última vez). Verificado de la forma aburrida: tras cada arranque, Wininit registra el evento 12, «LSASS.exe was started as a protected process with level: 4». El reinicio del servidor de archivos esperó hasta que cerré la base de datos de notas que tenía abierta en su recurso compartido. Reiniciar una máquina debajo de tus propios archivos abiertos es un tipo muy especial de gol en propia puerta. - Registros de eventos: el registro Directory Service tenía 1 MB. Un megabyte. Eso cubre más o menos «lo que ha pasado desde la hora de comer». Ahora Security 1 GB, Directory Service 256 MB, System/Application 128 MB cada uno. El disco es barato, y sin registros no hay análisis forense posible.
- Limpieza de DNS: activada con un envejecimiento de 7+7 días. Sin ella, cada cliente DHCP que se haya registrado alguna vez conserva su registro A para siempre, y al cabo de un año tu DNS es un museo.
- WinRM para los clientes: una GPO activa WinRM en la OU de clientes, con el cortafuegos abierto solo a la red de casa (
192.168.10.0/24), sin autenticación Basic y sin tráfico sin cifrar. Es el requisito previo para administrar los equipos a distancia, también con Windows Admin Center, que irá en el equipo de administración (no está soportado en un DC).
🪦 WSUS ha muerto. ¿Y quién descarga ahora las actualizaciones?
En 2024, Microsoft anunció que WSUS quedaba obsoleto. Sigue incluido en Server 2025 y sigue teniendo soporte, pero no recibe funciones nuevas y la dirección está clara. Mi configuración ya se pasó a Windows Update + directivas de grupo a secas: días de aplazamiento para los clientes, ventanas de mantenimiento fijas para los servidores, un DC parcheado el sábado como canario.
Pero WSUS hacía dos trabajos, y las reglas de aprobación solo cubren uno. El otro era el ancho de banda: descargar cada actualización una sola vez de internet y luego servirla a mil clientes por la LAN. ¿Qué lo sustituye?
Optimización de distribución (Delivery Optimization). Viene integrada en Windows y es básicamente BitTorrent para parches (con menos piratería y más Kerberos). Una actualización se divide en trozos. El primer cliente baja los trozos de la CDN de Microsoft. Cada cliente siguiente pregunta primero a sus pares: «¿alguien en mi red tiene ya el trozo 17?». Si es así, llega por la LAN; si no, de internet. Cuantos más clientes tenga una red, más parte de la descarga se queda en local. 1.000 clientes ya no significan 1.000× la descarga por tu conexión a internet.
Los ajustes que importan:
DODownloadMode = 1(LAN): pares detrás del mismo NAT/red. Es lo que usa mi GPO de clientes.DODownloadMode = 2(Grupo) conDOGroupIdSource = 1(sitio de AD): los clientes solo comparten con pares del mismo sitio de AD. Así una sucursal no se baja trozos desde la central por la WAN lenta. Por eso los sitios y subredes bien definidos vuelven a importar de repente, y por eso el cambio de nombre del sitio de más arriba no era puramente cosmético.- Microsoft Connected Cache: la versión adulta para entornos grandes. Un nodo de caché local por ubicación que descarga el contenido una vez y se lo sirve a todos, el heredero espiritual del «descargar una vez» de WSUS, sin la base de datos de WSUS ni todos sus cuidados.
Lo que sí pierdes: aprobar a mano actualizaciones individuales. Eso ahora vive en las directivas (aplazamientos, anillos, plazos) o, en la empresa, en Intune/Windows Autopatch. Para un homelab con dos clientes, todo esto es gloriosamente excesivo. Los dos portátiles comparten unos pocos cientos de MB al mes. Pero está bien conocer el mecanismo.
💾 Copias de seguridad de Windows Server: cómo funcionan de verdad
Tres DC se replican entre sí, así que el propio AD es redundante. Pero la replicación no es una copia de seguridad: una OU borrada se replica igual de rápido que una creada. (La papelera de reciclaje de AD de la última vez cubre el caso «ups, borrado». No cubre «el servidor no arranca».) Por eso HP1 y HP2 ejecutan ahora cada noche Copias de seguridad de Windows Server hacia su segundo SSD de 2 TB, vacío hasta ahora.
Bajo el capó:
- Primero, VSS. El servicio de instantáneas de volumen congela un snapshot coherente de los volúmenes. La base de datos de AD (
ntds.dit) tiene un writer de VSS, así que la copia es transaccionalmente limpia incluso mientras el DC sigue trabajando. Sin tiempo de inactividad, sin modo de mantenimiento. - Copia a nivel de bloque en VHDX. El snapshot se copia bloque a bloque en archivos VHDX en el volumen de destino. Tras la primera copia completa, las siguientes solo copian los bloques modificados, lo que hace que la tarea nocturna sea rápida.
- Versiones mediante instantáneas en el destino. Las versiones antiguas se guardan como instantáneas en el propio volumen de copia. Cuando se acaba el espacio, las más antiguas se eliminan automáticamente. No hace falta ningún script de retención.
- Qué incluye: Bare Metal Recovery (C:, la partición EFI, la partición de recuperación) más System State (base de datos de AD, SYSVOL, registro, archivos de arranque, los almacenes COM+ y de certificados). La base de datos de DHCP está en
C:\Windows\System32\dhcp, así que también va dentro.
Los tres escenarios de restauración:
- Archivos sueltos:
wbadmin get versionsy luego restaurar archivos o carpetas concretos de cualquier versión mientras el servidor sigue funcionando. - Objetos de AD estropeados: arrancar en el modo de restauración de servicios de directorio, restaurar el System State (no autoritativo: el DC se pone al día después por replicación) o marcar objetos concretos como autoritativos con
ntdsutilpara que se impongan a los otros DC. - Servidor muerto, disco muerto, sistema muerto: arrancar desde la ISO de Windows Server → Reparar el equipo → Recuperación de imagen del sistema, indicarle el disco de copia y reconstruye las particiones y restaura C: 1:1. Para un DC es una restauración no autoritativa: vuelve con el estado de la noche anterior y luego replica todo lo más reciente desde sus compañeros. Tiene que hacerse dentro de la vida útil de los tombstones (180 días), lo que nunca es un problema con una tarea nocturna.
La advertencia honesta: la copia vive dentro de la misma máquina. Eso cubre un disco de sistema muerto, una actualización fallida, un AD corrupto. Si muere la placa base, el SSD puede mudarse a un equipo de repuesto. Pero un incendio, un robo o un ransomware que cifre todos los volúmenes se llevarían la copia por delante. Para eso están las copias en otra máquina (ver la siguiente sección). Y para un DC siempre hay plan B: con dos compañeros sanos, reinstalar y volver a promover suele ser más rápido que restaurar nada.
📦 Copias de seguridad, segunda parte: sacar el archivo familiar de la máquina
Los DC siempre se pueden reconstruir a partir de sus compañeros. Los 1,5 TB de archivo familiar en el pool con paridad de HP3, no. La paridad protege frente a un SSD muerto, no frente a una carpeta borrada, un ransomware o un pool que decide tener un mal día. Así que el equipo de copias Linux que ya se trae mis instancias de Nextcloud ahora también se trae los recursos compartidos del NAS.
- Una cuenta dedicada de solo lectura.
svc-nas-backuprecibe Lectura en los tres recursos SMB y permisos NTFS de lectura y ejecución, y nada más: ni administrador ni Operadores de copia de seguridad. (Los Operadores de copia de seguridad en un DC pueden leerntds.dit, es decir: todo el dominio.) Su contraseña aleatoria de 32 caracteres está en un archivo de credenciales en el equipo Linux que solo puede leer root. - Automontajes CIFS de solo lectura. Los recursos se montan como
romediante fstab conx-systemd.automount. Una prueba de escritura desde el equipo de copias falla con «read-only file system», que es justo la idea: un equipo de copias comprometido no puede cifrar el origen. - rdiff-backup, un repositorio por usuario. El estado actual se guarda como archivos normales, las versiones antiguas como diffs inversos, 30 días de historial. El script se niega a copiar un recurso inaccesible o vacío. Si no, un hipo de la red quedaría registrado como «el usuario lo ha borrado todo».
La primera ejecución tardó unas seis horas, y las cifras fueron una lección sobre lo que de verdad cuesta tiempo. Mis 1,2 TB (unos miles de archivos comprimidos grandes) fluyeron a ~108 MB/s constantes y terminaron en tres horas. Los 236 GB de otro miembro de la familia, repartidos en 189.000 archivos, tardaron casi lo mismo. Para rdiff-backup, el número de archivos importa mucho más que el volumen de datos. La segunda ejecución tardó 73 segundos.
Y sí, después comprobé el número de archivos. No cuadraba. Tras un ligero momento de pánico: el Get-ChildItem de PowerShell se salta los archivos ocultos si no añades -Force. Con -Force y descontando la basura excluida (Thumbs.db, .DS_Store, archivos de bloqueo de Office), las cifras cuadraban al archivo. Fiarse está bien, pero con -Force.
🔐 BitLocker en los servidores: para el día en que los discos salgan de casa
Mi modelo de amenazas aquí es modesto: un disco que muere y vuelve por garantía, o un servidor que venderé dentro de cinco años. Nadie debería poder leer de él una base de datos de AD o una foto familiar. Así que BitLocker con solo TPM: sin PIN, porque los servidores tienen que arrancar sin nadie delante.
- Claves de recuperación en AD, y fuera de él. Una GPO en la OU Domain Controllers hace obligatoria la copia de la clave de recuperación en AD. Windows se niega a cifrar si eso falla. Las claves se guardan bajo el objeto de equipo y se replican a todos los DC: las claves de HP3 aparecieron en HP1 en menos de un minuto. Pero si los tres DC se quedan a la vez en la pantalla de recuperación (por ejemplo, tras actualizar la BIOS en todos), la clave está en AD y AD no está funcionando. Por eso también hay una copia en el gestor de contraseñas.
- La pantalla de recuperación es previa al arranque, así que la consola remota del iLO funciona para ella incluso sin licencia Advanced. Antes de actualizar el firmware,
Suspend-BitLocker -RebootCount 1evita la petición por completo. - Los volúmenes de datos se desbloquean automáticamente, y en el pool grande solo se cifra el espacio usado. Si no, con paridad tardaría días.
Dos giros de guion. Primero, el TPM de HP1 decía estar «owned» pero no «ready for storage», sin SRK aprovisionada. Probablemente sigue perteneciendo a alguna instalación anterior. Initialize-Tpm respondió con ClearRequired=True, así que hay que borrarlo. A propósito no lo dejé programado como ajuste de BIOS pendiente vía Redfish: se habría disparado en el siguiente reinicio desatendido de Windows Update a las 3 de la madrugada, y la petición de presencia física habría dejado al DC esperando ante una consola que nadie mira. Se hará a mano, con la consola del iLO abierta.
Segundo, el momento. HP1 y HP2 se reiniciaron para la protección LSA minutos antes de instalar la característica BitLocker. Get-WindowsFeature informa alegremente de «Installed», pero manage-bde.exe y el módulo de PowerShell solo aparecen tras el siguiente reinicio. HP3 se reinició casualmente un día después por parches y se cifró en el acto; los otros dos seguirán tras su próximo reinicio.
🔌 iLO: preguntarle directamente al hardware
Las tres máquinas (dos ProLiant DL20 Gen10 Plus y un MicroServer Gen10 Plus v2) tienen iLO 5, e iLO 5 habla Redfish, una API REST sobre HTTPS. Así que, en lugar de ir clicando por tres interfaces web, un solo script de Python leyó de las tres los ajustes de BIOS, el inventario de firmware, las temperaturas, los ventiladores y el Integrated Management Log.
- Energía: ya óptima en todas. Perfil de carga General Power Efficient Compute, regulador de energía Dynamic Power Savings, estados C6 de paquete. Los ventiladores giran al 6–8 % en reposo. Nada que ajustar, y poner «Static High Performance» solo convertiría electricidad en calor para una carga que nunca lo necesita.
- Firmware: al día (System ROM de 2026, iLO 5 v3.21).
- Medidor de potencia: marca 0 W. Estos modelos de gama de entrada no tienen fuentes de alimentación con medición. Qué se le va a hacer.
- IML: sobre todo eventos «link down» que coinciden con recableados y reinicios del switch. Un DL20 registró hace dos meses un único uncorrectable PCIe error que no ha vuelto a aparecer. Se queda en la lista de vigilancia.
- Limpieza: zona horaria corregida, NTP apuntando a los DC, nombres de host
-ilocoherentes y registros A para los iLO en la zona de AD, para que la documentación y la realidad usen los mismos nombres.
🗜️ Deduplicación: medida y descartada
El pool ReFS con paridad de HP3 guarda unos 1,5 TB de archivo familiar, y Server 2025 trae integradas una deduplicación y compresión ReFS nuevas y relucientes. ¡Tentador! Así que antes de activar nada: mirar los datos.
- El 77 % son
.rar, seguidos de JPEG, ZIP y MP4. Todo ya comprimido. Comprimir datos comprimidos da un error de redondeo. - Duplicados reales (mismo nombre, mismo tamaño, sin contar archivos multiparte): ~72 GB, alrededor del 5 %. Sobre todo copias de portátiles viejos dentro de copias de portátiles viejos. A todos nos ha pasado.
72 GB ahorrados frente a tareas de optimización nocturnas en un pool cuyas escrituras de paridad ya son el camino lento, más un almacén de fragmentos que, en un almacenamiento de paridad simple, se convierte en un punto único de «un bloque defectuoso ahora afecta a muchos archivos». Con 2,2 TB libres, la respuesta es no. La deduplicación brilla con discos de VM, VDI y destinos de copias de seguridad, no con un montón de archivos RAR. Limpiar las carpetas duplicadas a mano sale más barato que cualquier función.
🎯 Conclusión
El día uno hace que las cosas funcionen. El día dos las hace fiables: una fuente de hora de verdad, un DNS que sobrevive a un reinicio, menos servicios, una memoria más larga, contraseñas que rotan solas y una copia de seguridad que de verdad has pensado antes de necesitarla. Nada de esto es glamuroso, y casi nada aparece como marca verde. Y el hallazgo más inquietante no fue un parche que faltaba. Fue un dominio cuyo sentido del tiempo venía de un cristal de cuarzo sin supervisión.
Lo siguiente: borrar el TPM de HP1 y BitLocker en los dos primeros DC, y por fin exigir la firma LDAP. Es una única opción de seguridad en la Default Domain Controllers Policy, y sobrescribe en silencio el valor de registro que había puesto primero. Y luego quizá, quizá, otra vez algo de YAML. Empiezo a echarlo de menos. Un poco.
