Checklist de instalación limpia de Windows Server 2022: la configuración directa que evita problemas después

Principios: trata la instalación limpia como infraestructura de producción

Una “instalación limpia” no es un lienzo en blanco. Es un conjunto de valores por defecto, muchos elegidos por compatibilidad y no por tu tiempo de actividad. Tu trabajo es sustituir el misterio por intención.

Principio 1: Haz explícitas todas las dependencias

Nombra servidores según su función. Fija DNS. Decide las fuentes NTP. Define la cadencia de parches. Decide la retención de logs. Decide dónde van las copias y cómo pruebas las restauraciones. Si no está escrito y es observable, no existe.

Principio 2: Optimiza al final

Afinar el rendimiento sin datos de referencia es superstición con pasos extra. Consigue primero una compilación estable: controladores correctos, diseño de almacenamiento predecible, registros de eventos limpios y firmware conocido como bueno. Mide luego. Ajusta después.

Principio 3: Si no puedes diagnosticarlo en 10 minutos, lo construiste mal

En los primeros diez minutos de un incidente de producción deberías poder responder: qué cambió, qué está saturado y qué falla. Eso requiere trabajo previo: tamaños de logs, contadores, configuración de volcados de memoria y unos cuantos comandos estándar que todos usan.

Una cita para llevar en el bolsillo: “La esperanza no es una estrategia.” — General Gordon R. Sullivan. En operaciones, la esperanza es lo que haces cuando te saltaste la lista de verificación.

Hechos interesantes y contexto histórico (por qué Windows es como es)

• Journaling de NTFS se remonta a la era Windows NT; por eso Windows a menudo sobrevive mejor a pérdidas de energía que sistemas de archivos más antiguos, pero journaling no equivale a consistencia de aplicación.
• Windows Server Core existe porque los componentes GUI añaden superficie de parcheo y frecuencia de reinicios. Core ganó adopción seria cuando los administradores entendieron que “menos instalado” suele significar “menos roto”.
• Sensibilidad temporal de Active Directory es un legado que no desaparecerá: los tickets Kerberos tienen límite de tiempo, así que la sincronización horaria descuidada se convierte en “fallos de autenticación misteriosos”.
• La reputación de SMB mejoró mucho entre versiones; SMB 3.x trajo cifrado y mejor rendimiento que el antiguo estereotipo de “compartir archivos = lento”.
• Windows Firewall antes se trataba como una molestia de cliente. Ahora es un control de primera línea en el endurecimiento del servidor y se integra bien con políticas a escala.
• ReFS fue diseñado para manejar integridad de datos y volúmenes grandes, pero su matriz de compatibilidad (características, arranque, combinaciones con deduplicación) siempre ha sido más “política empresarial” que “vale todo”.
• Registro de eventos se volvió más estructurado con el tiempo, pero los tamaños por defecto siguen reflejando un mundo optimista donde las interrupciones son breves y los auditores indulgentes.
• UEFI y GPT no son sólo moda moderna. Reducen la probabilidad de acabar con limitaciones de arranque extrañas y diseños de particiones frágiles heredados de la era BIOS/MBR.

Decisiones previas a la instalación que no puedes “arreglar después”

Elige la edición y el modo de instalación correctos

Usa Server Core a menos que tengas un requisito imprescindible de componentes GUI (algunos agentes de proveedores, flujos de trabajo MMC heredados o roles específicos). Core reduce parches y superficie de ataque. Si tu organización no está lista, bien: instala Desktop Experience pero trátalo como deuda técnica temporal.

Decide: ¿unir al dominio ahora o después?

Unirse después a veces es más seguro cuando todavía estás construyendo almacenamiento/red y no quieres que Group Policy te estorbe. Pero unirse temprano puede imponer controles de seguridad básicos y darte gestión centralizada. Ambas son válidas; sólo no te “unan por accidente” y luego te preguntes por qué las configuraciones locales se siguen revirtiendo.

Plan de almacenamiento: disco SO vs disco de datos, y qué estás optimizando

Separa el SO de los datos. Siempre. Mantén el volumen del SO aburrido: tamaño predecible, suficiente espacio libre para actualizaciones y volcados, sin datos de aplicaciones. Pon los datos en volúmenes dedicados con etiquetas que digan la verdad (no “New Volume”). Si usas Storage Spaces, decide espejo vs paridad según el perfil I/O y las expectativas de reconstrucción, no por intuiciones.

Plan de red: IPs, DNS y reglas de enrutamiento

Escribe la IP prevista, gateway, servidores DNS y si este equipo debe registrarse en DNS. Decide si usas NIC teaming (y qué modo). Decide si haces etiquetado VLAN en el hipervisor o en el SO. Un servidor con dos gateways “útiles” por defecto es una carrera de soporte en una caja.

Estrategia de parches: WSUS, Windows Update for Business o manual

Decide quién se encarga de los parches y cuándo. Si es “lo haremos cuando tengamos tiempo”, en realidad estás decidiendo parchear durante un incidente. Elige una cadencia, define ventanas de mantenimiento y crea un plan de reversión.

Broma #1: El nombre por defecto del servidor es como dejar tu equipaje en el aeropuerto etiquetado “bag”. Viajará, sólo que no donde tú querías.

Listas de verificación / plan paso a paso (de cero a listo)

Fase 0: saneamiento de firmware y plataforma

• Actualiza BIOS/UEFI, firmware del controlador de almacenamiento, firmware de NIC y el equivalente a iDRAC/iLO antes de la instalación del SO cuando sea práctico.
• Activa arranque UEFI y confirma el plan de particionado GPT.
• Confirma ajustes de virtualización si aplica (VT-x/AMD-V, SR-IOV si es necesario).

Fase 1: Instalación e inmediatamente después

• Instala Windows Server 2022 (Core si es posible), elige la edición correcta y establece una contraseña local de administrador fuerte.
• Configura el nombre del host, IP, DNS y estrategia de sincronización horaria.
• Instala controladores del proveedor de forma intencional (NIC/almacenamiento), no “lo que Windows encontró”.
• Ejecuta Windows Update y reinicia hasta quedar limpio.

Fase 2: Configuración base

• Configura una base de políticas de Windows Firewall; permite sólo lo necesario.
• Establece la política de volcados (crash dump) y el tamaño del archivo de paginación para poder depurar pantallazos azules luego.
• Redimensiona los logs de eventos y ajusta el comportamiento de retención.
• Activa la gestión remota correctamente (WinRM, PowerShell remoting) con alcance auditable.

Fase 3: Almacenamiento y ruta de datos

• Inicializa y formatea discos de datos con etiquetas y tamaños de unidad de asignación adecuados al trabajo.
• Configura Storage Spaces/RAID con tolerancia a fallos documentada; prueba una falla si puedes (extrae un disco en laboratorio).
• Valida la política de caché de escritura y la protección eléctrica (BBU/caché con flash).

Fase 4: Prueba de copias de seguridad y restauración

• Instala el agente de backup, define trabajos y confirma copias con conocimiento de la aplicación donde sea necesario.
• Prueba la restauración de al menos un archivo y una ruta de recuperación de estado del sistema/aplicación.
• Documenta RPO/RTO en lenguaje llano.

Fase 5: Monitorización y ganchos operativos

• Instala agentes de monitorización, confirma cobertura de métricas/alertas (CPU, memoria, latencia de disco, errores de NIC, salud de servicios).
• Confirma reenvío de logs de eventos o ingestión en SIEM.
• Establece un “paquete estándar de evidencia” para incidentes.

Tareas de validación prácticas (comandos, salidas y decisiones)

Estos son los comandos que ejecutas el día uno y otra vez durante incidentes. Cada uno incluye lo que significa la salida y qué decides después. Ejecútalos en un PowerShell elevado salvo que se indique lo contrario.

Tarea 1: Confirma versión del SO, build y tipo de instalación

cr0x@server:~$ powershell -NoProfile -Command "Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber, CsName"
WindowsProductName : Windows Server 2022 Standard
WindowsVersion     : 21H2
OsBuildNumber      : 20348
CsName             : FS-PRD-01

Qué significa: Verificas que realmente instalaste lo que crees que instalaste (y lo que tu licenciamiento y baselines asumen).

Decisión: Si la edición/versión es incorrecta, para ahora y arréglalo. No construyas producción sobre “casi suficiente”.

Tarea 2: Verifica estado de reinicio pendiente (antes de culpar a “comportamiento aleatorio”)

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending' -ErrorAction SilentlyContinue | Out-String"

Qué significa: Si esto devuelve contenido (existe la clave), Windows suele estar a mitad de mantenimiento. Algunos roles/controladores se comportan de forma extraña hasta el reinicio.

Decisión: Si hay reinicio pendiente, prográmalo ahora—antes de “seguir configurando” y crear un estado a medio aplicar.

Tarea 3: Comprueba el nombre del host, unión al dominio y estado del canal seguro

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_ComputerSystem | Select-Object Name, Domain, PartOfDomain"
Name         Domain          PartOfDomain
----         ------          ------------
FS-PRD-01    corp.example    True

cr0x@server:~$ powershell -NoProfile -Command "Test-ComputerSecureChannel -Verbose"
True

Qué significa: El estado de unión al dominio es correcto y la confianza de la cuenta máquina está intacta.

Decisión: Si Test-ComputerSecureChannel falla, arregla la confianza (a menudo tiempo/DNS) antes de instalar servicios dependientes del dominio.

Tarea 4: Confirma configuración IP, servidores DNS y trampas de “múltiples gateways”

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPConfiguration | Format-List InterfaceAlias,IPv4Address,IPv4DefaultGateway,DNSServer"
InterfaceAlias    : Ethernet0
IPv4Address       : 10.20.30.40
IPv4DefaultGateway: 10.20.30.1
DNSServer         : {10.20.0.10, 10.20.0.11}

Qué significa: Tienes un gateway por defecto (bien), y DNS apunta a resolutores internos (habitual en servidores unidos a dominio).

Decisión: Si ves múltiples gateways por defecto en varias NIC, elimínalos y usa rutas estáticas si realmente es necesario.

Tarea 5: Valida resolución DNS y registro

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName -Name corp.example -Type A"
Name      Type TTL Section IPAddress
----      ---- --- ------- ---------
corp.example A   600 Answer  10.20.0.20

cr0x@server:~$ powershell -NoProfile -Command "ipconfig /registerdns"
Windows IP Configuration

Registration of the DNS resource records for all adapters of this computer has been initiated. Any errors will be reported in the Event Viewer in 15 minutes.

Qué significa: DNS básico funciona y el servidor puede registrar sus registros (crítico para muchos flujos de trabajo Windows).

Decisión: Si aparecen errores de registro en eventos del Cliente DNS, arregla permisos/configuración de depuración y confirma sufijos DNS correctos.

Tarea 6: Confirma fuente de sincronización horaria y desfase (Kerberos lo necesita)

cr0x@server:~$ powershell -NoProfile -Command "w32tm /query /status"
Leap Indicator: 0(no warning)
Stratum: 3 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Last Successful Sync Time: 2/5/2026 9:12:14 AM
Source: DC01.corp.example
Poll Interval: 6 (64s)

Qué significa: Estás sincronizando tiempo desde un controlador de dominio (comportamiento típico). El stratum indica el nivel de calidad.

Decisión: Si la Source es Local CMOS Clock o el desfase es grande, arregla el tiempo antes de que los problemas de autenticación de dominio aparezcan como “aleatorios”.

Tarea 7: Comprueba estado de Windows Update y hotfixes instalados

cr0x@server:~$ powershell -NoProfile -Command "Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5 HotFixID, InstalledOn"
HotFixID  InstalledOn
--------  -----------
KB503xxxx 1/28/2026 12:00:00 AM
KB503yyyy 1/14/2026 12:00:00 AM
KB503zzzz 12/10/2025 12:00:00 AM

Qué significa: Puedes probar el nivel de parches rápidamente. Esto importa cuando proveedores preguntan: “¿Están al día?”.

Decisión: Si el último parche es antiguo, deja de tratar esta máquina como “nueva” y trátala como “ya atrasada”. Parchea y reinicia hasta estabilidad.

Tarea 8: Verifica perfil de firewall y reglas efectivas

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction"
Name    Enabled DefaultInboundAction DefaultOutboundAction
----    ------- -------------------- ---------------------
Domain  True    Block                Allow
Private True    Block                Allow
Public  True    Block                Allow

Qué significa: El inbound por defecto está bloqueado (bien). Outbound allow es común; puedes endurecerlo más tarde con proxy o listas de permitidos.

Decisión: Si el perfil Público está activo en una NIC de servidor, corrige la clasificación de red o perseguirás “¿por qué este puerto no escucha?” problemas.

Tarea 9: Confirma que servicios críticos están configurados correctamente (y no ejecutándose por accidente)

cr0x@server:~$ powershell -NoProfile -Command "Get-Service | Where-Object {$_.Status -eq 'Running'} | Select-Object -First 10 Name, DisplayName, StartType"
Name    DisplayName                         StartType
----    -----------                         ---------
Dnscache DNS Client                         Automatic
LanmanServer Server                         Automatic
EventLog Windows Event Log                  Automatic
WinRM    Windows Remote Management (WS-Management) Automatic

Qué significa: Buscas “servicios sorpresa” (agentes de terceros, protocolos heredados, actualizadores de proveedores aleatorios).

Decisión: Si ves un servicio que no aprobaste, identifica la fuente del instalador y elimínalo/desactívalo antes de que se convierta en una responsabilidad sin parches.

Tarea 10: Inspecciona diseño de discos, estilo de partición y espacio libre

cr0x@server:~$ powershell -NoProfile -Command "Get-Disk | Select-Object Number, FriendlyName, PartitionStyle, Size, OperationalStatus"
Number FriendlyName          PartitionStyle Size         OperationalStatus
------ ------------          -------------- ----         -----------------
0      NVMe RAID Controller  GPT            476.94 GB    Online
1      DataDisk01            GPT            3.64 TB      Online

cr0x@server:~$ powershell -NoProfile -Command "Get-Volume | Select-Object DriveLetter, FileSystemLabel, FileSystem, SizeRemaining, Size"
DriveLetter FileSystemLabel FileSystem SizeRemaining Size
----------- -------------- --------- ------------- ----
C           OS             NTFS      120.45 GB     200 GB
D           DATA           NTFS      2.10 TB       3.64 TB

Qué significa: GPT está en uso (bien). Tienes etiquetado claro y suficiente espacio libre.

Decisión: Si C: es pequeño, arréglalo ahora. Windows Update, el componente store y los volcados castigarán el “minimalismo”.

Tarea 11: Comprueba ajustes de integridad del sistema de archivos y ejecuta un escaneo rápido

cr0x@server:~$ powershell -NoProfile -Command "Repair-Volume -DriveLetter C -Scan -Verbose"
VERBOSE: The volume was scanned and no problems were found.

Qué significa: Confirmas que el volumen no comienza su vida con corrupción o rarezas de almacenamiento subyacente.

Decisión: Si aparecen errores, deja de instalar aplicaciones e investiga almacenamiento/firmware/controladores inmediatamente.

Tarea 12: Valida rápidamente contadores de rendimiento de almacenamiento (la latencia dice la verdad)

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\LogicalDisk(D:)\Avg. Disk sec/Read','\LogicalDisk(D:)\Avg. Disk sec/Write' -SampleInterval 1 -MaxSamples 5 | Select-Object -ExpandProperty CounterSamples | Select-Object Path, CookedValue"
Path                                          CookedValue
----                                          -----------
\\FS-PRD-01\logicaldisk(D:)\avg. disk sec/read 0.0021
\\FS-PRD-01\logicaldisk(D:)\avg. disk sec/write 0.0045

Qué significa: La latencia es baja (milisegundos). Para muchas cargas, lecturas/escrituras sostenidas por encima de ~20–30ms es donde empieza el dolor.

Decisión: Si la latencia es alta en reposo, sospecha controladores, política de caché, RAID mal configurado o problemas del SAN subyacente.

Tarea 13: Confirma soporte TRIM para volúmenes con SSD

cr0x@server:~$ powershell -NoProfile -Command "fsutil behavior query DisableDeleteNotify"
NTFS DisableDeleteNotify = 0  (Disabled)
ReFS DisableDeleteNotify = 0  (Disabled)

Qué significa: “0” significa que las notificaciones de borrado (TRIM/UNMAP) están habilitadas, lo que ayuda a la longevidad y rendimiento de SSD en muchas pilas.

Decisión: Si está habilitado pero tu backend de almacenamiento no maneja bien UNMAP (algunos SANs aprovisionados dinámicamente), valida con el equipo de almacenamiento antes de cambiar ajustes a ciegas.

Tarea 14: Confirma versiones de controladores para NIC y controlador de almacenamiento

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class Net | Where-Object {$_.Status -eq 'OK'} | Select-Object -First 3 FriendlyName, InstanceId"
FriendlyName                    InstanceId
------------                    ----------
Intel(R) Ethernet Server Adapter PCI\VEN_8086&DEV_1592&SUBSYS...

cr0x@server:~$ powershell -NoProfile -Command "Get-WmiObject Win32_PnPSignedDriver | Where-Object {$_.DeviceName -like '*Ethernet*'} | Select-Object -First 1 DeviceName, DriverVersion, DriverDate"
DeviceName                               DriverVersion DriverDate
----------                               ------------ ----------
Intel(R) Ethernet Server Adapter         2.1.3.0       2024-11-02

Qué significa: Puedes probar la procedencia y edad del controlador.

Decisión: Si estás con drivers incluidos en la caja para hardware crítico en producción, considera drivers del proveedor. Pero no “actualices” durante un incidente sin un plan de reversión.

Tarea 15: Comprueba tamaños de logs de eventos y retención (porque los valores por defecto son mezquinos)

cr0x@server:~$ powershell -NoProfile -Command "wevtutil gl System | findstr /i \"maxSize retention\""
maxSize: 20971520
retention: false

Qué significa: 20MB es pequeño en la vida real. Retention false significa sobrescribir cuando sea necesario.

Decisión: Aumenta tamaños y/o reenvía logs. Si no lo haces, perderás la evidencia antes de abrir el Visor de Eventos.

Tarea 16: Confirma configuración de volcados de memoria (el seguro de “no podemos reproducirlo”)

cr0x@server:~$ powershell -NoProfile -Command "wmic recoveros get DebugInfoType, MinidumpDirectory, OverwriteExistingDebugFile"
DebugInfoType  MinidumpDirectory           OverwriteExistingDebugFile
7              %SystemRoot%\Minidump       TRUE

Qué significa: DebugInfoType 7 típicamente indica volcado de memoria automático. La ubicación de minidumps está definida.

Decisión: Asegura suficiente espacio libre y que los volcados los recollecta tu herramienta. Si no puedes capturar volcados, no podrás hacer post-mortems correctamente.

Configuración de almacenamiento que no te fallará

Volumen del SO: mantenlo limpio, dimensionado y aburrido

Da espacio a C:. No “lo justo”. Espacio. El componente store de Windows crece, los rollups de parches se expanden y contraen, y los volcados necesitan espacio. Si eres virtual, el aprovisionamiento fino puede ayudar—hasta que no. En cualquier caso, monitoriza espacio libre y configura alertas.

Volúmenes de datos: etiqueta, separa y elige el tamaño de unidad de asignación con intención

La mayoría de cargas en Windows funcionan con los tamaños de asignación NTFS por defecto, pero no todas. Bases de datos y sistemas de alto rendimiento pueden beneficiarse de clusters mayores; eso es una decisión de carga. No copies “clusters de 64K” porque alguien lo dijo en una conferencia.

Para servidores de archivos, considera cómo harás cuotas, deduplicación y políticas de escaneo antivirus. Para SQL, alinea con la guía del proveedor y mide. Para almacenamiento de máquinas virtuales, presta atención a patrones de escritura aleatoria y churn de metadatos.

Storage Spaces vs RAID por hardware vs LUNs SAN

RAID por hardware da comportamiento predecible, pero debes validar la política de caché y la protección por batería/flash. Storage Spaces puede ser excelente, pero es sensible a la configuración: columnas, interleave, resiliencia y awareness de gabinete importan. LUNs SAN desplazan la complejidad al array—genial cuando el equipo del array es bueno, peligroso cuando “alguien más” controla la verdad.

Caché de escritura: la forma más rápida de perder datos y la más rápida de mejorar benchmarks

Caché de escritura sin protección ante pérdida de energía es una apuesta contra la física. A veces te sale bien. Otras no. Decide qué historia quieres contar en la revisión post-incidente.

Elección de sistema de archivos: NTFS vs ReFS (y cuándo no ponerse creativo)

NTFS sigue siendo el predeterminado por una razón: compatibilidad amplia, soporte de arranque y herramientas maduras. ReFS tiene ventajas en escenarios de integridad y ciertas pilas de virtualización, pero su matriz de características puede sorprender según SKU y rol. Si no puedes explicar por qué eliges ReFS, elige NTFS y sigue adelante.

Redes: haz lo aburrido a propósito

Un gateway por defecto por host (casi siempre)

Si necesitas múltiples redes, usa VLANs y enrutamiento correctamente. Múltiples gateways por defecto hacen que el tráfico elija el caos. Si necesitas diferentes rutas de salida, usa rutas estáticas con métricas y documentación.

NIC teaming: hazlo con intención

El teaming puede mejorar resiliencia, pero también añade una capa que falla de formas nuevas y emocionantes. Si haces teaming, documenta el modo (independiente del switch vs LACP), hashing y dónde vive el etiquetado VLAN. Luego prueba la falla: desconecta un cable y observa el tráfico.

Configuración DNS: no te “ayudes” hacia un split-brain

Los servidores unidos al dominio deben usar DNS internos. Resolutores públicos en un miembro de dominio son una fuente clásica de rarezas (búsquedas SRV fallando, zonas integradas en AD ignoradas, resolución intermitente). Si necesitas resolución a Internet, configura reenvío en tu infraestructura DNS, no resolutores aleatorios.

Identidad, tiempo y cadenas de confianza

Sincronización horaria: decide quién es autoritativo

En un dominio, la jerarquía de tiempo importa. Los miembros deben sincronizar con los DCs. Los DCs deben sincronizar con una fuente de tiempo fiable. Los DCs virtualizados añaden diversión extra si la sincronización del hipervisor pelea con la del sistema Windows.

Certificados: planifica si terminas TLS localmente

Si el servidor aloja endpoints HTTPS (IIS, WinRM sobre HTTPS, servicios personalizados), decide tu estrategia de certificados temprano. PKI interna? CA pública? ¿Cómo renuevas automáticamente? Certificados expirados son la interrupción que llega con una invitación de calendario que ignoraste.

Administrador local: sólo para casos extremos y monitorizado

Tener una cuenta de administrador local para recuperación, pero no la uses en el día a día. Aplica mínimo privilegio y acceso justo a tiempo si tu organización puede gestionarlo. Si no, por lo menos haz que el uso del admin local sea ruidoso en logs.

Base de seguridad: cierra las puertas sin encerrarte

Empieza con menos roles y características

Instala sólo lo necesario. Cada rol añade superficie de parches, servicios y posibles malas configuraciones. Si no estás seguro, no lo instales aún. Siempre puedes añadir funciones. Quitarlas después es donde viven las sorpresas.

Firewall: allow-list entrante y documenta excepciones

Configura inbound por defecto a bloquear (como se mostró antes) y crea reglas explícitas para los servicios requeridos. Nombra las reglas de forma humana: “Allow SMB from FileServerSubnet”, no “New Rule 47”. Mantén el scope ajustado: IPs/subredes de origen, perfiles y puertos.

Gestión remota: WinRM está bien; WinRM sin gestionar no

Activa PowerShell remoting para operaciones, pero restringe quién puede usarlo. Considera listeners HTTPS donde proceda. Si expones WinRM ampliamente sin controles, estás donando superficie de ataque.

Higiene SMB: deshabilita lo que no necesites

SMBv1 debe estar muerto. Si un proveedor todavía lo necesita, la solución real es: reemplazar a ese proveedor. Si no puedes aún, aisla ese sistema y documenta el riesgo por escrito.

Broma #2: SMBv1 es como un fax: a veces aún funciona, y eso es exactamente por lo que da miedo.

Registro, telemetría y preservación de evidencia

Redimensiona los logs de eventos ahora, no durante el apagón

Los tamaños por defecto de los logs de eventos están ajustados para “un administrador ocasional revisa el Visor de Eventos”, no para respuesta real a incidentes. Aumenta System, Application, Security y cualquier log de rol específico (DNS Server, DFSR, Hyper-V, Failover Clustering, etc.).

Reenvía logs fuera de la máquina

Los logs locales son frágiles. Los atacantes los borran, los discos se llenan y la rotación sobrescribe. Reenvía a un colector central/SIEM. Si no tienes uno, al menos reenvía logs críticos a un Windows Event Collector. Cuando el servidor esté ardiendo, quieres evidencia en otro lugar.

Mide contadores de rendimiento base

Como mínimo, monitoriza CPU, memoria, latencia de disco, longitud de cola de disco (con contexto), errores/caídas de red y salud de servicios clave. La latencia vence a la utilización como predictor de dolor: un disco al 20% ocupado aún puede estar bloqueando tu app si los patrones de I/O son patológicos.

Copias de seguridad y recuperación: hazlo real

Copias sin pruebas de restauración son sólo sentimientos caros

Ejecuta una prueba de restauración temprano. No meses después con el “lo programaremos”. Restaura un archivo. Restaura una configuración. Restaura un objeto de aplicación si procede. Confirma que los permisos sobreviven. Confirma que puedes acceder al almacenamiento de backup durante un incidente (credenciales, rutas de red, reglas de firewall).

Define RPO y RTO en términos claros

¿Qué datos puedes perder (RPO)? ¿Cuánto tiempo puede estar caída la oferta (RTO)? Si no puedes responder, no tienes una estrategia de backup; tienes un hobby de backups.

Protege las copias de seguridad desde el servidor

La separación de credenciales importa. Si un ransomware toma el servidor, no debería apoderarse automáticamente de las copias. Usa cuentas separadas, almacenamiento inmutable cuando sea posible y segmentación de red que refleje la realidad.

Guion de diagnóstico rápido (encuentra el cuello de botella rápido)

Este es el “taladro de diez minutos”. Úsalo cuando usuarios reporten lentitud, errores o timeouts. No empieces reinstalando cosas. Empieza observando.

Primero: confirma el radio de impacto y qué cambió

• ¿Es un servidor o varios?
• ¿Es un rol (compartir archivos, web, AD, SQL) o todo?
• ¿Algún parche, reinicio, actualización de controladores, cambio de políticas, renovación de certificados?

Segundo: comprueba las cuatro saturaciones comunes (CPU, memoria, latencia de disco, red)

• CPU: uso sostenido alto, colas de ready largas en entornos virtuales.
• Memoria: poca memoria disponible, paginación intensa, trimming del working set.
• Disco: picos de latencia, acumulación de colas, errores de controlador.
• Red: caídas/errores, mismatch de duplex, problemas DNS, bucles de enrutamiento.

Tercero: valida resolución de nombres y tiempo

DNS y tiempo suplantan constantemente fallos de aplicación. Si la autenticación o el descubrimiento de servicios es raro, revisa Resolve-DnsName y w32tm temprano.

Cuarto: lee los logs de eventos como un adulto

Busca resets de controladora/disco, advertencias NTFS, conmutaciones por clustering, fallos de servicios y errores de auditoría de seguridad. No pases por encima. Filtra por el rango temporal alrededor del inicio reportado.

Quinto: aisla: ¿es el host, la VM o la dependencia?

Si estás virtualizado, compara contadores del invitado con métricas del host. Si el almacenamiento es compartido, comprueba si otros sistemas ven latencia. Si es una dependencia (AD/DNS/SAN), deja de tratarlo como un problema de un único servidor.

Errores comunes: síntomas → causa raíz → solución

1) “Todo está lento después de instalar”

Síntomas: Alta latencia, congelamientos esporádicos, servicios con timeouts, pero la CPU parece normal.

Causa raíz: Driver/controlador de almacenamiento usando un driver inbox genérico, caché de escritura mal configurada o RAID inicializándose en segundo plano con rendimiento degradado.

Solución: Instala drivers/herramientas del proveedor de almacenamiento, verifica caché + BBU/flash, confirma estado de inicialización del RAID, mide contadores de latencia y revisa logs del controlador.

2) “La unión al dominio funciona, pero la autenticación es inestable”

Síntomas: Errores Kerberos, RDP denegado, GPO inconsistente, Test-ComputerSecureChannel falla intermitentemente.

Causa raíz: Deriva de tiempo o mala configuración DNS (DNS público en un miembro de dominio, lista de sufijos equivocada o registros obsoletos).

Solución: Corrige servidores DNS a internos, ejecuta w32tm /resync, valida jerarquía de tiempo de DCs, limpia y registra de nuevo registros DNS.

3) “Puertos estaban abiertos ayer, hoy bloqueados”

Síntomas: La app funciona en una red pero no en otra; el firewall parece inconsistente.

Causa raíz: El perfil de red cambió (Domain vs Public) por NLA/alcanzabilidad DNS; reglas de firewall limitadas al perfil Domain solamente.

Solución: Restaura la detección de red de dominio (alcanzabilidad DNS/DC), ajusta el scope de las reglas y evita reglas que sólo funcionen en condiciones perfectas.

4) “El espacio en C: desaparece”

Síntomas: C: se llena inesperadamente, fallan actualizaciones, el servidor se vuelve inestable.

Causa raíz: Crecimiento del component store, logs/volcados, archivos temporales o aplicaciones escribiendo en el volumen del SO porque no se cambiaron los valores por defecto.

Solución: Mueve datos/logs de aplicaciones a un volumen de datos, redimensiona C: si es necesario, implementa rotación/reenvío de logs y configura alertas de umbrales de espacio libre.

5) “Las copias pasan pero las restauraciones fallan”

Síntomas: Trabajo de backup en verde, pero errores en restauración o datos incompletos al restaurar.

Causa raíz: Credenciales/permisos no validados, ajustes VSS/application-aware incorrectos o repositorio de backup inaccesible en condiciones de incidente.

Solución: Realiza pruebas de restauración, valida escritores VSS, asegura acceso al repositorio con credenciales separadas y documenta el runbook de restauración.

6) “No tenemos logs de la ventana del incidente”

Síntomas: El Visor de Eventos no muestra nada útil; Security log se sobreescribió; huecos en telemetría.

Causa raíz: Tamaños de logs por defecto, comportamiento de sobrescritura y falta de reenvío.

Solución: Aumenta tamaños de logs, reenvía centralmente y añade alertas cuando los logs se acerquen a capacidad o el reenvío falle.

Tres micro-historias del mundo corporativo (lo que realmente pasa)

Micro-historia 1: Un incidente causado por una suposición errónea

Construyeron una nueva VM Windows Server 2022 para hospedar una pequeña app web interna. El ingeniero asumió, razonablemente, que “DNS está bien” porque la VM resolvía dominios públicos. La app salió a producción y de inmediato empezó a tener timeouts al intentar autenticar usuarios.

El equipo persiguió logs de aplicación, luego configuraciones de IIS, luego reescribió una parte de la configuración. Nada funcionó. Era intermitente, que es el tipo de fallo más caro.

Eventualmente alguien ejecutó Resolve-DnsName para los registros SRV del dominio y obtuvo basura. La VM había sido apuntada a un resolutor público “temporalmente” durante la construcción. DNS público no responde los registros de servicio internos de AD. Kerberos caía en fallback, luego fallaba, luego tenía éxito según la caché y la ruta de código ejecutada.

La solución fue dolorosamente simple: poner DNS a los resolutores de dominio, vaciar cachés, registrar de nuevo, confirmar sincronización horaria y la app volvió a ser aburrida. La lección del postmortem no fue “DNS importa”. Fue “prueba dependencias con comandos, no con suposiciones”.

Micro-historia 2: Una optimización que salió mal

Una migración de servidor de archivos iba con retraso. Para acelerar, alguien activó caché de escritura agresiva y un puñado de “ajustes de rendimiento” recomendados en un post de 2016. Los benchmarks fueron fantásticos. Todos relajaron.

Dos semanas después, hubo un pequeño evento de energía en el rack. No un apagón dramático—sólo lo suficiente para rebotar una PDU. Los servidores volvieron. El servidor de archivos también, pero los usuarios empezaron a reportar archivos corruptos y “documentos que no abren”.

La caché del controlador de almacenamiento no tenía protección adecuada ante pérdida de energía configurada. La configuración era posible, pero el módulo de batería estaba degradado y se ignoraron las alarmas porque “sigue funcionando”. La caché de escritura se convirtió en un acelerador de corrupción de datos.

La recuperación tomó días de restauraciones y conversaciones incómodas. El equipo aprendió una verdad aburrida: el rendimiento es una característica sólo cuando la integridad está garantizada. Si no puedes explicar el modo de fallo de un cambio de tuning, no lo uses en producción.

Micro-historia 3: Una práctica aburrida pero correcta que salvó el día

Un host Windows Server 2022 que ejecutaba un servicio crítico hizo blue-screen dos veces en una semana. El proveedor pidió archivos de volcado y logs de eventos. Históricamente, aquí la historia termina con “no podemos reproducirlo” y una larga espera.

Pero este equipo tenía una política poco emocionante: logs dimensionados, volcados habilitados y un agente que enviaba evidencia fuera de la máquina. También tenían un paquete estándar de incidente: build del SO, versiones de drivers, actualizaciones recientes y eventos del controlador de almacenamiento.

Cuando llegó el tercer crash, ya tenían los volcados y el historial de drivers. El patrón coincidía con una versión específica de driver de NIC y un problema conocido que se activaba bajo carga. Revertir el driver y programar una actualización probada lo resolvió.

Sin heroísmos. Sin conjeturas. Solo la preparación que parece innecesaria hasta que te salva la semana.

Preguntas frecuentes

1) ¿Debo instalar Server Core o Desktop Experience?

Instala Server Core a menos que tengas un bloqueo concreto. Core reduce la superficie de parches y elimina mucha entropía guiada por GUI. Si tus operaciones dependen de herramientas GUI, usa Desktop Experience pero planea estandarizar y automatizar para reducir esa dependencia.

2) ¿Qué tamaño debería tener la unidad C:?

Suficiente para no pensar en ella durante parches o un crash. En la práctica: asigna margen significativo para actualizaciones, crecimiento del component store, logs y volcados. Si eres virtual, puedes crecer después, pero el “después” suele llegar en medio de un incidente.

3) ¿NTFS o ReFS para volúmenes de datos?

Prefiere NTFS salvo que puedas justificar ReFS para tu rol específico y hayas validado soporte de características. ReFS puede ser excelente en algunos escenarios de virtualización e integridad, pero no es una mejora universal.

4) ¿Necesito instalar controladores del proveedor o los de Windows son suficientes?

Para producción, considera seriamente controladores/firmware del proveedor para NIC y almacenamiento, especialmente en servidores físicos. Los drivers inbox están diseñados para compatibilidad amplia, no necesariamente mejor rendimiento o ritmo de corrección de errores para tu hardware.

5) ¿Cuál es la forma más rápida de saber si el almacenamiento es mi cuello de botella?

Comprueba contadores de latencia de disco (Avg. Disk sec/Read y Write), luego correlaciónalos con logs de controlador para resets y con timeouts de aplicación. Alta latencia con CPU normal es una firma clásica.

6) ¿Por qué la sincronización horaria está en la checklist? ¿No es automática?

Es automática hasta que no lo es. La deriva rompe Kerberos y hace los logs poco fiables. En entornos virtuales, la sincronización del hipervisor puede pelear con el tiempo de Windows. Verifica la fuente real y la última sincronización.

7) ¿Cómo dimensiono los logs de eventos?

Hazlos para respuesta a incidentes, no por estética. Si tu Security log se sobrescribe en horas durante un periodo ocupado, es demasiado pequeño. Si reenvías logs centralmente, aún puedes mantener logs locales lo bastante grandes para cubrir periodos de caída del reenvío.

8) ¿Cuál es la prueba mínima de backup tras instalar?

Restaura un archivo y valida que se abre. Si el servidor aloja una app, realiza una prueba de restauración consistente con la aplicación (o al menos valida que los escritores VSS están sanos) y confirma que permisos y metadatos sobreviven.

9) ¿Debo deshabilitar tráfico saliente en Windows Firewall?

No el primer día a menos que tengas la madurez de proceso para gestionarlo. Bloquear salidas puede ser un excelente control, pero requiere listas de permitidos disciplinadas y habilidades de troubleshooting. Empieza con allow-listing de entrada y añade controles de salida deliberadamente.

10) ¿Cómo evito “deriva de configuración misteriosa” después de instalar?

Únete al dominio con baselines GPO intencionales, gestiona configuración con automatización cuando sea posible y guarda un registro de roles/características instaladas y agentes aprobados. La deriva ocurre cuando nadie posee “el estándar”.

Conclusión: próximos pasos que te agradecerás

Después de una instalación limpia, tu objetivo no es “arranca”. Tu objetivo es “es diagnosable, parcheable, recuperable y aburrido”. Esa es la definición real de estable.

Haz lo siguiente:

1. Ejecuta las tareas de validación arriba y guarda las salidas como evidencia base.
2. Redimensiona los logs de eventos y verifica el reenvío fuera del servidor.
3. Prueba las copias restaurando algo real.
4. Configura monitorización para latencia de disco, espacio libre y salud de servicios antes de que los usuarios encuentren problemas por ti.
5. Documenta el estado final: configuración de red, diseño de almacenamiento, nivel de parches y cualquier desviación del estándar.

Si haces este trabajo ahora, el próximo incidente no se sentirá como arqueología. Se sentirá como operaciones: observa, decide, arregla y sigue adelante.