Usamos cookies propias y de terceros para ayudarte en tu navegación. Si continuas navegando consideramos que aceptas el uso de cookies. OK

lunes, 26 de agosto de 2013

Solucionar reversión de USN en Active Directory

Hace unos dias nos llamaron de una empresa por un problema que tenían en su Active Directory. La cuestión es que hacia unos días unos de sus Controladores de dominio dejaron de replicar despues de un abrupto corte de energía por lo cual los administradores resolvieron restaurar un backup (imagen de disco) que hacian diariamente a través de Symantec Recovery. El problema no solo que no se solucionó sino que la situación se agravó al ver que cuando querían forzar la réplica el Controlador de dominio arrojaba el siguiente error... "el servidor de destino está actualmente rechazando las peticiones de réplica".
Cuando nos dijeron cual era el método de recuperación que habían utilizado, instantaneamente se nos vino la idea de cual era el problema, seguramente se habia producido una reversión de USN. Solo faltaba comprobar y poner manos a la obra.
Antes de comprobar veamos que es una reversión de USN. Veamos un ejemplo para clarificar: (Ejemplo de Microsoft)
  1. Un administrador promueve tres controladores de dominio en un dominio. (En este ejemplo, los controladores de dominio son DC1, DC2 y DC2 y el dominio es Contoso.com). DC1 y DC2 están asociados de replicación directos. DC2 y DC3 también están asociados de replicación directos. DC1 y DC3 no son directos los asociados de replicación, pero reciban actualizaciones de origen a través de forma transitiva DC2.
  2. Un administrador crea 10 cuentas de usuario que corresponden para los USN de 1 a 10 en DC1. Todas estas cuentas replican a DC2 y DC3.
  3. En DC1, se captura una imagen de disco de un sistema operativo. Esta imagen tiene un registro de los objetos que corresponden a los locales de los USN de 1 a 10 en DC1.
  4. Los siguientes cambios se realizan en Active Directory:
    • Las contraseñas para todas las cuentas de usuario 10 que estaban creado en el paso 2 se restablecen en DC1. Estas contraseñas se corresponden con los USN (11) a través de 20. Todos los 10 actualizado contraseñas replicar a DC2 y DC3.
    • 10 nuevas cuentas de usuario que se corresponden con los USN 21 a través de 30 se crean en DC1. Estas cuentas de 10 usuario replican a DC2 y DC3.
    • 10 cuentas de equipo nueva que se corresponden con los USN (31) a 40 se crean en DC1. Estas cuentas de 10 equipo replican a DC2 y DC3.
    • 10 nuevos grupos de seguridad que se corresponden con los USN 41 a través de 50, se crean en DC1. Estos grupos de 10 seguridad replican a DC2 y DC3.
  5. DC1 experimenta un error de hardware o de un error de software. El administrador utiliza un utilidad de imágenes de disco para copiar el sistema operativo imagen que se creó en el paso 3, en su lugar. DC1 se inicia ahora con un activo Base de datos de directorio que tenga conocimiento de los USN de 1 a 10.

    Debido a que se ha copiado la imagen del sistema operativo en su sitio y  no se ha utilizado la restauración del estado del sistema, DC1 sigue utilizando el mismo ID. de invocación que creó la copia inicial de la base de datos y todos los cambios hasta a 50 de USN. DC2 y DC3 mantienen el mismo identificador de invocación de DC1 así como unvector de actualizaciónde 50 de USN de DC1.
El problema surge de la restauración, ya  que la imagen creada al disco no admite la restauracion del Estado del Sistema correctamente. 
Para solucionar este invonveniente, tenemos dos vías.
Primer caminio:  Restaurar el estado de sistema de un respaldo realizado con un software que admita el respaldo/restauración del active Directory.

Segundo camino: Elegir un controlador de dominio como principal y forzar a los demás a la despromoción y borrado de metadatos. Luego promocionar nuevos Controladores de dominio.
  

2 comentarios:

  1. Creo que en mi caso seria el segundo camino, solo quería preguntarte algunas cosas, tengo un controlador primario que es el catalogo global, y tengo varios secundarios pero por una migración de vmware ocurrió una reversión de usn, para resolver esta situación promovere un servidor secundario dandole todos los roles del anterior, entonces degradare el anterior. Mi pregunta ahora es ¿Puedo volver a sincronizar el anterior después de degradarlo y después volverlo a promover? ¿Hay posibilidad de perdida de información en ese proceso?

    ResponderEliminar
    Respuestas
    1. No. Un DC despromovido no se puede volver a promocionar. Si queres podes agregar otro sin problemas.

      Eliminar