Comprendre les données du journal de suivi des messages ?

un message de la soumission à  la livraison
finale.

Bien entendu, vous pouvez examiner
les données du journal d’un système
de production, mais ces journaux
sont généralement volumineux (plus
de 50 Mo) et donc il est plus difficile de
choisir un message particulier puis de
suivre sa progression. Les grands journaux
ralentissent le suivi, particulièrement
si le message a été envoyé à  une
longue DL (distribution list) ou s’il faut
suivre un message sur plusieurs serveurs
différents dans une entreprise.

Les serveurs qui hébergent des
Public Folders actifs peuvent générer
un lourd trafic de réplication, qui est
noté dans les journaux de suivi des
messages. On peut identifier les messages
de réplication par nom d’envoyeur,
qui est soit l’adresse X.500 interne
Exchange 2000 pour le Public
Folder Replication Agent (par
exemple, EX:/O=Acme/OU=Central/
CN=Configuration/CN=Servers/CN=
Server1/CN=Microsoft Public MDB)
ou l’adresse SMTP pour le Public
Folder Replication Agent (par
exemple, Server1-IS@acme.org). Les
journaux de suivi des messages stockent
le nom du serveur de destination
(le partenaire de réplication) dans le
champ Recipient-Address. Les journaux
de suivi des messages stockent
aussi des données pour les messages
entrants, y compris les notifications de
non-livraison et les reçus de livraison et
de lecture.

La feuille de calcul Excel illustrée figure
6 contient les données brutes du
journal de suivi des messages que
montre la boîte de dialogue Message
History dans la figure 5. Le message
émane d’un client MAPI et est destiné à 
deux destinataires SMTP externes. Par
conséquent, le traitement logique que
le moteur de routage effectue est
simple et direct. Le moteur accepte le message, vérifie les adresses SMTP et
dirige le message vers soit un connecteur
SMTP sur le même serveur (si présent),
soit un connecteur SMTP sur le
serveur qui présente le coût de routage
le plus bas possible. Vous pouvez
suivre les événements dans les figures
de la manière suivante, en notant qu’il
existe des entrées pour chaque adresse
de destinataire sur le message :

• event ID 1027 : Le client soumet le
  message au Store Driver.

• event ID 1019 : Le Store Driver
  soumet le message à  Advanced
  Queueing.

• event ID 1025 : Advanced Queueing
  traite le message.

• event ID 1024 : Le Categorizer reçoit
  le message et commence à  le traiter.

• event ID 1020 : Le moteur de routage
  place le message dans une file d’attente
  de destination et le prépare
  pour le transférer hors du serveur.

• event ID 1031 : Le moteur de routage
  transfère correctement le message et
  le traitement est terminé.

A titre de comparaison, voyons la
séquence d’événements pour un message
délivré à  une boîte à  lettres sur le
même serveur. Les mêmes événements
se produisent pour des livraisons
faites à  une boîte à  lettres dans un
autre SG (Storage Group).

• event ID 1027 : Le client soumet le
  message au Store Driver.

• event ID 1019 : Le Store Driver
  soumet le message à  Advanced
  Queueing.

• event ID 1025 : Advanced Queueing
  traite le message.

• event ID 1024 : Le Categorizer reçoit
  le message et commence à  le traiter.

• event ID 1023 : Le moteur de routage
  place le message dans la file d’attente
  de livraison locale.

• event ID 1028 : Le Store délivre le
  message à  la boîte à  lettres.

Les messages que soumettent les
clients OWA (Outlook Web Access)
journalisent la même suite d’entrées.Les clients POP3 et IMAP4 utilisent
SMTP pour soumettre des messages directement
au moteur de routage. Les
messages ne passent pas par le Store
Driver, donc la séquence commence à 
l’event ID 1019.

Parmi les autres entrées communes,
on trouve l’event ID 1023 (livraison
réussie à  une boîte à  lettres locale)
et event ID 1029 (transfert au
MTA pour livraison). Contrairement
aux journaux Exchange 5.5, les journaux
Exchange 2000 n’ont pas d’entrée
spéciale pour marquer l’extension
d’un groupe de distribution. On verra
plutôt une entrée event ID 1020 écrite
dans le journal pour chaque membre
du groupe après extension.

Les messages adressés à  un mélange
de destinataires uniques et de
groupes de distribution correspondant
à  des adresses locales et distantes posent
un problème particulier aux serveurs
de e-mail, particulièrement si
certains des destinataires appartiennent
à  de multiples groupes de distribution.
Le fait que le nombre de messages envoyés à  un groupe de distribution
soit déterminé par les propriétés
du groupe ne fait que compliquer
le traitement. Par exemple, les
propriétés de groupe que montre la figure
7 révèlent que tous les rapports
de livraison pour des messages envoyés
à  ce groupe vont à  l’envoyeur.
Autrement dit, si le groupe contient
une adresse incorrecte (comme un
contact dont l’adresse e-mail est périmée,
une boîte à  lettres dont le quota a
été dépassé), l’envoyeur recevra une
notification de non-livraison. Vous
pouvez définir les propriétés du
groupe pour supprimer les rapports de
livraison afin de réduire le trafic e-mail,
mais les utilisateurs n’auront plus alors
la certitude que leur message est arrivé.
Le moteur de routage effectue le
même traitement par message pour les
notifications hors bureau, que vous
pouvez aussi supprimer ou activer à 
l’aide des propriétés des groupes de
distribution. Bien entendu, les différentes
valeurs que vous pouvez
sélectionner pour ces propriétés se traduisent par des permutations de
génération de messages.

Comme Exchange 2000 traite les
rapports de livraison et les notifications
hors bureau message par message,
si vous envoyez un message
adressé à  deux groupes – un qui permet
les rapports de livraison et un qui
supprime les rapports – le moteur de
routage doit générer deux jeux de messages.
Ainsi, les destinataires du premier
groupe reçoivent une copie du
message avec ses propriétés définies
pour permettre les rapports de livraison,
et les destinataires de l’autre
groupe reçoivent une copie avec ses
propriétés définies pour supprimer les
rapports de livraison.

Vous ne voulez pas que les utilisateurs
reçoivent de multiples copies
d’un message, mais cela peut se produire
si le code du moteur de routage
ne traite pas toutes les circonstances
possibles quand le moteur de routage
construit la liste des destinataires pour
un message. Pour optimiser la liste des
destinataires, le moteur de routage va
étendre tous les groupes de distribution,
vérifier les rapports de livraison et
les propriétés de notification hors bureau
des groupes de distribution, puis
générer le nombre approprié de messages
pour répondre aux exigences
telles qu’elles sont déterminées par les
propriétés de chaque groupe. Le résultat
de la nature complexe des listes de destinataires est que vous pourriez
voir de multiples entrées event ID 1020
et event ID 1028 pour chaque adresse
sur un message quand vous examinez
les données du journal de suivi.

Par comparaison, Exchange 5.5
MTA utilise un processus appelé fanout
pour étendre les DL (ou groupes).
MTA construit la liste d’adresses puis
détermine la meilleure route possible
pour envoyer une copie unique du
message à  chaque destinataire.
Exchange 5.5 ne supporte pas le même
jeu de propriétés pour contrôler les
messages et rapports de livraison hors
bureau, donc il est plus facile de bâtir
une liste de destinataires.

Dans Exchange 2000 ou Exchange
5.5, si des messages en double sont
transmis, le Store du serveur récepteur
peut utiliser l’identificateur de messages
pour détecter les doublons et les
supprimer. Ce mécanisme d’arrêt garantit
qu’Exchange ne délivre pas de
messages en double.