Redondance des ombres dans Exchange Server
La redondance des clichés instantanés a été introduite dans Exchange 2010 pour fournir des copies redondantes des messages avant leur remise à des boîtes aux lettres. Dans Exchange 2010, la redondance des clichés instantanés retardait la suppression d'un message de la base de données de files d'attente sur un serveur de transport Hub jusqu'à ce que le serveur vérifie le saut suivant dans la remise achevée du chemin de remise du message. Si le saut suivant échouait avant de signaler la réussite de la remise au serveur de transport Hub, ce dernier soumettait de nouveau le message à ce saut suivant. Les serveurs de transport Hub Exchange 2010 utilisaient XSHADOW pour annoncer leur prise en charge de la redondance des clichés instantanés. Si un serveur de messagerie source ne prenait pas en charge la redondance des clichés instantanés, Exchange 2010 utilisait un accusé de réception retardé basé sur un intervalle de temps configuré sur le connecteur de réception pour faire une copie redondante du message.
Exchange 2016 et Exchange 2019 ont les mêmes améliorations que celles apportées à la redondance fantôme dans Exchange 2013 : le service de transport sur un serveur de boîtes aux lettres effectue désormais une copie redondante de tout message qu’il reçoit avant d’accuser réception du message au serveur d’envoi. La conservation de copies redondantes des messages en transit est plus qu’un effort optimal qui peut ou non fonctionner, car la redondance fantôme ne dépend désormais pas des fonctionnalités prises en charge du serveur d’envoi (la prise en charge ou l’absence de prise en charge de la redondance de l’ombre n’a pas d’importance). Cela permet de s'assurer que tous les messages figurant dans le pipeline de transport sont rendus redondants quand ils sont en transit. Si Exchange détermine que le message d'origine a été perdu en transit, la copie redondante du message est remise.
Pour plus d’informations sur les fonctionnalités de haute disponibilité de transport dans Exchange Server, consultez Transport high availability in Exchange Server. Pour plus d’informations sur la redondance d’un message une fois qu’un message a été remis avec succès, consultez Safety Net in Exchange Server.
Composants de la redondance des clichés instantanés
Le tableau suivant décrit les composants de redondance des clichés instantanés dans le service de transport sur les serveurs de boîtes aux lettres. Les termes suivants sont utilisés dans cette rubrique.
| Term | Description |
|---|---|
| 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. Pour les groupes de disponibilité de base de données (DAG) qui s'étalent sur plusieurs sites Active Directory, le DAG lui-même est toujours la limite (et non sur le site). Lorsqu'un message arrive sur un serveur de boîtes aux lettres dans la limite de la haute disponibilité du transport, Exchange tente de conserver deux copies redondantes du message sur les serveurs de boîtes aux lettres dans 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 boîtes aux lettres occupé à traiter le message principal. |
| Serveur de clichés instantanés | Serveur de boîtes aux lettres conservant les clichés instantanés pour le serveur principal. Un serveur de boîtes aux lettres peut être en même temps le serveur principal pour certains messages et le serveur de secours pour d'autres. |
| 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 boîtes aux lettres conserve pour des 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 | Version améliorée de la benne de transport dans Exchange 2013 ou version ultérieure. 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 Filet de sécurité dans Exchange Server. |
| 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 :
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 membres du DAG peuvent se trouver dans le site Active Directory local ou dans un site distant. Par défaut, si le DAG s'étend sur plusieurs sites Active Directory, la redondance des clichés instantanés préfère créer une copie redondante du message dans un site 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.
En cas de panne simultanée d’au moins deux serveurs de boîtes aux lettres impliqués dans la redondance des clichés instantanés d’un message.
La redondance des clichés instantanés est activée par défaut
Par défaut, la redondance des clichés instantanés est activée globalement dans le service de transport sur tous les serveurs de boîtes aux lettres. Le tableau suivant décrit les paramètres qui activent la redondance des clichés instantanés.
| Paramètre | Valeur par défaut | Description |
|---|---|---|
| ShadowRedundancyEnabled sur Set-TransportConfig | $true |
$true: la redondance de l’ombre est activée sur tous les serveurs de boîtes aux lettres de l’organisation.
|
| RejectMessageOnShadowFailure sur Set-TransportConfig | $false |
$false: Lorsqu’un cliché instantané du message ne peut pas être créé, le message principal est quand même accepté par les serveurs de boîtes aux lettres de l’organisation. Ces messages ne sont pas persistants de façon redondante quand ils sont en transit.
Remarque : Utilisez 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. L'emplacement et le moment où la copie redondante du message est créée dépendent de l'origine et de la destination du message. Il existe trois facteurs déterminants pour la création des clichés instantanés :
Messages reçus en provenance de l'extérieur d'une limite de haute disponibilité du transport (le DAG, ou un site Active Directory dans les environnements non DAG).
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.
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 instantanés et empêche un nouveau dépôt des messages instantanés à travers 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 reçoit un message en provenance de l’extérieur de la limite de haute disponibilité du transport, le serveur de boîtes aux lettres ne se préoccupe pas de la prise en charge ou non de la redondance des clichés instantanés 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 de messagerie 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.
Alors que la session SMTP d'origine avec le serveur de messagerie est 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 au sein 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éré par défaut (la valeur par défaut du paramètre ShadowMessagePreferenceSetting sur l’applet de commande Set-TransportConfig est
PreferRemote, mais vous pouvez la remplacerRemoteOnlypar 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 ShadowMessagePreferenceSetting ).
Le serveur principal transmet une copie du message au service de transport sur un autre serveur de boîtes aux lettres dont le service de transport confirme que la copie du message a bien été créée. 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.
Après avoir reçu l’accusé de réception du serveur de secours, le serveur principal accuse à son tour réception du message principal au serveur de messagerie d’origine dans la session SMTP d’origine, puis la session SMTP est fermée.
Messages envoyés à l’extérieur d’une limite de haute disponibilité du transport
Quand un serveur de boîtes aux lettres transmet un message à l’extérieur de la limite de haute disponibilité du transport et que le serveur de messagerie de l’autre côté accuse réception du message, le serveur de boîtes aux lettres déplace le message vers Safety Net. 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 le filet de sécurité, consultez Safety Net in Exchange Server.
Messages transmis à l’intérieur d’une limite de haute disponibilité du transport
Le routage des messages étant optimisé, lorsque la destination finale est dans un DAG ou un site Active Directory, plusieurs sauts entre des serveurs dans le DAG ou le site de destination 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 de destination ou Active Directory, le saut suivant pour le message est généralement la destination finale elle-même (par exemple, le serveur de boîtes aux lettres qui détient actuellement la copie active de la boîte aux lettres de destination). 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 des scénarios de basculement dans un DAG qui nécessitent la cmdlet Redirect-Message pour drainer les files d'attente de messages actives sur un serveur de boîtes aux lettres nécessitent plusieurs sauts à l'intérieur de la même limite de haute disponibilité du transport.
Redondance fantôme avec les serveurs de transport Hub Exchange 2010 dans le même site Active Directory dans les organisations Exchange 2016
Quand un serveur de transport Hub Exchange 2010 transmet un message à un serveur de boîtes aux lettres Exchange 2016 situé dans le même site Active Directory, le serveur de transport Hub Exchange 2010 annonce la prise en charge de la redondance des clichés instantanés à l'aide de la commande XSHADOW, mais le serveur de boîtes aux lettres n'annonce pas cette prise en charge. 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 2016.
Lorsque le service de transport sur un serveur de boîtes aux lettres Exchange 2016 transmet un message à un serveur de transport Hub Exchange 2010 situé dans le même site Active Directory, le serveur de boîtes aux lettres Exchange 2016 crée un cliché du message pour le serveur de transport Hub Exchange 2010. Lorsque le serveur de boîtes aux lettres Exchange 2016 reçoit un accusé de réception du serveur de transport Hub Exchange 2010, le serveur de boîtes aux lettres Exchange 2016 déplace le message traité avec succès vers Safety Net. Toutefois, les messages traités avec succès stockés dans Safety Net par le serveur de boîtes aux lettres Exchange 2016 ne sont jamais déposés à nouveau sur les serveurs de transport Hub Exchange 2010.
Délais d’expiration SMTP
Lors de la tentative de création d’une copie redondante du message, la connexion SMTP entre des serveurs (le serveur d’envoi et le serveur principal, ou le serveur principal et le serveur de secours) 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.0temporaire .
Si le cliché instantané d'un message est créé avec succès, mais que la session SMTP entre le serveur d'envoi et le serveur principal expire, le serveur principal accepte et traite le message principal. Le serveur d'envoi remet à nouveau le message n'ayant pas fait l'objet d'un accusé de réception, mais la détection de message en double empêche les utilisateurs de boîte aux lettres Exchange de voir les messages en double. Lorsque le serveur d'envoi dépose à nouveau le message, le serveur principal crée un autre cliché instantané du message. Il n'y a pas de relation entre les clichés instantanés créés au cours des nouveaux dépôts de messages par le serveur d'envoi.
Le tableau suivant décrit les paramètres qui contrôlent la création des clichés instantanés
| Source | Valeur par défaut | Description |
|---|---|---|
| ShadowMessagePreferenceSetting sur Set-TransportConfig | PreferRemote |
Ce paramètre est utilisé uniquement lorsque le serveur principal qui tente de créer un cliché instantané du message est un membre d'un DAG qui s'étend sur plusieurs sites Active Directory.
|
| MaxRetriesForRemoteSiteShadow sur Set-TransportConfig | 4 | Ce paramètre spécifie le nombre maximal de tentatives de création d’un cliché instantané du message sur un autre serveur dans le DAG lorsque la valeur du paramètre ShadowMessagePreferenceSetting est PreferRemote (valeur par défaut) ou RemoteOnly. Ce paramètre est utilisé uniquement lorsque le serveur de boîtes aux lettres est membre d'un DAG qui s'étend sur plusieurs sites Active Directory. Si un cliché instantané du message n’est pas créé après le nombre de tentatives spécifié, le résultat dépend de la valeur du paramètre RejectMessageOnShadowFailure :
|
| MaxRetriesForLocalSiteShadow sur Set-TransportConfig | 2 | Ce paramètre définit le nombre maximal de tentatives pour créer un cliché instantané du message sur un autre serveur de boîtes aux lettres dans le site Active Directory local lorsque :
Si un cliché instantané du message n’est pas créé après le nombre de tentatives spécifié, le résultat dépend de la valeur du paramètre RejectMessageOnShadowFailure :
|
| ConnectionInactivityTimeout sur Set-ReceiveConnector | 5 minutes pour les connecteurs de réception dans le service de transport sur des serveurs de boîtes aux lettres | Ce paramètre définit la durée maximale pendant laquelle une connexion SMTP ouverte avec un serveur de messagerie source peut rester inactive avant d'être interrompue. La valeur de ce paramètre doit être supérieure à la valeur du paramètre ConnectionTimeout . |
| ConnectionTimeout sur Set-ReceiveConnector | 10 minutes pour les connecteurs de réception dans le service de transport sur des serveurs de boîtes aux lettres | Ce paramètre définit la durée maximale pendant laquelle une connexion SMTP avec un serveur de messagerie source peut rester ouverte, même si le serveur transmet des données. La valeur de ce paramètre doit être supérieure à la valeur du 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 de secours ouvre une session SMTP avec le serveur principal pour une raison quelconque (y compris la transmission d'autres messages sans rapport) le serveur de secours émet la commande XQDISCARD pour déterminer l'état de suppression des messages principaux. Sinon, le serveur fantôme ouvre automatiquement une session SMTP avec le serveur principal après un intervalle de temps préconfiguré (paramètre ShadowHeartbeatFrequency sur l’applet de commande Set-TransportConfig ; la valeur par défaut est de 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. Les notifications de suppression sont stockées sur disque (et non dans la mémoire) par conséquent, si le service de transport Microsoft Exchange redémarre, les notifications de suppression persistent. 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 de secours ne peut pas ouvrir de session SMTP avec le serveur principal après un intervalle de temps préconfiguré (le paramètre ShadowResubmitTimeSpan sur la cmdlet Set-TransportConfig ; la valeur par défaut est 3 heures), le serveur de secours se promeut comme serveur principal, promeut les clichés instantanés comme messages principaux et transmet les messages au saut suivant. Cependant, chaque fois que le serveur de secours détecte que l'ID de base de données de files d'attente du serveur principal a changé, le serveur de secours se promeut également comme serveur principal, promeut les clichés instantanés en tant que messages principaux et transmet les messages au saut suivant. Cela peut se produire bien avant que la valeur du paramètre ShadowResubmitTimeSpan soit dépassée.
Le Gestionnaire de redondance des clichés instantanés est le composant d’un serveur de boîtes aux lettres responsable de la gestion de la redondance des clichés instantanés. 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 de secours pour chaque message principal en cours de traitement.
État de suppression à envoyer aux serveurs de secours.
Le Gestionnaire de redondance des clichés instantanés est responsable des actions suivantes pour tous les clichés instantanés se trouvant dans les files d'attente de clichés instantanés d'un serveur de secours :
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 des messages et d'autres messages d'effet secondaire tels que des notifications d'état de remise (également appelées DSN, notifications d'échec de remise ou notifications de non-remise) et des rapports de journal pour vérifier que la copie redondante du message n'est pas libérée tant que tous les embranchements du message n'ont pas été entièrement traités.
Le tableau suivant décrit les paramètres qui contrôlent la manière dont les clichés instantanés sont géré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. Notez qu'un serveur de secours peut également se promouvoir comme serveur principal avant la valeur de ce paramètre lorsqu'il est constaté que l'ID de base de données de files d'attente du serveur principal est différent. |
| 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 met en file d'attente les événements de suppression jusqu'à ce que le serveur de secours l'interroge. 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 des valeurs des paramètres SafetyNetHoldTime et MessageExpirationTimeout sur l’applet de commande 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
Le tableau suivant résume comment la redondance des clichés instantanés limite la perte des messages due à des pannes de serveur. Par souci de clarté, le serveur qui a été en panne se nomme Mailbox01.
| Scénario de récupération | Actions prises |
|---|---|
| Mailbox01 revient en ligne avec une nouvelle base de données de files d’attente avant que la valeur du paramètre ShadowResubmitTimeSpan a été dépassée (par défaut, 3 heures). Ce scénario peut se produire lorsque la base de données de files d'attente est irrécupérable en raison d'une altération des données ou d'une panne matérielle. |
Lorsque le nouvel ID de base de données de files d'attente est détecté sur Mailbox01, chaque serveur qui a des clichés instantanés en file d'attente pour Mailbox01 s'approprie ces derniers et les dépose à nouveau. Les messages sont ensuite remis à leurs destinations. Le délai maximal pour l’envoi des messages après la détection de la nouvelle base de données de file d’attente est la valeur du paramètre ShadowHeartbeatFrequency (par défaut, 2 minutes). |
| Mailbox01 revient en ligne avec la même base de données une fois que la valeur du paramètre ShadowResubmitTimeSpan est passée (par défaut, 3 heures). Ce scénario peut se produire après une panne de carte réseau ou une maintenance chronophage sur le serveur. |
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 d'autres systèmes de messagerie peuvent recevoir des copies des messages en double. Le délai maximal pour l’envoi des messages est la valeur du paramètre ShadowResubmitTimeSpan . |