Redondance des clichés instantanés
S’applique à : Exchange Server 2013
La redondance par ombre a été introduite dans Microsoft Exchange Server 2010 pour fournir des copies redondantes des messages avant qu’ils ne soient remis aux boîtes aux lettres. Dans Exchange 2010, la redondance fantôme a retardé la suppression d’un message de la base de données de transport sur un serveur de transport jusqu’à ce que le serveur vérifie que le tronçon suivant dans le chemin de remise du message a terminé la remise. Si le tronçon suivant a échoué avant de signaler la remise réussie au serveur de transport, le serveur de transport a de nouveau soumis le message à ce tronçon suivant. Les serveurs Exchange 2010 ont utilisé le verbe XSHADOW pour publier leur prise en charge de la redondance des ombres. Si un serveur SMTP ne prenait pas en charge la redondance de l’ombre, Exchange 2010 a utilisé l’accusé de réception différé basé sur un intervalle de temps configuré sur le connecteur de réception pour effectuer une copie redondante du message.
L’amélioration majeure de la redondance fantôme dans Microsoft Exchange Server 2013 est que le serveur de transport effectue désormais une copie redondante des messages qu’il reçoit avant qu’il reconnaisse avoir reçu correctement le message sur le serveur d’envoi. La prise en charge du serveur d’envoi ou l’absence de prise en charge de la redondance d’ombre n’a pas d’importance. Cela permet de garantir que tous les messages du pipeline de transport Exchange 2013 sont redondants pendant leur transit. Si Exchange 2013 détermine que le message d’origine a été perdu en transit, la copie redondante du message est redélisée.
Composants de la redondance des clichés instantanés
Le tableau suivant décrit les composants de la redondance d’ombre. Les termes suivants sont utilisés dans cette rubrique.
Term | Description |
---|---|
Serveur de transport | Un serveur Exchange qui a des files d’attente de messages et qui est responsable du routage des messages. Dans Exchange 2013, un serveur de transport est un serveur de boîtes aux lettres (le service de transport sur le serveur de boîtes aux lettres). |
Base de données de transport | Base de données de file d’attente de messages sur un serveur de transport Exchange 2013. Les files d’attente fantômes et le réseau de sécurité sont également stockés dans la base de données de transport. |
Limite de la haute disponibilité du transport | Groupe de disponibilité de base de données (DAG) dans des environnements DAG ou site Active Directory dans les environnements non-DAG. Lorsqu’un message arrive sur un serveur de transport dans la limite de haute disponibilité de transport, Exchange tente de conserver 2 copies redondantes du message sur les serveurs de transport à l’intérieur de la limite. Lorsqu'un message quitte la limite de la haute disponibilité du transport, Exchange interrompt la conservation des copies redondantes du message. |
Message principal | Message déposé dans le pipeline de transport pour remise. |
Message de cliché instantané | Copie redondante du message que le serveur de secours conserve jusqu'à la confirmation que le message principal a été traité avec succès par le serveur principal. |
Serveur principal | Serveur de transport qui traite actuellement le message principal. |
Serveur de clichés instantanés | Serveur de transport qui contient le message fantôme pour le serveur principal. Un serveur de transport peut être le serveur principal pour certains messages et le serveur fantôme pour d’autres messages simultanément. |
File d'attente de clichés instantanés | File d'attente de remise dans laquelle le serveur de secours stocke les messages instantanés. Pour les messages à plusieurs destinataires, chaque saut suivant pour le message principal nécessite des files d'attente de secours séparées. |
État de suppression | Informations qu’un serveur de transport conserve pour les messages instantanés qui indiquent que le message principal a été traité avec succès. |
Notification de suppression | Réponse qu'un serveur de clichés instantanés reçoit d'un serveur principal, indiquant qu'un message peut être supprimé. |
Safety Net | La version améliorée d’Exchange 2013 de la benne de transport. Les messages traités avec succès ou remis à la boîte aux lettres d'un destinataire par le service de transport sur un serveur de boîtes aux lettres sont déplacés dans Safety Net. Pour plus d'informations, consultez la rubrique Safety Net. |
Gestionnaire de redondance des clichés instantanés | Composant de transport qui gère la redondance des clichés instantanés. |
Pulsation | Processus qui permet aux serveurs principaux et aux serveurs de secours de vérifier mutuellement leur disponibilité. |
Exigences relatives à la redondance des clichés instantanés
Bien que cela puisse sembler évident, la redondance fantôme nécessite plusieurs serveurs de boîtes aux lettres Exchange 2013. Le serveur de boîtes aux lettres peut être des serveurs autonomes, ou des serveurs de boîtes aux lettres et des serveurs d’accès au client installés sur le même ordinateur.
- Si le serveur de boîtes aux lettres n'est pas membre d'un DAG, les autres serveurs de boîtes aux lettres doivent se trouver dans le site Active Directory local.
- Si le serveur de boîtes aux lettres est membre d'un DAG, les autres serveurs de boîtes aux lettres doivent appartenir au même DAG. Les autres serveurs de boîtes aux lettres qui appartiennent au DAG peuvent se trouver sur le site Active Directory local ou sur un site Active Directory distant. Si le DAG s’étend sur plusieurs sites Active Directory, la redondance fantôme préfère créer une copie redondante du message dans un site Active Directory distant pour la résilience du site.
Les situations dans lesquelles la redondance des clichés instantanés ne peut pas protéger les messages en transit sont les suivantes :
- Dans des environnements de serveur Exchange.
- Dans des DAG sous-mis en service.
- Lors de la défaillance simultanée de deux serveurs de transport ou plus impliqués dans la redondance fantôme d’un message.
La redondance des clichés instantanés est activée par défaut
Par défaut, la redondance d’ombre est activée globalement dans le service de transport sur tous les serveurs de boîtes aux lettres à l’aide du paramètre ShadowRedundancyEnabled sur l’applet de commande Set-TransportConfig . Par défaut, si le service de transport sur un serveur de boîtes aux lettres ne peut pas créer une copie redondante d’un message, le message n’est pas rejeté. Toutefois, vous pouvez configurer Exchange 2013 pour rejeter un message si une copie redondante du message n’est pas créée à l’aide du paramètre RejectMessageOnShadowFailure sur l’applet de commande Set-TransportConfig . Le message est rejeté avec un échec temporaire, mais le serveur d’envoi peut transmettre à nouveau le message. Le code de réponse SMTP est 451 4.4.0 Message failed to be made redundant.
Vous devez configurer Exchange 2013 pour rejeter les messages qui ne peuvent pas être redondants uniquement lorsque votre organisation dispose de plusieurs serveurs de boîtes aux lettres Exchange 2013 disponibles.
Le tableau suivant décrit les paramètres qui activent la redondance d’ombre.
Paramètres qui activent la redondance des ombres
Paramètre | Valeur par défaut | Description |
---|---|---|
ShadowRedundancyEnabled sur Set-TransportConfig | $true |
|
RejectMessageOnShadowFailure sur Set-TransportConfig | $false |
Ce paramètre n’est significatif que lorsque ShadowRedundancyEnabled a la valeur |
Création des clichés instantanés
L’objectif principal de redondance des clichés instantanés est de toujours avoir deux copies d’un message dans une limite de haute disponibilité du transport quand le message est en transit. Où et quand la copie redondante du message est créée dépend de l’origine du message et de son emplacement. Il existe trois facteurs déterminants principaux :
- Messages reçus en dehors d’une limite de haute disponibilité de transport.
- Messages envoyés à l'extérieur d'une limite de haute disponibilité du transport.
- Messages reçus du service de dépôt de transport de boîte aux lettres d'un serveur de boîtes dans la limite de haute disponibilité du transport.
Une limite de haute disponibilité de transport est l’une des suivantes :
- Un DAG, pour les serveurs de boîtes aux lettres qui sont membres d’un DAG. Cela inclut un DAG qui s’étend sur plusieurs sites Active Directory.
- Un site Active Directory, pour les serveurs de boîtes aux lettres qui n’appartiennent pas à un DAG.
La redondance des clichés instantanés n'effectue jamais le suivi des messages instantanés à travers une limite de haute disponibilité du transport. Lorsqu'un message franchit la limite de haute disponibilité du transport, la redondance des clichés instantanés commence ou redémarre. Cela réduit le trafic de maintenance des messages fantômes et empêche les réadmissions de messages fantômes de se produire au-delà de la limite de haute disponibilité du transport. Les serveurs de transport Hub Exchange 2010 constituent un cas particulier abordé plus loin dans cette rubrique.
Messages reçus en provenance de l’extérieur d’une limite de haute disponibilité du transport
Lorsque le service de transport sur un serveur de boîtes aux lettres Exchange 2013 reçoit un message provenant de l’extérieur de la limite de haute disponibilité de transport, le serveur de boîtes aux lettres n’est pas préoccupé par la prise en charge ou l’absence de prise en charge de la redondance fantôme par le serveur d’envoi. Tant que la redondance des clichés instantanés est activée, le serveur de boîtes aux lettres qui reçoit le message crée une copie redondante de ce dernier sur un autre serveur de boîtes aux lettres dans la limite de haute disponibilité du transport avant d'accuser réception du message au serveur d'envoi. Voici un exemple de la manière dont fonctionne le processus :
Un serveur SMTP transmet un message au service de transport sur un serveur de boîtes aux lettres. Le serveur de boîtes aux lettres est le serveur principal, et le message est le message principal.
Bien que la session SMTP d’origine avec le serveur SMTP soit toujours active, le service de transport sur le serveur principal ouvre une nouvelle session SMTP simultanée avec le service de transport sur un autre serveur de boîtes aux lettres de l’organisation pour créer une copie redondante du message.
- Si le serveur primaire est membre d'un DAG, le serveur principal se connecte à un autre serveur de boîtes aux lettres dans la même DAG. Si le DAG s’étend sur plusieurs sites Active Directory, un serveur de boîtes aux lettres dans un autre site Active Directory est préférable par défaut. Ce paramètre est contrôlé par le paramètre ShadowMessagePreference de l’applet de commande Set-TransportService . La valeur par défaut est
PreferRemote
, mais vous pouvez la remplacerRemoteOnly
par ouLocalOnly
. - Si le serveur principal n’est pas membre d’un DAG, le serveur principal se connecte à un autre serveur de boîtes aux lettres dans le même site Active Directory, quelle que soit la valeur du paramètre ShadowMessagePreference .
- Si le serveur primaire est membre d'un DAG, le serveur principal se connecte à un autre serveur de boîtes aux lettres dans la même DAG. Si le DAG s’étend sur plusieurs sites Active Directory, un serveur de boîtes aux lettres dans un autre site Active Directory est préférable par défaut. Ce paramètre est contrôlé par le paramètre ShadowMessagePreference de l’applet de commande Set-TransportService . La valeur par défaut est
Le serveur principal transmet une copie du message au service de transport sur un autre serveur de boîtes aux lettres, et le service de transport sur l’autre serveur de boîtes aux lettres reconnaît que la copie du message a été créée avec succès. La copie du message est le cliché instantané et le serveur de boîtes aux lettres qui le conserve est le serveur de secours pour le serveur principal. Le message existe dans une file d'attente de clichés instantanés sur le serveur de secours.
Une fois que le serveur principal reçoit l’accusé de réception du serveur fantôme, le serveur principal accuse réception du message principal au serveur SMTP d’origine dans la session SMTP d’origine, et la session SMTP est fermée.
Messages envoyés à l’extérieur d’une limite de haute disponibilité du transport
Lorsqu’un serveur de transport Exchange 2013 transmet un message en dehors de la limite de haute disponibilité de transport et que le serveur SMTP de l’autre côté accuse réception du message, le serveur de transport déplace le message dans le réseau de sécurité. Aucun nouveau dépôt du message à partir de Safety Net ne peut se produire après que le message principal a été transmis avec succès à travers la limite de haute disponibilité du transport. Pour plus d'informations sur Safety Net, consultez la rubrique Safety Net.
Messages transmis à l’intérieur d’une limite de haute disponibilité du transport
Le routage des messages est optimisé dans Exchange 2013 de sorte que lorsque la destination finale se trouve dans un DAG ou un site Active Directory, plusieurs tronçons entre le service de transport sur les serveurs de boîtes aux lettres de ce DAG ou site Active Directory ne sont généralement pas nécessaires. Une fois le message accepté par le service de transport sur un serveur de boîtes aux lettres dans le DAG ou le site Active Directory qui contient la destination finale du message, le tronçon suivant du message est généralement la destination finale elle-même. L’objectif de la redondance des ombres, qui consiste à conserver deux copies d’un message en transit, est rempli lorsqu’un cliché instantané du message existe n’importe où dans le DAG ou le site Active Directory. En règle générale, seuls les scénarios de basculement dans un DAG qui nécessitent l’applet de commande Redirect-Message pour vider les files d’attente actives sur un serveur de boîtes aux lettres nécessitent plusieurs tronçons dans la même limite de haute disponibilité de transport.
Redondance des clichés instantanés avec les serveurs de transport Hub Exchange 2010 dans le même site Active Directory
Lorsqu’un serveur de transport Hub Exchange 2010 transmet un message à un serveur de boîtes aux lettres Exchange 2013 dans le même site Active Directory, le serveur de transport Hub Exchange 2010 annonce la prise en charge de la redondance fantôme à l’aide de la commande XSHADOW, mais le serveur de boîtes aux lettres ne publie pas la prise en charge de la redondance fantôme. Cela empêche le serveur de transport Hub Exchange 2010 de créer un cliché instantané du message sur un serveur de boîtes aux lettres Exchange 2013.
Lorsque le service de transport sur un serveur de boîtes aux lettres Exchange 2013 transmet un message à un transport hub Exchange 2010 dans le même site Active Directory, le serveur de boîtes aux lettres Exchange 2013 masque le message pour le serveur de transport Hub Exchange 2010. Une fois que le serveur de boîtes aux lettres Exchange 2013 reçoit un accusé de réception du serveur de transport Hub Exchange 2010 indiquant que le message a été correctement reçu, le serveur de boîtes aux lettres Exchange 2013 déplace le message traité avec succès dans le réseau de sécurité. Toutefois, les messages correctement traités stockés dans Safety Net par la boîte aux lettres Exchange 2013 ne sont jamais soumis à nouveau aux serveurs de transport hub Exchange 2010.
Délais d’expiration SMTP
Pendant la tentative d’effectuer une copie redondante du message, la connexion SMTP entre le serveur SMTP d’envoi et le serveur principal, ou la session SMTP entre le serveur principal et le serveur fantôme peut expirer. Les connecteurs de réception et les connecteurs d’envoi ont tous deux un paramètre ConnectionInactivityTimeOut pour le moment où les données sont réellement transmises sur le connecteur. Les connecteurs de réception ont également un paramètre ConnectionTimeOut absolu.
Si l’une des sessions SMTP expire avant que le cliché instantané du message ne soit correctement créé et reconnu, le résultat est contrôlé par le paramètre RejectMessageOnShadowFailure sur l’applet de commande Set-TransportConfig . Par défaut, la valeur de ce paramètre est $false
, ce qui signifie que le message principal est accepté sans qu’un cliché instantané ne soit créé. Si la valeur de ce paramètre est $true
le message principal est rejeté avec l’erreur 451 4.4.0
temporaire .
Si le cliché instantané d’un message est correctement créé, mais que la session SMTP entre le serveur SMTP d’envoi et le serveur principal expire, le serveur principal accepte et traite le message principal. Le serveur SMTP d’envoi remet à nouveau le message non reconnu, mais la détection des messages en double empêche les utilisateurs de boîtes aux lettres Exchange de voir les messages en double. Lorsque le serveur SMTP d’envoi renvoie le message, le serveur principal crée un autre cliché instantané du message. Il n’existe aucune relation entre les messages fantômes créés lors des réadmissions de messages par le serveur SMTP d’envoi.
Le tableau suivant décrit les paramètres qui contrôlent la création des clichés instantanés
Paramètres de création de message d’ombre
Source | Valeur par défaut | Description |
---|---|---|
ShadowMessagePreferenceSetting sur Set-TransportConfig | PreferRemote |
Ce paramètre n’est significatif que lorsque le serveur principal qui tente de créer un cliché instantané du message est un serveur de boîtes aux lettres membre d’un DAG qui s’étend sur plusieurs sites Active Directory. |
MaxRetriesForRemoteSiteShadow sur Set-TransportConfig | 4 | Ce paramètre est utilisé lorsque le serveur de boîtes aux lettres est membre d’un DAG qui s’étend sur plusieurs sites Active Directory.
Lorsqu’un cliché instantané du message ne peut pas être créé :
|
MaxRetriesForLocalSiteShadow sur Set-TransportConfig | 2 | Ce paramètre est utilisé dans les circonstances suivantes :
Lorsqu’un cliché instantané du message ne peut pas être créé :
|
ConnectionInactivityTimeout sur Set-ReceiveConnector | 5 minutes dans le service de transport sur les serveurs de boîtes aux lettres 5 minutes dans le service de transport frontal sur les serveurs d’accès au client. 1 minute sur les serveurs de transport Edge. |
Ce paramètre spécifie la durée maximale pendant laquelle une connexion SMTP ouverte avec un serveur de messagerie source peut rester inactive avant la fermeture de la connexion. La valeur de ce paramètre doit être inférieure à la valeur spécifiée par le paramètre ConnectionTimeout . |
ConnectionTimeout sur Set-ReceiveConnector | 10 minutes dans le service de transport sur les serveurs de boîtes aux lettres 10 minutes dans le service de transport frontal sur les serveurs d’accès au client. 5 minutes sur les serveurs de transport Edge. |
Ce paramètre spécifie la durée maximale pendant laquelle une connexion SMTP avec un serveur de messagerie source peut rester ouverte, même si le serveur de messagerie source transmet des données. La valeur de ce paramètre doit être supérieure à la valeur spécifiée par le paramètre ConnectionInactivityTimeout . |
ConnectionInactivityTimeOut sur Set-SendConnector | 10 minutes | Ce paramètre spécifie la durée maximale pendant laquelle une connexion SMTP ouverte avec un serveur de messagerie de destination peut rester inactive avant d'être interrompue. |
Maintenance des messages instantanés
Après la création d'un cliché instantané, le travail de redondance des clichés instantanés ne fait que commencer. Le serveur principal et le serveur de secours doivent rester en contact pour suivre la progression du message.
Lorsque le serveur principal transmet correctement le message au saut suivant, et que le saut suivant accuse réception du message, le serveur principal met à jour l'état de suppression du message comme remise complète. L'état de suppression est fondamentalement un message contenant la liste des messages surveillés. Un message remis avec succès n'ayant pas besoin d'être conservé dans une file d'attente de clichés instantanés, une fois que le serveur de secours est informé que le serveur principal a transmis avec succès le message au saut suivant, le serveur de secours déplace le cliché instantané de la file d'attente des clichés instantanés vers Safety Net.
Le serveur de secours détermine l'état de suppression des clichés instantanés dans ses files d'attente de clichés instantanés en interrogeant le serveur principal. Si le serveur fantôme ouvre une session SMTP avec le serveur principal pour une raison quelconque, y compris la transmission d’autres messages non liés, le serveur fantôme émet la commande XQDISCARD pour déterminer l’état d’abandon des messages principaux. Si le serveur fantôme n’a pas ouvert de session SMTP avec le serveur principal après un intervalle de temps préconfiguré, le serveur fantôme ouvre une session SMTP avec le serveur principal et émet la commande XQDISCARD . L’intervalle de temps est contrôlé par le paramètre ShadowHeartbeatFrequency sur l’applet de commande Set-TransportConfig . La valeur par défaut est 2 minutes. Lorsque le serveur de secours ouvre une session SMTP avec le serveur principal, ce dernier répond par des notifications de suppression pour les messages qui s’appliquent au serveur de secours qui l’interroge. Dans Exchange 2013, les notifications d’abandon sont stockées sur le disque, et non en mémoire. Par conséquent, si le service de transport Microsoft Exchange redémarre, les notifications d’abandon sont conservées. Après le démarrage du service, le serveur principal connaît encore les messages qu’il a traités avec succès, et ces informations sont disponibles pour le serveur de secours.
La communication SMTP entre le serveur de secours et le serveur principal est utilisée en tant que pulsation qui détermine la disponibilité des serveurs. Si le serveur fantôme ne peut pas ouvrir une session SMTP avec le serveur principal après un intervalle de temps préconfiguré, ou si la base de données de transport du serveur principal a un ID de base de données différent, le serveur fantôme se présente comme le serveur principal, promeut les messages instantanés en tant que messages principaux et transmet les messages au tronçon suivant. L’intervalle de temps est contrôlé par le paramètre ShadowResubmitTimeSpan sur l’applet de commande Set-TransportConfig . La valeur par défaut est 3 heures.
Le Gestionnaire de redondance des ombres est le composant principal d’un serveur de transport Exchange 2013 responsable de la gestion de la redondance des ombres. Le Gestionnaire de redondance des clichés instantanés est responsable de la gestion des informations suivantes pour tous les messages principaux traités par un serveur :
- Serveur fantôme pour chaque message principal en cours de traitement.
- État de suppression à envoyer aux serveurs de secours.
Le Gestionnaire de redondance des ombres est responsable des éléments suivants pour tous les messages instantanés qu’un serveur fantôme a dans ses files d’attente d’ombre :
- Gestion de la liste des serveurs principaux pour chaque cliché instantané.
- Comparaison de l'ID de base de données originale et de l'ID actuel de la base de données de files d'attente dans laquelle la copie principale du message est stockée.
- Vérification de la disponibilité de chaque serveur principal pour lequel un cliché instantané est mis en file d'attente.
- Traitement des notifications de suppression provenant des serveurs principaux.
- Suppression des clichés instantanés des files d'attentes après réception de toutes les notifications de suppression.
- Choix du moment où le serveur de secours doit acquérir la propriété des clichés instantanés en devenant serveur principal.
- Suivi des bifurcations de messages et d’autres messages à effet secondaire tels que les notifications d’état de remise (DSN) et les rapports de journal pour vérifier que la copie redondante du message n’est pas libérée tant que toutes les duplications du message n’ont pas été entièrement traitées.
Le tableau suivant décrit les paramètres qui contrôlent la façon dont les messages instantanés sont conservés.
Paramètre | Valeur par défaut | Description |
---|---|---|
ShadowHeartbeatFrequency sur Set-TransportConfig | 2 minutes | Le temps maximal qu'un serveur de secours attend avant d'ouvrir une connexion SMTP sur le serveur principal pour vérifier l'état de suppression des messages. |
ShadowResubmitTimeSpan sur Set-TransportConfig | 3 heures | Le délai qu'un serveur observe avant de déterminer qu'un serveur principal a échoué et de s'approprier les clichés instantanés figurant dans la file d'attente des clichés instantanés pour le serveur principal inaccessible. |
ShadowMessageAutoDiscardInterval sur Set-TransportConfig | 2 jours | Temps pendant lequel un serveur conserve les événements de suppression pour les messages remis avec succès. Un serveur principal place en file d'attente les événements de suppression jusqu'à ce qu'il ait été interrogé par le serveur de clichés instantanés. Toutefois, si le serveur de secours n'interroge pas le serveur principal au cours de la période définie par ce paramètre, le serveur principal supprime les événements de suppression en file d'attente. |
SafetyNetHoldTime sur Set-TransportConfig | 2 jours | Temps pendant lequel les messages traités avec succès sont conservés dans Safety Net. Les messages instantanés non reconnus finissent par expirer de Safety Net après la somme de SafetyNetHoldTime et MessageExpirationTimeout sur Set-TransportService. |
MessageExpirationTimeout sur Set-TransportService | 2 jours | La durée de temps pendant laquelle un message peut rester dans une file d'attente avant d'expirer. |
Traitement des messages après une panne
La redondance de l’ombre réduit la perte de messages en raison de pannes de serveur. Lorsqu’un serveur de transport revient en ligne après une panne, il existe deux scénarios :
Le serveur revient en ligne avec une nouvelle base de données de transport : dans ce scénario, la base de données de transport est irrécupérable en raison d’une altération des données ou d’une défaillance matérielle. Dans ce cas, étant donné que le serveur de transport aura un nouvel ID de base de données, il sera reconnu comme un nouvel itinéraire par les autres serveurs de transport de l’organisation. Cela s’applique également au cas où un serveur n’a pas pu être récupéré et qu’un nouveau serveur a été approvisionné en remplacement.
Le serveur revient en ligne avec la même base de données de transport : dans ce scénario, le serveur de transport particulier n’a pas échoué, mais était hors connexion suffisamment longtemps pour que le serveur fantôme assume la propriété des messages et les soumettre à nouveau. Par exemple, une défaillance de carte réseau ou une longue maintenance sur le serveur provoquerait ce scénario.
Le tableau suivant récapitule la façon dont la redondance d’ombre réagit à ces deux scénarios. Pour plus de clarté, supposons que le serveur qui a connu une panne est nommé Mailbox01.
Traitement des messages dans les scénarios de récupération
Scénario de récupération | Actions prises |
---|---|
Mailbox01 revient en ligne avec une nouvelle base de données. | Lorsque Mailbox01 devient indisponible, chaque serveur qui a des clichés instantanés mis en file d’attente pour Mailbox01 prend la propriété de ces messages et les soumettre à nouveau. Les messages sont ensuite remis à leurs destinations. Le délai maximal pour les messages est la valeur du paramètre ShadowHeartbeatFrequency sur l’applet de commande Set-TransportConfig . La valeur par défaut est 2 minutes. |
Mailbox01 revient en ligne avec la même base de données. | Une fois Mailbox01 revenu en ligne, il livre les messages figurant dans ses files d'attente qui ont déjà été remis par les serveurs contenant les clichés instantanés de messages pour Mailbox01. Cela entraîne une remise en double de ces messages. Les utilisateurs de boîtes aux lettres Exchange ne voient pas de messages en double en raison de la détection des messages en double. Toutefois, les destinataires sur des systèmes de messagerie non Exchange peuvent recevoir des copies des messages en double. Le délai maximal pour les messages est la valeur du paramètre ShadowResubmitTimeSpan sur l’applet de commande Set-TransportConfig . La valeur par défaut est 3 heures. |