🌐 También en: English · Deutsch · Français
Hora de confesarse. Después del diario de batalla de la migración de Nextcloud, un número de dos cifras de ejecuciones de playbooks, un conjunto de reglas de nftables que vació alegremente las propias tablas de K3s y más YAML del que cualquier ser humano debería leer en una sola semana, estaba oficialmente hasta aquí de Nextcloud, de Ansible y de todo lo que contuviera la palabra «migración».
Así que hice lo que hace cualquier nerd de Linux sensato cuando está quemado de Linux: me pasé al otro lado. Tres servidores, tres instalaciones limpias de Windows Server 2025 y unas cuantas tardes de Active Directory, DNS, DHCP, directivas de grupo, Storage Spaces y BitLocker. Nada de YAML. Solo un montón de Get- y Set-.
Que quede claro: esto no es una historia de conversión. Ahora voy por dos vías. Linux se queda donde está y sigue haciendo el trabajo pesado, mientras que, a título personal, quiero aprender bien el lado de Microsoft, y en concreto el servidor. No «darle a Siguiente hasta que funcione». Entender qué hace un controlador de dominio al arrancar, por qué la conmutación por error de DHCP tiene la forma que tiene y qué escribe realmente una directiva de grupo en el registro. El homelab es el aula.
O, dicho de forma menos solemne: simplemente quiero trastear un tiempo con una infraestructura Windows de verdad. Dominio, directivas, servicios de archivos, parches, cifrado, virtualización, el paquete completo, con suficientes máquinas como para que se comporte como una pequeña empresa y no como una única VM de prueba que borraré al cabo de una hora.
🖥️ La alineación
Tres cajas HP, todas con iLO, todas ya con Windows Server 2025 y todas promovidas a controladores de dominio en el mismo bosque:
- HP1: controlador de dominio, emulador de PDC, DNS, DHCP
- HP2: controlador de dominio, DNS, DHCP (socio de conmutación por error de HP1)
- HP3: controlador de dominio, DNS, además de tres SSD en un pool de Storage Spaces, y el futuro servidor de archivos central de la casa
El dominio es muench.home.arpa. home.arpa es la zona que el RFC 8375 reserva exactamente para esto: redes domésticas. Se acabó el falso .local peleándose con mDNS, y no hace falta registrar un dominio público solo para ponerle nombre a un laboratorio.
Tres DC para un hogar es objetivamente excesivo. De eso se trata. Con tres puedo apagar uno, reiniciarlo o romperlo, y aun así ver cómo los otros dos siguen adelante. Resultó que eso fue exactamente lo que pude observar (más abajo, los detalles).
Y sí, las viejas costumbres se vinieron conmigo. No pienso ir clic a clic por el Administrador del servidor en tres máquinas. Todo se maneja en remoto por WinRM desde mi máquina de salto Linux con pywinrm. Las viejas costumbres tardan en morir, pero al menos ahora hablan PowerShell.
Primera trampa del viaje: WinRM envía el script en base64 por la línea de comandos, y Windows limita una línea de comandos a 8191 caracteres. Lo que sea más largo no falla. Simplemente no hace nada, en silencio. La solución: subir los scripts en trozos pequeños, comprobar un SHA256 en el destino y luego ejecutar. Muy Windows, muy didáctico.
Segunda trampa: activé el servidor OpenSSH como alternativa manual, y el puerto 22 daba timeout desde fuera aunque el servicio estaba en marcha y la regla del cortafuegos decía «habilitada». La regla creada automáticamente solo cubría el perfil Privado. Un servidor unido al dominio funciona con el perfil Dominio. Un Set-NetFirewallRule -Profile Domain,Private después, funcionó.
🤖 Mi coadministrador es una IA (y no, esto no es «vibe admin»)
Para ser totalmente transparente con ese pipeline de WinRM: no soy el único que lo usa. Cuando me atasco, Claude (la IA de Anthropic, que funciona como Claude Code en la máquina de salto Linux) se conecta a los servidores a través de exactamente esa interfaz WinRM y me ayuda con la configuración. Lee el estado actual, propone cambios, los explica, los aplica cuando digo que sí y después comprueba el resultado.
Así funciona en la práctica, porque aquí no hay magia: Claude se ejecuta en un terminal en la máquina Linux y puede ejecutar comandos de shell allí. Para comandos rápidos de una línea llama a los servidores directamente con pywinrm. Para cualquier cosa más grande, el flujo de trabajo es este:
1. write a PowerShell script locally (check_hp2.ps1, gpo_bitlocker.ps1, …)
2. open a WinRM session to the server (HTTP 5985, NTLM, message-encrypted)
3. upload the script in ~1200-char base64 chunks → C:\Temp\
4. compare SHA256 locally vs. on the server → abort if they differ
5. execute it, collect stdout + errors (unwrapping PowerShell's CLIXML error stream)
6. read the output, decide the next step → back to 1La subida por trozos y la suma de comprobación están ahí por el límite de 8191 caracteres de la trampa anterior: un script que se trunca por el camino es peor que uno que no llega. Los scripts son archivos .ps1 normales y corrientes, así que puedo leer cada uno antes o después de que se ejecute. Ese es además el efecto secundario agradable: al final de una sesión me queda un montón de PowerShell legible que muestra exactamente lo que se hizo, y puedo aprender de él.
Seguramente hayas oído el término vibe coding. Andrej Karpathy lo acuñó a principios de 2025 para un estilo de programación en el que describes lo que quieres en lenguaje llano, dejas que la IA escriba el código y aceptas más o menos lo que salga sin leerlo con atención. Va de código, y la parte de «vibe» es precisamente no comprobar.
Lo que hago aquí es la versión de administración de la primera mitad, pero deliberadamente no de la segunda. Dejar que una IA dispare comandos sin revisar contra tus controladores de dominio sería «vibe admin», y es una forma estupenda de conocer de cerca tu estrategia de copias de seguridad. Así que las reglas básicas son:
- Primero leer, después cambiar. Cada tarea empieza con un inventario de solo lectura de lo que está configurado de verdad, no de lo que creemos que está configurado.
- Yo decido, la IA ejecuta. Los cambios se hacen cuando doy mi visto bueno, y todo lo destructivo lleva antes una pregunta explícita.
- Verificar desde el otro lado. Una GPO no está terminada cuando
New-GPOdevuelve el control. Está terminada cuando el valor del registro aparece en la máquina de destino. La conmutación por error de DHCP no está arreglada hasta que ambos socios informan del nuevo ajuste. - Explicar el porqué. Quiero aprender Windows Server, no externalizarlo. Así que hago muchas preguntas del tipo «¿por qué es así?», y algunas de las mejores partes de este artículo salieron de esas respuestas.
Un ejemplo real de la sesión en la que escribí este artículo: queríamos activar la toma de control automática en la relación de conmutación por error de DHCP. El cmdlet en HP1 respondió con un escueto PermissionDenied, a pesar de tener derechos de administrador del dominio. Claude reconoció el patrón: el clásico doble salto (double hop). Yo estaba conectado a HP1 en remoto, el cmdlet tiene que cambiar a la vez el ajuste en HP2, y HP1 no tiene permitido pasar mis credenciales a una tercera máquina. La solución fue una tarea programada de un solo uso que se ejecuta localmente en HP1 con un inicio de sesión de verdad y que después se borra. Luego comprobamos el ajuste en ambos socios. Eso lo habría estado buscando en Google una hora. En su lugar, me llevé una lección de diez minutos sobre cómo funciona la delegación de credenciales en Windows.
No sustituye a entender las cosas. La IA es rápida y sabe mucho, pero también comete errores: en este viaje sobrescribió una variable de PowerShell porque olvidó que allí los nombres de variables no distinguen entre mayúsculas y minúsculas. Es más bien como programar en pareja con un compañero que se ha leído todos los artículos de Microsoft Learn que se han escrito, que nunca se cansa de preguntas y cuyo trabajo sigues revisando.
🌐 DNS: la parte sin la que AD no puede vivir
Active Directory es, en el fondo, un consumidor de DNS con opiniones muy firmes. Los clientes encuentran sus controladores de dominio mediante registros SRV (_ldap._tcp.dc._msdcs...), así que si el DNS está mal, todo está mal, normalmente de formas desconcertantes. Se aplica el antiguo haiku del sysadmin: No es el DNS. / No puede ser el DNS. / Era el DNS.
Los tres DC ejecutan DNS integrado en AD, así que las zonas se replican con el propio directorio en lugar de mediante transferencias de zona. Los tres son también catálogos globales, y el DHCP reparte los tres como servidores DNS, de modo que cualquiera de ellos puede desaparecer sin que los clientes se den cuenta:
PS> Get-DhcpServerv4OptionValue -ScopeId $scope -OptionId 6
OptionId Name Type Value
-------- ---- ---- -----
6 DNS Servers IPv4Address {…, …, …}Tres entradas. El orden de los resolvedores es cosa del cliente de todos modos, pero al menos cada cliente conoce las tres puertas.
📦 La FritzBox, degradada
Hasta ahora, mi FritzBox hacía lo que hace cualquier router doméstico: DHCP y DNS para toda la casa. Con Active Directory eso no funciona. Los miembros del dominio tienen que usar los controladores de dominio como servidores DNS, porque solo los DC conocen los registros SRV que le dicen a un cliente dónde vive su dominio. Repartir el router como DNS es el clásico error de configuración de AD: la unión al dominio falla, las GPO no se aplican sin decir nada y los inicios de sesión tardan cinco minutos sin motivo aparente.
Así que el servidor DHCP de la FritzBox está desactivado, el DHCP funciona ahora como rol en los servidores Windows (ver más abajo) y reparte los tres DC como servidores DNS, no la FritzBox.
Eso sí, la FritzBox no se ha quedado en paro. Sigue siendo la puerta de enlace predeterminada, así que todo el tráfico de internet sigue saliendo de casa a través de ella. Y los DC reenvían todas las consultas DNS de las que no son responsables, es decir, todo lo que queda fuera de muench.home.arpa, a la FritzBox, que pregunta al mundo exterior. Un reparto del trabajo limpio: Windows conoce la casa, la FritzBox conoce internet.
client ──DHCP────► HP1 / HP2 address, gateway = FritzBox, DNS = the 3 DCs
client ──DNS─────► any DC ──┬─ *.muench.home.arpa → answers itself
└─ everything else → forwards to FritzBox → internet
client ──traffic─► FritzBox (default gateway) ──────────────────────────► internetLa FritzBox ha pasado de «llevar la casa» a «vigilar la puerta de entrada». Se lo ha tomado sorprendentemente bien.
📡 Conmutación por error de DHCP: la sorpresa de las parejas
Mi plan era sencillo: tres servidores, tres nodos DHCP, todos en un feliz clúster de conmutación por error.
Windows tenía otros planes. La conmutación por error de DHCP funciona estrictamente por parejas. Una relación de conmutación por error tiene exactamente dos socios, y un ámbito solo puede pertenecer a una relación. No hay modo a tres, ni quórum, ni malla. El DHCP de Windows es estrictamente monógamo. Así que el tercer rol DHCP se desinstaló otra vez, y HP1 y HP2 comparten ahora el ámbito en modo de equilibrio de carga: se reparten el pool de direcciones al 50/50 y sincronizan las concesiones entre sí.
PS> Get-DhcpServerv4Failover | Select Name, Mode, State
Name Mode State
---- ---- -----
hp1-…-hp2 LoadBalance NormalEl pool en sí es deliberadamente aburrido: una /24, y el rango dinámico va de .70 a .245. Son 176 direcciones para portátiles, móviles, televisores y cualquier otra cosa que entre por la puerta. Todo lo que está por debajo de .70 está configurado de forma estática y queda fuera del pool: el router, los servidores, sus interfaces iLO y el resto de la infraestructura que nunca debería moverse. La parte alta queda libre como reserva.
PS> Get-DhcpServerv4Scope | Select ScopeId, StartRange, EndRange, LeaseDuration
ScopeId StartRange EndRange LeaseDuration
------- ---------- -------- -------------
192.168.10.0 192.168.10.70 192.168.10.245 8.00:00:00
Option 3 Router
Option 6 DNS Servers (all three DCs)
Option 15 DNS Domain Name muench.home.arpaAlgunos detalles que conviene conocer:
- Concesiones de 8 días. En un hogar en el que los mismos dispositivos vuelven cada día, las concesiones largas significan menos cháchara. También significan que una caída del DHCP pasa desapercibida durante días en lugar de minutos.
- Equilibrio de carga 50/50. Los dos servidores responden, y cada uno se encarga de la mitad de los clientes (según un hash de la dirección MAC). Si un socio desaparece, el otro sigue atendiendo a todos y renueva también los clientes de su socio, en pasos limitados por el MCLT. Tras 60 minutos sin contacto, pasa automáticamente a
PartnerDowny asume el pool completo. (Ese cambio automático venía desactivado de serie, y no lo activé hasta que estaba escribiendo este artículo). - MCLT de una hora. El Maximum Client Lead Time limita cuánto puede un servidor prolongar una concesión más allá de lo que sabe su socio. Es el margen de seguridad que impide que dos servidores repartan la misma dirección tras perder el contacto.
- Actualizaciones dinámicas de DNS. Los clientes se registran ellos mismos en las zonas de AD, así que cada portátil es accesible por su nombre, y el DHCP borra el registro cuando caduca la concesión.
- Autorización en AD. Un servidor DHCP de Windows solo reparte concesiones cuando está autorizado en Active Directory. Un servidor DHCP no autorizado que alguna persona bienintencionada enchufe se queda callado, siempre que sea uno de Windows.
En el momento de escribir esto, el pool está a un apabullante 3 % de ocupación. Planificación de capacidad de nivel empresarial.
Otra pequeña lección: quería dejar constancia de todos los dispositivos con configuración estática por debajo del rango dinámico, como «reservas de documentación» directamente en la consola de DHCP. Pues no. Add-DhcpServerv4Reservation solo acepta direcciones dentro del rango del ámbito. El DHCP no es una CMDB, y te lo hace saber.
🔐 Secure Boot, o cómo un DC espera a sus amigos
Las tres máquinas se instalaron en UEFI/GPT con un TPM 2.0 integrado, pero Secure Boot seguía desactivado en el firmware. Así que hoy tocaba ruta por las BIOS: un servidor cada vez, activar la opción, reiniciar, comprobar.
«Uno cada vez» se convirtió en una pequeña lección en sí misma. HP2 volvió a arrancar mientras HP1 seguía a mitad de reinicio, y durante unos siete minutos HP2 respondía al ping, tenía todos los puertos abiertos… y rechazaba cada inicio de sesión con un HTTP 401. Luces encendidas, pero nadie en casa.
No había nada roto. Un controlador de dominio recién arrancado quiere completar una sincronización inicial con sus socios de replicación antes de asumir del todo su papel de DC. Uno de esos socios seguía mirando una pantalla de POST, así que HP2 esperó educadamente a un timeout. En cuanto HP1 volvió, todo se puso en verde otra vez: replicación sin errores y la conmutación por error de DHCP de vuelta de CommunicationInterrupted a Normal.
Lección apuntada: no reinicies tus controladores de dominio en paralelo. Lo que nos lleva directamente al siguiente tema.
🪦 WSUS: instalado en mi cabeza, obsoleto en la realidad
Para cualquier administrador de Windows de cierta edad, «gestión de parches» significa WSUS. Estaba en mi lista: instalarlo en HP2, sincronizar el catálogo, aprobar actualizaciones, sentirme como una empresa de verdad y ver crecer SUSDB como una masa madre que nadie ha pedido.
Luego leí la letra pequeña. En 2024, Microsoft puso oficialmente WSUS en la lista de funciones obsoletas. Sigue incluyéndose en Server 2025 y sigue funcionando, pero no recibirá funciones nuevas, y todo el esfuerzo de desarrollo va a la parte de la nube: Windows Autopatch, Intune y Azure Update Manager. Aprender un producto el mismo año en que lo apuntan para la jubilación fue como estudiar para un examen que ya se ha cancelado. (Además, ejecutar WSUS con su base de datos e IIS en un controlador de dominio no es precisamente una buena práctica).
Así que las actualizaciones llegan directamente de Microsoft, y la directiva de grupo decide cuándo. Lo que nos lleva a la verdadera estrella de este artículo.
📜 Directivas de grupo: el YAML del mundo Windows
Si Ansible es «describe el estado deseado y deja que una herramienta lo imponga», las directivas de grupo son la misma idea, integrada en el sistema operativo desde el año 2000. Además, las entregan los propios controladores de dominio y se vuelven a aplicar cada 90 minutos, sin necesidad de ejecutar ningún playbook. Lo reconozco, estoy un poco impresionado. Por favor, no se lo cuentes a mis roles de Ansible.
Esto es lo que está activo ahora en el dominio, todo creado desde PowerShell (New-GPO, Set-GPRegistryValue, New-GPLink) y verificado después leyendo los valores reales del registro en las máquinas de destino:
1. Unidades de red asignadas. HP3 tiene una carpeta y un recurso compartido SMB por usuario (\\HP3\user1, \\HP3\user2, …). Cada usuario es dueño de su propia carpeta con control total tanto en los permisos NTFS como en los del recurso compartido, además de enumeración basada en el acceso, así que ni siquiera ves las carpetas que no puedes abrir. Las cuentas de usuario viven en su propia OU, y una sola GPO asigna las letras de unidad. Las preferencias de directiva de grupo con destino a nivel de elemento deciden quién recibe qué: user1 (ese soy yo, el administrador de la casa) recibe todas las unidades, y user2 solo la suya. Las rutas usan el nombre del servidor en lugar de la IP, para que la autenticación vaya por Kerberos en lugar de recurrir a NTLM.
2. Windows Update para los clientes. Mi ordenador de sobremesa y mi portátil rara vez están encendidos por la noche, así que «instalar a las 3 de la madrugada» no les sirve de nada. En su lugar:
- actualizaciones de calidad aplazadas 3 días, para que el resto de internet encuentre primero los parches defectuosos
- versión de características fijada, así que nada de actualizaciones sorpresa a la siguiente versión de Windows 11
- plazos de 3 días (calidad) y 7 días (características), más 2 días de gracia, tras los cuales el reinicio se produce me guste o no. Windows Update siempre ha sido un producto de «te guste o no»; ahora, al menos, la fecha la elijo yo
- horas activas de 07:00 a 23:00
- «Actualizar y apagar» en el menú de inicio/apagado, para que apagar por la noche haga el trabajo
- Optimización de distribución limitada a la LAN, para que las actualizaciones se descarguen una sola vez para toda la casa
3. Windows Update para los servidores: escalonado. Una GPO base en la OU Domain Controllers (descarga automática, instalación programada), más una pequeña GPO de programación por servidor con filtrado de seguridad, para que cada una se aplique exactamente a una máquina:
HP3 Saturday 03:00 ← the canary
HP1 Sunday 03:00
HP2 Sunday 05:00HP3 es el canario en la mina de los parches: recibe las actualizaciones un día antes que los demás. Si una actualización acumulativa rompe algo, me entero el sábado y todavía tengo un día para frenar el resto. Y HP1 y HP2 nunca se reinician a la vez. En la sección anterior está el porqué.
Pequeña trampa secundaria en el filtrado de seguridad: cuando quitas «Usuarios autenticados» del filtro, el grupo sigue necesitando Leer sobre la GPO, o nadie podrá leerla (recuerdos de MS16-072). El propio equipo recibe Aplicar, y Usuarios autenticados conserva Leer.
4. Modo oscuro, y adiós a Spotlight. Puramente cosmético, y totalmente a mi gusto: todos los usuarios de la casa reciben el modo oscuro para Windows y las aplicaciones, además de un escritorio negro liso. Nada de Windows Spotlight, ni de fotos rotativas del tipo «¿sabías que esta montaña está en Noruega?» con un punto interactivo que te invita a saber más. Spotlight es básicamente un salvapantallas con departamento de marketing.
El problema aquí era la edición. La directiva oficial «Turn off all Windows spotlight features» solo funciona en Windows Enterprise y Education. Mis clientes tienen Windows 11 Pro, donde la directiva simplemente se ignora. La solución son las preferencias de directiva de grupo: en lugar de una directiva oficial, la GPO escribe los valores del registro que pondría la propia aplicación Configuración:
HKCU\…\Themes\Personalize AppsUseLightTheme = 0 # dark apps
HKCU\…\Themes\Personalize SystemUsesLightTheme = 0 # dark taskbar/start
HKCU\…\Explorer\Wallpapers BackgroundType = 1 # solid color, kills Spotlight
HKCU\Control Panel\Colors Background = "0 0 0" # black
HKCU\Control Panel\Desktop Wallpaper = ""La acción está en Actualizar, así que un usuario puede cambiar el fondo, pero la siguiente actualización de directivas lo vuelve a poner en negro. Además, la GPO establece la directiva oficial «Turn off Spotlight collection on Desktop», como cinturón y tirantes para el día en que una máquina pase a Enterprise. Los cambios surten efecto en el siguiente inicio de sesión.
5. BitLocker. Ese se merece su propia sección.
🔒 BitLocker: ¿de qué protege realmente?
Antes de activar nada, quería un modelo de amenazas claro, porque «cifrado = seguro» es demasiado simple.
BitLocker protege los datos en reposo. Su trabajo es el portátil robado, el disco sacado de un servidor o el SSD que vuelve en garantía. Lo que no hace: proteger un sistema en marcha y desbloqueado. El malware, una cuenta comprometida o una contraseña débil lo ven todo en texto claro, igual que antes.
Luego viene la cuestión de cómo se desbloquea la clave:
- Solo TPM: el TPM libera la clave si la cadena de arranque no ha cambiado. Es cómodo y protege el disco extraído. Pero la máquina arranca sola hasta la pantalla de inicio de sesión, así que si roban la máquina entera, el único obstáculo del ladrón es el inicio de sesión de Windows.
- TPM + PIN: además, un PIN antes incluso de que arranque Windows. El dispositivo robado ya no es más que un ladrillo con un disco cifrado, o un pisapapeles muy caro con ventilador. Menos cómodo, pero para un portátil que viaja conmigo es la opción correcta.
Lo gracioso: ya había activado BitLocker en mi portátil el día anterior, solo con TPM y sin PIN. Buena noticia: el PIN se puede añadir después. Es solo un protector de clave adicional, y no se vuelve a cifrar nada:
manage-bde -protectors -add C: -TPMAndPINEl problema: Windows solo permite un PIN de prearranque si una directiva lo autoriza. Así que, sorpresa, otra GPO. Ahora hay dos directivas de BitLocker en el dominio:
- Todos los clientes: BitLocker se activa automáticamente en la unidad del sistema operativo, y la clave de recuperación se guarda en Active Directory. Se acabaron las claves en un archivo de texto en algún recurso compartido, o en un pósit debajo del teclado. Todos lo hemos visto. Algunos lo hemos escrito.
- El portátil: TPM + PIN es obligatorio al arrancar, mediante su propia GPO con filtrado de seguridad sobre exactamente esa máquina.
Con las GPO en su sitio, los siguientes pasos son gpupdate /force, añadir el protector de PIN y luego comprobar que la clave de recuperación aparece de verdad en el objeto de equipo en AD. Una copia de seguridad que nunca has comprobado es una esperanza, no una copia de seguridad.
Los servidores vienen después, empezando por HP3. Como futuro servidor de archivos central, también tendrá cifrado el volumen de Storage Spaces, y las claves irán a AD. Para un servidor que tiene que volver a arrancar sin supervisión, solo TPM es la opción pragmática, porque nadie quiere teclear un PIN en el iLO a las 3 de la madrugada después de un reinicio por parches.
💾 Storage Spaces: RAID 5 al estilo Microsoft
HP3 recibió tres SSD SATA de 2 TB para datos (el sistema operativo vive en un SSD aparte). En Linux habría tirado de mdadm o de OpenZFS RAIDZ1. En Windows, el equivalente es Storage Spaces: un pool con los discos físicos, encima un disco virtual con resiliencia de paridad (paridad simple con tres discos, o sea, RAID 5 en espíritu), formateado con ReFS:
PS> New-StoragePool -FriendlyName BackupPool -PhysicalDisks $disks ...
PS> New-VirtualDisk -StoragePoolFriendlyName BackupPool -ResiliencySettingName Parity ...
PS> Format-Volume -FileSystem ReFS ...
D:\ ReFS ~3.6 TB usableY luego, por supuesto, tocó hacer benchmark, con DiskSpd, el generador de carga de almacenamiento de la propia Microsoft y, más o menos, su respuesta a fio. Una vez más por la vía IA-a-través-de-WinRM. El método:
- Conseguir la herramienta: no se instala nada. El propio servidor descarga el
DiskSpd.zipoficial de las releases de Microsoft en GitHub aC:\Temp, lo descomprime y usa el binarioamd64. Es un único.exeportable. - Archivo de prueba: un archivo de 20 GB directamente en el volumen de paridad
D:. - Cuatro perfiles clásicos: secuencial con bloques de 1 MB (un hilo, profundidad de cola 8) y aleatorio con bloques de 4 KB (cuatro hilos, profundidad de cola 32 cada uno), cada uno una vez en lectura y otra en escritura.
- Condiciones justas: 5 segundos de calentamiento, 30 segundos de medición,
-Shpara saltarse tanto la caché de archivos de Windows como la caché de escritura de las unidades (si no, estás midiendo la RAM),-Lpara los percentiles de latencia. - Limpieza: después se borran la herramienta y el archivo de prueba, y lo único que queda en el servidor es un volumen libre.
# sequential write, 1 MB blocks
diskspd.exe -b1M -d30 -W5 -o8 -t1 -si -w100 -Sh -L D:\disktest.dat
# random read, 4 KB blocks, 4 threads x QD32
diskspd.exe -b4K -d30 -W5 -o32 -t4 -r -w0 -Sh -L D:\disktest.datUn pequeño script auxiliar en el lado Linux ejecuta cada perfil por WinRM y extrae solo la línea total: y el percentil 99 del informe tan parlanchín de DiskSpd. Y, cómo no, el primer benchmark me mintió, igual que dd en la máquina con ZFS:
Sequential read (1 MB) 20997 MiB/s ← three SATA SSDs. Sure.
Random read (4 KB) 739327 IOPSVeinte gigabytes por segundo con tres unidades SATA que tienen un límite de interfaz combinado de unos 1,6 GB/s. El culpable: la opción -c de DiskSpd vuelve a crear el archivo de prueba en cada ejecución, y ReFS sabe que los rangos que nunca se han escrito solo contienen ceros. Así que responde a esas lecturas a partir de los metadatos, sin tocar jamás un disco. Un benchmark rapidísimo de absolutamente nada. El SSD de Schrödinger: rapidísimo, siempre que nadie mire los datos.
Rellenas el archivo una vez con datos reales, mides sin -c y aparece la realidad:
Profile Throughput IOPS avg latency 99th pct
Sequential read (1 MB) 1169 MiB/s 1169 6.8 ms 24 ms
Random read (4 KB, 4x32) 633 MiB/s 162,109 0.55 ms 7.3 ms
Sequential write (1 MB) 88 MiB/s* 88 90.6 ms 427 ms
Random write (4 KB, 4x32) 1.8 MiB/s 461 276 ms 1095 ms
* up to 163 MiB/s in a separate 60-second runLas lecturas son estupendas. Las escrituras son… paridad. Cada escritura pequeña se convierte en un ciclo de lectura-modificación-escritura de datos más paridad, y sin un nivel de caché write-back en SSD/NVMe, la paridad de Storage Spaces es notoriamente lenta en eso. La columna de latencia cuenta la misma historia: una de cada cien escrituras pequeñas espera más de un segundo. Tiempo de sobra para replantearte tus decisiones vitales. Para un servidor de archivos y destino de copias de seguridad, donde los datos se escriben una vez y se leen a menudo, está bien. Para cualquier cosa con muchas escrituras aleatorias pequeñas, es un no rotundo.
Actualización (6 de octubre de 2026): la paridad era solo la mitad de la historia. El firmware de HPE había desactivado al arrancar la caché de escritura de los tres SSD, y el -Sh de DiskSpd midió exactamente ese estado, que daba la casualidad de que era como funcionaba el servidor a diario. Con la caché activada, una restauración en los mismos discos (ya con Linux) fue unas tres veces más rápida. La historia completa (en inglés): Two Things My SSDs Were Missing: TRIM After BitLocker, and a Write Cache My HPE Server Quietly Switched Off.
(Para ser justos: la medición coincidió con una copia grande en el mismo volumen, así que una nueva medición limpia sigue en mi lista. Pero el patrón está claro).
🧪 Lo siguiente: un hipervisor y mis propios certificados
«Cualquier cosa con muchas escrituras aleatorias pequeñas» es, por supuesto, una descripción educada de las máquinas virtuales. Y eso es justo con lo que quiero trastear a continuación: Hyper-V. Windows Server 2025 ya lo trae de todos modos, y quiero ver qué tal se siente en comparación con el mundo Proxmox que conozco: migración en vivo entre hosts, puntos de control, conmutadores virtuales y virtualización anidada para un laboratorio de pruebas dentro del laboratorio.
El benchmark de arriba ya respondió a una pregunta de diseño antes incluso de empezar. Los discos de las VM no van a ir al pool de paridad. Con ~460 IOPS de escritura aleatoria, una VM de Windows se pasaría la vida mirando un círculo que da vueltas. El círculo de carga como estilo de vida. Así que una configuración de hipervisor como es debido necesita otra distribución del almacenamiento: espejo en lugar de paridad, o NVMe local. Material para el próximo artículo.
El segundo punto de la lista: emitir mis propios certificados. Windows Server trae su propia PKI, los Servicios de certificados de Active Directory. En el lado Linux, cert-manager y Let’s Encrypt se encargan de todo lo que da a internet. Pero internamente hay todo un zoológico que nadie va a firmar nunca públicamente: interfaces web de iLO, RDP, LDAPS en los controladores de dominio y las páginas de administración de dispositivos variados. Cada uno de ellos me recibe ahora mismo con una advertencia de certificado que me he acostumbrado a cerrar con un clic. Ese es exactamente el reflejo que no quieres tener.
El plan es una pequeña CA interna, cuyo certificado raíz se distribuye a cada miembro del dominio mediante (cómo no) una directiva de grupo. Con plantillas de certificado e inscripción automática, las máquinas solicitan y renuevan sus propios certificados, como cert-manager, pero en edición Microsoft. El diseño de manual es una CA raíz sin conexión con una CA emisora por debajo. Está por ver si un homelab necesita de verdad dos niveles o si ese es el momento en que aprender se convierte en cosplay.
🎯 Conclusión
Hace una semana te habría dicho que administrar Windows es ir haciendo clic en asistentes. Resulta que con PowerShell y WinRM se puede automatizar con scripts sorprendentemente bien, y las directivas de grupo son básicamente gestión de configuración con un sistema operativo construido a su alrededor.
Las lecciones del camino fueron las mismas que en Linux: leer la letra pequeña (la conmutación por error de DHCP va por parejas, WSUS está obsoleto), no fiarse del primer benchmark (ReFS y sus ceros) y no reiniciarlo todo a la vez (los controladores de dominio son criaturas sociables).
Dos vías, entonces. Linux sigue llevando lo de producción, y Windows Server puede ser el patio de recreo donde aprendo. ¿Y sinceramente? Después de una semana de YAML, Get-ADReplicationPartnerMetadata me supo a vacaciones. 🏖️
P. D.: Y ahora, si me disculpas, tengo que ir a explicarle a la familia por qué su fondo de escritorio se ha vuelto negro de repente. «Es una directiva» no ha funcionado ni una sola vez como explicación en casa.
