Une meilleure gestion des serveurs

de messages
appelé Regtrace. Ce n’est pas le
même type d’application d’archivage
de messages offert par des fournisseurs
tiers. Celui-ci peut aider à  déboguer
des problèmes de trafic SMTP.
Regtrace transfère dans un répertoire
disque tout le e-mail traité par un serveur
virtuel SMTP. En examinant le email
contenu dans ce répertoire, on
peut détecter les problèmes. Bien que
ne servant pas quotidiennement, cet
utilitaire est un complément utile du
toolkit.

Suivi des messages. Dans le même
esprit, le snap-in MMC Exchange
Message Tracking Center, accessible directement
au moyen d’une console
MMC personnalisée ou de l’ESM, a été
complètement rénové. Le snap-in a désormais
une GUI de type Outlook,
illustrée figure 2, qui aide à  suivre les
messages manquants. La manière dont
Exchange traite les demandes de suivi
a également changé. Auparavant, une
console administrative qui voulait
suivre un message devait interroger
tous les serveurs impliqués dans le
chemin du message dans toute l’organisation.
La console extrayait les journaux
de trace de tous les serveurs sur
lesquels le suivi de messages était activé, puis interrogeait les journaux
pour trouver des entrées correspondantes.
Avec SP2, la console envoie les
demandes de suivi à  chaque serveur,
lequel traite la requête localement et
ne fournit en réponse que les entrées
correspondantes au lieu de tout le
journal. Cette méthode réduit le trafic
du réseau et accélère l’opération de
suivi.

Nouveau service Exchange
Management. Les nouvelles interfaces
DSAccess et Message Tracking dépendent
toutes deux du nouveau service
Microsoft Exchange Management. Ce
service ressemble un peu à  son homologue
System Attendant en ce qu’il effectue
des opérations de gestion pour
le compte du serveur. (Vous trouverez
le service Exchange Management dans
la liste des services qui apparaît au moment
du démarrage d’Exchange 2000.)
Si le service n’est pas en fonctionnement,
vous ne pourrez pas accéder aux
informations du répertoire ni utiliser le
Message Tracking Center.

Des notifications plus claires.
SP2 se distingue aussi par un texte
amélioré pour les DSN (Delivery Status
Notifications) que les utilisateurs reçoivent
quand un message ne peut pas
être délivré. Les raisons de la non-livraison
sont multiples, mais la cause
est souvent obscurcie par un texte abscons
pour l’utilisateur moyen. SP2 clarifie
ce texte. Ainsi, Exchange 2000 et
SP1 génère le même DSN pour un
message avec une adresse qu’Exchange
ne peut pas résoudre en consultant
un serveur cible dans DNS et pour un
message qu’un administrateur a supprimé
d’une file d’attente SMTP. SP2,
quant à  lui, fournit davantage de renseignements.
La figure 3 montre les
DSN que SP2 envoie dans ces deux cas.
(Exchange 2000 SP2 génère le DSN
supérieur quand une adresse n’existe
pas dans le domaine SMTP et renvoie
le DSN inférieur quand un administrateur
supprime un message d’une file
d’attente.) Le texte ainsi amélioré n’est
peut-être pas encore entièrement
compréhensible par les utilisateurs, mais le personnel d’assistance peut au
moins s’en servir pour résoudre le problème
à  l’origine du DSN.

On ne peut pas personnaliser les
messages DSN, mais SP2 ajoute un
nouvel événement de transport que le
service Routing Engine peut déclencher
avant qu’Exchange ne génère un
message DSN. On peut écrire du code
et l’associer à  cet événement pour
ajouter du texte approprié à  un message
DSN, mais seulement pour les
messages adressés à  des personnes
ayant envoyé des messages non délivrables
à  votre serveur. Le nouvel événement
est intéressant, mais il n’aidera
pas la plupart des utilisateurs, et la majorité
des administrateurs ne veut pas
écrire du code.