Migración de DC a Proxmox: cómo desenredar el caos de Active Directory
Restaurar un controlador de dominio es el equivalente informático a desactivar una bomba que tú no montaste, con los ojos vendados, mientras todo el mundo a tu alrededor grita que lo reconstruyas de cero, como si eso ayudara cuando la dirección exige una solución inmediata.
Imagina la escena: una empresa está probando Proxmox, entusiasmada con dejar atrás VMware y ahorrarse un buen dinero en licencias. Todo está respaldado en Veeam, se han seguido todos los pasos, la restauración concluye sin errores y, de repente, la tarjeta de red virtual desaparece como si nunca hubiera existido. Sin tarjeta no hay inicio de sesión, no hay DNS, no hay nada; solo un controlador de dominio roto mirándote fijamente con esa fría y acusadora pantalla de inicio de sesión de Windows. Así arranca esta particular historia con Proxmox.
La clásica pesadilla de la tarjeta de red desaparecida
Tras restaurar los controladores de dominio en Proxmox, el equipo técnico no podía iniciar sesión con la cuenta DSRM porque la tarjeta de red ni siquiera aparecía en el sistema. Esta situación típica con los controladores VirtIO debería haber sido fácil de solucionar. Incluso intentaron el viejo truco de usar DISM para inyectar los controladores a mano, pero Proxmox simplemente se negó a cooperar.
Ahí es donde empieza el pánico. Cuando te quedas fuera de tu propio controlador de dominio tras una restauración, no solo tienes una máquina virtual estropeada: tienes una bomba de tiempo en toda la empresa. Cada autenticación, cada resolución de DNS y cada directiva de grupo quedan colgando de un hilo. A la dirección no le importa que sea un problema de controladores; lo único que entienden es que nadie puede iniciar sesión para trabajar.
Aparecen los defensores de no restaurar controladores de dominio
Ya sabes quién entra en escena en ese instante: los administradores de sistemas veteranos que han visto de todo y ya no se inmutan. Su consejo es siempre idéntico: "Nunca restaures un controlador de dominio. Reconstrúyelo de cero".
No les falta razón, pero cuando estás en mitad de una caída del servicio, oír que reconstruyas todo es lo último que quieres escuchar. Su lógica tiene sentido. Si conservas al menos un DC sano en la red, restaurar otro desde una copia de seguridad es buscarse problemas de corrupción: los números de secuencia de actualización (USN) se desincronizan, la replicación de SYSVOL se rompe y, de golpe, tu bosque de Active Directory parece la escena de un crimen. La jugada correcta es levantar una máquina virtual limpia, promocionarla como nuevo DC y transferir los roles FSMO de forma ordenada. Intenta explicárselo a alguien que observa un DC roto sobre un hipervisor nuevo con un responsable respirándole en la nuca porque el sistema de tornos y tarjetas de acceso ha dejado de funcionar.
Los problemas de controladores de los que nadie te advierte
Hablemos del problema con la tarjeta de red. Siempre es la tarjeta de red. La capa de virtualización cambió de VMware a Proxmox, y el nuevo hipervisor no sabe qué hacer con el controlador de red virtual anterior. Terminas en ese extraño limbo donde Windows asegura que no existe ningún adaptador de red en el equipo. Montas la ISO de VirtIO, intentas inyectar controladores manualmente, maldices un poco, lo intentas de nuevo y sigues sin conseguir nada.
Inevitablemente, alguien en algún rincón suelta la frase conocida: "Ponle una E1000, esa nunca falla". Técnicamente es verdad. El adaptador E1000 es la vieja mula de carga de los controladores de red: lento y básico, pero garantiza que el sistema arranque con red. Es como usar un teléfono de tapa en 2025: no sincronizará tus contactos modernos, pero al menos te permite pedir ayuda.
El verdadero truco consiste en configurar la dirección MAC de la nueva tarjeta para que coincida exactamente con la anterior, porque Active Directory y DNS son muy quisquillosos con ese detalle. Luego, en cuanto consigues entrar, instalas los controladores VirtIO como corresponde, cambias de adaptador y haces como si todo hubiera salido según el plan.
La regla no escrita: nunca apliques un rollback a un DC
Uno de los administradores con más experiencia en la conversación compartió una lección que bien merece un cartel en la pared:
"La clave aquí es NO revertir el estado del DC una vez que ha tocado la red".
Parece simple, pero es el error más habitual. En el momento en que un controlador de dominio tiene contacto con la red, sus números internos de replicación (los USN) avanzan. Si reviertes un snapshot de esa máquina virtual o restauras un backup después de ese punto, estás reescribiendo la historia, y Active Directory detesta los viajes en el tiempo. Te arriesgas a generar objetos persistentes obsoletos, compañeros de replicación huérfanos y, en el peor de los casos, un USN rollback completo que deja tu bosque seriamente dañado.
La opción segura pasa siempre por hacer la migración paso a paso: levantas un DC, dejas que replique al completo, ejecutas un dcdiag exhaustivo y solo entonces pasas al siguiente. Jamás migres más de uno al mismo tiempo.
Por qué la dirección detesta la solución correcta
El otro aspecto frustrante es que la solución correcta suele sonar más trabajosa. Cuando alguien propuso crear un DC nuevo desde cero, el equipo dudó porque implicaba actualizar la configuración de DNS en una pila de dispositivos estáticos como impresoras, escáneres y equipos heredados.
Es una tarea incómoda, desde luego. Nadie quiere tocar hardware antiguo que lleva funcionando sin problemas desde 2012. Pero esa incomodidad es deuda técnica pura, y es lo primero que se rompe cuando modernizas tu infraestructura. Ignorarla solo traslada el problema hacia adelante hasta la próxima migración, la próxima restauración o la próxima llamada de emergencia a las 3 de la madrugada porque nadie puede autenticarse. Reconstruir los controladores de dominio puede parecer trabajo extra, pero también es la vía más limpia para saldar esa deuda.
El villano encubierto: VMware Tools y los restos de Hyper-V
Otro administrador recordó un detalle que se olvida con demasiada frecuencia: antes de iniciar la migración, desinstala VMware Tools y los servicios de integración de Hyper-V. Esos componentes se aferran al sistema operativo como lapas y provocan todo tipo de comportamientos erráticos cuando la máquina virtual aterriza en Proxmox. Es el equivalente virtual a meter la batería de un Tesla dentro de una camioneta Ford: ambos son vehículos, pero las piezas no encajan de forma natural.
Elimina las herramientas antiguas, añade los controladores VirtIO antes de migrar y tu restauración dejará de parecer un exorcismo.
No todas las copias de seguridad son realmente restaurables
Esta es la realidad que duele: disponer de un backup no garantiza que puedas restaurarlo sin riesgos.
Los controladores de dominio funcionan de forma muy distinta a los servidores de archivos o bases de datos SQL. Son sistemas vivos, en constante cambio y en continua replicación que no toleran quedarse congelados en el tiempo. Restaurar uno resucita una versión de tu Active Directory que el resto del bosque ya ha dejado atrás. Es como clonar a un amigo mientras el clon sigue creyendo que está en 2023. De pronto tienes a los dos caminando por ahí e insistiendo en que son el original, y ya te puedes imaginar los problemas que vienen después.
La luz al final del túnel: la experiencia colectiva se impone
Tras el desconcierto y los debates iniciales, los pasos a seguir quedaron bien claros:
- Montar la ISO de controladores VirtIO.
- Instalar los controladores manualmente.
- Añadir una tarjeta de red temporal (E1000 o RTL8139) para recuperar la conectividad.
- Reconstruir la tarjeta original con los parámetros adecuados.
- Probar la replicación antes de poner en línea el siguiente DC.
- Por lo que más quieras, no vuelvas a restaurar un DC desde backup.
No había magia en la solución, solo la experiencia acumulada de romper cosas y arreglarlas de la forma más dura.
Qué enseña realmente este caso
La conclusión principal tiene menos que ver con Proxmox, Veeam o VirtIO que con comprender la naturaleza de un controlador de dominio. Un DC es el pilar de tu infraestructura de identidad, y tratarlo como una carga de trabajo ordinaria de copia y restauración es comprar billetes para el desastre.
Cuando cambies de hipervisor o renueves entornos, reconstruye tus controladores de dominio desde cero, migra los roles ordenadamente, valida la replicación y actualiza los DNS. Sí, resulta tedioso, pero es la única manera de dormir tranquilo cuando termine la migración.
Si tu DC falla, todo se viene abajo con él. Las impresoras dejan de responder, los inicios de sesión se bloquean y la cafetera de la oficina de repente te pide una contraseña que nadie recuerda. Reconstruir resulta pesado, pero es la molestia que te salva de un incidente capaz de arruinar tu reputación profesional.
Conclusión
Al final, la migración a Proxmox funcionó. Los controladores de dominio volvieron a estar operativos, los controladores VirtIO respondieron adecuadamente y la empresa aprendió por las malas que no existen atajos con Active Directory.
Proxmox es una plataforma excelente: ligera, de código abierto y potente. Sin embargo, a Active Directory le da igual lo moderno que sea tu hipervisor. Solo busca replicación limpia y redes estables, y si intentas engañarlo con una restauración rápida y un comando DISM a la desesperada, te recordará quién manda dejándote fuera de tu propia red.
Así que la próxima vez que alguien proponga restaurar un DC desde una copia de seguridad diciendo que no pasará nada, hazte un favor: apoya la taza de café en la mesa, míralo fijamente a los ojos y dile:
"O reconstruimos, o morimos en el intento".