Suivi des éléments de calendrier dans Exchange 2010

Un problème récurrent dans les versions antérieures d'Exchange était de savoir ce qui s'était passé avec tel ou tel élément de calendrier: il a disparu ou il a été modifié, par qui, quand et comment?

La commande Get-CalendarDiagnosticLog dans Exchange 2010 permet d'en savoir plus. Elle dépanne lors de problèmes avec les éléments d'un calendrier en identifiant le client ou le composant en cause. Pour cela la commande reconstruit toutes les actions effectuées sur un élément depuis sa création.

La Théorie

Les données récoltées par la commande sont de 2 types: snapshot et metadata

Snapshots
Les snapshots fournissent un historique de l'élément de calendrier. Pour cela on utiilise la fonctionalité Copy-On-Write (COW) d'Exchange 2010 qui sauvegarde une copie de l'élément avant qu'une modification ne soit effectuée. Ainsi on obtient les différents états de l'élément à chaque étape de ses modifications.
Les snapshots s'appliquent à tous les types d'élément de calendrier, rendez-vous, réunions et messages de réunion. Les messages de réunion incluent les demandes de réunion, les réponses, les annulations et les transferts de notifications.
Un snapshot seul est insuffisant pour trouver quel a été le scénario et les opérations qui ont causé un changement à un élément de calendrier. Il manque le contexte lié à ce changement et ce contexte est enregistré dans la métadata de chaque élément.
Metadata
Ces informations de metadata sont ajoutées à l'élément de calendrier comme une entrée de propriété qui permet d'obtenir un diagnostic plus détaillé des causes de chaque changement. Quand une modification est faite dans un élément de calendrier, un snapshot est effectué en premier lieu pour conserver la metadata courante avant que la modification ne soit effectuée sur l'élément d'origine. Les informations de contexte de la metadata peuvent être classées en 3 types:
- Contexte de base
Qui a fait quoi en termes généraux. Ce type contient toute information relative à qui a effectué la modification (utilisateur, machine, application, etc...) et quelle est cette modification (création, mise à jour, effacement).
- Contexte historique
Quand cela a été fait. Ce type maintient un enregistrement de l'historique quand une modification a été effectuée tout en conservant d'autres informations importantes comme la date/heure de création.
- Contexte opération
Comment cela a été fait. Ce type contient les méthodes appelées, les arguments passés et les valeurs de ces arguments. La structure des données permet la représentation des séquences d'appels.

La Pratique

https://technet.microsoft.com/en-us/library/dd638102.aspx - paramètres de la commande

Un exemple courant d'utilisation: Get-CalendarDiagnosticLog -subject "XXX"  -identity TEST\user1 -LogLocation d:\loc\logs\user1

Une fois la commande exécutée, vous pouvez utiliser OutSpy https://www.dimastr.com/outspy/ ou MFCMAPI https://mfcmapi.codeplex.com/ pour ouvrir les fichiers .msg résultant.

Dans la pratique, il apparait que les attributs qui nous intéressent suivent l'ordre et le modèle ci-dessous:

i. 0x80xxxx1E = Type of Action | for example - Create, Update
ii. 0x80xxxx40 = Creation Time
iii. 0x80xxxx40 = Modification Time
iv. 0x80xxxx1E = Modifying Application
v. 0x80xxxx1E = Modifying Client
vi. 0x80xxxx1E = Client Version
vii. 0x80xxxx1E = Modifying Service
viii. 0x80xxxx1E = Responding Server
ix. 0x80xxxx1E = Server Version
x. 0x80xxxx1E = Client Server Service
xi. 0x80xxxx1E = Requesting User
xii. 0x80xxxx1E = Calendar Mailbox Server
xiii. 0x80xxxx1E = Calendar Mailbox Version
xiv. 0x80xxxx1E = Calendar Mailbox DN

Correspondance avec un cas concret:

id: 0x0006 is the action performed - SoftDelete
id: 0x0008 is the MR creation time - 01:46:57 08/03/2011
id: 0x0009 is the MR deletion time - 01:48:01 08/03/2011
id: 0x000C is the Modifying Application - empty
id: 0x000D is the Modifying Client - empty
id: 0x000E is the Client Version - 0.0.0.0
id: 0x000F is the Modifying Service - Microsoft.Exchange.RpcClientAccess.Service
id: 0x0010 is the Responding Server - EUR-TEST-S02
id: 0x0011 is the Server Version - 14,01,0218,011
id: 0x000B is the Client Server Service - Client=MSExchangeRPC;COW=Delegate
id: 0x000A is the Requesting User - /o=TEST Messaging/ou=Exchange Administrative Group/cn=Configuration/cn=Servers/cn=EUR-TEST-MBX03/cn=Microsoft System Attendant
id: 0x0012 is the Calendar Mailbox Server - EUR-TEST-MBX03,extemp.test.com
id: 0x0013 is the Calendar Mailbox Version - Version 14,1 (Build 218,0)
id: 0x0014 is the Calendar Mailbox DN - cn=Microsoft Private MDB

Le cas des délégations est malheureusement incomplet. En effet au lieu de voir le CN du délégué(e) dans le champ id: 0x000A, cn=Microsoft System Attendant est affiché, cf. ci-dessus.
Nous savons grâce au champ id: 0x000B, COW=Delegate, que c'est un(e) délégué(e) qui a effectué l'opération.
Pas de souci lorsqu'il n'y a qu'un(e) délégué(e), sinon il faut utiliser des outils complémentaires pour repérer la personne qui a effectué l'opération. Je recommande d'utiliser la commande Get-CalendarDiagnosticLog sur la BAL du VIP ET de ses délégué(e)s pour tenter d'obtenir plus d'information.

Le champ id: 0x0008 - creation time - peut servir de point de repère dans vos recherches.