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 SaveSucceeded signifie 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 -ExtendedProperties pour 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 RetentionHoldEnabled et ElcProcessingDisabled sont à 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.

Hi folks,

Mettre en place l’archivage dans Microsoft 365 revêt une importance cruciale pour plusieurs raisons. Tout d’abord, cela garantit une gestion efficace des données en permettant leur préservation à long terme, favorisant ainsi la conformité aux réglementations légales et aux normes de l’industrie. De plus, l’archivage contribue à libérer l’espace de stockage dans les boîtes aux lettres principales, optimisant ainsi les performances du système. En offrant une visibilité et un accès rapides aux données archivées, cette fonctionnalité facilite également la recherche et la récupération d’informations cruciales. En somme, l’archivage dans Microsoft 365 constitue une stratégie proactive pour assurer la sécurité, la conformité et la gestion efficiente des données au sein de votre environnement professionnel.

La solution la plus simple pour un archivage dans 365 est d’utiliser les options de rétention à travers des Tags.

Ces même Tags sont alors associé à une règle, que vous appliquerez aux boites en question, ou à l’ensemble des utilisateurs.

Dans le cas présent nous allons voir comment archiver une BAL de 95Gb afin de libérer de l’espace.

La première chose à faire est donc de créer votre tag

Ma règle est la suivante : Tout mail reçu agé de 1jours (oui c’est de la démo…) ira en archive

/!\ Les policies de type personnal sont laissées a la main de l’utilisateur, donc si votre policie doit etre appliquée à tout les utilisateurs (a qui la règle est appliqué (étape 3) alors choisissez default mode)

https://compliance.microsoft.com/exchangeinformationgovernance

La seconde est de créer la policie associée :

La création de la policie est simple, c’est un nom et un Tag (celui de l’étape 1)

Troisième étape : Associer la policie à une BAL en particulier

Ici nous allons choisir d’appliquer la règle Default 1 Day Archive à la boite de Bill.

Alors bien évidemment il est nécessaire que l’archivage soit actif sur la BAL de l’utilisateur, sinon, il ne ce passera rien …

Tout les éléments sont presque bons.

Noter que par défaut l’assistant de gestion des folders (la cmdlet qui organise le contenu des BALs) peut prendre jusqu’à 7 jours et ne s’exécutera que sur des BALs avec un volume > 100Mb (le chiffre est a vérifier) Puis faire de l’archivage pour 100Mb … c’est une question de gouvernance et donc un autre sujet.

Avant d’aller un peu plus loin, il faut comprendre l’archivage des BALs.

Par défaut vous disposez d’une boite de xGB 50 ou 100Gb en fonction de vos licences et d’une boite d’archive équivalente. Lors de l’archivage, la structure de votre BAL est conservée, folder, sous folder, etc. … pour être le réplicas de votre BAL primaire. Ce qui est plus simple pour les utilisateurs lors d’une recherche.

La partie extra storage arrive uniquement si vous activez l’option de “AutoExpandingArchiveEnabled” vous permettant alors d’aller jusqu’a 1,5Tb de storage additionnel, mais noté que si vous êtes à 1,5Tb de mails archivés la BAL s’arrêtera de fonctionner, et qu’avoir autant de mails suppose des problèmes de gestion et un mauvais usage de la BAL. Qui ouvrirai un fichier texte de 1Tb ?

Donc nous avons ici une boite mail de 95Gb et nous voulons la réduire avec de l’archivage, et bien let’s go, voici quelques cmdlet qui vont vous aider :

Vérifions déjà si la rétention est bien positionnée : get-mailbox bill@nokh.fr | fl *ret*

Parfait – la règle de Default 1 Day Archive est présente. Y’a plus qu’a … MAIS vérifier également que les autres paramètres de rétention soient à “FALSE” et principalement le “RententionHoldEnabled”

Si RetentionHoldEnabled a la valeur True, l’Assistant Dossier managé continue de traiter la stratégie de rétention MRM sur la boîte aux lettres (y compris l’application de balises de rétention aux éléments), mais elle n’expire pas dans les dossiers visibles par l’utilisateur (c’est-à-dire, dans les dossiers de la sous-arborescence IPM de la boîte aux lettres). Toutefois, l’Assistant Dossier managé continue de traiter les éléments du dossier Éléments récupérables, y compris la purge des éléments arrivés à expiration.

/!\ Par conséquent, définir ElcProcessingDisabled sur True est plus restrictif et a plus de conséquences que de définir la propriété RetentionHoldEnabled sur True.

L’option ElcProcessingDisabled est une autre propriété de boîte aux lettres liée au traitement d’une boîte aux lettres par l’Assistant Dossier managé (la valeur par défaut de cette propriété est False). Lorsque la propriété ElcProcessingDisabled est définie sur True (à l’aide de la Set-Mailbox -ElcProcessingDisabled $true commande ), elle empêche l’Assistant Dossier managé de traiter la boîte aux lettres. Ainsi, en plus de ne pas traiter la stratégie de rétention MRM, les autres fonctions effectuées par l’Assistant Dossier managé, telles que l’expiration des éléments dans le dossier Éléments récupérables en les marquant pour suppression définitive, ne seront pas effectuées.

Start-ManagedFolderAssistant bill@nokh.fr pour lancer les jobs d’archivage défini pour la boite de bill.

Si jamais cela ne fonctionne pas, vous pouvez passer par le ExchangeGUID

get-mailbox bill@nokh.fr | fl *guid*

Start-ManagedFolderAssistant <ExchangeGUID>

Alors parfois vous aurez besoin de savoir si le job c’est bien déroulé

$logProps = Export-MailboxDiagnosticLogs bill@nokh.fr -ExtendedProperties
$xmlprops = xml
$xmlprops.Properties.MailboxTable.Property | ? {$_.Name -like "ELC*"}

Ce qui va nous intéresser ici est le LastSuccessTimeStamp, permettant d’être 100% certain que le job est passé !

Un élément intéressant, mais surtout lié à PowerShell est de créer une routine d’export sous forme de report pour savoir quand est-ce que le job est passé pour la dernière fois pour les BAL disposant d’une archive, car je le rappel, meme si la MRM est configurée, mais que vous ne disposer pas d’archive active, … rien ne se passera.

Allez voici le résultat, vous constaterez que les structures sont conservés, et l’expérience utilisateur est conservée

Vous me direz, oui mais alors la différence avec le dossier archive ? Et bien aucun rapport avec de l’archivage, c’est un dossier … comme un autre

Tous les comptes ont accès à un dossier d’archivage. Pour les comptes Microsoft 365, Outlook.com et Exchange, le dossier d’archivage correspond à l’un des dossiers par défaut d’Outlook (par exemple, Boîte de réception, Éléments envoyés ou Éléments supprimés). Ce dossier ne peut pas être supprimé. Si vous utilisez Outlook avec un compte Exchange ou Exchange Online, les stratégies de dossier telles que les stratégies de rétention s’appliquent au dossier d’archivage.

L’utilisation du bouton Archiver pour déplacer des messages vers le dossier d’archivage ne réduit pas la taille de votre boîte aux lettres. Si vous devez réduire la taille de votre boîte aux lettres, vous pouvez utiliser l’archive en ligne dans Microsoft 365 pour les entreprises.

Stay tuned !