Virtualización de controladores de dominio con Hyper-V

Se aplica a: Windows Server 2022, Microsoft Hyper-V Server 2019, Windows Server 2019, Microsoft Hyper-V Server 2016, Windows Server 2016, Windows Server 2012 R2 y Windows Server 2012

Windows Server 2012 y versiones posteriores admiten controladores de dominio (DC) virtualizados con protecciones para evitar la reversión del número de secuencia de actualización (USN) en DC virtuales y la capacidad de clonar DC virtuales. La virtualización consolida diferentes roles de servidor en una única máquina física. Para obtener más información, consulte el tema sobre la virtualización segura de Active Directory Domain Services (AD DS).

Esta guía describe cómo ejecutar los DC como sistemas operativos invitados de 32 o 64 bits.

Planeamiento de la virtualización

Las siguientes secciones contienen consideraciones de planificación que debe conocer al virtualizar un DC, incluidos los requisitos de hardware, la arquitectura, la configuración y la gestión de la seguridad y el rendimiento.

Requisitos de Hyper-V

Para instalar y utilizar el rol Hyper-V, su hardware debe cumplir los siguientes requisitos:

• Debe tener un procesador x64.

• Su procesador debe permitirle habilitar la función de virtualización asistida por hardware.

  • Normalmente, esta configuración se conoce como Tecnología de virtualización de Intel (Intel VT) o Virtualización avanzada de micro dispositivos (AMD-V).

• Las siguientes secciones contienen consideraciones de planificación que debe conocer al virtualizar un DC, incluidos los requisitos de hardware, la arquitectura, la configuración y la gestión de la seguridad y el rendimiento.

  • Solo puede utilizar Hyper-V si activa el bit de desactivación de ejecución de Intel (XD) o el bit de no ejecución de AMD (NX).

Evite los puntos únicos de fallo

Al planificar la implementación de su DC virtual, debe preparar una estrategia para evitar la creación de puntos únicos de fallo. Puede evitar la introducción de posibles puntos únicos de fallo, o áreas en las que el tiempo de inactividad puede provocar que todo el sistema deje de funcionar, implementando la redundancia del sistema.

Las siguientes recomendaciones pueden ayudar a evitar los puntos únicos de fallo. Sin embargo, también es importante recordar que seguir estas recomendaciones puede aumentar los costes de administración.

• Ejecute al menos dos controladores de dominio virtualizados por dominio en diferentes hosts de virtualización. Esta configuración reduce el riesgo de perder todos los DC si un host de virtualización deja de funcionar.

• Diversifique el hardware que ejecuta sus DC. Por ejemplo, utilice diferentes CPU, placas base, adaptadores de red, etc. Un hardware diverso previene daños por mal funcionamiento de dispositivos y hardware o por configuración del proveedor.

• Si es posible, ejecute sus DC en hardware ubicado en diferentes regiones. Este enfoque reduce las consecuencias de los desastres que afectan a uno de los sitios que alojan sus DC.

• Añada DC físicos a todos sus dominios. Configurar su sistema para tener DC físicos evita que sus sistemas host experimenten fallos de funcionamiento de la plataforma de virtualización.

Consideraciones sobre la seguridad

Debe administrar el equipo host donde ejecuta sus DC virtuales con el mismo cuidado que lo haría con un DC con escritura, incluso si el equipo es solo un equipo unido a un dominio o a un grupo de trabajo. Este requisito es por razones de seguridad. Los hosts mal gestionados son vulnerables a los ataques de elevación de privilegios, en los que usuarios malintencionados obtienen acceso a privilegios superiores a los que se supone que deben tener porque el administrador asignó el nivel incorrecto de permiso a una asignación de rol de nivel inferior. Estos ataques pueden comprometer todas las máquinas virtuales (VM), dominios y bosques alojados en el equipo afectado.

Cuando planee virtualizar su DC, tenga en cuenta las siguientes consideraciones de seguridad:

• Las credenciales de administrador local de un equipo que aloja DC virtuales escribibles deben tratarse como iguales a las del administrador de dominio predeterminado de todos los dominios y bosques a los que pertenecen esos DC.

• Le recomendamos que configure su sistema para tener un host que ejecute una instalación Server Core de Windows Server sin aplicaciones aparte de Hyper-V. Esta configuración limita el número de aplicaciones y servidores que puede instalar en el servidor. Esta limitación resulta en un mejor rendimiento del sistema y también crea una superficie de ataque reducida, donde hay menos puntos de entrada para ataques maliciosos a través de aplicaciones y servicios.

• Para sucursales u otras ubicaciones difíciles de asegurar, le recomendamos que utilice DC de solo lectura (RODC). Si dispone de una red de gestión independiente, le recomendamos que solo conecte el host a la red de gestión. Para obtener más información sobre los RODC, consulte Instalación de un controlador de dominio de solo lectura (RODC) de Active Directory de Windows Server (Nivel 200).

• Puede proteger sus DC con BitLocker. En Windows Server 2016 y versiones posteriores, también puede utilizar la función virtual Trusted Platform Module (TPM) que proporciona el material de clave de invitado necesario para desbloquear el volumen del sistema.

• Las máquinas virtuales blindadas y tejido protegido pueden proporcionar más controles para proteger los DC.

Para obtener más información sobre la protección de los DC, consulte la Guía de procedimientos recomendados para proteger Active Directory.

Límites de seguridad para configuraciones de host e invitado

Puede implementar máquinas virtuales (VM) en muchos tipos diferentes de configuraciones de DC. Por lo tanto, debe considerar cuidadosamente cómo esas VM afectan los límites y las confianzas en su topología de Active Directory. La siguiente lista describe dos configuraciones que se pueden establecer para los DC y hosts de Active Directory en un servidor Hyper-V y equipos invitados que son VM que se ejecutan en el servidor Hyper-V:

• Un host que es un grupo de trabajo o un equipo miembro con un invitado que es un DC.
• Un host que es un grupo de trabajo o equipo miembro con un invitado que también es un grupo de trabajo o equipo miembro.

El siguiente diagrama muestra una configuración de tres máquinas virtuales DC invitadas alojadas en un servidor Hyper-V.

Diagrama de un ejemplo de implementación de tres máquinas virtuales (VM) y un servidor Hyper-V. Las tres VM están dentro de un rectángulo azul etiquetado como "máquinas invitadas". Las tres VM son controladores de dominio. VM 1 está en el dominio Corp y en el bosque Contoso.com. VM2 está en el dominio Fabrikam y en el bosque Fabrikam.com. VM 3 está en el dominio HQ y en el bosque Fineartschool.net. El servidor Hyper-V está fuera del rectángulo azul. Es un servidor miembro situado en el dominio Corp y el bosque Contoso.com.

Basado en el ejemplo de configuración en el diagrama anterior, aquí hay algunas consideraciones importantes que debe hacer al planificar una implementación como esta:

• Acceso de administrador

  • Las credenciales de administrador en el equipo host deben tratarse igual que las del administrador del dominio en el DC con permisos de escritura. Para un RODC invitado, las credenciales de administrador del equipo host deben tratarse igual que las del administrador local en el RODC invitado.

• Derechos administrativos del DC en el equipo host

  • Un administrador de un DC virtualizado tiene derechos administrativos sobre el host si une el host al mismo dominio. Sin embargo, este privilegio de acceso también puede dar a los usuarios maliciosos la oportunidad de comprometer todas las máquinas virtuales si pueden obtener acceso a la máquina virtual 1. Este escenario crea un posible vector de ataque. Puede evitar este vector de ataque asegurándose de que cualquier DC configurado para múltiples dominios o bosques tenga un dominio de administración centralizado en el que confíen todos los dominios, y haga que el host de virtualización sea miembro del dominio de administración con privilegios elevados. Este enfoque evita que los administradores de dominio individuales controlen el host y, por lo tanto, los otros dominios.

• Evitar ataques

  • Los usuarios maliciosos pueden atacar la VM 1 incluso si la instala como un RODC. Aunque los administradores RODC no tengan explícitamente derechos de administrador de dominio, pueden utilizar el RODC para aplicar políticas al equipo host. Estas políticas pueden incluir, por ejemplo, scripts de inicio. Si un actor malicioso encuentra una forma de obtener derechos de administrador RODC y envía una política con un script de inicio malicioso, puede comprometer el equipo host y utilizarlo para comprometer otras máquinas virtuales en el host.

• Seguridad de archivos de disco duro virtual (VHD)

  • Los archivos VHD de un DC virtual son como el disco duro físico de un DC físico. Debe ser tan cuidadoso asegurando el archivo VHD como lo haría con un disco duro. Asegúrese de que solo permite el acceso a estos archivos VHD a administradores fiables y de confianza.

• RODC

  • Puede colocar RODC en ubicaciones donde la seguridad física no esté garantizada, como sucursales. Puede proteger sus archivos VHD utilizando el Cifrado de unidad BitLocker de Windows contra ataques al host que impliquen el robo del disco físico. Sin embargo, estas protecciones no se aplican a los sistemas de archivos dentro del RODC.

Consideraciones de rendimiento

La arquitectura Microkernel de 64 bits mejora el rendimiento de Hyper-V con respecto a plataformas de virtualización anteriores.

El rendimiento de la VM depende de la carga de trabajo para la que se utilice. Le recomendamos que pruebe topologías de VM específicas para asegurarse de que está satisfecho con el rendimiento de la implementación de Active Directory. Puede evaluar el rendimiento bajo cargas de trabajo durante un período de tiempo específico utilizando herramientas como el Monitor de fiabilidad y rendimiento (Perfmon.msc) o el kit de herramientas Microsoft Assessment and Planning (MAP). La herramienta MAP también puede ayudarle a realizar un inventario de todos los servidores y roles de servidor que se encuentran actualmente en su red.

Para que se haga una idea de cómo funcionan las pruebas de rendimiento de los DC virtualizados, hemos creado una prueba de rendimiento de ejemplo utilizando la Herramienta de pruebas de rendimiento de Active Directory (ADTest.exe).

Las pruebas del Protocolo ligero de acceso a directorios (LDAP) se realizaron en un DC físico utilizando ADTest.exe. Las mismas pruebas se ejecutaron en un DC virtualizado que consistía en una VM alojada en un servidor idéntico al DC físico. En esta compilación de ejemplo solo se utilizó un procesador lógico para el equipo físico y solo un procesador virtual para la VM. Esta configuración permitió que la implementación alcanzara fácilmente el 100 % de utilización de la CPU.

La siguiente tabla muestra los resultados de las pruebas para los DC físicos y virtuales. Las letras y números entre paréntesis junto a los nombres de las pruebas son sus etiquetas en ADTest.exe. Estos datos muestran que el rendimiento del DC virtualizado se situó entre el 88 y el 98 por ciento del rendimiento del DC físico.

Medición	Probar	virtuales físicas	Las máquinas	Delta
Búsquedas/seg.	Buscar nombre común en el alcance base (L1)	11508	10276	-10.71 %
Búsquedas/seg.	Buscar un conjunto de atributos en el alcance base (L2)	10123	9005	-11.04 %
Búsquedas/seg.	Buscar todos los atributos en el alcance base (L3)	1284	1242	-3.27 %
Búsquedas/seg.	Buscar nombre común en el alcance de subárbol (L6)	8613	7904	-8.23 %
Enlaces correctos/seg.	Realizar enlaces rápidos (B1)	1438	1374	-4.45 %
Enlaces correctos/seg.	Realizar enlaces simples (B2)	611	550	-9.98 %
Enlaces correctos/seg.	Usar NTLM para realizar enlaces (B5)	1068	1056	-1.12 %
lógicas/s	Escribir varios atributos (W2)	6467	5885	-9.00 %

Para maximizar el rendimiento en nuestra implementación de prueba, instalamos componentes de integración (IC) en esta compilación de prueba para permitir que el SO invitado utilice controladores sintéticos compatibles con el hipervisor. Cuando se instala un CI, a veces es necesario utilizar controladores emulados de electrónica de unidad integrada (IDE) o adaptadores de red. En entornos de producción, debe reemplazar estos controladores emulados con controladores sintéticos para aumentar el rendimiento.

Basándose en esta prueba, considere las siguientes recomendaciones para mejorar el rendimiento:

• Cuando monitoriza el rendimiento de la VM utilizando la herramienta Perfmon.msc, a veces la información de la CPU para la VM no es del todo precisa. Esta imprecisión se debe a la forma en que la CPU virtual está programada para ejecutarse en el procesador físico. Para obtener información más precisa sobre la CPU de las máquinas virtuales que se ejecutan en servidores Hyper-V, utilice los contadores del procesador lógico del hipervisor Hyper-V en la partición host. Para obtener más información sobre el ajuste de rendimiento de AD DS e Hyper-V, consulte Directrices de optimización del rendimiento para Windows Server.

• Le recomendamos que evite utilizar VHDs de disco diferenciado en una VM configurada como DC, ya que los VHDs de disco diferenciado pueden reducir el rendimiento. Para obtener más información sobre los tipos de disco Hyper-V, incluidos los discos de diferenciación, consulte el Asistente para nuevos discos duros virtuales.

• También le recomendamos que se familiarice con la información sobre cómo utilizar AD DS en entornos de host virtual leyendo Cosas a tener en cuenta cuando aloje DCs de Active Directory en entornos de alojamiento virtual.

Consideraciones de la implementación

En las secciones siguientes se describen las prácticas comunes de máquina virtual para evitar al implementar DC y consideraciones especiales para la sincronización y el almacenamiento de tiempo.

Recomendaciones de implementación

Las plataformas de virtualización como Hyper-V tienen muchas características que facilitan la gestión, el mantenimiento, las copias de seguridad y la migración de máquinas. Sin embargo, hay ciertas recomendaciones que debe seguir para aprovechar estas características para sus DC virtuales.

• Para garantizar que las escrituras de Active Directory sean duraderas, no implemente archivos de base de datos de DC virtuales, como la base de datos de Active Directory NTDS.DIT, los registros y SYSVOL, en discos IDE virtuales. En su lugar, cree un segundo disco duro virtual (VHD) conectado a una controladora virtual Small Computer System Interface (SCSI) y asegúrese de que los archivos de la base de datos se encuentran en el disco SCSI VM cuando instale el DC.

• No implemente VHD de disco diferenciado en una VM que esté configurando como el DC. Si bien este enfoque facilita la reversión de la implementación a versiones anteriores, también disminuye el rendimiento. Para obtener más información sobre los tipos de VHD, consulte el Asistente para crear nuevos discos duros.

• No implemente dominios y bosques de Active Directory en una copia de un SO Windows Server sin utilizar antes la herramienta de preparación del sistema (sysprep) para prepararlos para la implementación. Para más información sobre cómo ejecutar Sysprep, consulte Información general sobre Sysprep (preparación del sistema).

  Advertencia

  No se recomienda ejecutar Sysprep en un DC promocionado, ya que puede afectar negativamente a la base de datos de AD y a los componentes relacionados y provocar los siguientes problemas:

  • Pérdida de datos
  • Corrupción de la base de datos de AD
  • Problemas de estabilidad y funcionalidad
  • Problemas con aplicaciones, servicios y controladores

• No implemente otros DC con una copia de un archivo VHD de un DC que haya implementado. No utilizar copias evita posibles situaciones de reversión de USN. Para obtener más información sobre la reversión de USN, consulte USN y reversión de USN.

  • En Windows Server 2012 y versiones posteriores, los administradores pueden clonar imágenes de DC para implementar más DC, pero solo si utilizan imágenes preparadas correctamente.

• No utilice la función de exportación de Hyper-V para exportar una máquina virtual que esté ejecutando un DC.

  • En Windows Server 2012 y posteriores, el sistema gestiona la exportación e importación de invitados virtuales de DC como una restauración no autorizada. Este proceso detecta si el ID de generación ha cambiado y si el DC no está configurado para la clonación.

  • Cuando exporte una máquina virtual invitada, debe asegurarse de que nadie la está utilizando. Para facilitar las cosas, puede utilizar Hyper-V Replication para crear una copia inactiva del DC. Cuando empiece a utilizar la imagen replicada, también debe realizar la limpieza como lo haría para la imagen de origen después de exportar una imagen de invitado de DC.

Conversión de físico a virtual

System Center VM Manager (VMM) le permite gestionar máquinas físicas y VM de forma unificada. También puede utilizar VMM para migrar un equipo físico a una VM. Este proceso de migración se denomina conversión de máquina física a VM, o conversión P2V. Para iniciar el proceso de conversión P2V, debe asegurarse de que la VM y el DC físico que está migrando no se están ejecutando al mismo tiempo. Asegurarse de que las dos máquinas no se están ejecutando al mismo tiempo evita escenarios de reversión de USN, como se describe en USN y reversión de USN.

Debe realizar la conversión P2V en modo sin conexión para mantener la coherencia de los datos de directorio cuando vuelva a encender el DC. Puede activar el modo sin conexión en el instalador Convertir servidor físico. Para obtener más información sobre cómo utilizar el modo sin conexión, consulte P2V: Convertir equipos físicos en VM en VMM.

También debe desconectar la VM de la red durante la conversión P2V. Solo debe habilitar el adaptador de red después de finalizar el proceso de conversión y verificar que todo funcione. En ese momento, debe apagar la máquina fuente física. No vuelva a encender el equipo fuente físico ni lo conecte a la red hasta que haya reformateado el disco duro.

Cómo evitar la reversión de USN

Cuando cree DCs virtuales, debe evitar crear escenarios de reversión de USN. Para evitar la reversión, puede configurar un nuevo DC virtual con la promoción normal, la promoción desde Install from Media (IfM) o clonando el DC si ya tiene al menos un DC virtual. Este enfoque también le permite evitar problemas de hardware o de plataforma que los invitados virtuales convertidos a P2V podrían encontrar.

Advertencia

Para evitar problemas con la replicación de Active Directory, asegúrese de que solo existe un DC físico o virtual en una red determinada en un momento dado. Puede reducir la probabilidad de que el clon antiguo sea un problema mediante uno de los métodos siguientes:

• Cuando el nuevo DC virtual se esté ejecutando, ejecute el siguiente comando dos veces para cambiar la contraseña de la cuenta del equipo:

  netdom resetpwd /Server:<domain-controller>
  

• Exporte e importe el nuevo invitado virtual para forzar que se convierta en un nuevo identificador de generación y un identificador de invocación de base de datos.

Entornos de prueba y migración de FaV

Puede utilizar la migración P2V en combinación con el VMM para crear entornos de prueba. Con este método, puede migrar los DC de producción de máquinas físicas a máquinas virtuales para crear un entorno de prueba sin tener que desactivar permanentemente los DC de producción. Sin embargo, debe crear el entorno de prueba en una red separada del entorno de producción para permitir que existan dos instancias del mismo DC. Es importante evitar las reversiones de USN al crear entornos de prueba mediante la migración P2V.

Creación de un entorno de prueba

Le recomendamos que haga lo siguiente cuando cree entornos de prueba utilizando P2V:

• Migre un DC en producción de cada dominio a una VM de prueba utilizando P2V basándose en las recomendaciones de Conversión de físico a virtual.

• Coloque los equipos físicos de producción y las máquinas virtuales de prueba en redes diferentes cuando los vuelva a poner en línea.

• Para evitar retrocesos de USN en el entorno de prueba, desconecte de la red todos los DC que planea migrar. Puede desconectar los DC deteniendo el servicio NTDS o reiniciando los equipos en modo de restauración de servicios de directorio (DSRM).

• No introduzca ninguna actualización nueva en el entorno después de desconectar los DC de la red.

• No conecte ninguno de los equipos a la red durante la migración P2V. Solo podrá volver a conectarlos una vez haya terminado de migrar todos los equipos.

• Solo debe promover los DC de prueba que realice después de la conversión P2V como réplicas en el entorno de prueba.

Servicio de hora y sincronización

Para las máquinas virtuales que haya configurado como DC, le recomendamos que desactive la sincronización horaria entre el sistema host y el sistema operativo invitado que actúa como DC. Si el DC invitado no se sincroniza con el sistema anfitrión, entonces se sincroniza con la jerarquía del dominio en su lugar.

Para desactivar el proveedor de sincronización horaria de Hyper-V, apague la VM, luego vaya a la configuración de la VM, seleccione Servicios de integración y desmarque la casilla de verificación Sincronización horaria.

Almacenamiento y optimización

Le recomendamos que siga las recomendaciones de almacenamiento de esta sección para optimizar el rendimiento de su DC VM y garantizar que sus escrituras de Active Directory sean duraderas.

• Para el almacenamiento de invitados, almacene el archivo de base de datos de Active Directory (Ntds.dit) y los archivos de registro y SYSVOL en un disco virtual distinto de los archivos del SO. Le recomendamos que almacene estos archivos en un disco SCSI virtual en un segundo VHD conectado a un controlador SCSI virtual. Un disco SCSI virtual aumenta el rendimiento y admite el acceso forzado a unidades (FUA). Con FUA, el sistema operativo escribe y lee directamente desde el medio, omitiendo cualquier mecanismo de almacenamiento en caché.

• Si utiliza BitLocker para proteger su invitado virtual DC, configure los volúmenes adicionales para el desbloqueo automático mediante el cmdlet de PowerShell Enable-BitLockerAutoUnlock.

• Cuando almacene archivos VHD en hosts, debe utilizar un disco que no sea utilizado frecuentemente por otros servicios o aplicaciones, como el disco de sistema para el SO host. Almacene cada archivo VHD en una partición independiente del sistema operativo del host y de otros archivos VHD, preferiblemente en una unidad física independiente.

• Su sistema de disco físico host debe cumplir al menos uno de los siguientes criterios para satisfacer los requisitos de integridad de datos de cargas de trabajo virtualizadas:

  • El host utiliza discos de clase servidor, como SCSI o Fibre Channel.

  • El host se asegura de que los discos están conectados a un HBA de caché respaldado por batería.

  • El host utiliza un controlador de almacenamiento como un sistema de matriz redundante de discos independientes (RAID) como dispositivo de almacenamiento.

  • El host utiliza un sistema de alimentación ininterrumpida (SAI) para alimentar el disco.

  • El host desactiva por defecto la función de caché de escritura del disco.

• Cuando se utilizan archivos VHD, se recomienda utilizar discos de tránsito o VHD de tamaño fijo, ya que están optimizados para el rendimiento. No recomendamos ampliar y diferenciar dinámicamente los discos porque pueden causar retrasos, degradación del rendimiento durante una actividad elevada del disco y posibles pérdidas de datos al volver a una instantánea anterior.

• Le recomendamos que utilice controladoras SCSI virtuales para reducir la posibilidad de que los datos de Active Directory se corrompan.

  • En los servidores Hyper-V que alojan DC virtuales, debe utilizar unidades físicas SCSI. Si su escenario no le permite utilizar unidades SCSI, debe desactivar el almacenamiento en caché de escritura en la unidad Advanced Technology Attachment (ATA) o Integrated Drive Electronics (IDE) que esté utilizando en su lugar. Para obtener más información, consulte Event ID 1539 — Database integrity (Evento de id. 1539: integridad de la base de datos).

Restricciones operativas para controladores de dominio VM

Los controladores de dominio que se ejecutan en máquinas virtuales tienen restricciones operativas que no se aplican a los DC que se ejecutan en equipos físicos. Cuando utilice un DC virtualizado, debe seguir estas directrices:

• No ponga en pausa, detenga ni almacene el estado guardado de un DC en una VM durante más tiempo que la vida útil del marcador de exclusión del bosque. La reanudación de un estado guardado que haya pausado o guardado durante más tiempo que el tiempo de vida del marcador de exclusión puede interferir con la replicación. Para obtener más información sobre cómo determinar la vigencia del marcador de exclusión del bosque, vea Determinar la vigencia del marcador de exclusión del bosque.

• No copie ni clone VHD.

• No tome ni utilice instantáneas de los DC virtuales. En su lugar, utilice un método de copia de seguridad más permanente y fiable.

• No use la característica Exportar en una máquina virtual que está ejecutando un DC.

• No restaure ni haga retroceder su DC o el contenido de una base de datos de Active Directory utilizando un método de copia de seguridad no admitido.

Consideraciones sobre las operaciones de copia de seguridad y restauración

Debe realizar copias de seguridad de sus DC para evitar la pérdida de datos debido a situaciones de desastre o errores administrativos. El método de copia de seguridad que admite Active Directory consiste en utilizar una aplicación de copia de seguridad para restaurar una copia de seguridad del estado del sistema realizada desde la instalación actual del DC. La aplicación debe ser compatible con Active Directory, como Windows Server Backup. Para obtener más información sobre los métodos de copia de seguridad compatibles, consulte la guía paso a paso de copia de seguridad y recuperación de AD DS.

En implementaciones virtualizadas, debe prestar especial atención a ciertos requisitos para las operaciones de copia de seguridad de Active Directory. Por ejemplo, si restaura un DC utilizando una copia del archivo VHD y no actualiza la versión de la base de datos del DC después de restaurarlo, puede causar problemas con la replicación debido a números de seguimiento inexactos entre las réplicas del DC. En la mayoría de los casos, la replicación no detecta este problema y no informa de ningún error, pero las incoherencias entre los DC pueden causar problemas en determinados escenarios.

Método recomendado para realizar copias de seguridad y restaurar los DC virtualizados

El método que recomendamos utilizar para realizar copias de seguridad y restaurar los DC virtualizados es ejecutar Windows Server Backup en el SO invitado. Para obtener más información, consulte Restaurar un controlador de dominio virtual.

Aunque técnicamente se pueden utilizar instantáneas o copias de archivos VHD para restaurar una copia de seguridad, no recomendamos utilizar estos métodos por los siguientes motivos:

• Si copia o clona un archivo VHD, la base de datos se vuelve obsoleta porque su número de versión de base de datos no se actualiza automáticamente cuando la restaura. Esta incoherencia en los números de seguimiento significa que si inicia el VHD en modo normal, puede provocar potencialmente una reversión de USN.

• Aunque Windows Server 2016 y versiones posteriores son compatibles con las instantáneas, estas no proporcionan el tipo de historial de copia de seguridad estable y permanente que necesita para restaurar de forma coherente su sistema durante situaciones de desastre. Las instantáneas basadas en Volume Shadow Copy Service (VSS) que se pueden crear en Windows Server 2016 Hyper-V y versiones posteriores tampoco son compatibles con BitLocker, lo que puede causar posibles problemas de seguridad. Este problema impide que el motor de base de datos de Active Directory acceda a la base de datos que contiene la instantánea cuando Hyper-V intenta montar el volumen de instantánea.

Nota:

El proyecto de VM blindada descrito en Tejido protegido y VM blindadas tiene una copia de seguridad impulsada por el host Hyper-V como no objetivo para la máxima protección de datos de la VM invitada.

USN y reversión de USN

En esta sección se describen los problemas de replicación que pueden ocurrir si se restaura la base de datos de Active Directory incorrectamente con una versión anterior de una máquina virtual. Para obtener más información acerca del proceso de replicación de Active Directory, consulte Conceptos de replicación de Active Directory.

Cómo AD DS y los DC usan USN

AD DS usa USN para realizar un seguimiento de la replicación de datos entre DC. Cada vez que se cambian datos en el directorio, el USN se incrementa para indicar un nuevo cambio.

Los DC de destino utilizan los USN para realizar un seguimiento de las actualizaciones de cada partición de directorio que almacenan. El USN también rastrea el estado de cada DC que almacena réplicas de estas particiones de directorio. Cuando los DC replican cambios entre sí, consultan a sus socios de replicación en busca de cambios con USN superiores al último cambio que el DC recibió de su socio.

Puede encontrar las tablas de metadatos de replicación que contienen los USN en el vector de actualización y la marca de agua alta. Tanto el DC de origen como el de destino utilizan estas tablas para filtrar las actualizaciones necesarias para el DC de destino.

El DC de destino mantiene la tabla de vectores de actualización para realizar un seguimiento de las actualizaciones de origen que recibe de todos los DC de origen. Cuando un DC de destino solicita cambios para una partición del directorio, proporciona su vector de actualización al DC de origen. A continuación, el DC de origen usa este valor para filtrar las actualizaciones que envía al DC de destino. El DC de origen envía su vector de actualización al DC de destino cuando finaliza un ciclo de replicación. El controlador de dominio de origen usa el USN para realizar un seguimiento de si el controlador de dominio de destino está sincronizado con las actualizaciones de origen en cada controlador de dominio y si las actualizaciones de los destinos están en el mismo nivel que el de origen.

El DC de destino mantiene la tabla de marca de agua alta para rastrear los cambios más recientes que recibió de un DC de origen específico para una partición específica. La tabla de marcas de agua evita que el DC de origen envíe cambios que el DC de destino ya haya recibido de él.

Identidad de la base de datos del directorio

Además de los USN, los DC hacen un seguimiento de la base de datos del directorio de los asociados de replicación de origen. El sistema mantiene la identidad de la base de datos de directorio que se ejecuta en el servidor separada de la identidad del propio objeto servidor. La identidad de la base de datos del directorio de cada DC se almacena en el atributo invocationID del objeto NTDS Settings, ubicado en la ruta cn=NTDS Settings, cn=ServerName, cn=Servers, cn=*SiteName*, cn=Sites, cn=Configuration, dc=*ForestRootDomain* del protocolo ligero de acceso a directorios (LDAP).

El sistema almacena la identidad del objeto servidor en el atributo objectGUID del objeto NTDS Settings. La identidad del objeto de servidor no cambia nunca. Sin embargo, la identidad de la base de datos de directorios cambia en las siguientes circunstancias:

• Cuando se produce un procedimiento de restauración del estado del sistema en el servidor.

• Cuando se añade una partición de directorio de aplicaciones al servidor, luego se elimina y se vuelve a añadir.

• Cuando una instancia Hyper-V activa sus escritores VSS en una partición que contiene un VHD de un DC virtual.

  En este escenario, el invitado desencadena sus propios escritores de VSS. Esta acción es el mismo mecanismo que utiliza el proceso de copia de seguridad y restauración. Este método restablece el atributo invocationID.

El atributo invocationID relaciona un conjunto de actualizaciones originadas en un DC con una versión específica de la base de datos del directorio. El vector de actualización y las tablas de marca de agua alta utilizan el invocationID y el GUID de DC respectivamente para que los DC reconozcan de qué copia de la base de datos de Active Directory procede la información de replicación.

El atributo invocationID es un valor de identificador único global (GUID) que es visible cerca de la parte superior de la salida después de ejecutar el comando repadmin /showrepl. El siguiente texto es un ejemplo del resultado que se obtiene al ejecutar el comando:

Repadmin: running command /showrepl against full DC local host
Default-First-Site-Name\VDC1
DSA Options: IS_GC
DSA object GUID: 966651f3-a544-461f-9f2c-c30c91d17818
DSA invocationID: b0d9208b-8eb6-4205-863d-d50801b325a9

Cuando se restaura AD DS en un DC, el sistema restablece el atributo invocationID. Este cambio aumenta el tráfico de replicación, con una duración relativa al tamaño de la partición que está replicando.

Para demostrar este escenario, el siguiente diagrama muestra un entorno de ejemplo en el que el controlador de dominio virtual VDC1 y el controlador de dominio DC2 son dos DC del mismo dominio. Este diagrama muestra cómo DC2 detecta el valor invocationID en VDC1 después de un reinicio en un escenario de restauración soportado.

Diagrama que representa un diagrama de flujo de la vista de VDC1 de sí mismo y la vista de DC2 de VDC1. En la línea VDC1, VDC1 comienza con un USN de 1000 y un ID de invocación de B. A continuación, se restaura a su versión anterior, que tiene un USN de 500 y un valor de ID de invocación de B. Se producen cambios en VDC1, que lo devuelven al USN 600 mientras que el ID de invocación sigue siendo el mismo. En la línea que dice "DC2 view of VDC1", DC2 comienza con un InvocationID de VDC1(A)@USN1000. Después de restaurar VDC1, DC2 restablece su USN esperado de 1000 a 500, convirtiendo su valor para el ID de invocación B en VDC1(B)@USN500. Continúa rastreando tanto el ID de invocación A como el ID de invocación B. Después del siguiente conjunto de cambios en VDC1, DC2 ahora rastrea el ID de invocación A de VDC1 de USN 1000 y su nuevo ID de invocación B de USN 600.

Reversión de USN

La reversión de USN se produce cuando el sistema no puede actualizar un USN de forma normal, un usuario elude las actualizaciones de USN o un DC intenta utilizar un USN inferior a su última actualización. Cuando el sistema detecta un retroceso del USN, detiene la replicación antes de que el desajuste pueda causar una divergencia en el bosque.

Muchos factores pueden causar una reversión del USN. Por ejemplo, puede ocurrir si utiliza archivos VHD antiguos o realiza una conversión P2V sin desconectar permanentemente la máquina física después de la conversión.

Prevención de reversiones de USN

Puede evitar las reversiones de USN tomando las siguientes precauciones:

• Cuando no se ejecute Windows Server 2012 o versiones posteriores, no tome ni use una instantánea de una máquina virtual del DC.

• No copie el archivo VHD del DC.

• Cuando no esté ejecutando Windows Server 2012 o posterior, no exporte una VM que esté ejecutando un DC.

• Restaure únicamente un DC o realice una reversión del contenido de una base de datos de Active Directory mediante soluciones de copia de seguridad de origen compatibles, como Windows Server Backup.

A veces, el sistema no puede detectar la reversión de USN antes de que pueda causar errores de replicación. Cuando encuentre errores de replicación, debe identificar el alcance del problema y solucionarlo lo antes posible. Para obtener más información sobre cómo eliminar los objetos persistentes que pueden producirse como resultado de la reversión de USN, consulte Evento de replicación de Active Directory 1388 o 1988: Se detecta un objeto persistente.

Detectar una reversión de USN

En la mayoría de los casos, el sistema puede detectar reversiones de USN rastreando inconsistencias en el atributo invocationID causadas por la restauración de un DC sin restablecer el atributo. Windows Server 2008 proporciona protecciones contra errores de replicación después de operaciones de restauración de DC no admitidas. Estas protecciones se activan cuando una restauración no admitida crea USN inferiores a las versiones originales, que representan cambios que los socios de replicación ya recibieron.

En Windows Server, cuando un DC de destino solicita cambios utilizando un USN utilizado anteriormente, el DC de destino interpreta la respuesta del socio de replicación como que sus metadatos de replicación están desactualizados. Los metadatos obsoletos significan que la base de datos de Active Directory en el DC de origen retrocedió a un estado anterior, por lo que el sistema responde en consecuencia.

Por ejemplo, supongamos que el archivo VHD de una máquina virtual ha retrocedido a una versión anterior. En este caso, el DC de destino inicia las siguientes medidas de cuarentena en el DC que ha identificado como que ha sufrido una restauración no soportada:

• AD DS pausa el servicio de Net Logon, lo que evita que las cuentas de usuario y de equipo cambien las contraseñas. Esto impide que se pierdan los cambios en caso de que ocurran después de una restauración incorrecta.

• AD DS deshabilita la replicación de entrada y de salida de Active Directory.

• AD DS genera el ID de evento 2095 en el registro de eventos del Servicio de directorio para registrar lo sucedido.

El siguiente diagrama muestra la secuencia de eventos que se producen cuando AD DS detecta una reversión de USN en VDC2, el DC de destino que se está ejecutando en una VM. En esta ilustración, la detección de reversión de USN se produce en VDC2 cuando un socio de replicación detecta que VDC2 envió un valor de USN actualizado visto anteriormente por el DC de destino. Esta condición indica que la base de datos de VDC2 ha experimentado una reversión.

Diagrama que muestra un diagrama de flujo de las actualizaciones de VDC2 y el valor de actualización de DC1 para VDC2. VDC2 comienza con un USN de 100 y un ID de invocación A. A continuación, actualiza sus USN de 101 a 200, que se replican en DC1. Sin embargo, el usuario también realiza una copia VHD del USN 200 del VDC2. A continuación, el VDC2 actualiza su USN de 201 a 350, y replica esos cambios en el DC1. Sin embargo, el VDC2 falla. El usuario restaura entonces VDC2 con la copia que hizo en el VHD USN 200. A continuación, el usuario realiza otra actualización en VDC2 para una nueva versión de los USN 201 a 355. DC1 solicita cambios superiores al USN 350 de VDC2 y se replica porque el USN en VDC2 es superior al de DC1. Sin embargo, la nueva versión de los USN 201 a 350 no es la misma que la del DC1, lo que provoca una reversión del USN.

Resolución de problemas del identificador de evento 2095

Si ve el ID de evento 2095 en el registro de eventos de Servicios de directorio, siga estas instrucciones inmediatamente:

1. Aísle la máquina virtual que registró el error de la red.

2. Compruebe si los cambios notificados se originaron en este DC y se propagaron a otros DC. Si el evento fue el resultado del uso de una instantánea o copia de una máquina virtual, intente averiguar cuándo se produjo la reversión de USN. Una vez que tenga tiempo, puede comprobar los socios de replicación de ese DC para determinar si la replicación se produjo después de la reversión.

   Puede utilizar la herramienta Repadmin para comprobar de dónde proceden los cambios. Para obtener más información acerca de cómo usar Repadmin, consulte Supervisar y solucionar problemas de replicación de Active Directory mediante Repadmin. Si no puede realizar una determinación, póngase en contacto con Soporte técnico de Microsoft para obtener ayuda.

3. Degradar el controlador de dominio de forma forzada. Esta operación implica la limpieza de los metadatos del DC y la incautación de los roles de maestro de operaciones, también conocidos como roles de operaciones de maestro único flexible (FSMO). Para obtener más información, consulte Recuperación de una reversión de USN.

4. Quite todos los archivos VHD anteriores del DC.

Reversión de USN no detectada

Es posible que el DC no detecte la reversión de USN en los siguientes casos:

• El archivo VHD está asociado a máquinas virtuales diferentes que se ejecutan en varias ubicaciones al mismo tiempo.

• El USN en el DC restaurado aumentó más allá del último USN recibido por el otro DC.

En el caso del archivo VHD, otros DC podrían replicarse con cualquiera de las máquinas virtuales y podrían producirse cambios en cualquiera de ellas sin replicarse en la otra. Esta divergencia del bosque es difícil de detectar y ocasiona respuestas impredecibles del directorio. Esto puede ocurrir después de la migración FaV si el DC físico y la máquina virtual se ejecutan en la misma red. Esta situación también podría suceder cuando se crean varios DC desde el mismo DC físico y, después, se ejecutan en la misma red.

En el escenario USN, un rango de USN se aplica a dos conjuntos diferentes de cambios. Este escenario puede ocurrir durante largos períodos sin que se detecte. Cuando se modifica un objeto creado durante este periodo, el sistema detecta un objeto persistente y lo notifica como Event ID 1988 en el Visor de Sucesos. El siguiente diagrama muestra por qué el DC podría no detectar la reversión de USN en este escenario.

Diagrama que muestra un diagrama de flujo para el proceso de detección de reversión en una compilación de ejemplo. Hay dos controladores de dominio etiquetados como "VDC1" y "DC2". La etapa inicial del diagrama de flujo muestra que el DC virtual, VDC1, toma una instantánea cuando su USN es 2000. Después de la instantánea, VDC1 crea 100 usuarios, y el VDC1 actualizado tiene ahora un USN de 2100. Las actualizaciones en VDC1 se replican a DC2, que ahora comparte el USN de 2100. Sin embargo, el VDC1 utiliza entonces la instantánea que tomó para revertir a su versión USN 2000. La versión revertida del VDC1 crea 150 nuevos usuarios, lo que eleva su USN a 2150. El VDC1 actualizado se replica en el DC2, pero el DC2 no detecta los cambios no coincidentes porque su USN es superior al USN de 2100 del DC2. El texto de la parte inferior dice: "No se detecta la reversión del USN, lo que provoca una divergencia no detectada en la que los USN de 2001 a 2100 no coinciden entre los dos controladores de dominio.

Controladores de dominio de solo lectura

Los controladores de dominio de solo lectura (RODC) son DC que alojan copias de solo lectura de las particiones de una base de datos de Active Directory. Los RODC evitan la mayoría de los problemas de la reversión de USN porque no replican ningún cambio a otros DC. Sin embargo, si un RODC replica desde un DC de solo escritura afectado por la reversión de USN, la reversión también afecta al RODC.

No recomendamos utilizar una instantánea para restaurar un RODC. Solo debe restaurar un RODC utilizando una aplicación de copia de seguridad compatible con Active Directory. Además, al igual que con los DCs escribibles, no debe permitir que un RODC esté fuera de línea durante más tiempo que el tiempo de vida de la lápida. De lo contrario, podrían aparecer objetos persistentes en el RODC.

Para obtener más información sobre la implementación de RODC, consulte la Guía paso a paso de controladores de dominio de solo lectura.

Contenido adicional

Aprenda a restaurar DCs virtualizados en Restaurar controladores de dominio virtualizados.