Mi reto
Tenemos servidores de Exchange en varios sitios, pero también a bordo de barcos. Los barcos están conectados a nuestra red a través de enlaces satelitales cuando están en el mar, pero cambian a puentes WiFi cuando están en el puerto.
Debido a la alta latencia (más de 500 ms) y los abandonos no infrecuentes (p. Ej., Cuando los barcos están girando), es probable que el intento de enviar correos electrónicos por encima de unos pocos megabytes en el mar falle y se vuelva a intentar hasta el límite ha sido conseguido. El resultado: el correo electrónico no se entrega y cada intento consume un valioso ancho de banda en el enlace satelital.
Una "solución" es limitar el tamaño máximo de correo electrónico para decir 5 MB, pero eso es difícil de usar y una restricción innecesaria mientras está en el puerto.
Idea aproximada
Lo que preferiría hacer es poner en cola todos los correos electrónicos más grandes que un límite establecido para su posterior entrega cuando está en el mar, mientras se envían todos los correos electrónicos pequeños de inmediato. Entonces estaba pensando en hacer ping al servidor de transporte del concentrador en nuestro centro de datos regularmente, cuando la latencia cae por debajo de ~ 400 ms, comenzaría a procesar la gran cola de correos electrónicos. Cuando la latencia aumenta más de 400 ms, enchufaría el agujero y dejaría que los correos electrónicos se vuelvan a poner en cola.
Ahora, no me he ensuciado mucho las manos con Exchange desde la versión 2003. En aquel entonces, podía programar correos electrónicos grandes para una entrega posterior, por lo que mi idea era hacer algo similar en Exchange 2010, luego escribir una forma de cambiar la entrega programación para correos electrónicos grandes entre 'siempre' y 'nunca'.
Obstáculo
No debería ser demasiado complicado crear un script como ese, pero luego leí que la función en la que confiaba se eliminó con Exchange 2007:
Esta era una característica presente en Exchange 2003, pero se ha eliminado para Exchange 2007. Se configuró en un conector SMTP con el "uso de tiempos de entrega diferentes para mensajes de gran tamaño".
TechCenter: ¿Es posible programar la entrega de correo electrónico según el tamaño en Exchange?
Preguntas
¿Es verdad? - ¿Esta característica ya no está presente en Exchange 2010, o simplemente se ha transformado en algo similar, que puedo usar para lograr mi objetivo? ¿Entonces qué?
¿Hay otra forma de diferir la entrega de correos electrónicos grandes en ciertos servidores de Exchange? Podría basarse en un cronograma o tal vez incluso requerir una acción específica: estoy bastante seguro de que habrá alguna forma de activar la entrega a través del script, solo necesito grandes correos electrónicos en una cola separada en los barcos.
¡Tus pensamientos sobre esto serán muy apreciados! :-)
Editar # 1: idea aproximada refinada
Me topé con dos CmdLets de PowerShell que creo que me pueden acercar bastante a mi objetivo:
Jugué un rato con Get-Message por un tiempo, para ver qué tipo de mensajes tratarían los comandos anteriores.
Lo más importante, estos comandos aceptan un filtro de tamaño de mensaje. Este comando enumerará los mensajes en cola, en el servidor actual, de más de 5 MB (5,242,880 bytes):
get-message -Filter {Size -gt 5242880}
Parece que Get-Message
solo devuelve mensajes de varias colas de entrega remota. Pero, ¿los mensajes que fluyen dentro del servidor, aunque brevemente, aparecen en una cola con la que Get / Suspend / Resume-Message se meterá?
Si no, la solución podría ser tan simple como un script programado cada pocos minutos, en la línea de (en pseudocódigo):
if ping_rtt > 400 Then
Suspend-Message -Filter {Size -gt 5242880}
Else
Resume-Message
EndIf
Preocupaciones / preguntas de seguimiento:
Principalmente irrelevante ahora - ver edición # 2.
Será Get-Message
nunca los mensajes para entrega intra-servidor - sólo los mensajes de colas de entrega remota volver? Si no, ¿el nombre de identidad de las colas de entrega remota sigue un cierto patrón que puedo usar para filtrar?
¿Podría / debería hacerse esto a través de un agente de transporte personalizado (como lo sugiere @longneck) o un sumidero de eventos (si este concepto todavía existe en Exchange 2010)?
Digamos que ejecuto el script cada 5 minutos, lo que aún significa que se envían mensajes grandes, potencialmente puede causar problemas por hasta 5 minutos, antes de ser suspendido. Aún estaríamos mejor de lo que estamos ahora, pero no es óptimo. Podría aumentar la frecuencia a cada minuto, pero no sería la solución más elegante.
Incluso si solo verifico el tiempo de ida y vuelta cada 5 minutos (para ahorrar tráfico satelital), qué mecanismo de intercambio necesitaría configurar, para verificar el último RTT registrado, cada vez que se envía un mensaje que se envía a una entrega remota hacer cola y luego tomar una acción apropiada?
Editar # 2: Soluciones propuestas
Permítanme resumir las soluciones propuestas, y sus ventajas y desventajas tal como las veo:
Agente de transporte personalizado
Concepto
- Controle periódicamente la latencia, clasifíquela como alta o baja (umbral: ¿400 ms?)
- A través de un Agente de transporte personalizado, suspenda / reanude todos los correos electrónicos que superen un umbral establecido, cuando cambie la clasificación de latencia
- A través del TA personalizado, ponga inmediatamente los mensajes grandes enviados posteriormente en modo "suspender", si la latencia es alta
Fortalezas
- Los correos electrónicos grandes nunca se intentan entregar cuando la latencia es alta
Debilidades
- No hay habilidades de desarrollo para hacer esto internamente (nota para mí mismo: el código fuente debe pertenecer a mi empresa como parte del contrato con el desarrollador externo)
- El software de terceros que se vincula con Exchange puede causar problemas al parchar o actualizar
- Se necesita algún tipo de acuerdo de soporte, en caso de que algo salga mal (ver arriba)
Mensajes grandes moderados
Concepto
- Controle periódicamente la latencia, clasifíquela como alta o baja (umbral: ¿400 ms?)
- Según la clasificación de latencia, configure las Reglas de transporte de Exchange mediante secuencias de comandos, para permitir que todos los mensajes fluyan o reenviar mensajes grandes al moderador
- Aprobar mensajes en la cola del moderador cuando el barco está en el puerto, posiblemente por un humano
Fortalezas
- Los correos electrónicos grandes nunca se intentan entregar cuando la latencia es alta
- Los mensajes se suspenden utilizando las reglas de transporte de Exchange nativas nativas
Debilidades
- Por lo que parece, los mensajes no pueden aprobarse programáticamente cuando la latencia es baja, por lo tanto, se requiere intervención humana cada vez que el barco está en el puerto
- Posiblemente problemas de privacidad, si la moderación no se maneja mediante programación
Preguntas
- ¿Se pueden aprobar los mensajes mediante programación desde el buzón del moderador? ¿Cómo?
Comandos programados de PowerShell
Concepto
- Controle periódicamente la latencia, clasifíquela como alta o baja (umbral: ¿400 ms?)
- Siempre que la latencia sea alta, con frecuencia (¿cada minuto?) Suspende cualquier mensaje grande (
Suspend-Message -Filter {Size -gt 5242880}
) - Cuando la latencia baje a baja, reanude todos los mensajes (
Resume-Message
)
Fortalezas
- Muy simple de implementar
Debilidades
- No es la solución más elegante.
- La entrega de cada nuevo mensaje grande se puede intentar durante el intervalo entre
Suspend-Message
comandos, posiblemente aún desperdiciando algo de ancho de banda y creando congestiones (aunque muy brevemente en comparación con no hacer nada)
Preguntas
- ¿Alguna idea sobre cómo evitar los intentos de entregar mensajes grandes, entre
Suspend-Message
comandos? - Será
Get-Message
nunca los mensajes para entrega intra-servidor - sólo los mensajes de colas de entrega remota volver? Si no, ¿el nombre de identidad de las colas de entrega remota sigue un cierto patrón que puedo usar para filtrar?
Editar # 3: El camino a seguir
Después de presentar las soluciones propuestas en mi equipo (incluido el proxy SMTP, que no pude incluir en la edición n. ° 2), y según mi propia intuición, decidimos optar por un Agente de transporte de Exchange personalizado.
Estoy en contacto con un par de empresas de consultoría, que me responderán cómo atacará el problema y cuánto costará.
Si tiene alguna experiencia con las tareas de programación de outsourcing, no dude en dejar comentarios a mi pregunta relacionada sobre Stack Overflow , porque no lo hago.