En este post me gustaría explicar un poco más sobre las instantáneas de Active Directory, y cómo se pueden o no utilizar.

En primer lugar, dejemos una cosa muy clara: ¡no se admiten las instantáneas de máquinas virtuales de controladores de dominio!

Permíteme repetir que si tienes un controlador de dominio virtualizado, y estás planeando tomar una instantánea de esa máquina virtual desde tu host (Hyper-V, VMWare o cualquier proveedor de nube pública) ¡detente!

Puede leer aquí, según lo declarado oficialmente por Microsoft http://technet.microsoft.com/en-us/library/virtual_active_directory_domain_controller_virtualization_hyperv(WS.10).aspx

No tome ni utilice una instantánea de un controlador de dominio virtual".

Lo mismo ocurre con la copia del disco duro virtual de un controlador de dominio, el uso de discos de diferenciación o cualquier otra función aún no inventada de retroceder en el tiempo la propia máquina virtual sin utilizar un método de copia de seguridad y restauración compatible.

Ahora, hablemos un poco del por qué.

Cuando los Controladores de Dominio replican utilizan un mecanismo llamado vector de actualización para rastrear los cambios replicados.

Digamos que tenemos dos controladores de dominio DC1 y DC2, ambos DCs en el dominio corp.contoso.com. Cada uno de estos controladores de dominio tendrá un número de secuencia de actualización local (USN) que rastrea los cambios realizados en la base de datos local. Estos USN son locales y no se replican (de ahí que sean diferentes entre los dos controladores de dominio).

Piense en los USN como contadores que cuentan los cambios realizados en cada DC localmente, un ejemplo de la vida real podría ser un guardia de seguridad a la entrada de un concierto contando la gente que entra. Ahora piense que este concierto tiene dos puertas, con dos guardias de seguridad. ¿Sería el mismo número? Seguro que no.

Digamos que nuestro DC1 tiene un USN comprometido máximo de 5000, y el DC2 tiene un USN comprometido máximo de 6000. (Volviendo al ejemplo de los guardias de seguridad, el guardia de seguridad nº 1 ha contado 5.000 personas entrando y el guardia de seguridad nº 2 ha contado 6.000 personas entrando).

Entonces, ¿qué tiene que ver con el vector up to dateness? Bueno, el vector UTD mantiene una lista local en cada DC de cuál fue el USN comprometido más alto en el intento de replicación anterior. Por lo tanto, si activamos la replicación en el estado actual, después de que termine con éxito el vector UTD en DC1 mostraría:

DC2 6000

Y el Vector UTD en el DC2 se mostraría:

DC1 5000

Nota: puede visualizar el vector de actualización utilizando el comando repadmin:

Repadmin /showutdvec DCName PartitionDN

Así que si volvemos al ejemplo de los guardias de seguridad, eso significa que en algún momento se llaman unos a otros diciendo: "Oye, he contado hasta 5.000 personas", aquí están sus nombres, y el otro dice: Genial, he contado hasta 6000, aquí están sus nombres.

Veamos ahora lo que ocurre durante una recuperación de instantáneas (hacer retroceder el servidor en el tiempo).

Digamos que recuperamos DC1 a un punto en el tiempo donde su USN comprometido más alto era 3000. Ahora recuerde, la tabla de vectores UTD en DC2 todavía almacena el valor de DC1 más alto comprometido USN como 5000. Cuando intentan replicar DC1 dice, hey tengo cambios hasta 3000. DC2 'le mira raro' y dice 'pero la última vez que replicamos tenías cambios hasta 5000′ ¿qué pasa?

¿El ejemplo de los guardias de seguridad? Después de esa primera llamada telefónica, viene otra llamada telefónica donde el guardia de seguridad # 1 dice 'Hey, conté hasta 3000 personas.', ¿respuesta del guardia de seguridad # 2? La última vez que hablamos dijiste que habías contado hasta 5000', ¿qué pasa?

¿Ves el problema?

Esta situación se denomina USN rollback, y en ese momento los DC dejaron de hablar entre sí y de replicar cualquier información.

¿Cómo se soluciona esto?

Cuando restaura utilizando un método compatible, el proceso de restauración cambia realmente la forma en que el controlador de dominio aparece en la tabla de vectores de actualización, cambiando el GUID de la base de datos (también denominado InvocationID). Las entradas en el vector de actualización no son en realidad nombres de DC, sino los GUID de base de datos de los controladores de dominio que se replican para el contexto de nomenclatura específico.

Nota: al ejecutar Repadmin /showutdvec DCName PartitionDN /nocache se mostrarán los GUIDs mencionados.

Así, cuando se restaura un DC utilizando un método compatible, el GUID de la base de datos cambia, por lo que DC2 sabe que ahora no está replicado con DC1, sino con DC1a (que sigue teniendo el mismo nombre de equipo, GUID de servidor, etc, pero tiene una base de datos AD diferente, que es lo que importa para la replicación).

Por lo tanto, en ese escenario es como si DC2 hubiera comenzado a replicarse con un nuevo controlador de dominio, por lo que no se produce ninguna reversión de USN.

Esta es la explicación completa de por qué no se admiten las instantáneas.

Una vez aclarado esto, ¿qué son unas buenas instantáneas?

Las buenas instantáneas son las que se hacen usando el comando ntdsutil, que usa VSS bajo las capuchas para crear una instantánea de la base de datos de Active Directory. Estas instantáneas no se pueden utilizar para restaurar la base de datos (exactamente por la misma razón que se explicó anteriormente), pero se pueden montar, inspeccionar, y alguna información se puede extraer de ellos, y se inserta en la base de datos de producción por herramientas como ldifde.exe y otros, pero más en instantáneas AD en posts posteriores.

Una lección importante de este artículo. Utilice la copia de seguridad del estado del sistema para realizar copias de seguridad de los controladores de dominio y asegúrese de saber cómo restaurarlas en todos los casos posibles.