Hola a todos de nuevo. Esta será una entrada breve, pero puede seros útil en casos en que tengáis que reparar una base de datos de Exchange fuera de un servidor (por ejemplo desde un cliente con Windows 10). Estos pasos están probados para las versiones 2013 / 2016.

La idea viene de una incidencia del pasado donde el cliente disponía de un único servidor que tenía que ser reinstalado por los daños que sufría a nivel de sistema operativo. Además de esto, nos encontramos con que las bases de datos que tenía estaban en “Dirty Shutdown” y eran de gran tamaño, por lo tanto también era necesario repararlas. Dependiendo de los daños en las mismas, tanto un “soft repair” como un “hard repair” pueden llevar mucho tiempo, así pues necesitábamos intentar repararlas a la vez que se reinstalaba el servidor en «modo recover». Aunque no ahondaremos en este artículo sobre cómo reparar una base de datos, os dejo un enlace a un artículo que puede ser interesante:

https://www.codetwo.com/admins-blog/how-to-use-exchange-extensible-storage-engine-utilities-eseutil-tool/

Para poder reparar una base de datos desde otro equipo necesitamos copiar 2 archivos, bien desde el servidor de Exchange o bien desde la ISO de instalación:

• Instalación de Exchange: «C:\Program Files\Microsoft\Exchange Server\V15\Bin» (es la ruta por defecto)
  
• ISO de instalación: «D:\Setup\ServerRoles\Common»

Los nombres de los archivos que necesitamos son:

• eseutil.exe
• ese.dll

Lo que haremos será copiar estos 2 archivos a otro equipo (tiene que ser x64). En mi caso haré el ejemplo con mi máquina cliente de Windows 10. Tendremos que tener acceso a la base de datos con acceso de lectura y escritura (y también a los logs en caso de querer intentar un “soft repair”). En nuestro caso como trabajábamos sobre máquinas virtuales, simplemente añadimos como unidad de red la ruta de la base de datos y copiamos los 2 archivos desde la ISO de la instalación a ella:

Ahora podremos ejecutar eseutil para comprobar el estado. En este caso: eseutil /mh <databasename.edb>. Y nos encontramos la base de datos en «Dirty shutdown».

Para simplificarlo nosotros únicamente haremos un «hard repair». En este caso con eseutil /P <databasename.edb>. Volveremos a ejecutar eseutil /mh <databasename.edb> para confirmar que queda como «Clean shutdown» y ya la tendremos lista para volver a utilizar.

NOTA: dado que hemos hecho un «hard repair», los logs previos no son necesarios, por lo cual deberemos moverlos a otra carpeta (o borrarlos) antes de intentar montar la base de datos.

Tras finalizar la instalación del servidor en «modo recover», simplemente desmontamos la base de datos existente, movimos los logs a otra carpeta y sobreescribimos con la base de datos reparada. Y confirmamos que se montase bien, por supuesto 🙂 .

Y hasta aquí la entrada de hoy. Quizá más adelante hablemos de otra forma de poder reparar una base de datos y redirigir mientras tanto el flujo de correo a otra temporal, que es una solución para poder dar servicio a los usuarios finales si hay que realizar alguna actuación sobre las bases de datos. Mientras tanto, que tengáis un buen día.