Ridondanza shadow

Si applica a: Exchange Server 2013

La ridondanza shadow è stata introdotta nel Microsoft Exchange Server 2010 per fornire copie ridondanti dei messaggi prima che vengano recapitati alle cassette postali. In Exchange 2010 la ridondanza shadow ha ritardato l'eliminazione di un messaggio dal database di trasporto in un server di trasporto fino a quando il server non ha verificato il recapito dell'hop successivo nel percorso di recapito del messaggio. Se l'hop successivo non è riuscito prima di segnalare il recapito corretto al server di trasporto, il server di trasporto ha inviato nuovamente il messaggio all'hop successivo. I server Exchange 2010 hanno usato il verbo XSHADOW per annunciare il supporto della ridondanza shadow. Se un server SMTP non supporta la ridondanza shadow, Exchange 2010 ha usato l'acknowledgement ritardato in base a un intervallo di tempo configurato nel connettore di ricezione per creare una copia ridondante del messaggio.

Il miglioramento principale della ridondanza shadow in Microsoft Exchange Server 2013 consiste nel fatto che il server di trasporto esegue ora una copia ridondante di tutti i messaggi ricevuti prima di confermare la corretta ricezione del messaggio al server di invio. Il supporto del server di invio o la mancanza di supporto per la ridondanza shadow non è importante. Ciò consente di garantire che tutti i messaggi nella pipeline di trasporto di Exchange 2013 vengano resi ridondanti mentre sono in transito. Se Exchange 2013 determina che il messaggio originale è stato perso durante il transito, la copia ridondante del messaggio viene ridistribuito.

Componenti della ridondanza shadow

Nella tabella seguente vengono descritti i componenti della ridondanza shadow. In questo argomento vengono utilizzati i seguenti termini:

Termine	Descrizione
Server di trasporto	Un server Exchange con code di messaggi ed è responsabile del routing dei messaggi. In Exchange 2013 un server di trasporto è un server Cassette postali (il servizio Trasporto nel server Cassette postali).
Database di trasporto	Database della coda di messaggi in un server di trasporto exchange 2013. Le code shadow e la rete di sicurezza vengono archiviate anche nel database di trasporto.
Limite di disponibilità elevata del trasporto	Un gruppo di disponibilità del database (DAG) in ambienti DAG, oppure un sito Active Directory in ambienti non DAG. Quando un messaggio arriva su un server di trasporto nel limite di disponibilità elevata del trasporto, Exchange tenta di mantenere 2 copie ridondanti del messaggio nei server di trasporto all'interno del limite. Quando un messaggio lascia il limite di disponibilità elevata del trasporto, Exchange smette di conservare le copie ridondanti del messaggio.
Messaggio principale	Il messaggio inviato alla pipeline di trasporto per il recapito.
Messaggio shadow	La copia ridondante del messaggio che il server shadow gestisce fino alla conferma che il messaggio primario è stato correttamente elaborato dal server primario.
Server primario	Server di trasporto che sta attualmente elaborando il messaggio primario.
Server shadow	Server di trasporto che contiene il messaggio shadow per il server primario. Un server di trasporto può essere il server primario per alcuni messaggi e il server shadow per altri messaggi contemporaneamente.
Coda shadow	La coda di recapito dove il server shadow archivia i messaggi shadow. Per i messaggi con più destinatari, ogni hop successivo per il messaggio primario richiede code shadow separate.
Stato di eliminazione	Informazioni mantenute da un server di trasporto per i messaggi shadow che indicano che il messaggio primario è stato elaborato correttamente.
Notifica di eliminazione	La risposta che un server shadow riceve da un server primario che indica che un messaggio shadow è pronto per la rimozione.
Rete sicura	Versione migliorata di Exchange 2013 del dumpster di trasporto. I messaggi correttamente elaborati o recapitati a un destinatario di cassette postali dal servizio Trasporto su un server Cassette postali sono trasferiti in Safety Net. Per ulteriori informazioni, vedere Rete sicura.
Shadow Redundancy Manager	Componente di trasporto che gestisce la ridondanza shadow.
Heartbeat	Il processo che consente ai server primari e ai server shadow di verificare reciprocamente la disponibilità.

Requisiti per la ridondanza shadow

Sebbene possa sembrare ovvio, la ridondanza shadow richiede più server Cassette postali di Exchange 2013. Il server Cassette postali può essere server autonomi oppure server Cassette postali e server Accesso client installati nello stesso computer.

• Se il server Cassette postali non è membro di un gruppo di disponibilità del database, gli altri server Cassette postali devono trovarsi nel sito Active Directory locale.
• Se il server Cassette postali è membro di un gruppo di disponibilità del database, gli altri server Cassette postali devono appartenere allo stesso gruppo. Gli altri server Cassette postali che appartengono al gruppo di disponibilità del database possono trovarsi nel sito active directory locale o in un sito di Active Directory remoto. Se il gruppo di disponibilità del database si estende su più siti di Active Directory, la ridondanza shadow preferisce creare una copia ridondante del messaggio in un sito di Active Directory remoto per la resilienza del sito.

Di seguito sono riportate le situazioni in cui la ridondanza shadow non può proteggere i messaggi in transito:

• Negli ambienti con server Exchange singolo.
• Nei gruppi di disponibilità del database con provisioning.
• Durante l'errore simultaneo di due o più server di trasporto coinvolti nella ridondanza shadow di un messaggio.

La ridondanza shadow è abilitata per impostazione predefinita

Per impostazione predefinita, la ridondanza shadow è abilitata a livello globale nel servizio Trasporto in tutti i server Cassette postali usando il parametro ShadowRedundancyEnabled nel cmdlet Set-TransportConfig . Per impostazione predefinita, se il servizio trasporto in un server Cassette postali non è in grado di creare una copia ridondante di un messaggio, il messaggio non viene rifiutato. È tuttavia possibile configurare Exchange 2013 per rifiutare un messaggio se non viene creata una copia ridondante del messaggio usando il parametro RejectMessageOnShadowFailure nel cmdlet Set-TransportConfig . Il messaggio viene rifiutato con un errore temporaneo, ma il server di invio può trasmettere nuovamente il messaggio. Il codice di risposta SMTP è 451 4.4.0 Message failed to be made redundant. È necessario configurare Exchange 2013 per rifiutare i messaggi che non possono essere resi ridondanti solo quando l'organizzazione dispone di più server Cassette postali di Exchange 2013 disponibili.

Nella tabella seguente vengono descritti i parametri che consentono la ridondanza shadow.

Parametri che abilitano la ridondanza shadow

Parametro	Valore predefinito	Descrizione
ShadowRedundancyEnabled in Set-TransportConfig	$true	$true consente la ridondanza shadow in tutti i server di trasporto dell'organizzazione. $false disabilita la ridondanza shadow in tutti i server di trasporto dell'organizzazione.
RejectMessageOnShadowFailure in Set-TransportConfig	$false	$false: quando non è possibile creare una copia shadow del messaggio, il messaggio primario viene accettato comunque dai server di trasporto dell'organizzazione. Questi messaggi non vengono resi persistenti in modo ridondante mentre sono in transito. $true: nessun messaggio viene accettato o riconosciuto da alcun server di trasporto nell'organizzazione fino a quando non viene creata correttamente una copia shadow del messaggio. Se non è possibile creare una copia shadow del messaggio, il messaggio primario viene rifiutato con un errore temporaneo. Tutti i messaggi nell'organizzazione sono persistenti in maniera ridondante durante il transito. È consigliabile impostare questo valore $true su solo se sono presenti più server Cassette postali di Exchange 2013 in un gruppo di disponibilità del database o in un sito di Active Directory in cui è possibile creare una copia shadow del messaggio. Questo parametro è significativo solo quando ShadowRedundancyEnabled è $true.

Modalità di creazione dei messaggi shadow

L'obiettivo principale della ridondanza shadow è sempre quello di avere due copie di un messaggio entro un limite di disponibilità elevata del trasporto mentre il messaggio è in transito. La posizione e il momento in cui viene creata la copia ridondante del messaggio dipende dalla provenienza del messaggio e dalla posizione in cui sta andando il messaggio. Esistono tre fattori determinanti principali:

• Messaggi ricevuti dall'esterno di un limite di disponibilità elevata del trasporto.
• Messaggi inviati esternamente a un limite di disponibilità elevata del trasporto.
• Messaggi ricevuti dal servizio Invio Trasporto cassette postali da un server Cassette postali nel limite di disponibilità elevata del trasporto.

Un limite di disponibilità elevata del trasporto è uno dei seguenti:

• Dag, per i server Cassette postali che sono membri di un dag. Questo include un gruppo di disponibilità del database che si estende su più siti di Active Directory.
• Un sito di Active Directory, per i server Cassette postali che non appartengono a un gruppo di disponibilità del database.

La ridondanza shadow non tiene mai traccia dei messaggi shadow attraverso un limite di disponibilità elevata del trasporto. Quando un messaggio supera il limite di disponibilità elevata del trasporto, la ridondanza shadow viene avviata o riavviata. Ciò riduce il traffico di manutenzione dei messaggi shadow e impedisce che le reinviazioni di messaggi shadow si verifichino attraverso il limite di disponibilità elevata del trasporto. I server Trasporto Hub di Exchange 2010 rappresentano un caso speciale e sono affrontati più avanti in questo argomento.

Messaggi ricevuti esternamente a un limite di disponibilità elevata del trasporto

Quando il servizio Trasporto in un server Cassette postali di Exchange 2013 riceve un messaggio dall'esterno del limite di disponibilità elevata del trasporto, il server Cassette postali non è preoccupato per il supporto o la mancanza di supporto per la ridondanza shadow da parte del server di invio. Finché la ridondanza shadow è abilitata, il server Cassette postali che riceve il messaggio crea una copia ridondante del messaggio su un altro server Cassette postali nel limite di disponibilità elevata del trasporto prima di dare atto della ricezione del messaggio al server di invio. Ecco un esempio di funzionamento del processo:

1. Un server SMTP trasmette un messaggio al servizio Trasporto in un server Cassette postali. Il server Cassette postali è il server primario e il messaggio è il messaggio primario.

2. Mentre la sessione SMTP originale con il server SMTP è ancora attiva, il servizio Trasporto nel server primario apre una nuova sessione SMTP simultanea con il servizio Trasporto in un altro server Cassette postali dell'organizzazione per creare una copia ridondante del messaggio.

   • Se il server primario è un membro di un DAG, il server primario si connette a un server Cassette postali diverso nello stesso DAG. Se il gruppo di disponibilità del database si estende su più siti di Active Directory, per impostazione predefinita è preferibile un server Cassette postali in un altro sito di Active Directory. Questa impostazione è controllata dal parametro ShadowMessagePreference nel cmdlet Set-TransportService . Il valore predefinito è PreferRemote, ma è possibile modificarlo in RemoteOnly o LocalOnly.
   • Se il server primario non è membro di un dag, il server primario si connette a un server Cassette postali diverso nello stesso sito di Active Directory, indipendentemente dal valore del parametro ShadowMessagePreference .

3. Il server primario trasmette una copia del messaggio al servizio Trasporto in un altro server Cassette postali e il servizio Trasporto nell'altro server Cassette postali riconosce che la copia del messaggio è stata creata correttamente. La copia del messaggio è il messaggio shadow e il server Cassette postali che lo gestisce è il server shadow per il server primario. Il messaggio esiste in una coda shadow sul server shadow.

4. Dopo che il server primario riceve l'acknowledgement dal server shadow, il server primario conferma la ricezione del messaggio primario al server SMTP originale nella sessione SMTP originale e la sessione SMTP viene chiusa.

Messaggi inviati esternamente a un limite di disponibilità elevata del trasporto

Quando un server di trasporto di Exchange 2013 trasmette un messaggio al di fuori del limite di disponibilità elevata del trasporto e il server SMTP dall'altro lato riconosce la corretta ricezione del messaggio, il server di trasporto sposta il messaggio in Safety Net. Non può verificarsi alcun rinvio del messaggio da Safety Net dopo che il messaggio primario è stato trasmesso attraverso il limite di disponibilità elevata del trasporto. Per ulteriori informazioni su Safety Net, vedere Rete sicura.

Messaggi trasmessi all'interno di un limite di disponibilità elevata del trasporto

Il routing dei messaggi è ottimizzato in Exchange 2013 in modo che quando la destinazione finale si trova in un gruppo di disponibilità del database o in un sito di Active Directory, in genere non sono necessari più hop tra il servizio Trasporto nei server Cassette postali in tale dag o sito di Active Directory. Dopo che il messaggio viene accettato dal servizio Trasporto in un server Cassette postali nel gruppo di disponibilità del database o nel sito di Active Directory che contiene la destinazione finale per il messaggio, l'hop successivo per il messaggio è in genere la destinazione finale stessa. L'obiettivo della ridondanza shadow di mantenere due copie di un messaggio in transito viene soddisfatto quando esiste una copia shadow del messaggio in qualsiasi punto del gruppo di disponibilità del database o del sito di Active Directory. In genere, solo gli scenari di failover in un dag che richiedono il cmdlet Redirect-Message per svuotare le code attive in un server Cassette postali richiederebbero più hop all'interno dello stesso limite di disponibilità elevata del trasporto.

Ridondanza shadow con server Trasporto Hub Exchange 2010 nello stesso sito Active Directory

Quando un server Trasporto hub di Exchange 2010 trasmette un messaggio a un server Cassette postali di Exchange 2013 nello stesso sito di Active Directory, il server Trasporto hub di Exchange 2010 annuncia il supporto per la ridondanza shadow usando il comando XSHADOW, ma il server Cassette postali non annuncia il supporto per la ridondanza shadow. Ciò impedisce al server Trasporto hub di Exchange 2010 di creare una copia shadow del messaggio in un server Cassette postali di Exchange 2013.

Quando il servizio Trasporto in un server Cassette postali di Exchange 2013 trasmette un messaggio a un trasporto hub di Exchange 2010 nello stesso sito di Active Directory, il server Cassette postali di Exchange 2013 nasconde il messaggio per il server Trasporto hub di Exchange 2010. Dopo che il server Cassette postali di Exchange 2013 riceve l'conferma dal server Trasporto hub di Exchange 2010 che il messaggio è stato ricevuto correttamente, il server Cassette postali di Exchange 2013 sposta il messaggio elaborato correttamente in Safety Net. Tuttavia, i messaggi elaborati correttamente archiviati in Safety Net dalla cassetta postale di Exchange 2013 non vengono mai più inviati ai server Trasporto hub di Exchange 2010.

Timeout SMTP

Durante il tentativo di eseguire una copia ridondante del messaggio, la connessione SMTP tra il server SMTP di invio e il server primario o la sessione SMTP tra il server primario e il server shadow potrebbe timeout. I connettori di ricezione e i connettori di invio hanno entrambi un parametro ConnectionInactivityTimeOut per quando i dati vengono effettivamente trasmessi sul connettore. I connettori di ricezione hanno anche un parametro ConnectionTimeOut assoluto.

Se una delle sessioni SMTP si verifica prima che la copia shadow del messaggio venga creata e riconosciuta correttamente, il risultato viene controllato dal parametro RejectMessageOnShadowFailure nel cmdlet Set-TransportConfig . Per impostazione predefinita, il valore di questo parametro è $false, il che significa che il messaggio primario viene accettato senza che venga creata una copia shadow. Se il valore di questo parametro è $true il messaggio primario viene rifiutato con l'errore 451 4.4.0temporaneo .

Se la copia shadow di un messaggio viene creata correttamente, ma la sessione SMTP tra il server SMTP di invio e il server primario scade, il server primario accetta ed elabora il messaggio primario. Il server SMTP di invio recapiterà nuovamente il messaggio non riconosciuto, ma il rilevamento dei messaggi duplicati impedirà agli utenti della cassetta postale di Exchange di visualizzare i messaggi duplicati. Quando il server SMTP di invio invia di nuovo il messaggio, il server primario creerà un'altra copia shadow del messaggio. Non esiste alcuna relazione tra i messaggi shadow creati durante la reinvio di messaggi da parte del server SMTP di invio.

Nella tabella seguente sono descritti i parametri che controllano la creazione dei messaggi shadow

Parametri di creazione dei messaggi shadow

Origine	Valore predefinito	Descrizione
ShadowMessagePreferenceSetting in Set-TransportConfig	PreferRemote	PreferRemote: provare a creare una copia shadow del messaggio in un server Cassette postali in un altro sito di Active Directory. Se l'operazione ha esito negativo, provare a creare una copia shadow del messaggio in un server nel sito active directory locale. LocalOnly: una copia shadow del messaggio deve essere eseguita solo in un server di trasporto nel sito active directory locale. RemoteOnly: una copia shadow del messaggio deve essere eseguita solo in un server di trasporto in un altro sito di Active Directory. Questo parametro è significativo solo quando il server primario che sta tentando di creare una copia shadow del messaggio è un server Cassette postali membro di un gruppo di disponibilità del database che si estende su più siti di Active Directory.
MaxRetriesForRemoteSiteShadow in Set-TransportConfig	4	Questo parametro viene usato quando il server Cassette postali è un membro di un dag che si estende su più siti di Active Directory. Se ShadowMessagePreferenceSetting è impostato su PreferRemote, prima il server Cassette postali tenta di creare una copia shadow del messaggio in un altro server Cassette postali in un sito active directory remoto fino al numero di volte specificato da MaxRetriesForRemoteSiteShadow. In caso di errore, il server Cassette postali tenta di creare una copia shadow del messaggio in un server Cassette postali diverso nel sito Active Directory locale fino al numero di volte specificato da MaxRetriesForLocalSiteShadow. Se ShadowMessagePreferenceSetting è impostato su RemoteOnly, il server Cassette postali tenta solo di creare una copia shadow del messaggio in un server Cassette postali in un sito active directory remoto fino al numero di volte specificato da MaxRetriesForRemoteSiteShadow. Il parametro Quando non è possibile creare correttamente una copia shadow del messaggio: Se RejectMessageOnShadowFailure è $true, il messaggio primario viene rifiutato con un errore temporaneo. Se RejectMessageOnShadowFailure è $false, il messaggio primario viene accettato comunque, ma non viene salvato in modo permanente in modo ridondante.
MaxRetriesForLocalSiteShadow in Set-TransportConfig	2	Questo parametro viene usato nelle circostanze seguenti: Se il server Cassette postali è un membro di un dag che si estende su più siti di Active Directory. Se ShadowMessagePreferenceSetting è impostato su PreferRemote, prima il server Cassette postali tenta di creare una copia shadow del messaggio in un altro server Cassette postali in un sito active directory remoto fino al numero di volte specificato da MaxRetriesForRemoteSiteShadow. In caso di errore, il server Cassette postali tenta di creare una copia shadow del messaggio in un server Cassette postali diverso nel sito Active Directory locale fino al numero di volte specificato da MaxRetriesForLocalSiteShadow. Se ShadowMessagePreferenceSetting è impostato su LocalOnly, il server Cassette postali tenta solo di creare una copia shadow del messaggio in un server Cassette postali diverso nel sito active directory locale fino al numero di volte specificato da MaxRetriesForLocalSiteShadow. Se il server Cassette postali non è un membro di un gruppo di disponibilità del database o se il server Cassette postali è membro di un gruppo di disponibilità del database presente in un sito di Active Directory, il server Cassette postali tenta solo di creare una copia shadow del messaggio in un server Cassette postali diverso nel sito active directory locale fino al numero di volte specificato da MaxRetriesForLocalSiteShadow. Quando non è possibile creare correttamente una copia shadow del messaggio: Se RejectMessageOnShadowFailure è $true, il messaggio primario viene rifiutato con un errore temporaneo. Se RejectMessageOnShadowFailure è $false, il messaggio primario viene accettato comunque, ma non viene salvato in modo permanente in modo ridondante.
ConnectionInactivityTimeout in Set-ReceiveConnector	5 minuti nel servizio di trasporto sui server Cassette postali 5 minuti nel servizio di trasporto front-end sui server Accesso client. 1 minuto sui server Trasporto Edge.	Questo parametro consente di specificare il tempo massimo per il quale una connessione SMTP aperta con un server di messaggistica di origine può restare inattiva prima che venga chiusa. Il valore di questo parametro deve essere inferiore al valore specificato dal parametro ConnectionTimeout .
ConnectionTimeout in Set-ReceiveConnector	10 minuti nel servizio di trasporto sui server Cassette postali 10 minuti nel servizio di trasporto front-end sui server Accesso client. 5 minuti sui server Trasporto Edge.	Questo parametro consente di specificare il tempo massimo per il quale una connessione SMTP con un server di messaggistica di origine può restare aperta anche se è in corso la trasmissione di dati dal server di messaggistica di origine. Il valore di questo parametro deve essere maggiore del valore specificato dal parametro ConnectionInactivityTimeout .
ConnectionInactivityTimeOut in Set-SendConnector	10 minuti	Questo parametro consente di specificare il tempo massimo per il quale una connessione SMTP aperta con un server di messaggistica di destinazione può restare inattiva prima che venga chiusa.

Modalità di manutenzione dei messaggi shadow

Dopo aver creato correttamente un messaggio shadow, il lavoro della ridondanza shadow è appena cominciato. Il server primario e il server shadow devono rimanere in contatto per tenere traccia dell'avanzamento del messaggio.

Quando il server primario trasmette correttamente il messaggio all'hop successivo e l'hop successivo conferma la ricezione del messaggio, il server primario aggiorna lo stato di rimozione del messaggio impostandolo come recapito completato. Lo stato di rimozione è fondamentalmente un messaggio che contiene un elenco di messaggi monitorati. Un messaggio recapitato correttamente non deve essere mantenuto in una coda shadow; nel momento in cui il server shadow sa che il server primario ha trasmesso correttamente il messaggio all'hop successivo, il server shadow sposta il messaggio shadow dalla coda shadow a Safety Net.

Il server shadow determina lo stato di rimozione dei messaggi shadow nelle code shadow interrogando il server primario. Se il server shadow apre una sessione SMTP con il server primario per qualsiasi motivo, inclusa la trasmissione di altri messaggi non correlati, il server shadow genera il comando XQDISCARD per determinare lo stato di eliminazione dei messaggi primari. Se il server shadow non ha aperto una sessione SMTP con il server primario dopo un intervallo di tempo preconfigurato, il server shadow aprirà una sessione SMTP con il server primario ed eseguirà il comando XQDISCARD . L'intervallo di tempo è controllato dal parametro ShadowHeartbeatFrequency nel cmdlet Set-TransportConfig . Il valore predefinito è 2 minuti. Dopo che il server shadow ha aperto una sessione SMTP con il server primario, questo risponde con le notifiche di rimozione per i messaggi corrispondenti al server shadow che esegue la query. In Exchange 2013 le notifiche di eliminazione vengono archiviate su disco, non in memoria. Pertanto, se il servizio Trasporto di Microsoft Exchange viene riavviato, le notifiche di eliminazione vengono mantenute. Dopo l'avvio del servizio, il server primario conosce ancora i messaggi elaborati correttamente e tali informazioni sono disponibili per il server shadow.

La comunicazione SMTP tra il server shadow e il server primario è utilizzata come heartbeat che determina la disponibilità dei server. Se il server shadow non riesce ad aprire una sessione SMTP con il server primario dopo un intervallo di tempo preconfigurato o se il database di trasporto del server primario ha un ID di database diverso, il server shadow si alza di livello come server primario, promuove i messaggi shadow come messaggi primari e trasmette i messaggi all'hop successivo. L'intervallo di tempo è controllato dal parametro ShadowResubmitTimeSpan nel cmdlet Set-TransportConfig . Il valore predefinito è 3 ore.

Shadow Redundancy Manager è il componente principale di un server di trasporto exchange 2013 responsabile della gestione della ridondanza shadow. Shadow Redundancy Manager è responsabile del mantenimento delle informazioni seguenti per tutti i messaggi principali che un server sta attualmente elaborando:

• Server shadow per ogni messaggio primario elaborato.
• Stato di eliminazione da inviare al server shadow.

Gestione ridondanza shadow è responsabile di quanto segue per tutti i messaggi shadow presenti nelle code shadow di un server shadow:

• Mantenimento dell'elenco di server primari per ogni messaggio shadow.
• Confronto tra l'ID database originale e l'ID database corrente del database delle code in cui è archiviata la copia primaria del messaggio.
• Controllo della disponibilità di ogni server primario per cui viene messo in coda un messaggio shadow.
• Elaborazione delle notifiche di eliminazione provenienti dai server primari.
• Rimozione dei messaggi shadow provenienti dalle code shadow dopo la ricezione di tutte le notifiche di rimozione previste.
• Decisione del momento in cui il server shadow deve assumere la proprietà dei messaggi shadow, divenendo server primario.
• Rilevamento delle biforcazioni dei messaggi e di altri messaggi con effetto collaterale, ad esempio notifiche sullo stato del recapito (DSN) e report del journal per verificare che la copia ridondante del messaggio non venga rilasciata fino a quando tutti i fork del messaggio non vengono elaborati completamente.

Nella tabella seguente vengono descritti i parametri che controllano il modo in cui vengono gestiti i messaggi shadow.

Parametro	Valore predefinito	Descrizione
ShadowHeartbeatFrequency in Set-TransportConfig	2 minuti	Il tempo massimo atteso da un server shadow prima di aprire una connessione SMTP al server primario per verificare lo stato di rimozione dei messaggi.
ShadowResubmitTimeSpan in Set-TransportConfig	3 ore	Il tempo che un server attende prima di decidere che si è verificato un errore in un server primario e di acquisire la proprietà dei messaggi shadow nella coda shadow per il server primario che non è raggiungibile.
ShadowMessageAutoDiscardInterval in Set-TransportConfig	2 giorni	Il tempo per cui un server conserva gli eventi di rimozione per i messaggi recapitati correttamente. Un server principale mette in coda gli eventi di eliminazione fino all'interrogazione da parte di un server shadow. Tuttavia, se il server shadow non interroga il server primario per la durata specificata in questo parametro, il server primario elimina gli eventi in coda.
SafetyNetHoldTime in Set-TransportConfig	2 giorni	Il tempo di conservazione in Safety Net dei messaggi elaborati correttamente. I messaggi shadow non riconosciuti alla fine scadono da Safety Net dopo la somma di SafetyNetHoldTime e MessageExpirationTimeout in Set-TransportService.
MessageExpirationTimeout in Set-TransportService	2 giorni	Quanto tempo un messaggio può rimanere in coda prima della scadenza.

Elaborazione del messaggio dopo un'interruzione

La ridondanza shadow riduce al minimo la perdita di messaggi a causa di interruzioni del server. Quando un server di trasporto torna online dopo un'interruzione, esistono due scenari:

• Il server torna online con un nuovo database di trasporto: in questo scenario il database di trasporto non è recuperabile a causa del danneggiamento dei dati o dell'errore hardware. In questo caso, poiché il server di trasporto avrà un nuovo ID di database, verrà riconosciuto come nuova route dagli altri server di trasporto dell'organizzazione. Questo vale anche per la situazione in cui non è stato possibile ripristinare un server ed è stato effettuato il provisioning di un nuovo server come sostituzione.

• Il server torna online con lo stesso database di trasporto: in questo scenario, il server di trasporto specifico non ha avuto esito negativo, ma è stato offline abbastanza a lungo da consentire al server shadow di assumere la proprietà dei messaggi e inviarli di nuovo. Ad esempio, un errore della scheda di rete o una manutenzione prolungata nel server causerebbe questo scenario.

Nella tabella seguente viene riepilogato il modo in cui la ridondanza shadow reagisce a questi due scenari. Per maggiore chiarezza, si supponga che il server con un'interruzione sia denominato Mailbox01.

Elaborazione dei messaggi negli scenari di ripristino

Scenario di ripristino	Azioni intraprese
Mailbox01 torna online con un nuovo database.	Quando Mailbox01 diventa non disponibile, ogni server con messaggi shadow in coda per Mailbox01 assumerà la proprietà di tali messaggi e li invierà di nuovo. I messaggi vengono quindi recapitati alle loro destinazioni. Il ritardo massimo per i messaggi è il valore del parametro ShadowHeartbeatFrequency nel cmdlet Set-TransportConfig . Il valore predefinito è 2 minuti.
Mailbox01 torna online con lo stesso database.	Dopo il ritorno online di Mailbox01, vengono recapitati i messaggi nelle relative code, che potrebbero già essere stati recapitati dai server che possiedono le copie shadow dei messaggi per Mailbox01. Ciò causerà il recapito duplicato di tali messaggi. Gli utenti delle cassette postali di Exchange non vedranno i messaggi duplicati grazie al rilevamento dei messaggi duplicati. Tuttavia, i destinatari nei sistemi di messaggistica non Di Exchange possono ricevere copie duplicate dei messaggi. Il ritardo massimo per i messaggi è il valore del parametro ShadowResubmitTimeSpan nel cmdlet Set-TransportConfig . Il valore predefinito è 3 ore.