Hola a todos, en esta ocasión vamos a centrarnos en un tema que a lo largo de los años siempre es recurrente entre nuestros clientes: «Mi disco se está quedando sin espacio por culpa de Exchange… ¿Qué hago?» . En este artículo os mostraré unos pequeños consejos o sugerencias a aplicar cuando nos encontramos con este problema o a la hora de implementar un nuevo Exchange en cualquiera de sus versiones 2013, 2016 o 2019.

Planificación

Todos sabemos que las “buenas prácticas” a veces son poco realistas y recomiendan cosas utópicas, difíciles o incluso imposibles de implementar en pequeñas y medianas empresas. Sin embargo, cuando hablamos de espacio en disco y Exchange, es algo tan crítico que no se debería de tomar a la ligera. Hoy en día no merece la pena ahorrar costes en almacenamiento ya que el precio de los discos es muy bajo. Obviamente, siempre hay que tener en cuenta el volumen de tráfico de correos de la organización, pero a la hora de dimensionar el almacenamiento, recomiendo hacerlo siempre muy por encima. Aquí y aquí encontraréis información al respecto.

Base de datos de buzones

Cuando instalamos Exchange, de forma predeterminada, se crea una base de datos y varios logs almacenados en la carpeta C:\Program Files\Microsoft\Exchange Server\V15\Mailbox\Mailbox Database XXXXXXXXXX.

Si estáis pensando en realizar una migración a una nueva versión de Exchange, o a la hora de crear usuarios en una nueva instalación, recomiendo hacer primero las siguientes dos cosas:

1. Crear otra base de datos en otro disco, con suficiente espacio libre en base al volumen de correos de la organización, migrar todos los buzones existentes (incluidos los famosos “Arbitration”) a la nueva base de datos y borrar la predeterminada.

2. Cambiar la ubicación de la base de datos predeterminada y los logs hacia otro disco que no sea C:, antes de empezar a hacer uso de ella (más información aquí). Ojo, tener en cuenta que para realizar este proceso la base de datos debe ser desmontada, por lo tanto, no estará operativa. Además, este procedimiento no sirve para bases de datos en DAG.

Además, desde hace ya unas cuantas versiones de Exchange, los logs de la base de datos también llamados ”transaction logs” no se borran automáticamente tras ser correctamente introducidos en la base de datos. Esto implica que necesita de un mantenimiento para evitar quedarnos sin espacio y evitar a la vez una posible corrupción de la misma. Para ello tenemos dos opciones:

• Habilitar la funcionalidad “Circular logging” que se encargará de “truncar” o eliminar los logs que ya se han introducido en la base de datos (más información aquí). Esta funcionalidad no está recomendada mantenerla permanente ya que de tener un problema con la base de datos no dispondremos de esos logs para aplicarlos a un backup.
• Usar Windows Server Backup, o cualquier otra aplicación de terceros que nos realice un backup correcto de nuestras bases de datos. Al hacerlo, purgará los logs ya incluidos en la base de datos (más información aquí).

Base de datos de cola de correos

Otra fuente de dolor de cabeza es la base de datos “mail.que” donde se almacenan temporalmente los mensajes a la espera de ser entregados. Esta es menos conocida y se almacena de forma predeterminada en C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\data\Queue. En determinadas organizaciones hemos visto que esta cola puede ocupar incluso más de 40 Gb. Esto se debe a muchos factores como pueden ser el intenso flujo de correos, si se tiene o no habilitada la funcionalidad “Shadow Redundancy” (proporciona copias redundantes de mensajes antes de que se entreguen a los buzones de correo) o si se ha cambiado la configuración original para guardar esos correos por más tiempo que el predeterminado.

En todo caso, siempre podemos mover la cola a otro disco que tengamos disponible. Bueno, realmente no movemos nada, ya que al cambiar la ubicación del archivo en “EdgeTransport.exe.config”, lo que sucede es que se genera otra nueva cola (base de datos) y se empiezan a almacenar en este nuevo sitio (más información aquí).

Archivos de registro generados directa e indirectamente por Exchange

Exchange 2013, 2016 y 2019 generan de forma predeterminada una gran cantidad de archivos de registro. La mayoría solamente nos serán útiles si tenemos algún tipo de problema ya que necesitaremos investigar y analizar estos logs.

Pero ¿qué pasa si mi servidor Exchange está funcionando perfectamente? Siendo así, estos registros no nos son de mucha utilidad.

La solución propuesta por los compañeros de TechNet es un script (encontraréis muchos otros en Internet) que nos permitirá deshabilitar y borrar los “Diagnostic logs”, los archivos ETL y aquellos otros generados por IIS. Lo podéis descargar desde aquí.

Espero que estos consejos os ayuden a mantener vuestros servidores de correo lo más “limpios” posible, para evitar quedaros sin espacio y por consiguiente causar un grave problema.

¡Un saludo y gracias por seguirnos!