En un día normal de trabajo, es posible que descubra que algunos o todos los usuarios del servidor Exchange no pueden enviar o recibir correos electrónicos e incluso no pueden acceder a su buzón. Después de investigar el problema, se da cuenta de que las bases de datos de los buzones no están montadas. Cuando intenta montar las bases de datos, obtiene un error como el que se indica a continuación.
No se ha podido montar la base de datos especificada. Base de datos especificada: Mailbox Database Exchange; Código de error: Ha fallado una operación de Active Manager. Error: La acción de la base de datos falló. Error: La operación falló con el mensaje: MapiExceptionDatabaseError: No se pudo montar la base de datos. (hr=0x80004005, ec=1108) Contexto de diagnóstico: Lid: 65256 Lid: 10722 StoreEc: 0x454 Lid: 1494 -- Contexto remoto Beg -- Lid: 45120 dwParam: 0x569817 Lid: 57728 dwParam: 0x56995F Lid: 46144 dwParam: 0x569A97 Lid: 34880 dwParam: 0x569A97 Lid: 34760 StoreEc: 0xFFFFFE0B Lid: 46144 dwParam: 0x56A13F Lid: 34880 dwParam: 0x56A13F Lid: 54472 StoreEc: 0x1388 Lid: 42184 StoreEc: 0x454 Lid: 1750 -- Fin de contexto remoto -- Lid: 1047 StoreEc: 0x454 [Base de datos: Mailbox Database Exchange, Servidor: R-FS1.webrooster.local]
En tal situación, lo primero que hay que hacer es mirar el almacenamiento en disco. Por lo general, el error ‘unable to mount database (‘hr=0x80004005, ec=1108)‘ aparece cuando el almacenamiento del disco está lleno. Ahora, si tienes la base de datos y los registros en discos separados, puedes comprobar ambas unidades. Si la unidad de la base de datos está llena, debe ampliar el almacenamiento o mover la base de datos a una unidad más grande. No es posible comprimir la base de datos, ya que está en un formato comprimido.
En el caso de que la ubicación del registro esté llena, el culpable podría ser un software antivirus que está interfiriendo con la copia de seguridad o las copias de seguridad no están haciendo una copia de seguridad correcta de su base de datos de Exchange y purgando las bases de datos. Otra razón por la que no se purgan los archivos de registro es que el software de copia de seguridad no es consciente de la aplicación o no es compatible con Exchange Server. En este caso, debe mover los archivos de registro a otra ubicación que tenga más espacio de almacenamiento o aumentar el espacio del disco si el servidor es una máquina virtual.
Si la base de datos sigue sin poder montarse, después de aumentar el espacio, hay que comprobar si la base de datos está dañada o no. Para ello, utilice la herramienta ESEUTIL.
Ejecutando el siguiente comando, puede identificar el estado de la base de datos.
EseUtil /MH <your edb file path>
Si la base de datos está en estado de Apagado Sucio, podría estar en una situación un poco complicada ya que la base de datos podría estar dañada o podría faltar un archivo de registro.
En tal caso, puede utilizar EseUtil para realizar una recuperación suave o una recuperación dura. Sin embargo, no hay garantía de que la base de datos se monte después.
En primer lugar, debe ejecutar el siguiente comando para identificar los registros necesarios,
eseutil /ml <Log path location>
Una vez que tengas el número de registro, normalmente es como E00, necesitas usar el parámetro R para iniciar una recuperación suave:
Eseutil /r e00 /l <Log path location>/d <Database path location>
Esto iniciará el proceso de recuperación. Dependiendo del tamaño y el daño de la base de datos, el proceso tomará algún tiempo. Una vez que haya terminado, deberá volver a ejecutar el comando Eseutil con el parámetro / MH para comprobar el estado de la base de datos. Si el estado de la base de datos es saludable, podrá montar su base de datos.
Si el estado de Apagado Sucio persiste, tienes dos opciones:
- Restaurar el servidor desde una copia de seguridad y perder todos los datos de la última copia de seguridad
- Realice un proceso de recuperación duro
PRECAUCIÓN: Si realizas la recuperación del disco duro, tienes que aceptar la pérdida de datos, ya que el proceso purga los datos dañados, independientemente de la cantidad. Por otra parte, después de realizar este proceso, Microsoft no proporcionará asistencia. Esto se debe a que cuando se recupera una base de datos con la recuperación dura, se codificará de forma dura alguna información. Cuando esto es notado por Microsoft, se negará a proporcionar asistencia.
Para realizar la recuperación dura, ejecute el siguiente comando:
Eseutil /P <Database file location full path>
Una vez ejecutado, se le advertirá de la pérdida de datos y deberá aceptarlo antes de continuar. Esta recuperación debe utilizarse como último recurso.
Una vez hecho esto, obtendrá una pantalla como la siguiente.
Tendrá que ejecutar EseUtil de nuevo con el parámetro MH para ver si el estado de la base de datos es saludable. Si la base de datos está sana, podrás montar la base de datos.
La solución fácil
La solución manual anterior llevará un tiempo considerable, sin saber si resolverá con éxito el problema. Sin embargo, hay una solución fácil disponible. Puede utilizar el mejor software de recuperación de Exchange – Stellar Repair for Exchange que puede abrir cualquier versión de la base de datos de Exchange Server. Si la base de datos está dañada, puede crear una nueva base de datos y mover a los usuarios en ella con un buzón en blanco. Puede adjuntar el archivo EDB a Stellar Repair for Exchange y exportar todos los buzones a la nueva base de datos de Exchange Server. Esta solución le permite restaurar el servicio en poco tiempo, sin complejos procesos de recuperación.
