Vos emails sont lents ? Audit Exchange : Guide rapide

Vos emails sont lents ? Les utilisateurs râlent ? Pourtant, quand vous regardez vos serveurs, tout semble vert. Bienvenue dans le monde merveilleux d’Exchange, où le diable se cache souvent dans les détails… ou dans les logs que personne ne lit.

Aujourd’hui, je vous montre comment réaliser un audit de santé complet de votre infrastructure, sans installer le moindre logiciel, juste avec PowerShell. Je vous expliquerai chaque commande pas à pas, même si vous débutez.

En fin d’article, je vous partage un cas réel où cette méthode a permis de découvrir pourquoi des emails prenaient 15 minutes voir des jours de retard sans raison apparente.


🛠️ L’Arme Secrète : PowerShell & WinRM

Nous allons utiliser WinRM (Windows Remote Management). C’est une technologie intégrée à Windows qui permet de piloter vos serveurs à distance, exactement comme si vous étiez assis devant l’écran, mais en ligne de commande.

La Commande de Base

Pour se connecter à un serveur à distance, on utilise :

Enter-PSSession -ComputerName "NomDuServeur"

Une fois entré, toutes les commandes que vous tapez s’exécutent là-bas.

Schéma de l’Infrastructure

Pour mieux visualiser ce que nous auditons, voici à quoi ressemble notre architecture cible :


Schéma Infrastructure Exchange

🔍 Étape 1 : Vérifier la Porte d’Entrée (Les serveurs « Front-End »)

Dans une architecture moderne, vos emails passent d’abord par des serveurs « Frontaux » (ou Reverse Proxy, souvent gérés par IIS ARR). Si la porte est bloquée, personne n’entre.

1. Le service Web tourne-t-il ?

Exchange, c’est avant tout du web (OWA, ActiveSync).

Get-Service W3SVC

Pour le néophyte : Cette commande demande simplement « Hé, est-ce que le service qui gère les sites web est démarré ? ». On veut voir Status : Running.

2. Y a-t-il des erreurs à l’entrée ?

Get-EventLog -LogName System -EntryType Error,Warning -Newest 20

Traduction : « Affiche-moi les 20 dernières erreurs ou avertissements du système ». C’est comme regarder le journal de bord du capitaine.


🩺 Étape 2 : Le Cœur du Système (Les serveurs « Backend »)

C’est ici que sont stockées les boîtes aux lettres. C’est là que ça se corse.

1. Les Services Vitaux

Exchange est une usine à gaz avec plein de services. Mais seuls quelques-uns sont critiques pour que le courrier circule.

Get-Service MSExchangeIS, MSExchangeTransport
  • MSExchangeIS (Information Store) : C’est la base de données de vos mails.
  • MSExchangeTransport : C’est le facteur qui trie et livre le courrier.

2. L’Espace Disque (Le tueur silencieux)

Si vos disques sont pleins, Exchange s’arrête net pour se protéger.

Get-Volume

L’astuce : Regardez la colonne SizeRemaining. Sur un serveur Exchange, il faut toujours avoir de la marge (plusieurs Go) pour les logs de transaction.

3. Les Logs d’Application (Là où se cache la vérité)

C’est la commande la plus puissante de cet audit.

Get-EventLog -LogName Application -EntryType Error -Newest 10 | Format-List

Traduction : « Montre-moi les 10 dernières erreurs de l’application en détail ».


🚩 L’Étude de Cas : Le Mystère du « Backend-02 »

Sur une infrastructure récente, tout semblait parfait. Ping OK. Services OK. Disques OK. Pourtant, on se plaignait de lenteurs.

En lançant la commande d’analyse des logs sur le deuxième nœud Backend (appelons-le Backend-Exchange-02), voici ce que nous avons trouvé :

TimeGenerated : 1/8/2026 9:44:00 AM
EventID : 1057
Source : MSExchange Extensibility
Message : Agent 'Exchange DkimSigner' went async but did not call Resume...
TimeGenerated : 1/8/2026 9:28:21 AM
EventID : 1057
Source : MSExchange Extensibility
Message : Agent 'Exchange DkimSigner' went async but did not call Resume...
TimeGenerated : 1/8/2026 9:13:01 AM
EventID : 1057
Source : MSExchange Extensibility
Message : Agent 'Exchange DkimSigner' went async but did not call Resume...

Qu’est-ce que ça veut dire ?

Il y a un petit programme tiers (un « Agent ») installé sur Exchange pour signer les mails (le DKIM, c’est comme un sceau de cire numérique pour prouver que le mail vient bien de vous). Ce programme plantait silencieusement.

Le Diagnostic

En regardant les heures des erreurs, on a vu :

  • 09:13 : Erreur
  • 09:28 : Erreur (+15 min)
  • 09:44 : Erreur (+16 min)

L’explication : Exchange essayait d’envoyer un mail. L’agent DKIM plantait. Exchange attendait, puis mettait le mail de côté (« Ok, je réessaierai plus tard »). Et « plus tard » dans Exchange, c’est souvent 15 minutes. Donc, à cause de ce petit bug invisible, les mails prenaient 15 minutes, 30 minutes, 45 minutes de retard… jusqu’à ce que l’agent finisse par marcher par chance, ou que le mail expire !

  • PROBLÈME CRITIQUE
    • Source : MSExchange Extensibility
    • Message d’Erreur : « Agent ‘Exchange DkimSigner’ went async but did not call Resume on the new thread… »
    • Impact Technique : L’agent de signature DKIM (tiers) plante ou ne répond pas correctement lors du traitement asynchrone des emails.
    • Conséquence Opérationnelle : Risque direct de ralentissement de la livraison des mails (mise en file d’attente) ou d’échecs de transport si l’agent timeout.

Comment résoudre ?

Objectif : Rétablir la signature DKIM sans les plantages sur le serveur fautif

Comparaison des configurations

En comparant la configuration du serveur qui plante avec celui qui fonctionne, nous avons trouvé une différence de configuration.

  • Serveur Sain : Configuré pour chercher le fichier clé test.fr.
  • Serveur Fautif : Configuré pour chercher test.fr.pem.

L’erreur subtile : L’agent DKIM a une particularité. Si vous spécifiez une extension (comme .pem), il peut cesser de chercher dans le dossier par défaut (keys) et ne regarde qu’à la racine. Résultat : « Fichier introuvable » -> Crash -> Mail bloqué -> Réessai dans 15 min.

La Solution : L’objectif est d’aligner la configuration sur celle du serveur sain.

  1. Configuration XML : Corriger le chemin dans le fichier settings.xml pour utiliser test.fr (sans extension).
  2. Fichiers : Renommer les fichiers dans le dossier C:\Program Files\Exchange DkimSigner\keys :
    • test.fr.pem -> test.fr
    • test.fr.pem.pub -> test.fr.pub

Enfin, pour appliquer les changements, on relance le service Transport. Note : L’agent DKIM n’est pas un service à part, mais une « extension » (DLL) chargée par Exchange. Il est donc obligatoire de redémarrer le service de Transport principal pour qu’il recharge sa configuration.

Restart-Service MSExchangeTransport

Potentielle mise à jour si nécessaire

Procédure :

  1. Télécharger la dernière version de l’agent (ex: sur GitHub ou site éditeur).
  2. Désinstaller l’ancienne version via « Programmes et Fonctionnalités ».
  3. Installer la nouvelle version.
  4. Vérifier que l’agent est actif : Get-TransportAgent "Exchange DkimSigner"
  5. Surveiller les logs pendant 30 minutes :Get-EventLog -LogName Application -Source « MSExchange Extensibility » -Newest 20

La Morale

Sans aller fouiller dans les logs avec PowerShell, on aurait pu chercher des heures (ou des jours) pourquoi le réseau « semblait » lent.

Avec quelques lignes de PowerShell, vous pouvez transformer « Je crois que ça marche » en « Je SAIS que ça marche ».

Apprenez à écouter vos serveurs, ils ont souvent la réponse !

🎁 Bonus Expert : La Cheat Sheet

Pour aller plus loin, voici les commandes que tout admin Exchange devrait connaître par cœur :

1. Santé des Bases de Données (DAG)

Get-MailboxDatabaseCopyStatus

Affiche l’état de réplication. Surveillez CopyQueueLength (Doit être 0) et ReplayQueueLength.

2. Flux de Mail (Transport)

Get-Queue -Summary

Donne un aperçu instantané des files d’attente (Submission, Delivery). Si MessageCount > 100, inquiétez-vous.

Test-Mailflow -TargetEmailAddress <email>

Envoie un mail sonde pour tester la délivrance de bout en bout.

3. Maintenance Serveur

Get-ServerComponentState -Identity <ServerName>

Indispensable pour voir si un composant est « Inactive » (Maintenance Mode) ou « Active ».

4. Connectivité Client

Test-MAPIConnectivity et Test-ServiceHealth

Vérifie que les clients Outlook peuvent réellement se connecter aux bases.