Active Directory no suele morir con un estruendo. Se va quedando cojo: un único controlador de dominio que «aún tira», copias que respaldan carpetas pero no el estado del sistema, cuentas de gente que se fue en 2019 y un disco C: que lleva meses al 97 %. El viernes a las 18:30, cuando nadie de la plantilla de una PYME en Tenerife quiere oír hablar de FSMO ni de SYSVOL, ese deterioro se cobra el lunes entero. Este artículo no es un manual de certificación. Es la lista de errores caros que vemos en servidores Windows de empresas de la isla —y cómo evitarlos sin convertir el CPD en un proyecto de seis meses.
Si estáis decidiendo si el servidor se queda en el armario o se híbrida, leed también la comparativa de servidor on-premise frente a cloud. Aquí nos centramos en lo que ya tenéis encendido: el dominio, los parches y las decisiones que parecen menores hasta que no lo son.
Por qué AD se degrada (y por qué duele más en una oficina pequeña)
En una multinacional hay dos controladores, un procedimiento de altas y un contrato de mantenimiento informático con ventanas de parcheo. En una PYME de veinte personas el servidor suele ser «el de siempre»: un torre o un Dell de hace ocho años que hace de controlador de dominio, de file server, de servidor de impresión y, a veces, de host de una aplicación de gestión. Cuando ese único rol se estropea, no cae «un servicio». Caen los inicios de sesión, las carpetas, las impresoras y el programa con el que se factura.
Active Directory concentra identidades: quién entra, a qué carpeta, qué política de contraseña, qué equipo está o no en el dominio. Un error de AD no se arregla reinstalando Word. Se arregla con copias del estado del sistema, con un segundo DC o con muchas horas de alguien que sepa no empeorarlo. El coste no es la licencia de Windows Server. Es la jornada de una gestoría sin poder abrir expedientes, o un almacén que no imprime etiquetas.
En Canarias el agravante es el tiempo de reacción. Un partner que no pisa la isla o un técnico interno de vacaciones convierten un disco lleno en un fin de semana perdido. Por eso estos errores no son caprichos de informáticos. Son riesgos de continuidad. El artículo sobre qué pasa si el servidor cae un viernes describe el escenario; este, las causas que lo hacen más probable.
Tampoco es un problema solo de Windows antiguo. Un Server 2022 mal parcheado, con un solo DC y el antivirus desactivado «porque ralentiza», acumula la misma deuda. La versión del sistema operativo no perdona la arquitectura.
Error 1: un solo controlador de dominio (y el mito del «si falla, reinstalo»)
Un único DC es el clásico de las oficinas que crecieron sin que nadie redibujara el mapa. Funciona años. Hasta que el disco del sistema se llena, se corrompe una base NTDS o un apagón deja el equipo en un estado en el que no replica nada porque no hay con quién replicar. «Reinstalo Windows y creo el dominio otra vez» suena barato en la cabeza de quien no ha migrado perfiles, permisos NTFS, GPOs y un software de gestión atado al SID del dominio. En la práctica es una semana de oficina a medio gas y usuarios que ya no son los mismos objetos.
Un segundo controlador no tiene por qué ser un servidor caro en un rack redundante. En muchas PYMES basta un DC adicional en una máquina virtual, en un equipo decente o, en escenarios híbridos, una estrategia clara de identidades con Microsoft 365. Lo que no basta es «el portátil del dueño por si acaso». Un DC debe tener IP estable, copia, parches y que alguien sepa que existe.
Roles FSMO, catálogo global, DNS integrado: no hace falta que dirección recuerde las siglas. Sí que pregunte a su partner: «si se apaga ese torre, ¿alguien puede iniciar sesión e imprimir el lunes?». Si la respuesta es un silencio o un «restauramos el backup del servidor» sin matiz, tenéis un único punto de fallo. Restaurar un DC desde una copia mal hecha puede ser peor que el apagón: USN rollback, objetos fantasma, contraseñas que no coinciden.
En Tenerife vemos otro hábito: el DC único hace también de servidor de archivos en el mismo volumen. Un ransomware o un disco lleno por una carpeta de vídeos de un comercial tumba identidad y datos a la vez. Separar roles —aunque sea en dos máquinas virtuales en el mismo host— ya reduce el radio. Separar el host y tener copia del estado del sistema, más.
- Preguntad cuántos DC hay y dónde están físicamente.
- Comprobad que el DNS de los puestos apunta a esos DC, no a 8.8.8.8 «porque así navega mejor».
- No promocionéis un DC en un PC de usuario «para probar» y lo olvidéis: queda un punto débil.
- Documentad la password de Directory Services Restore Mode en un sitio que no sea un post-it en el propio servidor.
Error 2: copias de carpetas sin backup del estado del sistema
Copiar la unidad de datos a un NAS cada noche da una sensación de seguridad muy agradable. No restaura Active Directory. El estado del sistema (system state) incluye el registro, SYSVOL, la base NTDS y trozos sin los cuales un Windows Server miembro de un dominio no vuelve a ser el mismo servidor. Una copia de archivos «de las carpetas de usuarios» os salva los PDF. No os salva el dominio.
El error se detecta el día que hay que recuperar el DC: el software de backup nunca se configuró para system state, o se configuró y lleva ocho meses en rojo porque el agente caducó. Nadie lo mira. En un contrato serio de servidor, la revisión de jobs de backup —éxito, tamaño, tiempo, alerta— es tan rutinaria como el café. Si vuestro «backup» es un robocopy lanzado a mano, no tenéis restauración de AD.
También falla el otro extremo: una imagen completa del servidor que nunca se ha levantado en otro hardware o en una VM de prueba. Las imágenes mienten hasta que arrancan. Un restore test anual de system state, en ventana controlada, es aburrido y barato comparado con un dominio irrecuperable. En Infofase lo tratamos como parte del diseño de servidores para empresas, no como un extra exótico.
Si el backup vive en el mismo host o en un NAS unido al dominio con las mismas credenciales de administrador, un ransomware o un error de borrado se lleva producción y copia. Ahí el error de AD se cruza con el de copias. No es casualidad: los incidentes feos suelen ser dos fallos a la vez, no uno.
Lista mínima que un gerente puede exigir por escrito: hay copia de system state; hay alerta si falla; hay una copia que el dominio no puede borrar; se ha restaurado al menos una vez en los últimos doce meses en un entorno de prueba. Si alguna casilla es no, el riesgo no es teórico.
Error 3: cuentas de ex-empleados, «admin» compartido y privilegios eternos
La persona se fue en agosto. La cuenta sigue habilitada en enero «por si hay que consultar un archivo». A veces la contraseña es la misma que usaba en el correo. A veces es miembro de Domain Admins porque «así no había que pedir permisos». Ese es el escenario que un atacante espera: credenciales válidas, sin MFA, con más derechos de los que el puesto necesitaba.
El ritual correcto es aburrido y no se improvisa el último viernes. Deshabilitar el mismo día de la baja, quitar de grupos privilegiados, reasignar buzón y OneDrive, revisar reglas de reenvío, rotar contraseñas de cuentas de servicio que esa persona conocía, y un inventario de VPN y de acceso a NAS. Si el ex-empleado era «el que sabía de informática», el riesgo sube: puede que tenga copias de contraseñas en un gestor personal o en un Excel.
El usuario «Administrador» con una contraseña de 2016 que todo el mundo conoce es el primo del error anterior. No hay auditoría posible si cinco personas entran como el mismo admin. Cuentas nominativas, privilegios justos, y una cuenta break-glass guardada fuera del día a día. En entornos híbridos, el equivalente es un Global Admin de Microsoft 365 compartido en un WhatsApp de gerencia. Mismo veneno, otra consola.
Las cuentas de servicio —SQL, copias, antivirus, aplicaciones de gestión— merecen una mención. Se crean con Domain Admin «para que funcionen», se olvidan y nunca se rotan. Un malware que robe ese hash tiene las llaves. El endurecimiento de AD (tiering, LAPS para administradores locales, menos exposición RDP) es el trabajo de ciberseguridad en empresa; el primer paso es dejar de tener veinte administradores de dominio.
En talleres, clínicas y comercios de la isla es frecuente el puesto «de práctica» o el PC del almacén con una sesión siempre abierta de un usuario privilegiado. No es un detalle de higiene. Es la sesión que se usa cuando alguien enchufa un USB o abre el correo de la factura falsa.
Error 4: WSUS, parches y el servidor que «mejor no tocar»
Windows Server sin parchear es una de las deudas más fáciles de explicar y más difíciles de cobrar: «si lo actualizo, deja de ir el programa de siempre». A veces es verdad que un ERP viejo odia un cumulative. A veces es superstición de 2014. El resultado es un DC o un file server con vulnerabilidades de hace años, RDP expuesto «un rato» y un WSUS que nadie ha mirado desde que lo instaló un técnico de paso.
WSUS mal cuidado es peor que no tenerlo: los puestos creen que se actualizan, el servidor no aprueba nada y el disco se llena de parches que nadie limpia. El disco al 100 % —siguiente error— a menudo nace aquí. Un plan de parches no es «martes de Microsoft a lo loco en producción». Es: inventario de qué no se puede tocar sin proveedor de la aplicación, ventana mensual, copia previa, y un criterio para críticos de seguridad fuera de ciclo.
Si no hay WSUS ni Intune ni ningún control, cada PC se actualiza cuando el usuario no cancela el reinicio. El servidor, nunca. Esa asimetría es exactamente lo que busca un exploit de privilegios locales o de un servicio expuesto. No hace falta un APT. Hace falta un script y un puerto 3389 abierto a Internet «porque el contable entra desde casa».
En 2026, además, el fin de soporte de sistemas antiguos no es un rumor. Un Server 2012 R2 o un Windows 10 que ya no recibe parches no se «aguanta un año más» de forma gratuita: se paga en riesgo. El recambio se presupuesta; no se niega. Quien compare esto con el coste de un técnico interno frente a outsourcing verá que el parcheo rutinario es precisamente el trabajo que un único perfil no cubre cuando está de baja o de vacaciones.
Error 5: disco al 100 %, logs que no rotan y el viernes que no arranca
El disco del sistema lleno es el incidente más evitable y más frecuente. WSUS, IIS, perfiles de usuario que se han ido al C:, copias locales olvidadas, un SQL que crece, dumps de memoria y la papelera de reciclaje de administrador. Windows empieza a fallar de formas poco elegantes: no aplica GPOs, no replica, no escribe logs, el escritorio se vuelve lento y, en el peor momento, el servicio de AD o de copias se detiene.
La prevención es prosaica: alertas de umbral (80 %, 90 %), perfiles y datos fuera del volumen del sistema, limpieza controlada de WSUS, y que nadie use el DC como almacén de ISO y de fotos de la cena de empresa. Cuando el disco ya está al 100 %, no es el momento de «borrar a ojo» carpetas de Windows. Es el momento de un técnico que sepa qué se puede mover y de una copia previa si aún se puede hacer.
Los logs importan el día del incidente y el día que el servidor no arranca. Si el registro de eventos está a tope y no hay retención, perdéis la historia. Si no hay espacio, el propio sistema deja de registrar. Es un círculo feo. Monitorizar espacio y servicios de AD (replicación, DNS, Netlogon) es menos glamuroso que comprar un servidor nuevo. Evita comprar un servidor nuevo de urgencia un viernes.
Un detalle isleño: el aire acondicionado del cuarto de comunicaciones se estropea en agosto, el torre térmica se va de temperatura y el disco muere o el equipo se apaga solo. El error no es solo de software. Un servidor de empresa no vive debajo del mostrador junto a la fotocopiadora. Polvo, calor y un SAI muerto son tan Active Directory como una GPO mal aplicada: el dominio no inicia si el hardware no inicia.
Cómo priorizar el arreglo sin rehacer el mundo
No hace falta un proyecto de rediseño para dejar de dormir mal. Un orden que funciona en PYMES: uno, inventario honesto (un DC o dos, dónde está el DNS, qué backup hay de system state). Dos, espacio en disco y alertas. Tres, cuentas privilegiadas y bajas pendientes. Cuatro, RDP y VPN fuera de Internet abierto. Cinco, segundo DC o, al menos, una restauración probada. Seis, parches con ventana. Siete, no mezclar file server sensible en el mismo volumen del sistema si se puede evitar.
Si el hardware ya dio su vida útil, el rediseño —virtualización, NAS, identidades híbridas— se planifica; no se niega hasta el apagón. En el caso de Canary Islands Consulting se ve un enfoque de servidor, red y copias pensados juntos. No todas las empresas necesitan ese alcance. Todas necesitan no tener un único DC sin system state y con el C: al 99 %.
Pedid al partner un informe de una página, no un novelón. Estado del dominio, copias, cuentas admin, parches, espacio, y tres acciones de los próximos treinta días. Si el informe no cabe en una página, suele ser porque nadie ha mirado el servidor en dos años y ahora todo es urgente. Urgente y caro son primos.
Infofase trabaja con técnicos propios en la isla: no es lo mismo un remoto que no puede cambiar un disco que alguien que entra, ve el SAI en bypass y el switch sin UPS. El catálogo de servicios cubre servidor y mantenimiento; el artículo, el criterio para no pagar dos veces el mismo error.
Preguntas frecuentes
¿Hace falta un segundo servidor físico solo para Active Directory?
No siempre. En muchas PYMES un segundo DC virtual en un host decente, con copia y parches, ya corta el riesgo de «se apagó el torre y no entra nadie». Lo que no sustituye un segundo DC es una imagen que nunca se ha restaurado o un disco USB en el cajón. Preguntad por el coste de un DC adicional frente al coste de un lunes sin dominio en Tenerife.
¿Sirve una copia de las carpetas de usuarios para recuperar el dominio?
No. Eso recupera ficheros. El dominio necesita system state o una estrategia de recuperación de DC documentada y probada. Si solo habéis respaldado «los datos», asumid que un desastre de AD es un proyecto, no un restore de una hora.
¿Dejamos las cuentas de ex-empleados por si hay que consultar un archivo viejo?
No. Se deshabilitan al salir, se retiran privilegios y, si hace falta un archivo, se recupera con una cuenta actual y un procedimiento. Una cuenta viva de alguien que ya no está es una puerta. El archivo se puede guardar; la identidad, no.
¿Es peligroso actualizar Windows Server si el ERP es antiguo?
Puede ser delicado; por eso existe la ventana, la copia y, a veces, el proveedor de la aplicación. Lo peligroso de verdad es no actualizar nunca y exponer RDP. Un partner con cabeza no parchea a lo loco un viernes de cierre. Tampoco deja un Server sin soporte «porque aún abre».
El disco C: está al 95 %. ¿Borramos la carpeta Windows.old y ya?
No a ciegas. Algunos limpiados son seguros; otros rompen el sistema. Primero, copia si es posible y un técnico que distinga WSUS, perfiles, logs y basura real. Un DC al 100 % no es un sitio para experimentar con el Liberador de espacio a las 19:00.
¿Active Directory sigue teniendo sentido si ya usamos Microsoft 365?
En muchos casos, sí, de forma híbrida: el dominio local sigue mandando en impresoras, ERP y carpetas, y las identidades se sincronizan. En otros, se puede ir a un modelo más cloud. Lo que no se puede es tener un AD abandonado «porque el correo ya está en la nube». Ese AD abandonado sigue siendo el que abre las puertas de la oficina.
