Windows Server 2025 / Crear una lista práctica de mantenimiento del servidor

Una lista de mantenimiento útil comprueba que los servicios funcionan para sus usuarios, que los datos se pueden recuperar y que los cambios recientes no han causado daños. Para cada comprobación, defina el resultado esperado, la frecuencia, la evidencia, un responsable y qué hacer si falla; marcar una casilla sin esos criterios no demuestra que el servidor esté sano.

Definir el funcionamiento normal de cada función

Prepare un inventario por servidor con nombre, dirección IP, funciones, responsable, dependencias, vía de administración y destino de las copias. Añada una operación normal y su resultado esperado para cada función, realizada desde un cliente representativo. Poder abrir la consola o ver un servicio en ejecución no demuestra que los usuarios puedan autenticarse, abrir archivos o utilizar la aplicación.

Función Comprobación funcional de ejemplo
Active Directory (AD) y Sistema de nombres de dominio (DNS) Localizar un controlador, resolver los nombres necesarios, autenticar contra el dominio y comprobar replicación; una sesión en caché no basta.
Servidor de archivos Con una cuenta normal, leer y escribir donde corresponde y comprobar que otra cuenta sin permisos no accede; use archivos de prueba propios.
Protocolo de configuración dinámica de host (DHCP) Revisar direcciones disponibles por ámbito y confirmar en un cliente autorizado una concesión con dirección y opciones esperadas.
Servidor web Abrir el nombre HTTPS real, comprobar respuesta y contenido esperado y revisar registros; no aceptar errores de certificado para dar la prueba por válida.

El inicio de sesión con información de dominio almacenada en caché puede permitir entrar en un equipo sin contactar con un controlador; no basta para comprobar Active Directory (AD). Del mismo modo, una prueba con un administrador puede ocultar errores de permisos de usuarios normales. Use una cuenta y una ruta representativas con los permisos necesarios, sin elevar sus privilegios para que la prueba pase. Una denegación solo es correcta si también confirma que el recurso funciona para el usuario autorizado.

Asignar revisiones diarias, semanales y mensuales

Frecuencia orientativa Qué revisar Respuesta si hay una anomalía
Diaria o según la criticidad Respuesta del servicio, copias fallidas o no ejecutadas, espacio y alertas importantes. Determinar impacto y posibilidad de recuperación; avisar al responsable con evidencia y prioridad.
Semanal Errores repetidos, crecimiento, actualizaciones pendientes y cambios de cuentas o grupos. Relacionar tendencias con cambios; asignar investigación, responsable y plazo, sin dar por probada una causa.
Mensual o después de cambios Pruebas de restauración, vencimiento de certificados o licencias, accesos y retención. Actuar antes de vencer, revisar dependencias antes de retirar accesos y corregir deficiencias de recuperación.

Las frecuencias de la tabla son ejemplos que debe ajustar al impacto de una interrupción y a la velocidad de cambio. Una copia fallida o un certificado próximo a vencer no deben esperar a la revisión mensual si la recuperación o el servicio están en riesgo. Defina el destinatario de cada alerta, un plazo de respuesta y a quién avisar si no responde. Si no se ejecutó una comprobación, márquela como pendiente o no realizada; no copie el resultado anterior como si fuera nuevo.

Recopilar el estado básico y comprobar cada función

Ejecute estas consultas en Windows PowerShell del servidor que desea revisar, con autorización de lectura y elevación cuando la requieran los registros. Compruebe primero el nombre devuelto y anote hora y zona horaria. Los comandos muestran información; no crean un informe ni realizan pruebas funcionales de todas las funciones. Guarde cada ejecución mediante su procedimiento de informes en una ubicación restringida, con nombre de servidor y fecha únicos, sin sobrescribir evidencia anterior:

hostname
Get-CimInstance Win32_OperatingSystem | Select-Object LastBootUpTime
Get-Volume | Select-Object DriveLetter,FileSystemLabel,Size,SizeRemaining
Get-WinEvent -FilterHashtable @{LogName='System';StartTime=(Get-Date).AddDays(-1);Level=1,2} -MaxEvents 30

La segunda línea muestra el último arranque. En Get-Volume, Size y SizeRemaining son bytes: compare capacidad y espacio libre, calcule el porcentaje solo cuando Size sea mayor que cero y considere el crecimiento y el espacio necesario para actualizaciones y copias. Puede haber volúmenes sin letra; no los trate automáticamente como errores ni cambie particiones. La última línea consulta solo System, niveles 1 y 2 —crítico y error— desde las últimas 24 horas, con un máximo de los 30 eventos más recientes. No incluye advertencias, Application ni todos los canales de función. Según la documentación de Get-WinEvent, la consulta puede fallar por permisos: distinga ese error de la ausencia de coincidencias. Conserve proveedor, ID, hora y mensaje; amplíe el intervalo si el límite oculta el inicio del incidente. La ausencia de eventos no demuestra que todo funcione, y un servicio detenido puede ser de inicio manual o por desencadenador.

En controladores, utilice los diagnósticos de replicación de AD y verifique DNS; revise socios, último éxito y errores, sin forzar sincronizaciones o cambiar DNS por rutina. Para el Protocolo de configuración dinámica de host (DHCP), consulte las estadísticas del ámbito IPv4 en el servidor correspondiente y confirme una concesión desde un cliente de prueba aprobado; no libere la dirección de un equipo en uso solo para probar. En copias, compruebe las versiones del destino real y el equipo de origen: una lista sin destino puede incluir copias ya no disponibles. Un catálogo no acredita una restauración. Añada solo pruebas pertinentes a las funciones instaladas y no instale módulos ni servicios para ejecutar indiscriminadamente todos los controles.

Registrar evidencia y seguimiento

Campo Qué debe permitir comprobar
Hora y destino Servidor, fecha, hora, zona horaria y persona que realizó la comprobación.
Prueba y resultado esperado Cuenta o contexto y operación concreta; definir qué significa éxito o denegación esperada.
Resultado real y evidencia Correcto, fallido o no realizado; código y referencia al informe o registro protegido.
Impacto, responsable y plazo Servicio afectado, prioridad, persona que actúa y fecha límite o escalamiento.
Recomprobación y cierre Repetición de la misma prueba después de corregir y decisión de cerrar o mantener la incidencia.

Por ejemplo, en FS1 puede registrar «lectura y escritura de un archivo propio en Sales desde el cliente con sales.user1; acceso a Support denegado». Si Sales también falla, no marque correcta la denegación de Support sin investigar conectividad y autenticación. Vincule la incidencia con evidencia, responsable y plazo; después de corregir repita las dos pruebas con el mismo contexto. Para la recuperación, use la restauración de archivos en una ubicación separada y conserve su resultado como evidencia, sin inventar tiempos ni comprobaciones exitosas.

Para contraseñas, tokens y claves de recuperación, guarde únicamente la referencia a su ubicación segura, nunca el secreto en la hoja o el informe. Restrinja también los registros que contienen usuarios, rutas o direcciones internas. Separe tres resultados: el script terminó, la tarea de copia declaró éxito y se verificó una restauración utilizable. Una incidencia repetida no se convierte en normal: mantenga responsable, fecha límite y condición de revisión de cualquier excepción.

Repetir las pruebas después de los cambios

Tras una actualización o un cambio de red, permisos, certificado o almacenamiento, repita la operación funcional y la medición de referencia afectadas. Antes del cambio, documente los valores anteriores, la forma de recuperación y el acceso de consola si la administración remota deja de funcionar. Aplique un cambio acotado y planificado cada vez; si empeora el resultado, deténgase, valore el impacto y utilice el procedimiento de reversión aprobado en lugar de acumular cambios.

  • Haga la restauración en otra ubicación y compruebe datos, listas de control de acceso (ACL) y duración. La prueba de recuperación de archivos permite comparar contenido y permisos sin reemplazar el original.
  • Considere el fallo del host o almacenamiento compartido aunque haya varias máquinas virtuales. Dos servidores en el mismo soporte no garantizan independencia frente a ese fallo.
  • Tras renovar un certificado, compruebe que el servicio presenta el nuevo certificado para el nombre correcto y que la cadena es válida desde el cliente. La renovación en el almacén no prueba que se haya actualizado el enlace del servicio.
  • Antes de retirar cuentas, reglas o directivas, identifique servicios, tareas y usuarios dependientes. Conserve el estado anterior y el procedimiento de reversión, y repita la prueba después del cambio.

Actualice la lista cuando cambien funciones, servidores o responsables. Un nuevo servicio necesita una prueba funcional y un método de recuperación; al retirar un servidor, cierre explícitamente sus alertas y accesos y decida la conservación de copias según la política. No borre la última copia útil solo porque desaparezca el servidor del inventario. Una fila se cierra cuando la prueba relevante vuelve a dar el resultado esperado y queda documentada la decisión.