Programe / enfileire emails grandes no Exchange 2010, adie até a latência diminuir

Meu desafio

Temos servidores Exchange em vários locais, mas também a bordo de navios. Os navios estão conectados à nossa rede através de links de satélite quando estão no mar, mas mudam para pontes WiFi quando estão no porto.

Devido à alta latência (500+ ms) e interrupções incomuns (por exemplo, quando os navios estão virando), a tentativa de enviar e-mails acima de alguns megabytes enquanto no mar provavelmente falha e pode ser tentada novamente até o limite foi alcançado. O resultado: o email não é entregue e cada tentativa consome uma largura de banda valiosa no link via satélite.

Uma "solução" é limitar o tamanho máximo de e-mail para 5 MB, mas isso dificilmente é fácil de usar e é uma restrição desnecessária enquanto estiver na porta.

Ideia aproximada

O que eu prefiro fazer é enfileirar todos os e-mails maiores que um limite definido para entrega posterior no mar, enquanto envia todos os e-mails pequenos imediatamente. Eu estava pensando em fazer ping no servidor de transporte de hub em nosso datacenter regularmente, quando a latência cai abaixo de ~ 400 ms, eu começava a processar a grande fila de emails. Quando a latência sobe mais de 400 ms, eu tapava o buraco e deixava os e-mails na fila novamente.

Agora, eu não sujo minhas mãos com o Exchange desde a versão 2003. Naquela época, era possível agendar emails grandes para entrega posterior, então minha ideia era fazer algo semelhante no Exchange 2010 e criar uma maneira de alternar a entrega. agende grandes e-mails entre 'sempre' e 'nunca'.

Obstáculo

Não deve ser muito complicado criar um script como esse, mas li que o recurso em que eu confiava foi removido com o Exchange 2007:

Esse era um recurso presente no Exchange 2003, mas foi removido para o Exchange 2007. Ele foi definido em um Conector SMTP com o 'uso de prazos de entrega diferentes para mensagens de tamanho grande'.

TechCenter: É possível agendar a entrega de email com base no tamanho do Exchange?

Questões

É verdade? - Esse recurso não está mais presente no Exchange 2010 ou apenas se transformou em algo semelhante que posso usar para atingir meu objetivo? Se sim, o que?

Existe outra maneira de adiar a entrega de emails grandes em determinados servidores Exchange? Pode ser com base em um cronograma ou talvez até exigir uma ação específica - tenho certeza de que haverá uma maneira de acionar a entrega por meio de script, só preciso de emails grandes em uma fila separada nos navios.

Seus pensamentos sobre isso serão muito apreciados! :-)

Edição # 1: Idéia aproximada refinada

Eu me deparei com dois CmdLets do PowerShell que acho que podem me aproximar bastante do meu objetivo:

• Suspend-Message
• Resume-Message

Eu brinquei com o Get-Message por um tempo, para ver que tipo de mensagens os comandos acima lidariam.

Mais importante ainda, esses comandos aceitam um filtro de tamanho de mensagem. Este comando listará as mensagens na fila, no servidor atual, maiores que 5 MB (5.242.880 bytes):

get-message -Filter {Size -gt 5242880}

Parece que Get-Messageapenas retorna mensagens de várias filas de entrega remota. Mas as mensagens que fluem dentro do servidor, ainda que brevemente, aparecem em uma fila na qual Get / Suspend / Resume-Message irá mexer?

Caso contrário, a solução pode ser tão simples quanto um script agendado a cada poucos minutos, seguindo as linhas de (no pseudo-código):

if ping_rtt > 400 Then
    Suspend-Message -Filter {Size -gt 5242880}
Else
    Resume-Message
EndIf

Preocupações / perguntas de acompanhamento:

Principalmente irrelvant agora - veja a edição # 2.

Irá Get-Messageretornar apenas as mensagens de filas de entrega remota - nunca mensagens para entrega intra-servidor? Caso contrário, o nome da identidade das filas de entrega remota segue um certo padrão que eu posso usar para filtrar?

Isso pode / deve ser feito por meio de um agente de transporte personalizado (como sugerido por @longneck) ou de um coletor de eventos (se esse conceito ainda existir no Exchange 2010)?

Digamos que eu execute o script a cada 5 minutos, o que ainda significa que mensagens grandes sendo enviadas podem potencialmente causar problemas por até 5 minutos, antes de serem suspensas. Ainda estaríamos melhor do que estamos agora, mas não é o ideal. Eu poderia aumentar a frequência a cada minuto, mas não seria a solução mais elegante.

Mesmo se eu apenas verificar o tempo de ida e volta a cada 5 minutos (para economizar tráfego sat), qual mecanismo do Exchange eu precisaria configurar, para verificar o último RTT gravado, cada vez que uma mensagem é enviada para uma remota remota fila e, em seguida, executar ações apropriadas?

Edit # 2: Soluções propostas

Permitam-me resumir as soluções propostas e seus prós e contras, como eu o vejo:

Agente de Transporte Personalizado

Conceito

• Monitore periodicamente a latência, classifique-a como alta ou baixa (limite: 400 ms?)
• Por meio de um Agente de transporte personalizado, suspenda / retome todos os emails maiores que um limite definido, quando a classificação de latência for alterada
• Por meio do AT personalizado, coloque imediatamente as mensagens grandes enviadas posteriormente no modo "suspender", se a latência for alta

Forças

• E-mails grandes nunca são tentados entregues quando a latência é alta

Fraquezas

• Nenhuma habilidade de desenvolvimento para fazer isso internamente (observação: o código-fonte deve pertencer à minha empresa como parte do contrato com o desenvolvedor externo)
• O software de terceiros vinculado ao Exchange pode causar problemas ao corrigir ou atualizar
• É necessário algum tipo de contrato de suporte, caso algo dê errado (veja acima)

Mensagens grandes moderadas

Conceito

• Monitore periodicamente a latência, classifique-a como alta ou baixa (limite: 400 ms?)
• Com base na classificação de latência, configure as Regras de Transporte do Exchange por meio de script, para permitir que todas as mensagens fluam ou encaminhar mensagens grandes para o moderador
• Aprovar mensagens na fila do moderador quando o navio estiver no porto, possivelmente por um ser humano

Forças

• E-mails grandes nunca são tentados entregues quando a latência é alta
• As mensagens são suspensas usando regras de transporte nativas nativas do Exchange

Fraquezas

• Pelo que parece, as mensagens não podem ser aprovadas programaticamente quando a latência é baixa; portanto, é necessária intervenção humana sempre que o navio está no porto
• Possivelmente problemas de privacidade, se a moderação não for tratada de forma programática

Questões

• As mensagens podem ser aprovadas programaticamente a partir da caixa de correio do moderador? Quão?

Comandos agendados do PowerShell

Conceito

• Monitore periodicamente a latência, classifique-a como alta ou baixa (limite: 400 ms?)
• Desde que a latência seja alta, freqüentemente (a cada minuto?) Suspende qualquer mensagem grande ( Suspend-Message -Filter {Size -gt 5242880})
• Quando a latência cair para baixo, retome todas as mensagens ( Resume-Message)

Forças

• Muito simples de implementar

Fraquezas

• Não é a solução mais elegante
• A entrega de cada nova mensagem grande pode ser tentada enquanto o intervalo entre os Suspend-Messagecomandos, possivelmente ainda desperdiçando alguma largura de banda e criando congestionamentos (embora muito brevemente comparado a não fazer nada)

Questões

• Alguma idéia de como impedir tentativas de entregar mensagens grandes, Suspend-Messagecomandos intermediários ?
• Irá Get-Messageretornar apenas as mensagens de filas de entrega remota - nunca mensagens para entrega intra-servidor? Caso contrário, o nome da identidade das filas de entrega remota segue um certo padrão que eu posso usar para filtrar?

Edição # 3: O caminho a seguir

Depois de apresentar as soluções propostas em minha equipe (incluindo o proxy SMTP, que não incluí na edição nº 2), e com base no meu próprio pressentimento, decidimos optar por um Exchange Transport Agent personalizado.

Estou em contato com algumas empresas de consultoria, que responderão a mim como o problema será atacado e o que custaria.

Se você tem alguma experiência com tarefas de programação de terceirização, sinta-se à vontade para deixar comentários sobre minha pergunta relacionada ao Stack Overflow , porque não.

Para resolver o problema da maneira solicitada, você pode escrever seu próprio Agente de Transporte usando o SDK do Microsoft Exchange Transport Agent . Os Agentes de Transporte são baseados em eventos, portanto, o Exchange chamará uma função na sua biblioteca quando uma mensagem for recebida. Sua biblioteca pode fazer algo como reter a mensagem. Se você não possui as habilidades internas para fazer isso, tenho certeza de que poderia contratar um desenvolvedor para escrever para você.

Mas não acho que seja uma ótima solução. Como alternativa para você investigar, convém procurar algo como um proxy SMTP para obter links de baixa qualidade. Como você descobriu, o SMTP é um protocolo horrível para links de baixa qualidade, porque uma conexão interrompida faz com que a transmissão de mensagens seja reiniciada desde o início, em vez de continuar de onde parou. Se você for contratar um desenvolvedor para algo, considere escrever um programa de servidor que aceite conexões SMTP de entrada e envie a mensagem para uma instância remota desse mesmo programa na outra extremidade da conexão via satélite de uma maneira recuperável ( possivelmente segregando as mensagens grandes das mensagens pequenas via porta TCP para permitir o tratamento de QoS pelo seu acelerador WAN). A instância remota poderia, após o recebimento da mensagem completa,

Moderação da mensagem

Uma solução provavelmente não ideal é usar uma regra de transporte para encaminhar mensagens de um determinado tamanho para o gerente do remetente ou para uma caixa de correio designada (no servidor Exchange do navio) para moderação. Dessa forma, se estiverem no mar, as mensagens grandes poderão ser essencialmente enfileiradas em outra caixa de correio. Quando o navio chega ao porto, o gerente ou o moderador designado pode aprová-los para entrega.

As desvantagens são:

• esta regra está sempre ativada, a menos que você a desabilite manualmente (mas pode ser feita por meio de um script); mesmo na porta, mensagens grandes serão redirecionadas para a caixa de correio do moderador
• todas as mensagens grandes precisariam de revisão manual por alguém antes do envio, mas você pode adicionar exceções à regra para itens específicos
• outra pessoa estaria lendo e-mails enviados, o que pode não ser o ideal devido a questões de privacidade, mas isso depende da sua organização

Uma vantagem é que você teria que tomar decisões humanas sobre se uma mensagem deveria ou não ser enviada, como se um usuário estivesse tentando enviar um monte de porcarias não relacionadas ao trabalho que atrapalhariam a conexão sem motivo. Eles podem ser corrigidos por controles administrativos, como apontar para uma política e dar um tapa no pulso para que não o façam novamente.

Regras de Transporte do Exchange 2010

Script personalizado

RE: Um script personalizado para gerenciar e-mails grandes. Pude ver algo como o abaixo, que habilitaria / desabilitaria o conector de envio no servidor Exchange. Uma desvantagem é que todo o correio é mantido na fila em vez de apenas mensagens grandes, mas alguma lógica nesse sentido deve funcionar:

1. Verifique a latência. Se estiver baixo, ative o conector de envio, cancele a suspensão de mensagens grandes e aguarde 5 minutos (ou outro período arbitrário). Se estiver alto, desative o conector de envio.
2. Espere 5 minutos.
3. Após 5 minutos, verifique as mensagens grandes e suspenda-as. Reative o conector de envio de forma que as mensagens enfileiradas sejam liberadas até a fila ficar vazia (você pode até passar uma mensagem por vez para não entupir o link da fila / WAN após reativar o conector de envio)
4. Desative o conector de envio e vá para o 1

Essa lógica não é totalmente polida para fazer 100% de sentido, mas você entendeu: enfileirar todo o correio, verificar a latência, suspender mensagens grandes se estiver alto, desenfileirar o correio, enfileirar todo o correio, etc. Outra desvantagem da execução se um script travar ou parar, como você saberia reinicializá-lo sem uma equipe de TI a bordo dos navios? Ele pode potencialmente parar todos os emails de saída indefinidamente (se parar após a desativação do conector de envio) ou você pode perder o controle de mensagens grandes se deixar o conector de saída ativado e o script não estiver mais em execução.

Proxy SMTP

Mesmo que você tenha indicado que é contra qualquer manipulação de mensagens fora do Exchange, depois de pensar um pouco mais sobre isso, decidi que estou com @longneck usando algum tipo de solução de proxy SMTP. Até o SMTP do IIS tem um mecanismo de entrega adiado que, aparentemente, o Exchange 2010 não possui. Você pode redirecionar mensagens grandes para o servidor SMTP do IIS que podem armazená-las em disco e, verificando a latência primeiro, fazer com que o servidor SMTP do IIS as envie por meio de um script quando a latência estiver baixa. Na pior das hipóteses, se o mecanismo de agendamento travar ou parar, as mensagens grandes ficam presas no disco, mas as mensagens pequenas continuam sendo enviadas. Provavelmente existem soluções melhores que o SMTP do IIS, e eu nunca as usei, mas é apenas um exemplo.

Configurar email SMTP no IIS 7

Tente dar uma olhada nos novos recursos de "Otimização de mensagens" introduzidos no Exchange 2010 SP1. Pode ser muito útil para o seu caso de uso.

http://technet.microsoft.com/en-us/library/bb232205(v=exchg.141).aspx