ConnexionCas pratique
Diagnostic d’un archivage inefficace dans Exchange Online
Dans un environnement Exchange Online, j’ai observé un cas où l’archivage In-Place était activé sur une boîte aux lettres, mais sa taille ne diminuait pas. Autrement dit, même après avoir coché l’option d’archivage, les messages restaient dans la boîte principale. Ce comportement surprenant peut résulter de tags de rétention mal configurés, d’un hold actif ou d’un problème lors du traitement par le Managed Folder Assistant (MFA). Je vous présente ici un retour d’expérience détaillé, illustré par les outils de diagnostic PowerShell et MFCMAPI, afin d’identifier la cause racine de ce dysfonctionnement.
Extraction des logs diagnostics et interprétation des propriétés ELC
Pour investiguer, j’ai utilisé la cmdlet PowerShell Export-MailboxDiagnosticLogs -ExtendedProperties, qui exporte de nombreuses propriétés de la boîte aux lettres pour le diagnostic. Par exemple, Tony Redmond illustre cette approche en important le log au format XML et en filtrant les propriétés dont le nom commence par “ELC” (pour Email Lifecycle)practical365.com. Ces propriétés ELC reflètent l’activité du MFA sur la mailbox : durée de traitement, nombre d’éléments taggés, archivés ou supprimés lors de la dernière exécution, etc.
Les principales propriétés clés sont :
- ElcAssistantLock : indique si le MFA est verrouillé (1) ou non (0) sur la boîte.
- ElcFaiSaveStatus / ElcFaiDeleteStatus : statut de la création/suppression de l’élément FAI (Folder Associated Item) caché pour les tags de rétention. Par exemple
SaveSucceededsignifie que le MFA a créé/mis à jour le FAI lors de cette passe. - ElcLastRunArchivedFromRootItemCount : nombre de messages déplacés depuis la boîte principale vers l’archive lors de la dernière exécution du MFA. (Similairement, les compteurs “Deleted” et “Tagged” indiquent respectivement les suppressions et étiquetages réalisés.)
Première exécution de
Export-MailboxDiagnosticLogs (avant traitement MFA). On voit ici que **toutes les valeurs “ElcLastRunItemCount” sont à 0** et ElcFaiSaveStatus = SaveNotAttempted. Cela signifie que le MFA n’a encore appliqué aucun tag ou archivage. En particulier, ElcAssistantLock = 0, confirmant que l’assistant n’était pas en cours d’exécution au moment du log.
Seconde capture après que le MFA a été lancé. On constate que
ElcFaiSaveStatus = SaveSucceeded, indiquant que l’élément FAI a été créé/mis à jour. Le compteur ElcLastRunArchivedFromRootItemCount = 918 (flèche rose non présente ici) montre que 918 messages ont été déplacés vers l’archive lors de cette exécution. Les autres compteurs affichent le détail : par exemple ElcLastRunDeletedFromRootItemCount = 495 (éléments supprimés), et 4263 éléments ont été taggés pour suppression (TaggedWithExpiry). Cela montre qu’après activation des tags de rétention, le MFA a bien traité un volume important de messages.
Troisième capture (exécution suivante).
ElcAssistantLock = 1 (flèche rose) indique que le MFA était en cours d’exécution lors de la collecte du log. Cette passe n’a pas déplacé de nouveaux éléments (ElcLastRunArchivedFromRootItemCount = 0), mais on observe un pic de 67068 éléments taggés pour suppression (ElcLastRunTaggedWithExpiryItemCount), et un temps de traitement très élevé. Le statut ElcFaiSaveStatus = SaveNotAttempted suggère que le FAI n’a pas été modifié à nouveau ce jour-là. Autrement dit, le MFA a détecté un grand nombre de messages à traiter (vraisemblablement en fonction des tags existants), sans actualiser le FAI ni archiver supplémentaire.
Dans l’ensemble, ces logs ELC montrent qu’un traitement MFA s’est bien déclenché et a appliqué les tags/archives sur plusieurs milliers de messages, mais que la seconde exécution n’a fait qu’étiqueter un très grand nombre d’éléments sans mouvement additionnel. La présence du verrou (ElcAssistantLock = 1) et les compteurs élevés confirment que l’assistant tourne normalement.
Vérification manuelle avec MFCMAPI (PR_RETENTION_DATE)
Pour comprendre pourquoi les éléments tagués n’ont pas été déplacés, j’ai donc inspecté manuellement la propriété PR_RETENTION_DATE d’un message via MFCMAPI. Cette propriété (visible uniquement si un tag personnel ou de boîte a été appliqué) donne la date et l’heure de suppression programmée de l’élément. Par exemple, dans la capture ci-dessous (boîte de “Michael N.”), on voit PR_RETENTION_DATE = 01/10/2024 pour un e-mail (flèche rose). Cela signifie qu’à cette date (en UTC) le message devait expirer selon le tag en vigueur.
Capture MFCMAPI de la boîte de “Michael N.” La flèche rose pointe la propriété PR_RETENTION_DATE d’un e-mail, ici positionnée au 1er octobre 2024. Cette valeur renseigne la date d’expiration effective de l’élément selon le tag de rétention appliqué.
L’observation clé est que les dates de rétention de ces messages sont toutes postérieures au moment du diagnostic. En d’autres termes, même si le MFA a correctement tagué de nombreux messages (comme le montre les logs ELC), ceux-ci ne seront archivés/supprimés qu’à l’échéance de PR_RETENTION_DATE. Tant que cette date n’est pas atteinte, les éléments restent dans la boîte principale.
Analyse croisée et interprétation
La corrélation entre les logs ELC et les dates PR_RETENTION_DATE explique le comportement constaté. Les logs montrent des dizaines de milliers de messages marqués pour suppression (“TaggedWithExpiry”), mais MFCMAPI révèle que la plupart de ces messages sont encore loin de leur date d’expiration.
Autrement dit, aucun conflit technique n’empêchait le MFA de traiter la boîte : l’assistant a tourné et appliqué les tags. Le retard dans l’archivage provient simplement du fait que les tags appliqués ont des durées très longues. Par exemple, si un tag “Supprimer au bout de 365 jours” a été appliqué en mai 2023, la PR_RETENTION_DATE est en octobre 2024, d’où le report du déplacement.
Il n’a pas non plus été nécessaire de forcer l’archivage : le MFA s’exécute automatiquement en cloud (au moins une fois par semaine). Cependant il faut vérifier que RetentionHoldEnabled est à False et qu’ElcProcessingDisabled est False (via Get-Mailbox | fl *Retention*), éliminant un hold éventuel. J’ai également vérifié les tags existants : Microsoft rappelle que les tags désactivés ou configurés en “Never delete/archive” ont priorité et empêchent toute action. Dans notre cas, aucun tag n’était en « jamais archiver » et la politique de rétention utilisée contenait des tags personnels dont la durée, bien que longue, était valide.
En résumé, le diagnostic croisé montre que le MFA fonctionne correctement. Le problème d’« archivage inefficace » tenait au paramétrage des tags : les messages n’étaient pas encore arrivés au terme de leur rétention.
Conclusion et recommandations
Pour diagnostiquer et corriger ce type de situation, il faut retenir plusieurs bonnes pratiques :
- Collecter les logs MFA avec
Export-MailboxDiagnosticLogs -ExtendedPropertiespour visualiser les compteurs ELC (comme vu ci-dessus). Cela confirme si l’assistant a réellement traité la boîte (présence d’un timestamp et de compteurs non nuls). - Examiner les propriétés PR_RETENTION_DATE via MFCMAPI ou script (par exemple, avec Get-MessageTrace ou Get-MailboxFolderStatistics) pour vérifier si les dates d’expiration sont atteignables. Un PR_RETENTION_DATE dans le futur explique un archivage différé.
- Forcer manuellement le MFA si besoin (cmdlet
Start-ManagedFolderAssistant -Identity <utilisateur> -Archive) et patienter quelques heures pour voir l’effet. - Vérifier les tags de rétention associés à la boîte : s’assurer qu’aucun tag n’est désactivé et qu’aucun tag “Never” (jamais archiver/supprimer) ne bloque le traitement. Contrôler les durées des tags : les plus longues priment sur les plus courtes.
- Vérifier les propriétés de la boîte : s’assurer que
RetentionHoldEnabledetElcProcessingDisabledsont àFalse, afin de ne pas empêcher MFA (comme décrit par Microsoft). - Surveiller l’interface utilisateur : après traitement, on peut aussi confirmer visuellement dans Outlook que les tags sont appliqués aux messages (dans OWA, les tags de rétention apparaissent avec leurs dates d’expiration).
En appliquant ces contrôles, on peut isoler rapidement la cause racine d’un archivage qui ne se matérialise pas.
