Cuando tiene un grupo de disponibilidad de base de datos (DAG) dentro de Exchange, tiene la tranquilidad de que sus buzones de correo se replican entre sitios y uno de los servidores se cae, los usuarios podrán trabajar sin intervención manual. En un entorno normal y saludable, realizar una conmutación por error a otro miembro del DAG debería ser fácil y debería probarse de vez en cuando. Esto lo pondrá en forma y tendrá un escenario documentado de cómo lograr la continuidad del negocio si ocurriera un desastre.

Pero esto es en el escenario ideal donde todo funciona como debe ser. En otros casos, uno podría tener problemas que necesita saber cómo manejar o recuperarse. La mayoría de las empresas prueban su conmutación por error una vez al año o, a veces, en intervalos más frecuentes. La prueba de conmutación por error no es algo que solo se pruebe. Esto también puede ocurrir durante las actualizaciones mensuales de Windows, ya que será necesario reiniciar el servidor principal.

Sin embargo, si la protección de conmutación por error de DAG falla o no funciona cuando es necesario, puede usar un software de recuperación de Exchange, como Stellar Repair for Exchange para extraer los buzones de correo de la base de datos del servidor Exchange fallido y restaurarlos en un servidor Live Exchange.

Tomando el escenario en vivo:

tomando por example, dos servidores de Exchange 2010, uno está en el sitio principal y es el propietario preferido de los servicios y las bases de datos, y el otro es el servidor secundario con todas las copias de la base de datos. El sitio principal puede fallar por varias razones y una ocasión sería una falla de energía o una prueba del generador. No se pudo efectuar nada, pero el servidor de Exchange se apagó debido a una mala configuración en las opciones de energía del hipervisor

Desafortunadamente, durante los cortes de energía abruptos, se pueden encontrar problemas como que ningún usuario puede acceder a su buzón después de que se enciende el servidor.

La primera cosa para verificar en tales casos, son los registros DNS del servicio de detección automática que deberían apuntar a ambos servidores como el siguiente example.

mail.mydomain.com de registro tipo A apuntando a 192.168.0.15
mail.mydomain.com de registro tipo A apuntando a 192.168.0.25
autodiscover.mydomain.com escribe un registro que apunta a 192.168.0.15
autodiscover.mydomain.com del registro de tipo A que apunta a 192.168.0.25

Si debería ser una conmutación por error perfecta, los usuarios obtendrían el error:

“Lo sentimos, estamos teniendo problemas para abrir este artículo. Esto podría ser temporal, pero si lo vuelve a ver, es posible que desee reiniciar Outlook. Los problemas de red impiden la conexión a Microsoft Exchange”.

Nada que, como se menciona en muchos artículos y bases de conocimiento, el problema pueda deberse a que el DAG tarda un poco de tiempo hasta que afecta una conmutación por error. Si el problema persiste y aún obtiene el mismo error e incluso al usar OWA obtiene un error similar que dice

“Su solicitud no se puede completar en este momento. Por favor, inténtelo de nuevo más tarde”;

En esta etapa no se asuste ya que siempre hay una alternativa y una razón.

esta primera cosa para verificar el estado del clúster mediante PowerShell para que el clúster vea el estado. Ejecute Get-ClusterNode y confirme que el servidor principal se muestra inactivo y el servidor secundario se muestra activo. Luego, también debe verificar las copias de las bases de datos utilizando Get-MailboxDatabaseCopyStatus y si puede encontrar que las bases de datos no están montadas y el estado del índice de contenido se muestra como fallido. Esto debería activar inmediatamente un proceso para montar las bases de datos, pero es probable que las bases de datos no se monten manualmente, ya que no se montaron automáticamente. Una vez que se soluciona el problema y se inicia el servidor principal, es posible que termine con un servidor que no se inicia o un sistema operativo dañado

Aunque esto podría ser un desastre si su servidor principal no arranca, podría haber alguna forma de restaurar la continuidad del negocio. Dado que el clúster parece haber fallado en el servidor secundario, ¿por qué las bases de datos no se montan automáticamente? En tal caso, habría que abrir Exchange Management Shell y usar ESEUtil para identificar cualquier problema con la base de datos como

                      
                        eseutil.exe /mh "M:mbxmbx01"
                      
                    

y lo primero que se debe notar es el estado de la base de datos. Si se encuentra en un estado de apagado sucio, estas son señales de que la base de datos está dañada. Al tener un DAG, si el clúster no se está ejecutando y no está en buen estado, las bases de datos de Exchange no se montarán. Entonces, si el servidor principal no arranca y está inactivo, hay que desalojarlo del clúster.

En esta etapa y algunos contratiempos en el camino después de reiniciar el servidor secundario, las bases de datos deberían montarse sin problemas. Si los clientes aún no pudieran conectarse, sería necesario cambiar el registro DNS que apunta al servidor principal para que apunte al secundario. Esto ahorraría la molestia de ir en cada Outlook cliente y rehacer el perfil. Aunque esta no es la forma correcta, al menos hará que todos los clientes se conecten y puedan acceder a su buzón hasta que se establezca un plan para reinstalar un servidor.

Dado que en la mayoría de los casos tener un servidor secundario, significa que las especificaciones del servidor secundario no serían las mismas que las del servidor principal, ya que está ahí para desastres y apenas se usa, excepto para replicar datos. Es posible que observe desconexiones frecuentes de los usuarios a sus buzones de correo y en el registro de la aplicación del servidor puede notar errores como “El servidor de buzón de Exchange: [mail.mydomain.com] ha alcanzado su umbral de tiempo de espera. El servidor de buzones estará protegido de nuevas solicitudes de [60] segundos.” Este error significa que el servidor está demasiado ocupado con solicitudes y debe detener todas las solicitudes hasta que esté libre.

Si llega a esta etapa, lo más probable es que acelere el plan para instalar un nuevo Exchange Server y comenzar a transferir los buzones. Uno puede exportar los buzones a PST usando el cmdlet de PowerShell New-MailboxExportRequest, pero dado que la única solución era desalojar el servidor y las bases de datos aún piensan que hay una copia de la base de datos del servidor principal fallido, pueden ocurrir algunos errores y no lo hará. podrá exportar cualquier archivo PST desde su archivo EDB. Desafortunadamente, no puede simplemente exportar directamente desde un archivo EDB sin su Exchange Server principal en línea. El software de recuperación de bases de datos de Exchange de terceros es la mejor alternativa a Solve Exchange 2016 DAG failover.

Afortunadamente, con Stellar Repair for Exchange puede resolver la conmutación por error DAG de Exchange 2016 y montar fácilmente todos los archivos EDB en la aplicación. El escaneo rápido le permitirá navegar a través de la base de datos EDB. Además de poder recuperar buzones de correo de archivos EDB corruptos y exportar carpetas públicas a PST. Puede exportar a la base de datos de Exchange en vivo después de configurar un nuevo DAG o Exchange Server. Esto le ahorrará mucho tiempo y hará que todos trabajen y minimice el tiempo de inactividad.