Redundância de sombra

Aplica-se a: Exchange Server 2013

A redundância sombra foi introduzida no Microsoft Exchange Server 2010 para fornecer cópias redundantes de mensagens antes de serem entregues em caixas de correio. No Exchange 2010, a redundância sombra atrasou a eliminação de uma mensagem da base de dados de transporte num servidor de transporte até que o servidor verificava o próximo salto no caminho de entrega de mensagens para concluir a entrega. Se o salto seguinte tiver falhado antes de comunicar a entrega com êxito no servidor de transporte, o servidor de transporte voltou a submeter a mensagem para esse salto seguinte. Os servidores do Exchange 2010 utilizaram o verbo XSHADOW para anunciar o suporte de redundância sombra. Se um servidor SMTP não suportar a redundância sombra, o Exchange 2010 utilizou a confirmação atrasada com base num intervalo de tempo configurado no conector Receber para fazer uma cópia redundante da mensagem.

A grande melhoria da redundância sombra no Microsoft Exchange Server 2013 é que o servidor de transporte faz agora uma cópia redundante de todas as mensagens recebidas antes de reconhecer que recebe a mensagem de volta ao servidor de envio com êxito. O suporte do servidor de envio ou a falta de suporte para redundância sombra não importa. Isto ajuda a garantir que todas as mensagens no pipeline de transporte do Exchange 2013 são redundantes enquanto estão em trânsito. Se o Exchange 2013 determinar que a mensagem original foi perdida em trânsito, a cópia redundante da mensagem será resgatada novamente.

Componentes de redundância sombra

A tabela seguinte descreve os componentes da redundância sombra. Estes termos são utilizados ao longo do tópico.

Termo	Descrição
Servidor de transporte	Um servidor Exchange que tem filas de mensagens e é responsável pelo encaminhamento de mensagens. No Exchange 2013, um servidor de transporte é um servidor de Caixa de Correio (o serviço transporte no servidor da Caixa de Correio).
Base de dados de transporte	A base de dados de fila de mensagens num servidor de transporte do Exchange 2013. As filas sombra e a Rede de Segurança também são armazenadas na base de dados de transporte.
Limite de elevada disponibilidade do transporte	Um grupo de disponibilidade de base de dados (DAG) em ambientes DAG ou um site do Active Directory em ambientes não DAG. Quando uma mensagem chega a um servidor de transporte no limite de elevada disponibilidade de transporte, o Exchange tenta manter duas cópias redundantes da mensagem em servidores de transporte dentro do limite. Quando uma mensagem deixa o limite de elevada disponibilidade do transporte, o Exchange deixa de manter cópias redundantes da mensagem.
Mensagem primária	A mensagem enviada para o pipeline de transporte para entrega.
Mensagem sombra	A cópia redundante da mensagem que o servidor sombra retém até confirmar que a mensagem primária foi processada com êxito pelo servidor primário.
Servidor primário	O servidor de transporte que está atualmente a processar a mensagem primária.
Servidor sombra	O servidor de transporte que contém a mensagem sombra para o servidor primário. Um servidor de transporte pode ser o servidor primário de algumas mensagens e o servidor sombra para outras mensagens em simultâneo.
Fila de sombras	A fila de entrega onde o servidor sombra armazena mensagens sombra. Para mensagens com vários destinatários, cada próximo salto para a mensagem primária requer filas sombra separadas.
Eliminar status	As informações que um servidor de transporte mantém para mensagens sombra que indicam que a mensagem primária foi processada com êxito.
Eliminar notificação	A resposta que um servidor sombra recebe de um servidor primário que indica que uma mensagem sombra está pronta para ser eliminada.
Rede de Segurança	O Exchange 2013 melhorou a versão do contentor de lixo de transporte. As mensagens que são processadas ou entregues com êxito a um destinatário da caixa de correio pelo serviço transporte num servidor de Caixa de Correio são movidas para a Rede de Segurança. Para obter mais informações, consulte Rede de Segurança.
Gestor de Redundância Sombra	O componente de transporte que gere a redundância sombra.
Pulsação	O processo que permite que os servidores primários e os servidores sombra verifiquem a disponibilidade uns dos outros.

Requisitos para redundância sombra

Embora possa parecer óbvio, a redundância sombra requer vários servidores de Caixa de Correio do Exchange 2013. O servidor da Caixa de Correio pode ser servidores autónomos ou servidores de Caixa de Correio e servidores de Acesso de Cliente instalados no mesmo computador.

• Se o servidor da Caixa de Correio não for membro de um DAG, os outros servidores da Caixa de Correio têm de estar no site do Active Directory local.
• Se o servidor da Caixa de Correio for membro de um DAG, os outros servidores da Caixa de Correio têm de pertencer ao mesmo DAG. Os outros servidores da Caixa de Correio que pertencem ao DAG podem estar no site do Active Directory local ou num site remoto do Active Directory. Se o DAG abranger vários sites do Active Directory, a redundância sombra prefere criar uma cópia redundante da mensagem num site remoto do Active Directory para resiliência do site.

Estas são as situações em que a redundância sombra não pode proteger mensagens em trânsito:

• Em ambientes de servidor exchange individuais.
• Em DAGs subprovisionados.
• Durante a falha simultânea de dois ou mais servidores de transporte envolvidos na redundância sombra de uma mensagem.

A redundância sombra está ativada por predefinição

Por predefinição, a redundância sombra está ativada globalmente no serviço Transporte em todos os servidores da Caixa de Correio ao utilizar o parâmetro ShadowRedundancyEnabled no cmdlet Set-TransportConfig . Por predefinição, se o serviço Transporte num servidor de Caixa de Correio não conseguir criar uma cópia redundante de uma mensagem, a mensagem não será rejeitada. No entanto, pode configurar o Exchange 2013 para rejeitar uma mensagem se não for criada uma cópia redundante da mensagem com o parâmetro RejectMessageOnShadowFailure no cmdlet Set-TransportConfig . A mensagem é rejeitada com uma falha transitória, mas o servidor de envio pode transmitir a mensagem novamente. O código de resposta SMTP é 451 4.4.0 Message failed to be made redundant. Deve configurar o Exchange 2013 para rejeitar mensagens que não podem ser redundantes apenas quando a sua organização tem vários servidores de Caixa de Correio do Exchange 2013 disponíveis.

A tabela seguinte descreve os parâmetros que permitem a redundância sombra.

Parâmetros que permitem a redundância sombra

Parâmetro	Valor padrão	Descrição
ShadowRedundancyEnabled em Set-TransportConfig	$true	$true ativa a redundância sombra em todos os servidores de transporte na organização. $false desativa a redundância sombra em todos os servidores de transporte na organização.
RejectMessageOnShadowFailure em Set-TransportConfig	$false	$false: quando não é possível criar uma cópia sombra da mensagem, a mensagem principal é aceite de qualquer forma pelos servidores de transporte na organização. Essas mensagens não são mantidas redundantemente enquanto estão em trânsito. $true: nenhuma mensagem é aceite ou reconhecida por qualquer servidor de transporte na organização até que uma cópia sombra da mensagem seja criada com êxito. Se não for possível criar uma cópia sombra da mensagem, a mensagem primária é rejeitada com um erro transitório. Todas as mensagens na organização são mantidas redundantemente enquanto estão em trânsito. Deve definir este valor como $true apenas se tiver vários servidores de Caixa de Correio do Exchange 2013 num site da DAG ou do Active Directory onde pode ser criada uma cópia sombra da mensagem. Este parâmetro só é significativo quando ShadowRedundancyEnabled é $true.

Como as mensagens sombra são criadas

O objetivo main da redundância sombra é ter sempre duas cópias de uma mensagem dentro de um limite de elevada disponibilidade de transporte enquanto a mensagem estiver em trânsito. Onde e quando a cópia redundante da mensagem é criada depende de onde a mensagem veio e para onde vai a mensagem. Existem três fatores principais que determinam:

• Mensagens recebidas de fora de um limite de elevada disponibilidade de transporte.
• Mensagens enviadas fora de um limite de elevada disponibilidade de transporte.
• Mensagens recebidas do serviço Submissão de Transporte da Caixa de Correio a partir de um servidor de Caixa de Correio dentro do limite de elevada disponibilidade de transporte.

Um limite de elevada disponibilidade do transporte é um dos seguintes:

• Um DAG, para servidores de Caixa de Correio que são membros de um DAG. Isto inclui um DAG que abrange vários sites do Active Directory.
• Um site do Active Directory, para servidores de Caixa de Correio que não pertencem a um DAG.

A redundância sombra nunca monitoriza as mensagens sombra num limite de elevada disponibilidade de transporte. Quando uma mensagem ultrapassa o limite de elevada disponibilidade do transporte, a redundância sombra começa ou reinicia. Isto reduz o tráfego de manutenção de mensagens sombra e impede que resubmissões de mensagens sombra ocorram no limite de elevada disponibilidade do transporte. Os servidores de Transporte do Hub do Exchange 2010 são um caso especial e são abordados mais adiante neste tópico.

Mensagens recebidas de fora de um limite de elevada disponibilidade de transporte

Quando o serviço transporte num servidor de Caixa de Correio do Exchange 2013 recebe uma mensagem de fora do limite de elevada disponibilidade do transporte, o servidor da Caixa de Correio não está preocupado com o suporte ou a falta de suporte para redundância sombra pelo servidor de envio. Enquanto a redundância sombra estiver ativada, o servidor da Caixa de Correio que recebe a mensagem efetua uma cópia redundante da mensagem noutro servidor da Caixa de Correio dentro do limite de elevada disponibilidade do transporte antes de reconhecer a receção da mensagem de volta para o servidor de envio. Eis um exemplo de como o processo funciona:

1. Um servidor SMTP transmite uma mensagem para o serviço Transporte num servidor de Caixa de Correio. O servidor da Caixa de Correio é o servidor primário e a mensagem é a mensagem principal.

2. Embora a sessão SMTP original com o servidor SMTP ainda esteja ativa, o Serviço de transporte no servidor primário abre uma nova sessão SMTP simultânea com o serviço Transporte num servidor de Caixa de Correio diferente na organização para criar uma cópia redundante da mensagem.

   • Se o servidor primário for membro de um DAG, o servidor primário liga-se a um servidor de Caixa de Correio diferente no mesmo DAG. Se o DAG abranger vários sites do Active Directory, é preferível por predefinição um servidor de Caixa de Correio num site do Active Directory diferente. Esta definição é controlada pelo parâmetro ShadowMessagePreference no cmdlet Set-TransportService . O valor predefinido é PreferRemote, mas pode alterá-lo para RemoteOnly ou LocalOnly.
   • Se o servidor primário não for membro de um DAG, o servidor primário liga-se a um servidor de Caixa de Correio diferente no mesmo Site do Active Directory, independentemente do valor do parâmetro ShadowMessagePreference .

3. O servidor primário transmite uma cópia da mensagem para o serviço Transporte noutro servidor de Caixa de Correio e o serviço Transporte no outro servidor da Caixa de Correio reconhece que a cópia da mensagem foi criada com êxito. A cópia da mensagem é a mensagem sombra e o servidor da Caixa de Correio que a contém é o servidor sombra do servidor primário. A mensagem existe numa fila sombra no servidor sombra.

4. Depois de o servidor primário receber a confirmação do servidor sombra, o servidor primário reconhece a receção da mensagem primária para o servidor SMTP original na sessão SMTP original e a sessão SMTP é fechada.

Mensagens enviadas fora de um limite de elevada disponibilidade de transporte

Quando um servidor de transporte do Exchange 2013 transmite uma mensagem fora do limite de elevada disponibilidade do transporte e o servidor SMTP do outro lado reconhece a receção bem-sucedida da mensagem, o servidor de transporte move a mensagem para a Rede de Segurança. Não é possível submeter novamente a mensagem da Rede de Segurança depois de a mensagem primária ter sido transmitida com êxito através do limite de elevada disponibilidade do transporte. Para obter mais informações sobre a Rede de Segurança, consulte Rede de Segurança.

Mensagens transmitidas dentro de um limite de elevada disponibilidade de transporte

O encaminhamento de mensagens é otimizado no Exchange 2013 para que, quando o destino final estiver num site da DAG ou do Active Directory, não sejam normalmente necessários vários saltos entre o serviço Transporte em servidores de Caixa de Correio nesse site da DAG ou do Active Directory. Depois de a mensagem ser aceite pelo serviço transporte num servidor de Caixa de Correio no site do DAG ou do Active Directory que contém o destino final da mensagem, o próximo salto para a mensagem é normalmente o destino final. O objetivo da redundância sombra de manter duas cópias de uma mensagem em trânsito é cumprido quando existe uma cópia sombra da mensagem em qualquer parte do site do DAG ou do Active Directory. Normalmente, apenas os cenários de ativação pós-falha num DAG que exijam o cmdlet Redirect-Message para drenar as filas ativas num servidor da Caixa de Correio exigiriam vários saltos dentro do mesmo limite de elevada disponibilidade de transporte.

Redundância sombra com servidores de Transporte do Hub do Exchange 2010 no mesmo site do Active Directory

Quando um servidor de Transporte do Hub do Exchange 2010 transmite uma mensagem para um servidor de Caixa de Correio do Exchange 2013 no mesmo site do Active Directory, o servidor de Transporte do Hub do Exchange 2010 anuncia suporte para redundância sombra com o comando XSHADOW, mas o servidor da Caixa de Correio não anuncia suporte para redundância sombra. Isto impede que o servidor de Transporte do Hub do Exchange 2010 crie uma cópia sombra da mensagem num servidor de Caixa de Correio do Exchange 2013.

Quando o Serviço de transporte num servidor de Caixa de Correio do Exchange 2013 transmite uma mensagem para um Transporte de Hub do Exchange 2010 no mesmo site do Active Directory, o servidor da Caixa de Correio do Exchange 2013 ensombra a mensagem para o servidor de Transporte do Hub do Exchange 2010. Depois de o servidor da Caixa de Correio do Exchange 2013 receber a confirmação do servidor de Transporte do Hub do Exchange 2010 de que a mensagem foi recebida com êxito, o servidor da Caixa de Correio do Exchange 2013 move a mensagem processada com êxito para a Rede de Segurança. No entanto, as mensagens processadas com êxito armazenadas na Rede de Segurança pela Caixa de Correio do Exchange 2013 nunca são reenviadas para os servidores de Transporte do Hub do Exchange 2010.

Tempos limite de SMTP

Durante a tentativa de fazer uma cópia redundante da mensagem, a ligação SMTP entre o servidor SMTP de envio e o servidor primário ou a sessão SMTP entre o servidor primário e o servidor sombra pode exceder o tempo limite. Os conectores receive e Send connectors têm um parâmetro ConnectionInactivityTimeOut para quando os dados estão realmente a ser transmitidos no conector. Os conectores de receção também têm um parâmetro ConnectionTimeOut absoluto.

Se alguma das sessões SMTP exceder o limite de tempo antes de a cópia sombra da mensagem ser criada com êxito e reconhecida, o resultado será controlado pelo parâmetro RejectMessageOnShadowFailure no cmdlet Set-TransportConfig . Por predefinição, o valor deste parâmetro é $false, o que significa que a mensagem primária é aceite sem a criação de uma cópia sombra. Se o valor deste parâmetro for $true a mensagem primária for rejeitado com o erro 451 4.4.0transitório .

Se a cópia sombra de uma mensagem for criada com êxito, mas a sessão SMTP entre o servidor SMTP de envio e o servidor primário exceder o limite de tempo, o servidor primário aceita e processa a mensagem primária. O servidor SMTP de envio irá entregar novamente a mensagem não reconhecida, mas a deteção de mensagens duplicadas impedirá os utilizadores da caixa de correio do Exchange de verem as mensagens duplicadas. Quando o servidor SMTP de envio voltar a submeter a mensagem, o servidor primário criará outra cópia sombra da mensagem. Não existe nenhuma relação entre as mensagens sombra criadas durante as resubmissões de mensagens pelo servidor SMTP de envio.

A tabela seguinte descreve os parâmetros que controlam a criação de mensagens sombra

Parâmetros de criação de mensagens sombra

Origem	Valor padrão	Descrição
ShadowMessagePreferenceSetting em Set-TransportConfig	PreferRemote	PreferRemote: tente fazer uma cópia sombra da mensagem num servidor de Caixa de Correio num site do Active Directory diferente. Se a operação falhar, tente fazer uma cópia sombra da mensagem num servidor no site do Active Directory local. LocalOnly: uma cópia sombra da mensagem só deve ser efetuada num servidor de transporte no site do Active Directory local. RemoteOnly: uma cópia sombra da mensagem só deve ser efetuada num servidor de transporte num site do Active Directory diferente. Este parâmetro só é significativo quando o servidor primário que está a tentar fazer uma cópia sombra da mensagem é um servidor da Caixa de Correio que é membro de um DAG que abrange vários sites do Active Directory.
MaxRetriesForRemoteSiteShadow em Set-TransportConfig	4	Este parâmetro é utilizado quando o servidor da Caixa de Correio é membro de um DAG que abrange vários sites do Active Directory. Se ShadowMessagePreferenceSetting estiver definido como PreferRemote, primeiro, o servidor da Caixa de Correio tenta criar uma cópia sombra da mensagem noutro servidor da Caixa de Correio num site do Active Directory remoto até ao número de vezes especificado por MaxRetriesForRemoteSiteShadow. Se isto falhar, o servidor da Caixa de Correio tenta criar uma cópia sombra da mensagem num servidor de Caixa de Correio diferente no site do Active Directory local até ao número de vezes especificado por MaxRetriesForLocalSiteShadow. Se ShadowMessagePreferenceSetting estiver definido como RemoteOnly, o servidor da Caixa de Correio tenta apenas criar uma cópia sombra da mensagem num servidor de Caixa de Correio num site remoto do Active Directory até ao número de vezes especificado por MaxRetriesForRemoteSiteShadow. O parâmetro Quando uma cópia sombra da mensagem não pode ser criada com êxito: Se RejectMessageOnShadowFailure for $true, a mensagem primária é rejeitada com um erro transitório. Se RejectMessageOnShadowFailure for $false, a mensagem principal será aceite de qualquer forma, mas não será mantida redundantemente.
MaxRetriesForLocalSiteShadow em Set-TransportConfig	2	Este parâmetro é utilizado nas seguintes circunstâncias: Se o servidor da Caixa de Correio for membro de um DAG que abrange vários sites do Active Directory. Se ShadowMessagePreferenceSetting estiver definido como PreferRemote, primeiro, o servidor da Caixa de Correio tenta criar uma cópia sombra da mensagem noutro servidor da Caixa de Correio num site do Active Directory remoto até ao número de vezes especificado por MaxRetriesForRemoteSiteShadow. Se isto falhar, o servidor da Caixa de Correio tenta criar uma cópia sombra da mensagem num servidor de Caixa de Correio diferente no site do Active Directory local até ao número de vezes especificado por MaxRetriesForLocalSiteShadow. Se ShadowMessagePreferenceSetting estiver definido como LocalOnly, o servidor da Caixa de Correio tenta apenas criar uma cópia sombra da mensagem num servidor de Caixa de Correio diferente no site do Active Directory local até ao número de vezes especificado pelo MaxRetriesForLocalSiteShadow. Se o servidor da Caixa de Correio não for membro de um DAG ou se o servidor da Caixa de Correio for membro de um DAG que esteja num site do Active Directory, o servidor da Caixa de Correio tenta apenas criar uma cópia sombra da mensagem num servidor de Caixa de Correio diferente no site do Active Directory local até ao número de vezes especificado por MaxRetriesForLocalSiteShadow. Quando uma cópia sombra da mensagem não pode ser criada com êxito: Se RejectMessageOnShadowFailure for $true, a mensagem primária é rejeitada com um erro transitório. Se RejectMessageOnShadowFailure for $false, a mensagem principal será aceite de qualquer forma, mas não será mantida redundantemente.
ConnectionInactivityTimeout em Set-ReceiveConnector	5 minutos no serviço Transporte em servidores de Caixa de Correio 5 minutos no serviço transporte front-end em servidores de Acesso de Cliente. 1 minuto nos servidores de Transporte edge.	Este parâmetro especifica o tempo máximo durante o qual uma ligação SMTP aberta com um servidor de mensagens de origem pode permanecer inativa antes de a ligação ser fechada. O valor deste parâmetro tem de ser inferior ao valor especificado pelo parâmetro ConnectionTimeout .
ConnectionTimeout em Set-ReceiveConnector	10 minutos no serviço Transporte em servidores de Caixa de Correio 10 minutos no serviço transporte front-end em servidores de Acesso de Cliente. 5 minutos nos servidores de Transporte edge.	Este parâmetro especifica o tempo máximo durante o qual uma ligação SMTP com um servidor de mensagens de origem pode permanecer aberta, mesmo que o servidor de mensagens de origem esteja a transmitir dados. O valor deste parâmetro tem de ser maior do que o valor especificado pelo parâmetro ConnectionInactivityTimeout .
ConnectionInactivityTimeOut em Set-SendConnector	10 minutos	Este parâmetro especifica o tempo máximo durante o qual uma ligação SMTP aberta a um servidor de mensagens de destino pode permanecer inativa antes de a ligação ser fechada.

Como as mensagens sombra são mantidas

Após a criação com êxito de uma mensagem sombra, o trabalho de redundância sombra ainda agora começou. O servidor primário e o servidor sombra têm de permanecer em contacto uns com os outros para controlar o progresso da mensagem.

Quando o servidor primário transmite a mensagem com êxito para o salto seguinte e o próximo salto reconhece a receção da mensagem, o servidor primário atualiza a status de eliminação da mensagem à medida que a entrega é concluída. A status de eliminação é basicamente uma mensagem que contém uma lista de mensagens que estão a ser monitorizadas. Uma mensagem entregue com êxito não precisa de ser mantida numa fila sombra, pelo que assim que o servidor sombra souber que o servidor primário transmitiu a mensagem com êxito para o salto seguinte, o servidor sombra move a mensagem sombra da fila sombra para a Rede de Segurança.

O servidor sombra determina a status de eliminação das mensagens sombra nas respetivas filas sombra ao consultar o servidor primário. Se o servidor sombra abrir uma sessão SMTP com o servidor primário por qualquer motivo, incluindo a transmissão de outras mensagens não relacionadas, o servidor sombra emite o comando XQDISCARD para determinar a eliminação status das mensagens primárias. Se o servidor sombra não tiver aberto uma sessão SMTP com o servidor primário após um intervalo de tempo pré-configurado, o servidor sombra abrirá uma sessão SMTP com o servidor primário e emitirá o comando XQDISCARD . O intervalo de tempo é controlado pelo parâmetro ShadowHeartbeatFrequency no cmdlet Set-TransportConfig . O valor predefinido é 2 minutos. Depois de o servidor sombra abrir uma sessão SMTP com o servidor primário, o servidor primário responde com as notificações de eliminação de mensagens que se aplicam ao servidor sombra de consulta. No Exchange 2013, as notificações de rejeição são armazenadas no disco e não na memória. Por conseguinte, se o serviço de Transporte do Microsoft Exchange reiniciar, as notificações de rejeição serão mantidas. Após o início do serviço, o servidor primário ainda sabe das mensagens que processou com êxito e essas informações estão disponíveis para o servidor sombra.

A comunicação SMTP entre o servidor sombra e o servidor primário é utilizada como heartbeat que determina a disponibilidade dos servidores. Se o servidor sombra não conseguir abrir uma sessão SMTP com o servidor primário após um intervalo de tempo pré-configurado ou se a base de dados de transporte do servidor primário tiver um ID de base de dados diferente, o servidor sombra promove-se como o servidor primário, promove as mensagens sombra como mensagens primárias e transmite as mensagens para o salto seguinte. O intervalo de tempo é controlado pelo parâmetro ShadowResubmitTimeSpan no cmdlet Set-TransportConfig . O valor padrão é 3 horas.

O Gestor de Redundância Sombra é o componente principal de um servidor de transporte do Exchange 2013 responsável pela gestão da redundância sombra. O Gestor de Redundância Sombra é responsável por manter as seguintes informações para todas as mensagens principais que um servidor está atualmente a processar:

• O servidor sombra para cada mensagem primária a ser processada.
• A eliminação status a ser enviada para os servidores sombra.

O Gestor de Redundância Sombra é responsável pelo seguinte para todas as mensagens sombra que um servidor sombra tem nas suas filas sombra:

• Manter a lista de servidores primários para cada mensagem sombra.
• Comparar o ID da base de dados original e o ID de base de dados atual da base de dados de fila onde a cópia primária da mensagem está armazenada.
• Verificar a disponibilidade de cada servidor primário para o qual uma mensagem sombra está em fila.
• Processamento de notificações de eliminação de servidores primários.
• Remover as mensagens sombra das filas sombra depois de todas as notificações de eliminação esperadas serem recebidas.
• Decidir quando o servidor sombra deve assumir a propriedade das mensagens sombra, tornando-se um servidor primário.
• Controlar bifurcações de mensagens e outras mensagens de efeito colateral, como notificações de status de entrega (DSNs) e relatórios de diário para verificar se a cópia redundante da mensagem não é lançada até que todos os forks da mensagem sejam totalmente processados.

A tabela seguinte descreve os parâmetros que controlam a forma como as mensagens sombra são mantidas.

Parâmetro	Valor padrão	Descrição
ShadowHeartbeatFrequency em Set-TransportConfig	2 minutos	A quantidade máxima de tempo que um servidor sombra aguarda antes de abrir uma ligação SMTP ao servidor primário para marcar eliminar status de mensagens.
ShadowResubmitTimeSpan em Set-TransportConfig	3 horas	Quanto tempo um servidor aguarda antes de decidir que um servidor primário falhou e assume a propriedade das mensagens sombra na fila sombra do servidor primário inacessível.
ShadowMessageAutoDiscardInterval em Set-TransportConfig	2 dias	Durante quanto tempo um servidor retém eventos de rejeição para mensagens entregues com êxito. Os servidores primários eliminam eventos até serem consultados pelo servidor sombra. No entanto, se o servidor sombra não consultar o servidor primário durante a duração especificada neste parâmetro, o servidor primário elimina os eventos de eliminação em fila.
SafetyNetHoldTime em Set-TransportConfig	2 dias	Durante quanto tempo as mensagens processadas com êxito são mantidas na Rede de Segurança. As mensagens sombra não reconhecidas acabam por expirar da Rede de Segurança após a soma de SafetyNetHoldTime e MessageExpirationTimeout em Set-TransportService.
MessageExpirationTimeout em Set-TransportService	2 dias	Quanto tempo uma mensagem pode permanecer numa fila antes de expirar.

Processamento de mensagens após uma indisponibilidade

A redundância sombra minimiza a perda de mensagens devido a falhas no servidor. Quando um servidor de transporte volta a estar online após uma falha, existem dois cenários:

• O servidor volta a ficar online com uma nova base de dados de transporte: neste cenário, a base de dados de transporte é irrecuperável devido a danos nos dados ou a falhas de hardware. Neste caso, uma vez que o servidor de transporte terá um novo ID de base de dados, será reconhecido como uma nova rota pelos outros servidores de transporte na organização. Isto também se aplica à situação em que não foi possível recuperar um servidor e um novo servidor foi aprovisionado como uma substituição.

• O servidor volta a estar online com a mesma base de dados de transporte: neste cenário, o servidor de transporte específico não falhou, mas ficou offline o tempo suficiente para o servidor sombra assumir a propriedade das mensagens e submetê-las novamente. Por exemplo, uma falha de card de rede ou uma manutenção longa no servidor causaria este cenário.

A tabela seguinte resume como a redundância sombra reage a estes dois cenários. Para maior clareza, suponha que o servidor que teve uma falha tem o nome Caixa de Correio01.

Processamento de mensagens em cenários de recuperação

Cenário de recuperação	Medidas tomadas
A Caixa de Correio01 volta a estar online com uma nova base de dados.	Quando a Caixa de Correio01 fica indisponível, cada servidor com mensagens sombra em fila de espera para a Caixa de Correio01 assumirá a propriedade dessas mensagens e irá submetê-las novamente. Em seguida, as mensagens são entregues nos respetivos destinos. O atraso máximo das mensagens é o valor do parâmetro ShadowHeartbeatFrequency no cmdlet Set-TransportConfig . O valor predefinido é 2 minutos.
A caixa de correio01 volta a estar online com a mesma base de dados.	Depois de a Caixa de Correio01 voltar a ficar online, irá entregar as mensagens nas suas filas, que já foram entregues pelos servidores que contêm cópias sombra de mensagens para a Caixa de Correio01. Isto resultará na entrega duplicada destas mensagens. Os utilizadores da caixa de correio do Exchange não verão mensagens duplicadas devido à deteção de mensagens duplicadas. No entanto, os destinatários em sistemas de mensagens que não são do Exchange podem receber cópias duplicadas de mensagens. O atraso máximo das mensagens é o valor do parâmetro ShadowResubmitTimeSpan no cmdlet Set-TransportConfig . O valor padrão é 3 horas.