Article d’origine publié le vendredi 1er juin 2012

Au cours des derniers mois, nous avons reçu des rapports de croissance excessive du dossier Éléments récupérables (que beaucoup appellent Benne, bien que le terme ne soit plus vraiment utilisé). Deux grands scénarios peuvent contribuer à cette croissance excessive.

  1. Contrôle de version par récupération d’élément unique et suspension pour litige
  2. Journalisation des versions du calendrier

Récupération d'élément unique et suspension pour litige

La récupération d’élément unique et la suspension pour litige permettent de conserver les données dans la boîte aux lettres. Si ces fonctionnalités ne vous sont pas familières, lisez mon billet précédent Récupération d’élément unique dans Exchange 2010 pour plus d'informations.

Outre la conservation des données dans la boîte aux lettres, la récupération d’élément unique et la suspension pour litige permettent aussi le contrôle de version. Fondamentalement, lorsqu’un élément est modifié, une copie sur écriture (COW) est effectuée pour conserver la version originale de l’élément. L’élément original est placé dans le dossier Éléments récupérables\Versions. Ce dossier n’est pas visible aux utilisateurs.

Étant donné qu’Exchange 2010 change la façon dont les clients se connectent et accèdent aux données de leur boîte aux lettres, l’opération de copie sur écriture se produit dans la couche XSO (Exchange System Objects) du serveur d’accès au client.

Comment est déclenchée une copie sur écriture ?

  • Pour les messages et les publications (IPM.Note* et IPM.Post*), la copie sur écriture capture les modifications dans l’objet, le corps, les pièces jointes, les expéditeurs/destinataires et les dates d'envoi/réception.
  • Pour d’autres types d’éléments, la copie sur écriture capture toutes les modifications de l’élément à l’exception des déplacements entre dossiers et des modifications de l’état lu/non lu.
  • Les brouillons ne font pas l’objet d’une copie sur écriture pour éviter des copies excessives lorsqu’ils sont sauvegardés automatiquement.

Qu’est-ce qui peut provoquer une croissance excessive du dossier Éléments récupérables ?

Overflowing-Trash-Can_thumb[1]Le comportement de la copie sur écriture peut entraîner une croissance excessive. Nous avons découvert dans ce scénario, qui fait intervenir Microsoft Outlook, la cause principale de la copie sur écriture excessive :

  1. Vous créez un rendez-vous dans le calendrier.
  2. Vous attachez un document Office au rendez-vous et vous l’enregistrez.
  3. Plus tard, vous décidez d’ouvrir le rendez-vous pour référencer quelque chose dans le document Office. Vous ouvrez le document.
  4. En arrière-plan, Outlook commence à enregistrer automatiquement ce rendez-vous ouvert et son document ouvert correspondant (par défaut, Outlook enregistre automatiquement toutes les 3 minutes).
  5. Chaque événement d’enregistrement automatique déclenche une copie sur écriture. Mais comme l’enregistrement automatique enregistre à la fois le document Office et le rendez-vous, il y a deux événements de copie sur écriture. Pour chaque pièce jointe supplémentaire, une version de copie sur écriture sera aussi créée.

Aïe, c’est vrai.

Les pièces jointes font partie du message, la création d’une copie pour chaque pièce jointe de l’élément n’a donc aucun sens. Fondamentalement, quand vous enregistrez un élément qui contient une pièce jointe, Outlook effectue les actions suivantes :

  1. CreateAttachment
  2. SaveAttachment
  3. SaveMessage

La copie sur écriture intervient aux deux étapes SaveAttachment et SaveMessage. En fouillant dans le code, nous avons découvert que l’appel à SaveAttachment appelle la méthode Flush (un moyen par lequel le client synchronise l'état avec le serveur) sur le message auquel il est associé après l’enregistrement de la pièce jointe. C’est cet appel à la méthode Flush qui indique au code de la copie sur écriture qu’il doit agir.

Après une analyse plus poussée, nous avons réalisé que l’opération de copie sur écriture est déclenchée par n’importe quel appel à la méthode Flush. C’est une découverte capitale parce que la méthode Flush peut être initiée dans de nombreux scénarios, entraînant potentiellement les milliers d’événements de copie sur écriture décelés par plusieurs utilisateurs dans leurs environnements.

Dans Exchange 2010 SP2 RU3 et versions ultérieures, la copie sur écriture fait la différence entre les opérations de vidage et d'enregistrement et n’est déclenchée qu’en cas d’enregistrement.

Journalisation des versions du calendrier

La journalisation des versions du calendrier est le processus par lequel les modifications du calendrier à l’intérieur d’une boîte aux lettres sont enregistrées via la copie sur écriture. La journalisation des versions du calendrier a été introduite dans Exchange 2010 pour permettre la résolution des problèmes et réparer les problèmes de fiabilité du calendrier.

Le concept de journalisation des versions du calendrier consiste à créer un journal chaque fois qu’un élément du calendrier est modifié. Ces journaux fournissent un historique de la réunion. Vous pouvez utiliser l’applet de commande Get-CalendarDiagnosticLog pour passer en revue l’historique et déterminer lequel des clients a effectué une action destructrice. La journalisation des versions du calendrier est aussi utilisée par l’Assistant de réparation du calendrier, qui se sert des journaux pour essayer de déterminer l’historique d’un élément de calendrier spécifique suite à la détection d’une incohérence.

La journalisation des versions du calendrier est activée par défaut sur les boîtes aux lettres dans Exchange 2010. Vous pouvez la désactiver ou l'activer sur une boîte aux lettres via la propriété CalendarVersionStoreDisabled. Notez que le nom de la propriété est CalendarVersionStoreDisabled, la valeur par défaut $false signifie donc que la journalisation des versions du calendrier est activée par défaut. En fonction de la configuration de la boîte aux lettres, un processus différent est suivi pour le stockage des copies des éléments du calendrier :

  1. Si la boîte aux lettres n’est pas activée pour la récupération d'élément unique ou la suspension pour litige, alors les versions supprimées des éléments du calendrier sont conservées à la racine du dossier Éléments récupérables pendant 120 jours. Les versions supprimées (le corps et les pièces jointes qui ne sont pas de premier niveau ni incorporées dans le message sont supprimés) sont créées à l’aide de la copie sur écriture.
  2. Si la boîte aux lettres est activée pour la récupération d’élément unique ou la suspension pour litige, des copies complètes des éléments du calendrier sont conservées dans les dossiers Éléments récupérables\Suppressions ou Éléments récupérables\Versions. Une version supprimée est créée via l’infrastructure de copie sur écriture dès qu’une opération de suppression définitive est effectuée sur un élément du calendrier dans les dossiers Éléments récupérables\Suppressions ou Éléments récupérables\Versions. Cette version supprimée est placée à la racine du dossier Éléments récupérables et conservée pendant 120 jours. Une version supprimée n'est pas créée quand l’âge de l’élément dans le dossier Éléments récupérables\Suppressions ou Éléments récupérables\Versions est supérieur à 134 jours (120 + 14). Cela peut arriver si vous modifiez la période de rétention, si l’Assistant du dossier de boîte aux lettres n’est pas en cours d’exécution, si la suspension pour litige est désactivée, etc.).

En raison du problème mentionné plus haut sur la façon dont la logique de copie sur écriture ne faisait pas la distinction entre les opérations de vidage et d’enregistrement, la journalisation des versions du calendrier, parfois, peut utiliser une grande partie du quota du dossier Éléments récupérables (et pour rappel, le seuil d’avertissement est de 20 Go et le quota maximum est de 30 Go).

Bien que la version SP2 RU3 résout les problèmes de la copie sur écriture, pour éviter que la journalisation des versions du calendrier n'utilise la totalité du quota du dossier Éléments récupérables, nous avons introduit dans la version SP2 RU2 une modification de l’architecture grâce à laquelle la journalisation des versions du calendrier prend désormais en compte la taille du dossier Éléments récupérables avant de lancer une copie sur écriture.

Si la taille du dossier est supérieure à la valeur RecoverableItemsWarningQuota, la journalisation des versions du calendrier est désactivée pour la boîte aux lettres. La valeur RecoverableItemsWarningQuota utilisée dépend des paramètres de la boîte aux lettres :

  1. Si UseDatabaseQuotaDefaults de la boîte aux lettres a la valeur $true, alors la valeur RecoverableItemsWarningQuotade la base de données de la boîte aux lettres sera utilisée.
  2. Si UseDatabaseQuotaDefaults de la boîte aux lettres a la valeur $false, alors la valeur RecoverableItemsWarningQuota de la boîte aux lettres sera utilisée.

Si la journalisation des versions du calendrier est désactivée, l’événement suivant est généré dans le journal d’événements de l’application sur le serveur d’accès au client :

Event ID: 5003
Source: MSExchange Mid-Tier Storage
Task Category: CopyOnWrite
Level: Information
Description: User mailbox <legacyExchangeDN> has exceeded the dumpster warning quota. Calendar logging has been disabled for the mailbox.

Mais ce n’est pas tout ce que nous faisons. Je n’entrerai pas dans les détails à ce stade précoce du développement, mais nous travaillons à l’amélioration de la journalisation des versions du calendrier pour réduire son impact sur notre déploiement. Je vous informerai de nos avancées via ce blog.

Ross Smith IV
Responsable principal du programme
Exchange Customer Experience

Ce billet de blog a été traduit de l’anglais. L’article d’origine est disponible à la page Holy COW! Changes to Recoverable Items versioning in Exchange 2010 SP2 RU3