Mientras preparaba un entorno de prueba (máquinas virtuales) para la migración de Lotus Notes a Exchange Server 2007, me encontré con un problema interesante: Todos los mensajes enviados a los destinatarios internamente (dentro de Exchange) o externamente (Lotus Notes o Internet), terminaban en la carpeta Borradores.

No se generaron advertencias, mensajes de error ni NDR en la interfaz de usuario. Esto fue bastante desconcertante, por decir lo menos. Así que decidí hacer lo que la mayoría de los experimentados profesionales de TI considerarían como el siguiente paso lógico: Profundizar más.

Comencé mirando a través de los registros de eventos en el Buzón de correo de Exchange y los servidores de transporte de Hub. En el registro de la aplicación del Servidor de buzón, noté el ID de evento 1009, Un evento de advertencia con el Origen y la Categoría etiquetados como «MSExchangeMailSubmission». La descripción del Evento fue acertada: «El servicio de envío de correo de Microsoft Exchange no puede ponerse en contacto actualmente con ningún servidor de transporte Central en el sitio local de Active Directory. Los servidores pueden estar demasiado ocupados para aceptar nuevas conexiones en este momento.»

Supongo que le debo un gran «Gracias» a la persona de Microsoft que creó las etiquetas significativas para el Origen y la Categoría de eventos, justo el tipo de cosas que damos por sentado.

De todos modos, dado que había fuertes indicios de que el problema existía en el servidor de Transporte del Concentrador, comencé a examinar el registro de aplicaciones del Servidor de Transporte del Concentrador. No se registraron errores, pero hubo una advertencia: ID de evento: 15002, Fuente: MSExchangeTransport, Categoría: ResourceManager. En mi prisa por resolver el problema, ignoré el evento de advertencia y asumí que el servidor solo se quejaba de los recursos del sistema en la máquina virtual, no muy lejos de la verdad.

Mientras tanto, usé Telnet para conectarme al puerto 25 del servidor de transporte del concentrador e inmediatamente recibí una respuesta que decía:

452 4.3.1 Recursos insuficientes del sistema

Conexión al host perdida

Esto me llevó a echar un vistazo más de cerca al ID de evento de advertencia: 15002 en el registro de la aplicación del servidor de transporte del concentrador. Leí la descripción cuidadosamente:

» La presión de recursos es constante a alta. Estadísticas:

Microsoft: La Guía Esencial para la Participación de los usuarios Finales de Microsoft Teams
La Guía Esencial para la participación de los usuarios finales de Microsoft Teams

Le mostramos 10 prácticas recomendadas, consideraciones y sugerencias que pueden enriquecer su implementación de Microsoft Teams y garantizar la adopción y la participación de los usuarios finales.

Obtener la Guía

Cola de base de datos y espacio en disco («C:Archivos de programa Microsoftexchange ServerTransportRolesdataQueuemail.que») = 63%

Espacio en disco de registro de base de datos de cola («C: Archivos de programa, Microsoftexchange ServerTransportRolesdataQueue») = 63%

Versión buckets = 1

Bytes privados = 16%

Carga de memoria física = 53%

Envío de correo entrante desde otros servidores de Transporte de Concentradores, Internet, el directorio de recogida, el directorio de reproducción y el servidor de buzones de correo, si se encuentra en un servidor de transporte de Concentradores, se ha detenido.

La carga de correo electrónico de la base de datos de colas, si está disponible, continúa.»

Desplazarse hacia abajo en la descripción y leer los detalles ayudó a J, pero espera, tenía 2,94 GB de espacio libre en mi máquina virtual que ejecutaba el rol de servidor de transporte del concentrador. Entonces, ¿por qué Exchange se quejaba del espacio en disco?

Después de algunas investigaciones, me encontré con este artículo sobre Technet que me presentó un concepto no tan conocido, pero novedoso, introducido en Exchange Server 2007: La contrapresión. Si bien puede leer más detalles sobre el tema en las páginas a las que se hace referencia, esencialmente la contrapresión es una función de supervisión de recursos del sistema integrada en los roles de Transporte de concentradores y Servidor perimetral de Exchange Server 2007, y afecta a la entrega de mensajes en función del estado de los recursos del sistema.

Después de aplicar la fórmula que usa Exchange para calcular los umbrales para el servicio de transporte (100*(tamaño de la unidad de disco duro – 4 GB) / tamaño de la unidad de disco duro), me di cuenta de que el alto valor resultante para la base de datos de cola y el espacio en disco en mi entorno (50%) era mayor que el ALTO umbral calculado por Exchange (49%).

Consejo: Si el espacio libre disponible es inferior a 4 GB, el nivel de utilización de la unidad de disco duro se considera alto.

Así que mis opciones para que el correo fluyera fueron:

  • Aumentar el espacio disponible en disco (recomendado para entornos de producción) O
  • Aumentar el umbral apropiado (NO recomendado para entornos de producción)

Como estaba usando un entorno de prueba, decidí tomar la ruta fácil y anular los cálculos predeterminados para el alto nivel de utilización de la unidad de disco duro especificando un nuevo valor en EdgeTransport.exe.archivo de configuración que se puede encontrar en el directorio C: Program FilesMicrosoftExchange ServerBin. Cambié el valor predeterminado de PercentageDatabaseDiskSpaceUsedHighThreshold de «0» a » 80 » y reinicié el servicio de transporte de Microsoft Exchange.

Comprobé que el mensaje de advertencia no volvía a aparecer después de reiniciar el servicio e intenté enviarme un mensaje de nuevo utilizando OWA-SUCCESSFUL!! También noté que el mensaje que se colocó previamente en la carpeta de borrador (durante el problema) también se entregó con éxito sin ninguna intervención manual.

Si bien la contrapresión es una característica interesante de Exchange y está destinada a abordar los problemas de recursos del sistema de manera más elegante, espero que las empresas continúen invirtiendo en soluciones de monitoreo efectivas para Exchange, como System Center Operations Manager, para evitar problemas como el descrito anteriormente. La excepción de-course es un escenario en el que está probando una solución de intercambio en un entorno de prueba en el que es posible que no tenga el lujo de tener recursos del sistema de clase de producción.