Lorsqu’un message est déposé, vous avez deux possibilités de base au niveau du routage : transférer le message à un autre serveur (distant), ou le remettre localement. Pour Exchange 5.5., l’événement consigné dans le fichier journal dépendra de la proportion de destinataires locaux et distants. Si tous les destinataires sont
Comptage des messages envoyés
locaux, seul l’événement 1000 est enregistré. Ce dernier représente à la fois le dépôt et la remise du message. Dans le cas d’un ou de plusieurs destinataires distants, l’événement 4 est journalisé. Si un message comporte à la fois des destinataires locaux et des destinataires distants, le journal comporte les événements 4 et 1000 et chacun enregistre les destinataires associés à leur type de remise respectif. Par exemple, si un message comporte neuf destinataires, dont quatre locaux et cinq distants, quatre destinataires sont journalisés avec l’événement 1000 et cinq avec l’événement 4.
Pour déterminer le nombre de dépôts de messages, il faut localiser toutes les instances des événements 4 et 1000. Néanmoins, le simple comptage de toutes ces entrées ne reflète pas le nombre réel de messages déposés. Comme certains ont à la fois des destinataires locaux et distants, il faut corréler les événements correspondant au même message afin d’éviter un comptage en double. Pour cela, il convient d’examiner l’ID de message toujours unique, dans le champ 1. Par exemple, la figure 3 affiche trois entrées d’ID de message uniques (surlignées) et un ID de message en double. Autrement dit, seulement trois messages ont été envoyés, même si quatre entrées figurent dans le journal. (La figure présente uniquement la première ligne de chaque entrée.)
Pour collecter des statistiques par utilisateur en vue de la classification des modes d’utilisation, il faut également examiner le champ 7 (surligné en gras), car il consigne l’expéditeur du message. La figure 3 indique deux expéditeurs uniques, Ben et Andrew. Les ID de message sont uniques pour les messages d’Andrew, d’où une valeur 2 pour le comptage des messages envoyés par celui-ci. Comme les événements 4 et 1000 sont consignés pour le message envoyé par Ben, mais qu’il n’y a qu’un ID de message, le comptage pour Ben est de 1 et non de 2.
Lors de la journalisation d’un dépôt de message, Exchange 2003 et Exchange 2000 n’effectuent pas de distinction entre les destinataires locaux et distants. Ces versions d’Exchange journalisent une entrée 1027 pour chaque destinataire, comme l’illustre la figure 4. Cela facilite nettement la tâche de comptage des dépôts de messages car il suffit d’examiner un seul événement. Mais la consignation d’un événement par destinataire impose là encore de supprimer les doublons au moyen de l’ID unique, afin de corréler les événements représentant le même message. Dans Exchange 2003 et Exchange 2000, les journaux de suivi ont deux champs d’ID de message : le champ 10, MSGID, et le champ 18, Linked-MSGID. La valeur du champ 10 est générée par le composant spécifique qui écrit dans le journal et varie d’une entrée à l’autre. Par exemple, MSGID a une valeur lorsque la banque d’informations écrit dans le journal et une autre s’il s’agit du catégoriseur, même si ces composants traitent le même message. Le champ 10 sert à associer tous les événements concernant un composant particulier. Les valeurs du champ 18 seront utilisées en priorité car elles corrèlent toutes les entrées correspondantes dans le journal. L’entrée du champ 18 est identique à l’ID de message visible dans Outlook au niveau de la page des propriétés générales d’un message.
Téléchargez cette ressource
Microsoft 365 Tenant Resilience
Face aux failles de résilience des tenants M365 (configurations, privilèges, sauvegarde). Découvrez 5 piliers pour durcir, segmenter et surveiller vos environnements afin de limiter l’impact des attaques. Prioriser vos chantiers cyber et améliorer la résilience de vos tenants Microsoft 365.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Fraude par identité synthétique : comment l’IA peut redonner confiance aux entreprises et à leurs clients
- VirtualBrowser protège la navigation web à la source
- Innovation et performance : le rôle clé du consulting dans la transformation numérique
- Sekoia.io : l’alternative européenne qui s’impose dans la cybersécurité
Articles les + lus
Moderniser le développement logiciel : de la fragmentation à l’intégration
Analyse Patch Tuesday Mars 2026
Une nouvelle ère de la modernisation du mainframe
Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
DevX Summit EMEA : les développeurs au cœur de la révolution de l’IA
À la une de la chaîne Tech
- Moderniser le développement logiciel : de la fragmentation à l’intégration
- Analyse Patch Tuesday Mars 2026
- Une nouvelle ère de la modernisation du mainframe
- Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
- DevX Summit EMEA : les développeurs au cœur de la révolution de l’IA
