En este pequeño articulo relatare un poco sobro como solucione este problema para volver a tener nuestro DAG (la parte del usnRollBack yo no la trabaje pero hay bastante información en la web… Bing es su amigo en estos casos).
Primero que nada unos conceptos, cuando creas un DAG veras dos objetos uno en la partición de configuración en “CN=Database Availability Groups,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=tuOrganizacion,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=sysadmin-cr,DC=com” tipo “msExchMDBAvailabilityGroup” el cual es el DAG en sí, este contiene parámetros de configuración como el file share witness, dirección IP y otras. El segundo objeto lo encontraremos en la partición de dominio, un objeto tipo “computer” que es la representación del DAG, este lo llamaremos el “CNO (Cluster Name Object)”.Además de esto nos interesa el atributo “msExchMDBAvailabilityGrouoLink” que está en los objetos tipo “msExchExchangeServer”, básicamente acá se apunta la membresía del servidor con el DAG. De hecho en el objeto del DAG este se refleja como el “msExchMDBAvailabilityGrouoLinkBL”
Muy bien, recordemos que no podemos eliminar un equipo de un DAG si este tiene copias de bases de datos por lo cual estas deben de ser eliminadas. Una vez que nuestros bases de datos de buzones no tengan copia alguna entonces será posible modificar la membresía del DAG removiendo sus miembros. Les sugiero dar un vistazo al “msExchMDBAvailabilityGroupLink” para evitar problemas más adelante.
Ahora que el DAG no tiene miembros lo podremos remover sin problema alguno.
Nótese que este no es el proceso normal, acá estoy trabajando en caliente con un ambiente en producción, no hay más servidores de Mailbox disponibles ni otras opciones, valore usted su posición antes de proceder de una manera así de drástica.
Una vez eliminado el DAG debo de detener y deshabilitar el servicio del “Cluster Service” esto en cada miembro del antiguo DAG.
También debo mencionar que en las bases de datos o “msExchPrivateMDB” (buzones de correo) y/o “msExchPublicMDB” (carpetas compartidas) se refleja cual es el servidor primario de dicha base de datos, llamado “master”. Esta información se almacena en el “msExchMasterServerOrAvailabilityGroup” el cual muy probablemente luego de eliminar el DAG va a mostrar el GUID del objeto borrado y otra información que no le será muy común, basta con actualizar este atributo con el “distinguishedName” del servidor que ahora hospeda la base de datos. Uno de los cambios en Exchange 2010 es el hecho de que las bases de datos son portables, estas ya no están ligadas a un servidor especifico, solamente se hospedan en estos, pero esto también la necesidad de que su nombre sea único en la organización de Exchange.
En nuestro caso en CNO no existía y las opciones de restauración eran nulas.
Como siguiente paso pre-configuraremos el objeto del CNO, creando un objeto tipo “computer” en el contenedor de nuestra elección, dicho objeto debe estar deshabilitado y además necesitamos darle “Full Control” al grupo del “Exchange Trusted Subsystem” y al primer equipo que vayamos a unir al DAG. Desde luego esto luego de un tiempo prudencial para la replicación de Active Directory.
Cuando agreguemos dicho equipo al DAG parte de las modificaciones que se realizaran habilitaran la cuenta, mantenga esto en mente por si el proceso falla que usted verifique dicho objeto continúe deshabilitado.
Si usted pudo agregar el miembro del DAG exitosamente pues es usted el héroe y feliz administrador de un DAG, a partir de este punto la administración es completamente normal.
Se agregan y configuran otros miembros, las redes, copias de bases de datos y demás.
Cualquier duda sugiero dar un vistazo a http://technet.microsoft.com/en-us/library/ff367878.aspx , http://technet.microsoft.com/en-us/library/dd351172.aspx y finalmente http://technet.microsoft.com/en-us/library/dd298065.aspx
Hasta pronto!
No comments:
Post a Comment