Instalación profesional de Windows Server 2025: Roles, actualizaciones y endurecimiento en 60 minutos

Reglas básicas para una instalación profesional de 60 minutos

Una instalación “profesional” no es un conjunto mágico de cambios en el registro. Es una secuencia que evita que cometas errores irreversibles
(diseño de disco equivocado, edición incorrecta, identidad incorrecta, colocación indebida de roles) y te deja con un servidor que puedes razonar.

Regla 1: Decide para qué sirve esta máquina y para qué no

Un servidor, un trabajo—al menos al principio. Controlador de dominio más servidor de archivos más SQL más “ah, también es servidor de impresión” es la forma en que
conviertes el mantenimiento en una negociación con rehenes. Elige la carga de trabajo primaria y construye en torno a ella.

Regla 2: Trata los valores por defecto como “temporales”, no como “buenos”

Los valores por defecto están optimizados para “arranca con éxito para todo el mundo”, no para “sobrevive en tu entorno”. Tu postura de seguridad, cadencia de actualizaciones
y perfil de almacenamiento son tu responsabilidad. Microsoft te da una línea de partida, no una meta final.

Regla 3: Si no puedes reconstruirlo, no lo posees

Toma notas mientras avanzas. Mejor: scriptealo. Pero incluso una lista de verificación estricta vence a “recuerdo haber hecho clic en algo”. El día que necesitas reconstruir
rápido es el día en que tu memoria se convierte en folklore.

Idea parafraseada atribuida a Werner Vogels: “Todo falla; diseña para que el sistema pueda continuar y recuperarse rápidamente.”
Esa mentalidad aplica a servidores Windows tanto como a flotas de microservicios.

Hechos y contexto interesantes (lo que explica los valores por defecto actuales)

• Server Core no es nuevo. Microsoft lo introdujo en la era de Windows Server 2008 para reducir la superficie de ataque y la cantidad de parches; sigue siendo la opción donde “lo aburrido gana”.
• El journaling de NTFS es antiguo, y eso es un cumplido. NTFS ha sido el predeterminado desde los años 90; está probado en batalla, aunque Windows moderno también impulsa ReFS para ciertos escenarios.
• El cifrado y la firma de SMB se volvieron comunes por una razón. El movimiento lateral y el robo de credenciales convirtieron los recursos compartidos “rápidos pero confiados” en una responsabilidad.
• PowerShell se convirtió en la interfaz real de administración hace años. Desde Windows Server 2012, la administración “GUI-primero” se ha convertido silenciosamente en “respaldada por PowerShell”.
• Windows Defender ya no es un juguete. El antivirus integrado maduró hasta convertirse en una base de seguridad de endpoint seria; ignorarlo suele ser peor que habilitarlo.
• La evolución de Hyper-V cambió la colocación de roles. Una vez que la virtualización se volvió estándar, el viejo modelo de “una aplicación por servidor físico” murió—pero “un trabajo por VM” sigue siendo sensato.
• Los sesgos de diseño de Active Directory todavía influyen en las instalaciones. La sincronización de tiempo, DNS y suposiciones de identidad hacen que el orden de configuración inicial importe más en Windows de lo que mucha gente espera.
• Patch Tuesday es política, no una sugerencia. La cadencia es institucional. Si tu estrategia de actualizaciones no la respeta, derivarás hasta que te veas obligado a reaccionar durante un incidente.

El plan de 60 minutos (qué hacer y en qué orden)

La idea no es hacerlo todo en 60 minutos. La idea es hacer primero el trabajo irreversible y de alto impacto,
y luego dejar el sistema en un estado seguro, parcheable y soportable. Este es el camino que mantiene a tu yo futuro fuera de problemas.

Minutos 0–10: Instala con elecciones sensatas de disco y edición

• Elige la edición y el modo de despliegue correctos (Server Core salvo que tengas una razón real).
• Confirma UEFI vs BIOS, Secure Boot y TPM si planeas BitLocker.
• Particiona de forma sensata: separa el SO de los datos y registros cuando sea práctico.

Minutos 10–25: Identidad y bases de acceso

• Configura el nombre del host, direccionamiento IP, DNS y puerta de enlace.
• Arregla la sincronización horaria y la zona horaria (Kerberos te castigará después si no lo haces).
• Habilita la administración remota (WinRM/PowerShell remoting), luego restringe RDP.

Minutos 25–40: Parchar y reiniciar como adulto

• Aplica las últimas actualizaciones acumulativas antes de añadir roles.
• Confirma la fuente de actualizaciones (WSUS, Windows Update for Business o Microsoft Update directo) y que coincida con la política.
• Reinicia hasta llegar a “no quedan actualizaciones pendientes”. Un reinicio es una esperanza, no un proceso completo.

Minutos 40–55: Instala roles y características (mínimo)

• Añade solo los roles que necesitas hoy.
• Confirma que los servicios, puertos en escucha y reglas de firewall coinciden con lo previsto.
• Valida los registros de eventos por advertencias de instalación de roles ahora, no tres meses después.

Minutos 55–60: Aplica endurecimiento base y toma una instantánea (o copia de seguridad)

• Habilita Defender, aplica el firewall, desactiva lo innecesario.
• Activa BitLocker si está soportado y planificado operacionalmente.
• Crea un punto de control / instantánea “estado dorado” si está virtualizado, o al menos una copia de seguridad y una exportación de configuración.

Broma #1: Si saltas el parcheo porque “es nuevo”, enhorabuena—tu servidor ahora es una pieza de museo con malware interactivo.

Opciones de instalación que importan (y las que no)

Server Core vs Desktop Experience

Si construyes roles de infraestructura (AD DS, DNS, DHCP, host Hyper-V, servidor de archivos) y no tienes una dependencia firme de una GUI local,
elige Server Core. Menos binarios significa menos parches, menos rutas de ataque y menos “misterio” instalado para soportar
características de UI que no usas.

Usa Desktop Experience cuando tengas una aplicación de proveedor que insiste en herramientas locales de UI o complementos MMC antiguos que funcionan mal de forma remota.
Pero trátalo como un coste: más parches, más servicios, más cosas que endurecer.

UEFI, Secure Boot y TPM: decide temprano

UEFI + Secure Boot + TPM te dan una historia de confianza de plataforma que realmente aguanta auditorías y respuesta a incidentes. Si quieres BitLocker
en la unidad del SO sin manejo de claves manuales extraño, quieres TPM.

No “planees añadir TPM más tarde”. Las decisiones de hardware y TPM virtual tienen repercusiones en el cifrado, los procesos de recuperación y la postura de cumplimiento.

Diseño de discos: separa los dominios de fallo

La unidad del SO debe ser aburrida. Mantenla más pequeña, más fácil de imagenar, más fácil de respaldar y menos propensa a llenarse por registros de aplicaciones
que alguien olvidó rotar.

Un diseño pragmático en muchas empresas:

• C: Solo SO (más herramientas mínimas).
• D: Binarios de aplicaciones / servicios (opcional).
• E: Datos.
• F: Registros y temporales (especialmente para IIS, staging de backups, trabajos ETL).

Las letras exactas no importan. Lo que importa es la separación.

Elección de sistema de archivos: NTFS vs ReFS

NTFS sigue siendo el predeterminado seguro por compatibilidad amplia. ReFS tiene ventajas en integridad y algunos escenarios de almacenamiento a gran escala, pero
no es un reemplazo universal para todas las cargas (algunas aplicaciones y herramientas de backup aún tienen opiniones al respecto).

Si no sabes por qué necesitas ReFS, probablemente no lo necesitas. Si lo necesitas, ya tienes un plan de pruebas.

Post-instalación: identidad, red, hora y acceso remoto

Nómbralo como lo buscarás a las 3 a. m.

Los nombres de host deben codificar entorno y rol de forma que los humanos los puedan interpretar rápidamente. Manténlo lo suficientemente corto para herramientas y certificados.
Evita la creatividad. Los nombres ingeniosos envejecen mal.

Red: usa estático donde importa, documenta donde no

Controladores de dominio, servidores DNS, hosts Hyper-V, nodos de almacenamiento y cualquier dependencia deben tener direccionamiento estático. Los servidores de aplicaciones
pueden usar DHCP con reservas, según tu entorno. En cualquier caso, asegura que DNS sea correcto y consistente.

Sincronización horaria: la dependencia invisible que rompe la autenticación

Kerberos es extremadamente educado hasta que los relojes se desincronizan, y entonces se vuelve extremadamente estricto. Configura la zona horaria, confirma la fuente NTP y verifica
el desfase. Hazlo antes de unir un dominio o promover un DC, no después.

Administración remota: WinRM primero, RDP segundo

Si puedes administrar el servidor vía PowerShell Remoting y MMC/RSAT desde una estación de administración, necesitas mucho menos RDP. Mantén RDP disponible
para break-glass, pero reduce la exposición. No trates RDP como tu plano de control principal.

Roles y características: instala solo lo que puedas defender

Los roles no son “características”, son contratos

Instalar un rol es aceptar parchearlo, monitorizarlo y entender sus modos de fallo. La forma más rápida de arruinar un servidor nuevo es
instalar “un poco de todo” para decidir después.

Patrones de roles comunes que no te harán lamentarlo

• Controlador de dominio (AD DS + DNS): mantenlo limpio. Sin aplicaciones extra. Sin recursos compartidos. Sin SQL.
• Servidor de archivos: aislarlo de los DCs, aplicar firma/cifrado SMB donde corresponda y planear cuotas/FSRM desde temprano.
• Host Hyper-V: trata al host como firmware. Roles mínimos, accesos mínimos, parches predecibles.
• IIS: bloquea módulos, limita privilegios del pool de aplicaciones y mantén TLS/cifras consistentes con la política.

Instala roles con PowerShell para ser explícito

Las instalaciones por GUI ocultan detalles. PowerShell muestra lo que cambió. Eso es mejor para notas de tickets, revisiones de cambios y reconstrucciones futuras.

Actualizaciones: parchea como si importara

Elige un modelo de actualización y cíñete a él

En entornos corporativos normalmente caerás en uno de estos:

• WSUS (aprobación central y control on‑prem): bueno cuando necesitas gobernanza estricta.
• Windows Update for Business (control de actualizaciones en la nube mediante políticas): bueno para escala y consistencia.
• Microsoft Update directo: aceptable para servidores aislados, laboratorios o despliegues pequeños con disciplina de procesos.

Lo que no debes hacer: mezclar modelos a la ligera. Así terminas con “algunos servidores parcheados, otros no, y nadie sabe por qué”.

Parchea antes de los roles (por lo general)

Un servidor recién instalado está atrasado en actualizaciones acumulativas. Parchar temprano reduce las probabilidades de raras incidencias al instalar roles y reduce la ventana de exposición.
Sí, hay excepciones (algunos roles requieren reinicios en medio de la instalación), pero la regla general se mantiene.

Los ciclos de reinicio son parte del parcheo, no un inconveniente

Tu trabajo no es “instalar actualizaciones”. Tu trabajo es “llegar a un estado limpio sin reinicios pendientes y sin actualizaciones fallidas”.
Los estados de reinicio pendiente causan rarezas: servicios que no se cargan, controladores a medio aplicar, cambios de políticas que no surten efecto.

Endurecimiento: reduce el radio de impacto sin sabotearte

Principios de base

• Menores privilegios: ejecuta servicios con los mínimos derechos. Evita LocalSystem salvo que disfrutes vivir peligrosamente.
• Reducir servicios en escucha: cada puerto abierto es una promesa de defenderlo.
• Cifrar donde importe: datos en reposo (BitLocker) y datos en tránsito (TLS, cifrado/firmado SMB según se requiera).
• Haz el logging aburrido y completo: registros de seguridad, logging de PowerShell y reenvío de eventos si lo tienes.

Postura de firewall: denegar por defecto es una filosofía

Windows Firewall no es decoración opcional. Actívalo para todos los perfiles. Crea reglas entrantes explícitas para lo que necesitas. Luego verifica
lo que realmente está en escucha. Si confías en “está en una VLAN interna”, estás construyendo para 2009, no para ahora.

Endurecimiento de RDP: mantenlo, pero hazlo difícil de abusar

Requiere Network Level Authentication. Restringe quién puede iniciar sesión por RDP. Considera acceso just-in-time mediante herramientas de acceso privilegiado
si las tienes. Como mínimo, no expongas RDP ampliamente y no permitas grupos de administradores por accidente.

Configuración de Defender: el valor por defecto es decente, el predeterminado afinado es mejor

En muchos entornos, habilitar la protección en tiempo real de Defender y la protección basada en la nube es una mejora inmediata respecto a “nada” o
“un agente de terceros expirado”. Si un proveedor exige exclusiones, negocia: rutas estrechas, procesos restringidos y documenta por qué.

Desactiva lo que no usas

Cada característica innecesaria añade superficie de parcheo y sorpresas. Ejemplos: SMBv1 (no lo uses), protocolos TLS legados (no), componentes de servidor web en servidores no web (¿por qué?),
y cuentas locales con contraseñas de larga duración (deja de hacer esto).

Almacenamiento y sistema de archivos (comprobaciones SRE)

Los problemas de rendimiento suelen ser problemas de almacenamiento con máscara de CPU

Windows te permitirá construir un servidor sobre almacenamiento thin-provisioned con caché de escritura deshabilitada, poner los registros en el disco del SO y luego
“misteriosamente” ir lento bajo carga. El SO no es misterioso. Es literal.

Decide qué tipo de almacenamiento tienes

• NVMe/SAS SSD local: más rápido y simple. Ideal para hosts Hyper-V y cargas independientes.
• SAN (FC/iSCSI): compartido y manejable, pero la latencia y la configuración multipath importan.
• Almacenamiento SMB / NAS: bueno para compartidos y algunos escenarios Hyper-V, pero requiere ajuste SMB y diseño de red cuidadoso.

Alineación de particiones y tamaño de bloque: sí, aún importa

Windows moderno generalmente hace lo correcto, pero aún deberías verificar lo que obtuviste. Suposiciones equivocadas aquí crean dolor a largo plazo:
ventanas de backup que se alargan, picos de latencia de SQL y monitoreo que dice “todo está bien” mientras los usuarios se quejan.

Planea la ubicación y crecimiento de los registros

“Pondremos los registros en C: por ahora” es una frase clásica previa al incidente. Pon los registros en un lugar con espacio y monitorización. Si una aplicación llena
su volumen de registros, debe fallar de una forma que puedas ver, no corromper el SO.

Tareas prácticas con comandos, salidas y decisiones (12+)

Estas son las comprobaciones básicas que ejecuto en un servidor nuevo. Cada tarea incluye un comando, qué significa la salida y qué decisión tomar.
Ejecútalas en una sesión de PowerShell elevada.

Tarea 1: Confirma edición e tipo de instalación del SO

cr0x@server:~$ powershell -NoProfile -Command "Get-ComputerInfo | Select-Object WindowsProductName,WindowsEditionId,OsHardwareAbstractionLayer"
WindowsProductName                WindowsEditionId OsHardwareAbstractionLayer
-----------------                ----------------- --------------------------
Windows Server 2025 Datacenter    ServerDatacenter 10.0.26100.1

Significado: Confirma que no instalaste por accidente Standard cuando necesitabas Datacenter, o Desktop Experience cuando querías Core.

Decisión: Si la edición/modo de instalación es incorrecto, detente ahora y reinstala. “Arreglar después” suele ser una reconstrucción completa.

Tarea 2: Comprueba el estado de reinicio pendiente (el saboteador silencioso)

cr0x@server:~$ powershell -NoProfile -Command "Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'"
True

Significado: True indica que Windows cree que hay un reinicio pendiente debido al servicing.

Decisión: Reinicia y vuelve a comprobar antes de instalar roles o diagnosticar problemas “aleatorios”.

Tarea 3: Valida el nombre del host y la pertenencia al dominio

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

Significado: Confirma que te uniste al dominio previsto y no acabaste en WORKGROUP en un servidor “de producción”.

Decisión: Si la pertenencia al dominio es incorrecta, arréglala antes de instalar roles que dependan de AD (y antes de emitir certificados).

Tarea 4: Verifica la configuración NIC (IP, DNS y si DHCP se cuela)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPConfiguration | Select-Object InterfaceAlias,IPv4Address,IPv4DefaultGateway,DnsServer"
InterfaceAlias IPv4Address    IPv4DefaultGateway DnsServer
-------------- -----------    ------------------ ---------
Ethernet0      10.20.5.21     10.20.5.1         {10.20.1.10, 10.20.1.11}

Significado: Confirma que el servidor tiene la dirección correcta y apunta DNS a tus resolutores (no al router, no a 8.8.8.8, no a sí mismo salvo que sea DNS).

Decisión: Si DNS es incorrecto, arréglalo ahora. Los errores de resolución de nombres desperdician días y hacen que AD parezca culpable cuando no lo es.

Tarea 5: Confirma sincronización horaria y desfase

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

Significado: Muestra tu fuente de tiempo y si la última sincronización fue exitosa.

Decisión: Si la fuente es “Local CMOS Clock” en un servidor unido al dominio que no es el emulador PDC, corrige NTP. Los problemas de autenticación aman la deriva del reloj.

Tarea 6: Confirma que Windows Firewall está habilitado para todos los perfiles

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

Significado: Estás bloqueando entrantes por defecto, lo que obliga a reglas explícitas.

Decisión: Si algún perfil está deshabilitado, habilítalo y crea reglas de permiso necesarias. No confíes en mitos perimetrales.

Tarea 7: Mira qué está realmente en escucha en la red

cr0x@server:~$ powershell -NoProfile -Command "Get-NetTCPConnection -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess | Sort-Object LocalPort | Select-Object -First 10"
LocalAddress LocalPort OwningProcess
------------ --------- -------------
0.0.0.0      135       968
0.0.0.0      445       4
0.0.0.0      3389      1440
::          445       4
::          3389      1440

Significado: Los puertos abiertos son superficie de ataque real. Esto te dice qué está expuesto.

Decisión: Si ves oyentes inesperados (agentes antiguos, servicios de proveedor, servidores web), identifícalos y elimina/deshabilita o bloquéalos con firewall.

Tarea 8: Mapea puertos en escucha a servicios/procesos

cr0x@server:~$ powershell -NoProfile -Command "Get-Process -Id 1440 | Select-Object Id,ProcessName,Path"
Id   ProcessName Path
--   ----------- ----
1440 TermService C:\Windows\System32\svchost.exe

Significado: Confirma quién posee el puerto (aquí, RDP vía Terminal Services).

Decisión: Si un proceso es inesperado o se ejecuta desde una ruta extraña, considéralo sospechoso hasta demostrar lo contrario.

Tarea 9: Comprueba salud de Defender y protección en tiempo real

cr0x@server:~$ powershell -NoProfile -Command "Get-MpComputerStatus | Select-Object AMServiceEnabled,AntispywareEnabled,AntivirusEnabled,RealTimeProtectionEnabled,IoavProtectionEnabled"
AMServiceEnabled AntispywareEnabled AntivirusEnabled RealTimeProtectionEnabled IoavProtectionEnabled
---------------- ------------------ --------------- ------------------------- --------------------
True             True               True            True                      True

Significado: Confirma que Defender no está deshabilitado por accidente o por una GPO antigua.

Decisión: Si está deshabilitado, averigua por qué. Si se requiere un AV de terceros, verifica que esté instalado y saludable en lugar de dejar un hueco.

Tarea 10: Confirma estado de actualizaciones y últimas fechas de instalación

cr0x@server:~$ powershell -NoProfile -Command "Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5"
Source Description      HotFixID  InstalledBy          InstalledOn
------ -----------      --------  -----------          -----------
FS01   Update           KB503xxxx NT AUTHORITY\SYSTEM  2/5/2026
FS01   Security Update  KB503yyyy NT AUTHORITY\SYSTEM  2/5/2026
FS01   Update           KB503zzzz NT AUTHORITY\SYSTEM  2/5/2026
FS01   Update           KB502aaaa NT AUTHORITY\SYSTEM  1/14/2026
FS01   Update           KB502bbbb NT AUTHORITY\SYSTEM  1/14/2026

Significado: Puedes saber rápido si el servidor está al día o meses atrasado.

Decisión: Si los parches más recientes son antiguos, arregla tu canal de actualizaciones antes de instalar más roles. La deuda técnica empieza al instante.

Tarea 11: Comprueba si BitLocker está habilitado (y si TPM es usable)

cr0x@server:~$ powershell -NoProfile -Command "Get-BitLockerVolume -MountPoint 'C:' | Select-Object MountPoint,VolumeStatus,ProtectionStatus,EncryptionPercentage"
MountPoint VolumeStatus    ProtectionStatus EncryptionPercentage
---------- ------------    ---------------- --------------------
C:         FullyEncrypted  On               100

Significado: Confirma que el cifrado en reposo está activo.

Decisión: Si requieres cifrado y está apagado, actívalo ahora y custodia las claves de recuperación según la política. Si no tienes un proceso de gestión de claves, no improvises.

Tarea 12: Valida diseño de discos y volúmenes (evita el futuro “C: lleno”)

cr0x@server:~$ powershell -NoProfile -Command "Get-Volume | Select-Object DriveLetter,FileSystemLabel,FileSystem,SizeRemaining,Size | Sort-Object DriveLetter"
DriveLetter FileSystemLabel FileSystem SizeRemaining Size
----------- -------------- ---------- ------------- ----
C           OS             NTFS       58.4 GB       120 GB
E           DATA           NTFS       1.6 TB        2.0 TB
F           LOGS           NTFS       350 GB        400 GB

Significado: Muestra dónde hay espacio y si tu plan de volúmenes coincide con la realidad.

Decisión: Si registros y datos viven en C:, cámbialo antes de que las apps entren en producción. Moverlo después es más difícil y arriesgado.

Tarea 13: Comprueba salud del almacenamiento (vista tipo SMART vía Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-PhysicalDisk | Select-Object FriendlyName,MediaType,HealthStatus,OperationalStatus,Size"
FriendlyName      MediaType HealthStatus OperationalStatus Size
------------      --------- ------------ ----------------- ----
NVMe Disk 0       SSD       Healthy      OK                1.8 TB
NVMe Disk 1       SSD       Healthy      OK                1.8 TB

Significado: Señal básica: Windows piensa que los discos están saludables y operativos.

Decisión: Si ves “Warning” o “Unhealthy”, detente e investiga antes de confiar datos a este host.

Tarea 14: Confirma roles instalados (y detecta los accidentales)

cr0x@server:~$ powershell -NoProfile -Command "Get-WindowsFeature | Where-Object { $_.Installed -eq $true } | Select-Object -First 15"
Display Name                                            Name                       Install State
------------                                            ----                       -------------
File and Storage Services                               FileAndStorage-Services    Installed
File Server                                             FS-FileServer              Installed
Windows Server Backup                                   Windows-Server-Backup      Installed
Windows Defender Features                               Windows-Defender-Features  Installed
Remote Server Administration Tools                      RSAT                       Installed

Significado: Confirma lo que realmente instalaste.

Decisión: Si ves roles que no necesitas (por ejemplo, Web-Server en un servidor de archivos), elimínalos. Menos código, menos problemas.

Tarea 15: Instala un rol explícitamente (ejemplo: File Server) y verifica

cr0x@server:~$ powershell -NoProfile -Command "Install-WindowsFeature -Name FS-FileServer -IncludeManagementTools"
Success Restart Needed Exit Code      Feature Result
------- -------------- ---------      --------------
True    No             Success        {File Server}

Significado: El rol se instaló correctamente y no requiere reinicio (esta vez).

Decisión: Si Restart Needed es Yes, reinicia ahora—no apiles más cambios sobre un reinicio pendiente.

Tarea 16: Verifica configuración básica de SMB (firma, dialectos)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol,EnableSMB2Protocol,RequireSecuritySignature,EncryptData"
EnableSMB1Protocol EnableSMB2Protocol RequireSecuritySignature EncryptData
------------------ ------------------ ------------------------ -----------
False              True               True                     False

Significado: SMBv1 está desactivado (bien), SMBv2+ está activo, la firma es obligatoria y el cifrado es opcional actualmente.

Decisión: Para recursos sensibles o redes no confiables, habilita el cifrado SMB por recurso o globalmente. No cifres a ciegas sin medir el impacto en la CPU.

Broma #2: Desactivar el firewall porque “está bloqueando mi app” es como quitar el detector de humo porque suena fuerte.

Guía de diagnóstico rápido (encuentra el cuello de botella)

Cuando un servidor nuevo se siente lento, no adivines. No reinstales controladores por aburrimiento. Haz una breve triage que te diga dónde se fue el tiempo.
El objetivo es aislar CPU, presión de memoria, latencia de almacenamiento, red o identidad/DNS.

Primero: ¿Es almacenamiento, y es obvio?

• Comprueba cola de disco y latencia: si el almacenamiento es lento, todo es lento.
• Comprueba si el volumen del SO está casi lleno: poco espacio causa comportamientos patológicos y actualizaciones fallidas.
• Revisa los registros de eventos: reinicios de disco, advertencias storport, problemas NTFS.

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\PhysicalDisk(_Total)\Avg. Disk sec/Read','\PhysicalDisk(_Total)\Avg. Disk sec/Write' -SampleInterval 2 -MaxSamples 3"
Timestamp                 CounterSamples
---------                 --------------
2/5/2026 9:02:11 AM       \\FS01\physicaldisk(_total)\avg. disk sec/read : 0.004
                          \\FS01\physicaldisk(_total)\avg. disk sec/write: 0.007
2/5/2026 9:02:13 AM       \\FS01\physicaldisk(_total)\avg. disk sec/read : 0.005
                          \\FS01\physicaldisk(_total)\avg. disk sec/write: 0.009
2/5/2026 9:02:15 AM       \\FS01\physicaldisk(_total)\avg. disk sec/read : 0.004
                          \\FS01\physicaldisk(_total)\avg. disk sec/write: 0.008

Significado: Latencias en milisegundos de un solo dígito suelen ser saludables para muchas cargas. Decenas/centenas de ms indican problemas.

Decisión: Si la latencia es alta, deja de culpar a “Windows” y empieza a revisar backend de almacenamiento, políticas de caché de escritura, multipath SAN y vecinos ruidosos.

Segundo: Presión de CPU y memoria (comprobaciones simples primero)

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\Processor(_Total)\% Processor Time','\Memory\Available MBytes' -SampleInterval 2 -MaxSamples 3"
Timestamp                 CounterSamples
---------                 --------------
2/5/2026 9:03:01 AM       \\FS01\processor(_total)\% processor time : 12.4
                          \\FS01\memory\available mbytes : 18234
2/5/2026 9:03:03 AM       \\FS01\processor(_total)\% processor time : 10.1
                          \\FS01\memory\available mbytes : 18190
2/5/2026 9:03:05 AM       \\FS01\processor(_total)\% processor time : 11.7
                          \\FS01\memory\available mbytes : 18210

Significado: La CPU no está al máximo y la memoria no está hambrienta.

Decisión: Si la CPU es alta, identifica los procesos principales y revisa si hay escaneos antivirus, logging descontrolado o indexación mal configurada. Si la memoria es baja, confirma el comportamiento de paginación y el dimensionamiento de las apps.

Tercero: DNS e identidad (porque todo depende de ello)

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName corp.example -Type SOA"
Name         Type TTL  Section    NameHost
----         ---- ---  -------    --------
corp.example SOA  3600 Answer     dns01.corp.example

Significado: La resolución DNS funciona y devuelve información autoritativa.

Decisión: Si DNS es lento o falla, arréglalo antes de diagnosticar timeouts de aplicaciones. Las apps no manejan mal DNS con gracia; solo sufren creativamente.

Cuarto: Conceptos básicos de red (no hagas benchmarks con deseos)

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection -ComputerName dns01.corp.example -Port 53"
ComputerName           : dns01.corp.example
RemoteAddress          : 10.20.1.10
RemotePort             : 53
InterfaceAlias         : Ethernet0
SourceAddress          : 10.20.5.21
TcpTestSucceeded       : True

Significado: La conectividad básica a una dependencia funciona en el puerto esperado.

Decisión: Si esto falla, tienes problemas de enrutamiento/firewall/VLAN. Deja de tocar la construcción del servidor y ve a hablar con la ruta de red.

Errores comunes: síntomas → causa raíz → arreglo

1) “La instalación del rol tuvo éxito, pero los servicios fallan o se comportan de forma extraña”

Síntomas: Los servicios no arrancan; las características funcionan parcialmente; el Visor de Eventos muestra errores de servicing/CSI; los reinicios parecen “arreglarlo a veces”.

Causa raíz: Estado de reinicio pendiente por actualizaciones o instalaciones de características.

Arreglo: Reinicia hasta que los estados pendientes se despejen; confirma con la comprobación del registro de reinicio pendiente. Luego vuelve a ejecutar la instalación/ reparación del rol.

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

Síntomas: Errores de Kerberos, GPO que no se aplica, accesos denegados esporádicos.

Causa raíz: Desajuste de tiempo o jerarquía NTP incorrecta.

Arreglo: Verifica w32tm /query /status; corrige la fuente de tiempo; confirma la zona horaria; resíncroniza y vuelve a probar.

3) “Los recursos compartidos son lentos, especialmente en horas pico”

Síntomas: Operaciones de copia se detienen; el Explorador se congela; la CPU del servidor parece bien.

Causa raíz: Picos de latencia de almacenamiento (congestión SAN, thin provisioning, política de caché de escritura, snapshots en segundo plano).

Arreglo: Mide contadores de latencia; revisa rendimiento del almacenamiento backend; separa logs/temporales; considera QoS o volúmenes dedicados.

4) “RDP está expuesto y aparecen intentos de password spray”

Síntomas: Ruido en el registro de seguridad, cuentas bloqueadas, IPs aleatorias intentando iniciar sesión.

Causa raíz: RDP permitido ampliamente; reglas de firewall demasiado permisivas; controles de acceso débiles.

Arreglo: Restringe RDP a subredes de administración/VPN; exige NLA; limita grupos permitidos; considera desactivar RDP en el perfil público por completo.

5) “Windows Update sigue fallando con errores crípticos”

Síntomas: Las actualizaciones se descargan pero no se instalan; fallos repetidos; errores del servicing stack.

Causa raíz: Poco espacio en C:, configuración de origen de actualizaciones rota o componentes de servicing obsoletos.

Arreglo: Libera espacio; confirma la política de origen de actualizaciones; reinicia; luego intenta de nuevo. Si persiste, puede tocar una reparación de instalación o reconstrucción—decide según lo reproducible del build.

6) “Después del endurecimiento, una app falla en producción”

Síntomas: La app no puede enlazar a un puerto, no puede escribir registros, no puede autenticarse con servicios remotos.

Causa raíz: Cambios de endurecimiento aplicados sin un modelo de excepciones específico para la app (permisos de cuentas de servicio, ACLs de carpetas, reglas de firewall).

Arreglo: Avanza con excepciones dirigidas: reglas de firewall estrechas, ACLs de mínimo privilegio y permisos documentados para cuentas de servicio. Evita deshabilitaciones globales.

Tres micro-historias corporativas (cómo falla esto en la práctica)

Micro-historia 1: El incidente causado por una suposición equivocada

Un equipo creó una nueva VM Windows para una app crítica. El ingeniero asumió “DHCP está bien; mantendrá la misma IP” porque la VM vivía en un clúster estable.
Nadie hizo una reserva. Nadie documentó la dirección. Pasó las pruebas porque la IP no cambió durante semanas.

Luego, un mantenimiento rutinario del hipervisor movió la VM a otro host con un segmento de red distinto y una configuración de alcance DHCP diferente.
El servidor arrancó, pidió una dirección y obtuvo una nueva IP. La depuración de DNS eventualmente eliminó el registro antiguo y lo sustituyó por el nuevo.
La app no usaba DNS, sin embargo. Estaba codificada con la antigua IP en tres lugares, incluido un conector de proveedor que nadie conocía.

El modo de fallo fue cinematográfico: los usuarios vieron errores intermitentes porque la mitad de los clientes almacenaba en caché la IP antigua y la otra mitad resolvía la nueva.
La autenticación parecía bien. CPU y RAM parecían bien. El monitoreo parecía bien—porque los monitores apuntaban a la dirección antigua.

La solución fue aburrida: IP estática (o una reserva), DNS correcto y una regla que exige que las dependencias se dirijan por nombre DNS, no por IP, salvo que haya una razón documentada.
La lección real: “Funcionó en pruebas” no es evidencia de corrección. Es evidencia de que el tiempo aún no te castigó.

Micro-historia 2: La optimización que rebotó

Otra organización ejecutaba un servidor de archivos concurrido sobre almacenamiento compartido. Alguien notó que habilitar el cifrado SMB “mejoraría la seguridad”, así que lo activaron globalmente.
El cambio pasó una prueba superficial: unas copias de archivos funcionaron y no saltaron alarmas. El ingeniero dejó un registro de cambio y se fue a casa satisfecho.

Dos días después, el rendimiento en horas pico degradó. No catastróficamente—suficiente para causar colas, tiempos de inicio de sesión más largos y tickets difíciles de correlacionar.
La CPU del servidor de archivos subió. El rendimiento de red pareció algo menor. La latencia de almacenamiento aumentó porque los clientes reintentaban operaciones durante la congestión.
Todos culparon al SAN porque siempre se culpa al SAN.

El postmortem encontró al verdadero culpable: sobrecarga de cifrado en clientes antiguos y en un subconjunto de flujos de trabajo de alto rendimiento. El servidor tenía CPU de sobra, pero el patrón de sesiones SMB cifradas
aumentó el coste por conexión. El cambio también interactuó con el escaneo antivirus en aperturas de archivo, multiplicando la sobrecarga de una forma que los benchmarks no capturaron.

El rollback mejoró el rendimiento de inmediato. La solución a futuro fue más madura: habilitar cifrado solo para recursos sensibles, confirmar soporte de cliente y probar con cargas representativas.
Las mejoras de seguridad son buenas. Las mejoras de seguridad sin pruebas de rendimiento crean un nuevo tipo de outage.

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

Una empresa estandarizó un checklist estricto de build: parchear a estado actual, verificar reinicio pendiente, aplicar reglas de firewall base, exportar configuración de roles y tomar una instantánea limpia.
No era glamoroso, así que nadie lo presumía. Simplemente lo hacían, cada vez.

Meses después, una actualización acumulativa nueva provocó un extraño bucle de arranque en un subconjunto de VMs debido a una interacción con una configuración particular del controlador de almacenamiento virtual.
El síntoma parecía “Windows está roto”. Los intentos de recuperación fueron caóticos en equipos que no tenían un estado conocido o un patrón de build consistente.

Este equipo restauró la instantánea tomada justo después del build base. Compararon exportaciones de configuración entre los estados bueno y malo.
Pudieron demostrar qué cambió, cuándo y en qué hosts. Eso hizo la escalada al equipo de plataforma precisa en lugar de emocional.

La solución fue sencilla: ajustar la configuración del controlador virtual, aplicar la actualización otra vez y confirmar estabilidad.
La checklist no evitó el bug. Evitó que el incidente se convirtiera en una excavación arqueológica de varios días.

Listas de verificación / plan paso a paso

Checklist pre-instalación (5 minutos, ahorra horas)

• Confirma el rol del servidor: DC, servidor de archivos, host Hyper-V, IIS, servidor de aplicaciones, etc.
• Decide el modo de instalación: Server Core salvo que necesites GUI local.
• Decide el plan de discos: SO vs datos vs registros; dimensiona con crecimiento en mente.
• Decide la fuente de actualizaciones: WSUS vs WUfB vs Microsoft Update directo.
• Decide la línea base de seguridad: postura de firewall, política RDP, política Defender, requisito de BitLocker.
• Confirma que tienes procedimientos de break-glass (admin local, consola de emergencia).

Checklist de instalación (15 minutos)

• Instala la edición prevista de Windows Server 2025.
• Usa UEFI + Secure Boot si está soportado.
• Particiona volúmenes según lo planificado; etiqueta volúmenes claramente (OS, DATA, LOGS).
• Establece una contraseña fuerte para admin local y guárdala en tu gestor de secretos según la política.

Checklist primer arranque (20 minutos)

• Configura el nombre del host y reinicia (hazlo ahora para que no te sorprenda después).
• Configura NICs: IP estática para dependencias de infraestructura; servidores DNS correctos.
• Configura zona horaria y verifica la fuente NTP.
• Habilita WinRM/PowerShell remoting como método principal de administración (según política).
• Activa firewall para todos los perfiles; crea reglas explícitas para redes de gestión.

Checklist de parcheo (10–20 minutos, varía con el ancho de banda)

• Instala las últimas actualizaciones.
• Reinicia.
• Busca más actualizaciones.
• Repite hasta que no haya actualizaciones pendientes ni reinicios requeridos.

Checklist roles y endurecimiento (10–20 minutos)

• Instala solo los roles requeridos con PowerShell.
• Verifica que los puertos en escucha y las reglas del firewall coincidan con la intención.
• Confirma el estado de Defender; implementa exclusiones necesarias de forma estrecha.
• Habilita BitLocker si es requerido y tienes procesos de custodia de claves/recuperación.
• Exporta un “recibo” de configuración (roles, ajustes de red) en tu registro de cambios.
• Toma una instantánea/checkpoint o realiza una copia de seguridad base.

Preguntas frecuentes (FAQ)

1) ¿Debería usar Server Core para Windows Server 2025?

Sí, salvo que tengas una dependencia específica de GUI. Core reduce la superficie de parches y tiende a comportarse mejor con una administración remota disciplinada.
Si tu equipo carece de madurez operativa en Core, mejora las prácticas del equipo—no penalices al servidor.

2) ¿Cuándo debo instalar roles: antes o después de parchear?

Después de parchear, en la mayoría de los casos. Parchar primero reduce incidencias extrañas al instalar roles y encoge la ventana de exposición.
Si un rol exige prerrequisitos que cambian el servicing, instala prerrequisitos, reinicia, parchea y luego sigue.

3) ¿Es Windows Defender suficiente en servidores?

Para muchos entornos, Defender es una base sólida—especialmente comparado con “nada” o un agente de terceros sin mantenimiento.
Si la política exige otra cosa, perfecto; solo asegúrate de tener protección efectiva y telemetría, no una casilla marcada.

4) ¿Debería habilitar BitLocker en servidores?

Si tienes requisitos de cumplimiento, datos sensibles o riesgo de exposición de discos (nube, colo, laptops convertidos en servidores—sí, existen), entonces sí.
Pero hazlo con custodia de claves y proceso de recuperación. El cifrado sin recuperación no es seguridad; es pérdida de datos autoinfligida.

5) ¿Realmente necesito mantener el firewall activado dentro del centro de datos?

Sí. Las redes internas no son automáticamente confiables y el movimiento lateral es una técnica estándar de atacantes.
Mantén el firewall activo, bloquea entrantes por defecto y permite explícitamente puertos de gestión y de aplicaciones.

6) ¿Cómo elijo entre NTFS y ReFS?

Si necesitas máxima compatibilidad y no tienes una razón específica, elige NTFS.
Considera ReFS cuando tengas un caso de uso validado y un plan de pruebas que incluya backups, restauraciones y compatibilidad de aplicaciones.

7) ¿Cuál es la forma más rápida de saber si la “lentitud” es almacenamiento?

Comprueba contadores de latencia de disco y los registros de eventos relacionados con almacenamiento. Si las lecturas/escrituras son consistentemente de decenas de milisegundos o peor bajo carga normal,
almacenamiento es tu primer sospechoso, incluso si la CPU parece calmada.

8) ¿Debería permitir RDP en absoluto?

Permítelo como un camino controlado de break-glass, no como tu herramienta de administración diaria.
Restringe a redes de administradores, exige NLA y limita quién puede iniciar sesión. Prefiere PowerShell remoting para operaciones rutinarias.

9) ¿Cómo evito servidores “copos de nieve”?

Usa PowerShell para instalaciones y configuración, conserva una lista de verificación de build y guarda exportaciones de configuración en tus registros de cambios.
Si un servidor no puede reconstruirse desde pasos documentados, es un copo de nieve—no importa lo confiado que se vea el instalador.

10) ¿Cuál es el conjunto mínimo de comprobaciones tras la primera hora?

Confirma: no hay reinicios pendientes, las actualizaciones están al día, firewall activado, Defender sano, DNS/hora correctos, solo puertos esperados en escucha y volúmenes con espacio y registros fuera de C:.
Ese es el umbral “seguro para seguir”.

Siguientes pasos (mantenlo aburrido)

Después de la primera hora, tu trabajo cambia de “construir” a “operar”. Haz esto a continuación:

• Define umbrales de monitorización para espacio en disco, latencia de disco, CPU, memoria y actualizaciones fallidas. Si no lo mides, lo descubrirás por tickets.
• Centraliza logs si tu entorno lo admite (reenvío de eventos/SIEM). Los logs locales están bien hasta que el servidor cae.
• Documenta el contrato de rol: qué puertos están abiertos, qué cuentas de servicio existen, qué backups corren y cuál es el procedimiento de restauración.
• Prueba una restauración. Los backups sin restauraciones son solo sensaciones caras.
• Programa ventanas de parcheo y demuestra que puedes reiniciar sin drama. El miedo a reiniciar es cómo los servidores se vuelven no parcheables.

Tu objetivo no es construir un servidor que puedas admirar. Es construir un servidor que puedas olvidar—porque está parcheado, endurecido, observable y hace su único trabajo sin drama.