Redundância de sombra

Aplica-se a: Exchange Server 2013

A redundância de 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 de sombra atrasou a exclusão de uma mensagem do banco de dados de transporte em um servidor de transporte até que o servidor verificava o próximo salto no caminho de entrega de mensagens concluído. Se o próximo salto falhar antes de relatar a entrega bem-sucedida de volta ao servidor de transporte, o servidor de transporte reapresentou a mensagem para o próximo salto. Os servidores do Exchange 2010 usaram o verbo XSHADOW para anunciar seu suporte de redundância de sombra. Se um servidor SMTP não deu suporte à redundância de sombra, o Exchange 2010 usou o reconhecimento atrasado com base em um intervalo de tempo configurado no conector De recebimento para fazer uma cópia redundante da mensagem.

A maior melhoria para a redundância de sombra no Microsoft Exchange Server 2013 é que o servidor de transporte agora faz uma cópia redundante de todas as mensagens recebidas antes de reconhecer o recebimento com êxito da mensagem de volta para o servidor de envio. O suporte ou a falta de suporte do servidor de envio para redundância de sombra não importa. Isso ajuda a garantir que todas as mensagens no pipeline de transporte do Exchange 2013 sejam 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á revivido novamente.

Componentes de redundância de sombra

A tabela a seguir descreve os componentes da redundância de sombra. Esses termos são usados em todo o tópico.

Termo	Descrição
Servidor de transporte	Um servidor do Exchange que tem filas de mensagens e é responsável pelo roteamento de mensagens. No Exchange 2013, um servidor de transporte é um servidor de caixa de correio (o serviço de transporte no servidor da caixa de correio).
Banco de dados de transporte	O banco de dados de fila de mensagens em um servidor de transporte do Exchange 2013. Filas de sombra e Safety Net também são armazenadas no banco de dados de transporte.
Limite de alta disponibilidade de transporte	Um DAG (grupo de disponibilidade de banco de dados) em ambientes DAG ou um site do Active Directory em ambientes que não são DAG. Quando uma mensagem chega em um servidor de transporte no limite de alta 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 alta disponibilidade de transporte, o Exchange deixa de manter cópias redundantes da mensagem.
Mensagem primária	A mensagem enviada ao pipeline de transporte para entrega.
Mensagem de sombra	A cópia redundante da mensagem que o servidor sombra manté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á processando a mensagem primária no momento.
Servidor sombra	O servidor de transporte que contém a mensagem de sombra para o servidor primário. Um servidor de transporte pode ser o servidor primário para algumas mensagens e o servidor de sombra para outras mensagens simultaneamente.
Fila de sombras	A fila de entrega em que o servidor sombra armazena mensagens de sombra. Para mensagens com vários destinatários, cada próximo salto para a mensagem primária requer filas de sombra separadas.
Descartar status	As informações que um servidor de transporte mantém para mensagens de sombra que indicam que a mensagem primária foi processada com êxito.
Descartar notificação	A resposta que um servidor sombra recebe de um servidor primário indicando que uma mensagem de sombra está pronta para ser descartada.
Rede de Segurança	A versão aprimorada do Exchange 2013 do despejo de transporte. As mensagens processadas ou entregues com êxito a um destinatário de caixa de correio pelo serviço de transporte em um servidor de caixa de correio são movidas para a Rede de Segurança. Para obter mais informações, consulte Rede de Segurança.
Gerenciador de Redundância de Sombras	O componente de transporte que gerencia a redundância de sombra.
Pulsação	O processo que permite que servidores primários e servidores de sombra verifiquem a disponibilidade uns dos outros.

Requisitos para redundância de sombra

Embora possa parecer óbvio, a redundância de sombra requer vários servidores da 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 ao 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 deverão estar no site do Active Directory local.
• Se o servidor mailbox for um membro de um DAG, os outros servidores de caixa de correio deverão pertencer ao mesmo DAG. Os outros servidores de caixa de correio que pertencem ao DAG podem estar no site do Active Directory local ou em um site remoto do Active Directory. Se o DAG abranger vários sites do Active Directory, a redundância de sombra preferirá criar uma cópia redundante da mensagem em um site remoto do Active Directory para resiliência do site.

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

• Em ambientes de servidor do Exchange único.
• Em DAGs sub provisionados.
• Durante a falha simultânea de dois ou mais servidores de transporte envolvidos na redundância de sombra de uma mensagem.

A redundância de sombra é habilitada por padrão

Por padrão, a redundância de sombra é habilitada globalmente no serviço de transporte em todos os servidores da Caixa de Correio usando o parâmetro ShadowRedundancyEnabled no cmdlet Set-TransportConfig . Por padrão, se o serviço de transporte em um servidor da Caixa de Correio não puder criar uma cópia redundante de uma mensagem, a mensagem não será rejeitada. No entanto, você pode configurar o Exchange 2013 para rejeitar uma mensagem se uma cópia redundante da mensagem não for criada usando 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. Você deve configurar o Exchange 2013 para rejeitar mensagens que não podem ser redundantes somente quando sua organização tiver vários servidores da caixa de correio do Exchange 2013 disponíveis.

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

Parâmetros que habilitam a redundância de sombra

Parâmetro	Valor padrão	Descrição
ShadowRedundancyEnabled em Set-TransportConfig	$true	$true permite a redundância de sombra em todos os servidores de transporte da organização. $false desabilita a redundância de sombra em todos os servidores de transporte da organização.
RejectMessageOnShadowFailure em Set-TransportConfig	$false	$false: quando uma cópia de sombra da mensagem não pode ser criada, a mensagem primária é aceita de qualquer maneira por servidores de transporte na organização. Essas mensagens não são redundantemente persistentes enquanto estão em trânsito. $true: nenhuma mensagem é aceita ou reconhecida por qualquer servidor de transporte na organização até que uma cópia de sombra da mensagem seja criada com êxito. Se uma cópia de sombra da mensagem não puder ser criada, a mensagem primária será rejeitada com um erro transitório. Todas as mensagens na organização são redundantes enquanto estão em trânsito. Você deve definir esse valor $true apenas se tiver vários servidores da caixa de correio do Exchange 2013 em um site do DAG ou do Active Directory em que uma cópia de sombra da mensagem pode ser criada. Esse parâmetro só é significativo quando ShadowRedundancyEnabled é $true.

Como as mensagens de sombra são criadas

O objetivo principal da redundância de sombra é sempre ter duas cópias de uma mensagem dentro de um limite de alta disponibilidade de transporte enquanto a mensagem está em trânsito. Onde e quando a cópia redundante da mensagem é criada depende de onde a mensagem veio e para onde a mensagem está indo. Há três fatores determinantes principais:

• Mensagens recebidas de fora de um limite de alta disponibilidade de transporte.
• Mensagens enviadas fora de um limite de alta disponibilidade de transporte.
• Mensagens recebidas do serviço envio de transporte da caixa de correio de um servidor de caixa de correio dentro do limite de alta disponibilidade de transporte.

Um limite de alta disponibilidade de transporte é um dos seguintes:

• Um DAG, para servidores de caixa de correio que são membros de um DAG. Isso 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 de sombra nunca rastreia mensagens de sombra em um limite de alta disponibilidade de transporte. Quando uma mensagem cruza o limite de alta disponibilidade de transporte, a redundância de sombra começa ou é reiniciada. Isso reduz o tráfego de manutenção de mensagens de sombra e impede que reenviações de mensagens de sombra ocorram em todo o limite de alta disponibilidade de transporte. Os servidores de Transporte do Hub do Exchange 2010 são um caso especial e são discutidos posteriormente neste tópico.

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

Quando o serviço de transporte em um servidor da Caixa de Correio do Exchange 2013 recebe uma mensagem de fora do limite de alta disponibilidade de transporte, o servidor mailbox não está preocupado com o suporte ou falta de suporte para redundância de sombra pelo servidor de envio. Enquanto a redundância de sombra estiver habilitada, o servidor mailbox que recebe a mensagem faz uma cópia redundante da mensagem em outro servidor da Caixa de Correio dentro do limite de alta disponibilidade de transporte antes de reconhecer o recebimento da mensagem de volta para o servidor de envio. Aqui está um exemplo de como o processo funciona:

1. Um servidor SMTP transmite uma mensagem para o serviço de transporte em um servidor de caixa de correio. O servidor da caixa de correio é o servidor primário e a mensagem é a mensagem primária.

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 Transport em um 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 se conectará a um servidor de caixa de correio diferente no mesmo DAG. Se o DAG abranger vários sites do Active Directory, um servidor de caixa de correio em um site do Active Directory diferente será preferido por padrão. Essa configuração é controlada pelo parâmetro ShadowMessagePreference no cmdlet Set-TransportService . O valor padrão é PreferRemote, mas você pode alterá-lo para RemoteOnly ou LocalOnly.
   • Se o servidor primário não for membro de um DAG, o servidor primário se conectará 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 de transporte em outro servidor da Caixa de Correio e o serviço de 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 de sombra e o servidor da caixa de correio que a mantém é o servidor de sombra do servidor primário. A mensagem existe em uma fila de sombras no servidor de sombras.

4. Depois que o servidor primário recebe o reconhecimento do servidor sombra, o servidor primário reconhece o recebimento 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 alta disponibilidade de transporte

Quando um servidor de transporte do Exchange 2013 transmite uma mensagem fora do limite de alta disponibilidade de transporte e o servidor SMTP do outro lado reconhece o recebimento bem-sucedido da mensagem, o servidor de transporte move a mensagem para a Rede de Segurança. Nenhuma resubmissão da mensagem da Rede de Segurança pode ocorrer depois que a mensagem primária tiver sido transmitida com êxito pelo limite de alta disponibilidade de transporte. Para obter mais informações sobre o Safety Net, consulte Safety Net.

Mensagens transmitidas dentro de um limite de alta disponibilidade de transporte

O roteamento de mensagens é otimizado no Exchange 2013 para que, quando o destino final estiver em um site do DAG ou do Active Directory, vários saltos entre o serviço de transporte em servidores de caixa de correio nesse site DAG ou Active Directory normalmente não sejam necessários. Depois que a mensagem é aceita pelo serviço de transporte em um 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 em si. O objetivo da redundância de sombra de manter duas cópias de uma mensagem em trânsito é cumprido quando uma cópia de sombra da mensagem existe em qualquer lugar no site do DAG ou do Active Directory. Normalmente, somente cenários de failover em um DAG que exigem o cmdlet Redirecionamento-Mensagem para drenar as filas ativas em um servidor da Caixa de Correio exigiriam vários saltos dentro do mesmo limite de alta disponibilidade de transporte.

Redundância de 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 da 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 de sombra usando o comando XSHADOW, mas o servidor mailbox não anuncia suporte para redundância de sombra. Isso impede que o servidor de Transporte do Hub do Exchange 2010 crie uma cópia de sombra da mensagem em um servidor da Caixa de Correio do Exchange 2013.

Quando o serviço de transporte em um servidor da Caixa de Correio do Exchange 2013 transmite uma mensagem para um Transporte do Hub do Exchange 2010 no mesmo site do Active Directory, o servidor da caixa de correio do Exchange 2013 sombreia a mensagem para o servidor de Transporte do Hub do Exchange 2010. Depois que o servidor da Caixa de Correio do Exchange 2013 recebe o reconhecimento 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 Safety Net. No entanto, as mensagens processadas com êxito armazenadas no Safety Net by Exchange 2013 Mailbox nunca são reenviadas para os servidores de Transporte do Hub do Exchange 2010.

Tempo limite de SMTP

Durante a tentativa de fazer uma cópia redundante da mensagem, a conexã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 ter tempo limite. Receber conectores e Enviar conectores têm um parâmetro ConnectionInactivityTimeOut para quando os dados estão sendo transmitidos no conector. Os conectores de recebimento também têm um parâmetro ConnectionTimeOut absoluto.

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

Se a cópia de sombra de uma mensagem for criada com êxito, mas a sessão SMTP entre o servidor SMTP de envio e o servidor primário sair, o servidor primário aceitará e processará a mensagem primária. O servidor SMTP de envio entregará novamente a mensagem não reconhecida, mas a detecção de mensagens duplicadas impedirá que os usuários da caixa de correio do Exchange vejam as mensagens duplicadas. Quando o servidor SMTP de envio reenvia a mensagem, o servidor primário criará outra cópia de sombra da mensagem. Não há nenhuma relação entre as mensagens de sombra criadas durante as resubmissões de mensagem pelo servidor SMTP de envio.

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

Parâmetros de criação de mensagens de sombra

Origem	Valor padrão	Descrição
ShadowMessagePreferenceSetting em Set-TransportConfig	PreferRemote	PreferRemote: tente fazer uma cópia de sombra da mensagem em um servidor de caixa de correio em um site do Active Directory diferente. Se a operação falhar, tente fazer uma cópia de sombra da mensagem em um servidor no site do Active Directory local. LocalOnly: uma cópia de sombra da mensagem só deve ser feita em um servidor de transporte no site do Active Directory local. RemoteOnly: uma cópia de sombra da mensagem só deve ser feita em um servidor de transporte em um site do Active Directory diferente. Esse parâmetro só é significativo quando o servidor primário que está tentando fazer uma cópia de sombra da mensagem é um servidor de caixa de correio que é membro de um DAG que abrange vários sites do Active Directory.
MaxRetriesForRemoteSiteShadow em Set-TransportConfig	4	Esse parâmetro é usado quando o servidor mailbox é 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 tentará criar uma cópia de sombra da mensagem em outro servidor da Caixa de Correio em um site remoto do Active directory até o número de vezes especificado por MaxRetriesForRemoteSiteShadow. Se isso falhar, o servidor mailbox tentará criar uma cópia de sombra da mensagem em um servidor de caixa de correio diferente no site do Active Directory local até o número de vezes especificado por MaxRetriesForLocalSiteShadow. Se ShadowMessagePreferenceSetting estiver definido como RemoteOnly, o servidor da caixa de correio só tentará criar uma cópia de sombra da mensagem em um servidor de caixa de correio em um site remoto do Active Directory até o número de vezes especificado por MaxRetriesForRemoteSiteShadow. O parâmetro Quando uma cópia de sombra da mensagem não pode ser criada com êxito: Se RejectMessageOnShadowFailure for $true, a mensagem primária será rejeitada com um erro transitório. Se RejectMessageOnShadowFailure for $false, a mensagem primária será aceita de qualquer maneira, mas não será redundantemente persistente.
MaxRetriesForLocalSiteShadow em Set-TransportConfig	2	Esse parâmetro é usado nas seguintes circunstâncias: Se o servidor mailbox for um 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 tentará criar uma cópia de sombra da mensagem em outro servidor da Caixa de Correio em um site remoto do Active directory até o número de vezes especificado por MaxRetriesForRemoteSiteShadow. Se isso falhar, o servidor mailbox tentará criar uma cópia de sombra da mensagem em um servidor de caixa de correio diferente no site do Active Directory local até o número de vezes especificado por MaxRetriesForLocalSiteShadow. Se ShadowMessagePreferenceSetting estiver definido como LocalOnly, o servidor da caixa de correio só tentará criar uma cópia de sombra da mensagem em um servidor de caixa de correio diferente no site do Active Directory local até o número de vezes especificado pelo MaxRetriesForLocalSiteShadow. Se o servidor mailbox não for membro de um DAG ou se o servidor mailbox for um membro de um DAG que está em um site do Active Directory, o servidor mailbox só tentará criar uma cópia de sombra da mensagem em um servidor caixa de correio diferente no site do Active Directory local até o número de vezes especificado por MaxRetriesForLocalSiteShadow. Quando uma cópia de sombra da mensagem não pode ser criada com êxito: Se RejectMessageOnShadowFailure for $true, a mensagem primária será rejeitada com um erro transitório. Se RejectMessageOnShadowFailure for $false, a mensagem primária será aceita de qualquer maneira, mas não será redundantemente persistente.
ConnectionInactivityTimeout no Set-ReceiveConnector	5 minutos no serviço de transporte em servidores de caixa de correio 5 minutos no serviço de transporte front-end em servidores de acesso ao cliente. 1 minuto em servidores do Edge Transport.	Esse parâmetro especifica o tempo máximo em que uma conexão SMTP aberta com um servidor de mensagens de origem pode permanecer ociosa antes que a conexão seja fechada. O valor desse parâmetro deve ser menor que o valor especificado pelo parâmetro ConnectionTimeout .
ConnectionTimeout no Set-ReceiveConnector	10 minutos no serviço de transporte em servidores de caixa de correio 10 minutos no serviço de transporte front-end em servidores de acesso ao cliente. 5 minutos em servidores de Transporte de Borda.	Esse parâmetro especifica o tempo máximo em que uma conexão SMTP com um servidor de mensagens de origem pode permanecer aberta, mesmo que o servidor de mensagens de origem esteja transmitindo dados. O valor desse parâmetro deve ser maior que o valor especificado pelo parâmetro ConnectionInactivityTimeout .
ConnectionInactivityTimeOut no Set-SendConnector	10 minutos	Esse parâmetro especifica o tempo máximo em que uma conexão SMTP aberta com um servidor de mensagens de destino pode permanecer ociosa antes que a conexão seja fechada.

Como as mensagens de sombra são mantidas

Depois que uma mensagem de sombra for criada com êxito, o trabalho de redundância de sombras apenas começou. O servidor primário e o servidor sombra precisam manter contato uns com os outros para acompanhar o progresso da mensagem.

Quando o servidor primário transmite a mensagem com êxito para o próximo salto e o próximo salto reconhece o recebimento da mensagem, o servidor primário atualiza o status de descarte da mensagem conforme a entrega é concluída. O status de descarte é basicamente uma mensagem que contém a lista de mensagens que estão sendo monitoradas. Uma mensagem entregue com êxito não precisa ser mantida em uma fila de sombras, portanto, depois que o servidor sombra souber que o servidor primário transmitiu a mensagem com êxito para o próximo salto, o servidor de sombra move a mensagem de sombra da fila de sombras para a Rede de Segurança.

O servidor de sombra determina o status de descarte das mensagens de sombra em suas filas de sombra consultando 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 de sombra emitirá o comando XQDISCARD para determinar o status de descarte 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 padrão é de 2 minutos. Depois que o servidor sombra abre uma sessão SMTP com o servidor primário, o servidor primário responde com as notificações de descarte para mensagens que se aplicam ao servidor de sombra de consulta. No Exchange 2013, as notificações de descarte são armazenadas em disco, não na memória. Portanto, se o serviço de Transporte do Microsoft Exchange for reiniciado, as notificações de descarte serão persistentes. Depois que o serviço é iniciado, o servidor primário ainda sabe sobre as mensagens processadas 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 é usada como a pulsação que determina a disponibilidade dos servidores. Se o servidor sombra não puder abrir uma sessão SMTP com o servidor primário após um intervalo de tempo pré-configurado ou se o banco de dados de transporte do servidor primário tiver uma ID de banco de dados diferente, o servidor de sombra se promoverá como o servidor primário, promoverá as mensagens de sombra como mensagens primárias e transmitirá as mensagens para o próximo salto. O intervalo de tempo é controlado pelo parâmetro ShadowResubmitTimeSpan no cmdlet Set-TransportConfig . O valor padrão é 3 horas.

O Shadow Redundância Manager é o componente principal de um servidor de transporte do Exchange 2013 responsável por gerenciar a redundância de sombra. O Gerenciador de Redundância de Sombras é responsável por manter as seguintes informações para todas as mensagens primárias que um servidor está processando no momento:

• O servidor de sombra para cada mensagem primária que está sendo processada.
• O status de descarte a ser enviado para servidores de sombra.

O Gerenciador de Redundância de Sombras é responsável pelo seguinte por todas as mensagens de sombra que um servidor de sombra tem em suas filas de sombra:

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

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

Parâmetro	Valor padrão	Descrição
ShadowHeartbeatFrequency em Set-TransportConfig	2 minutos	O tempo máximo que um servidor sombra aguarda antes de abrir uma conexão SMTP com o servidor primário para verificar o status de descarte das mensagens.
ShadowResubmitTimeSpan em Set-TransportConfig	3 horas	Quanto tempo um servidor aguarda antes de decidir se um servidor primário falhou e assume a propriedade de mensagens de sombra na fila de sombras para o servidor primário que é inacessível.
ShadowMessageAutoDiscardInterval em Set-TransportConfig	2 dias	Por quanto tempo um servidor retém eventos de descarte para mensagens entregues com êxito. Uma fila de servidor primário descarta eventos até ser consultado pelo servidor de sombras. No entanto, se o servidor sombra não consultar o servidor primário pela duração especificada neste parâmetro, o servidor primário excluirá os eventos de descarte enfileirados.
SafetyNetHoldTime em Set-TransportConfig	2 dias	Quanto tempo as mensagens processadas com êxito são retidas na Rede de Segurança. As mensagens de sombra não reconhecidas eventualmente expiram da Safety Net após a soma de SafetyNetHoldTime e MessageExpirationTimeout no Set-TransportService.
MessageExpirationTimeout no Set-TransportService	2 dias	Quanto tempo uma mensagem pode permanecer em uma fila antes de expirar.

Processamento de mensagens após uma interrupção

A redundância de sombra minimiza a perda de mensagens devido a interrupções no servidor. Quando um servidor de transporte volta a ficar online após uma interrupção, há dois cenários:

• O servidor volta online com um novo banco de dados de transporte: nesse cenário, o banco de dados de transporte é irrecuperável devido à corrupção de dados ou falha de hardware. Nesse caso, como o servidor de transporte terá uma nova ID de banco de dados, ele será reconhecido como uma nova rota pelos outros servidores de transporte da organização. Isso também se aplica à situação em que um servidor não pôde ser recuperado e um novo servidor foi provisionado como uma substituição.

• O servidor volta a funcionar com o mesmo banco de dados de transporte: nesse cenário, o servidor de transporte específico não falhou, mas ficou offline o suficiente para que o servidor sombra assumisse a propriedade das mensagens e as reenviasse. Por exemplo, uma falha no cartão de rede ou uma manutenção longa no servidor causaria esse cenário.

A tabela a seguir resume como a redundância de sombra reage a esses dois cenários. Para maior clareza, suponha que o servidor que teve uma interrupção se chama Caixa de Correio01.

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

Cenário de recuperação	Medidas tomadas
A caixa de correio01 volta online com um novo banco de dados.	Quando a Caixa de Correio01 ficar indisponível, cada servidor que tiver mensagens de sombra enfileiradas para o Mailbox01 assumirá a propriedade dessas mensagens e as reapresentará. Em seguida, as mensagens são entregues em seus destinos. O atraso máximo para mensagens é o valor do parâmetro ShadowHeartbeatFrequency no cmdlet Set-TransportConfig . O valor padrão é de 2 minutos.
A caixa de correio01 volta online com o mesmo banco de dados.	Depois que o Mailbox01 voltar a funcionar, ele entregará as mensagens em suas filas, que já foram entregues pelos servidores que contêm cópias de sombra de mensagens para a Caixa de Correio01. Isso resultará na entrega duplicada dessas mensagens. Os usuários da caixa de correio do Exchange não verão mensagens duplicadas devido à detecçã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 para mensagens é o valor do parâmetro ShadowResubmitTimeSpan no cmdlet Set-TransportConfig . O valor padrão é 3 horas.