Tuesday, February 28, 2017

Exchange 2016 (12) : découverte électronique (eDiscovery)

English Summary: we are introduced to some basic concepts of "In-place eDiscovery". After adding a user to the "Discovery Management" group, we watch this user configure a search on a specific keyword, preview the results and then copy the discovered messages to the Discovery Search Mailbox which can be added to the Outlook profile of authorized users (and in particular, members of the Discovery Management group. 

***

La découverte électronique (ou "eDiscovery") fournit le moyen de chercher des messages contenant des mots spécifiques (ou d'autres caractéristiques) dans les boîtes aux lettres de l'organisation. Celle-ci pourrait mener une telle recherche pour les besoins d'une enquête interne ou d'une affaire de justice.

Note : le nom complet en anglais est "In-place eDiscovery", traduit par "découverte électronique inaltérable" dans la documentation officielle en français de Microsoft, et souvent abrégé en "eDiscovery". Je vais moi-même abréger le français en "découverte électronique". J'ai un doute concernant l'exactitude de la traduction mais c'est un autre sujet.

En principe, personne n'a le droit d'accéder à l'ensemble des boîtes aux lettres de l'organisation. Même les administrateurs Exchange n'ont pas ce droit. A priori, les membres du groupe "Discovery Management" ont ce droit mais le groupe en question ne contient aucun membre par défaut. En pratique, les administrateurs Exchange peuvent ajouter à ce groupe des personnes déléguées à la découverte électronique (avec l'approbation de la direction de l'organisation).

Note : le groupe "Discovery Management" se traduit par "Gestion de la découverte" dans la documentation mais dans le Centre d'administration d'Exchange - CAE ou EAC - les noms anglais d'origine sont retenus :




Pour ceux qui voudraient consulter la documentation complète de Microsoft, je fournis ce lien :

Découverte électronique inaltérable dans Exchange 2016

Et pour la version anglaise originale...

In-Place eDiscovery in Exchange 2016

De mon côté, je vais me mettre au fait de la découverte électronique version Exchange 2016 et effectuant les opérations suivantes :

  • Ajouter un utilisateur au groupe "Discovery Management" afin qu'il puisse faire des recherches dans l'ensemble des boîtes aux lettres. Précisions qu'il pourrait limiter la recherche à une seule boîte aux lettres ou à seulement un groupe de boîtes aux lettres aussi.
  • Accéder à la Console d'administration Exchange en tant que la personne déléguée à la découverte électronique et effectuer une recherche.
  • Observer le résultat de la recherche et copier les messages vers la boîte aux lettres dite de découverte où l'on peut examiner les messages en détail.


***

J'ouvre les propriétés du groupe Discovery Management en cliquant sur l'icône du crayon (voir la capture d'écran ci-dessus) et en ajoutant la personne qui sera chargée de la découverte électronique. Dans notre exemple, ce sera Paul York :



Il suffit de descendre jusqu'à la partie "Membres", de cliquer sur le signe " + ", de chercher l'utilisateur en question et de l'ajouter au groupe. Observons que le groupe possède les rôles "Legal Hold" et "Mailbox Search". C'est ce dernier rôle qui nous intéresse ici.


Ensuite, Paul York ouvre une session dans le CAE/EAC avec l'URL visible dans la capture d'écran ci-dessous, va à la section "gestion de la conformité" puis "découverte électronique et conservation inaltérables" où il clique sur le signe " + " pour créer une nouvelle recherche :



Note : Nous pouvons constater dans la capture d'écran ci-dessus que Paul York a moins d'options comparé à un administrateur d'organisation Exchange.

Nous donnons un nom et une description à notre recherche. Dans un autre texte, nous avons fait des essais avec SSL. C'est ce "mot-clé" que nous utiliserons pour notre recherche :



Note : nous cliquons sur "Suivant" (etc.) pour passer à l'étape suivante. Je n'insiste pas là-dessus et je cadre mes captures d'écran de sorte à se concentrer sur l'essentiel.


Nous avons l'option de chercher dans certaines boîtes aux lettres, toutes les boîtes aux lettres ou aucune (et préférer une recherche dans les dossiers publics). Dans ce cas, notre recherche portera sur toutes les boîtes aux lettres :




C'est à cette étape que nous définissons les critères de recherche. Plusieurs critères, y compris les dates, peuvent se configurer mais je me contenterai d'un simple mot-clé (SSL) : 




Je conserverai les paramètres indéfiniment :




Nous cliquons sur "Terminer" (hors le cadre de la capture d'écran ci-dessus) et la recherche est lancée. Comme mon environnement d'essai ne compte que quelques boîtes aux lettres presque vides, la recherche s'achève aussitôt : 





Nous pouvons voir une estimation des résultats de recherche :




Rien ne s'affiche et si je regarde certaines propriétés de la recherche (éléments: 0) ce n'est pas encourageant. En revanche, si je clique sur "Aperçu des résultats de recherche" :



Je vois que quatre éléments, en fait, ont été trouvés :




L'aperçu pourrait suffire à nos exigences mais si nous voulons examiner les messages de plus près, nous pouvons les copier vers une boîte aux lettres de découverte :



Il faut choisir une boîte aux lettres de découverte (ou de détection...) et puis copier les messages vers cette boîte :



Dans l'image ci-dessus, il s'agit en fait de la boîte aux lettres de découverte par défaut (Discovery Search Mailbox). Voici comment elle se présentait quand je l'ai sélectionnée plus haut : 



Quoi qu'il en soit, les messages ont été copiés vers cette boîte aux lettres et les personnes y ayant accès peuvent l'ajouter à leur profile Outlook. En tant que membre du groupe "Discovery Management", Paul York bénéficie de cet accès. Voici à quoi ressemble la disposition des messages découverts dans Outlook (2010) :




Monday, February 27, 2017

Exchange 2016 (11) : maintenance des bases de données

English summary: with Exchange 2010 SP1, the ISINTEG tool was replaced with the New-MailboxRepairRequest PowerShell cmdlet (ISINTEG should no longer be used). However, the related Get-MailboxRepairRequest (useful for observing the progression of the task) was not functional in Exchange 2010. We had to wait for later versions of Exchange, notably 2013 and 2016. Using an Exchange 2016 test environment, I take a new look at the *-MailboxRepairRequest cmdlets and review the status of another Exchange maintenance tool: ESEUTIL. In particular, I concentrate on the M* options (MH, MK, ML).

***

J'ai abordé le sujet de la maintenance des bases de données pour Exchange 2010 dans un texte du 22 novembre 2015 (en anglais) :

Exchange 2010 - ESEUTIL - ISINTEG - New-MailboxRepairRequest

A ma connaissance, rien de substantiel n'a changé depuis mais je voulais tout de même revoir ces concepts, maintenant que j'ai accès à un serveur Exchange 2016 (CU3).

Avec Exchange 2010, nous pouvions exécuter la commande New-MailboxRepairRequest (avec divers paramètres) mais nous ne pouvions pas observer le progrès de l'opération avec la commande Get-MailboxRepairRequest.

Get-MailboxRepairRequest


Voici d'autres remarques...
  • ISINTEG n'est plus une option valable depuis Exchange 2010 SP1. L'outil se trouve toujours dans le dossier \bin mais il n'a pas été mis à jour pour les bases de données Exchange 2013 et 2016. Il serait donc extrêmement risqué d'insister à utiliser cet utilitaire dépassé. De plus, il fallait démonter les bases de données avant d'exécuter cette commande, ce qui n'est pas le cas pour New-MailboxRepairRequest.
  • ESEUTIL avec les paramètres /P ou /R - Ces options ont pour objectif de réparer ou de recupérer (repair or recover) des base de données. Le risque de pertes de données est réel. Il est recommandé de ne pas utiliser ces commandes sans consulter d'abord l'assistance technique de Microsoft.
  • ESEUTIL avec le paramètre /D - Il s'agit d'une défragmentation "hors ligne" de la base de données en question. Les boîtes aux lettres ne seront pas accessibles pendant la défragmentation et celle-ci pourrait prendre beaucoup de temps selon la taille de la base de données. Par ailleurs, elle nécessite un espace libre égal à la taille de la base de données à défragmenter (et encore 10%). Au total, cette opération est de plus en plus déconseillée. Si notre environnement Exchange met en oeuvre des DAG (Database Availability Groups), il ne faut pas défragmenter les bases de données du tout. En effet, les membres du DAG reconnaissent les copies de la base de données à un numéro appelé "rand". Il faut que ce numéro soit le même pour chacune des copies d'une base de données. Or, la défragmentation crée une nouvelle base de données (avec le même nom) et déplace les boîtes aux lettres vers cette nouvelle base de données. Mais si le nom reste le même, le "rand" change et cela perturbe le fonctionnement du DAG.
  • ESEUTIL avec le paramètre /G - ce mode nous permet de vérifier si une base de données contient des incohérences. Cette vérification se fait en lecture seule et ne représente aucun risque pour la base de données. Par contre, il faut la démonter.
  • ESEUTIL avec le paramètre M (et une autre lettre : MH, ML, MK

- MH - pour voir les informations d'en-tête d'une base de données.
- ML - pour voir les informations d'en-tête d'un fichier de transaction
- MK - pour voir les informations d'en-tête d'un fichier de "checksum".

Je n'ai pas abordé cet aspect dans mon texte précédent sur ESEUTIL (voir le lien ci-dessus) et je veux me racheter ici.

Comme pour les autres commandes ESEUTIL, nous devons au préalable démonter la base de données à analyser. De plus, nous devons indiquer le chemin vers le fichier .edb ou naviguer jusqu'au fichier .edb à analyser.

Note : la base de données consiste en un fichier .edb.

Allons voir cela de plus près avec le commande ESEUTIL /MH.

Voici la base de données que nous allons analyser - MBXDB-01 :



Mais c'est à la ligne de commande que nous devons travailler.

J'ouvre donc l'invite (cmd) et après avoir navigué jusqu'à l'emplacement de la base de données, j'exécute la commande suivante :

eseutil /mh mbxdb01.edb



Qu'est-ce qui ne va pas ?

Dans la capture d'écran de l'EAC plus haut, vous avez sans doute observé que l'état de la base de données MBXDB-01 est "monté". Vous vous souvenez peut-être qu'il faut démonter les base de données avant de les manipuler avec les commandes ESEUTIL. Je vais donc démonter MBXDB-01 :

Dismount-Database MBXDB-01



Essayons la première commande à nouveau :


Nous avons mentionné un numéro qu'on appelle "rand" et qui permet aux partenaires de réplication d'identifier les bases de données qui participent à un DAG.

Ce numéro est visible dans la capture d'écran (désigné par un des points rouges).

Un autre paramètre utile à retenir est l'état de la base de données ou plutôt "state" puisqu'on garde les noms anglais.

Nous devons en tenir compte si nous effectuons une restauration de données vers un emplacement différent de l'original. Dans ce cas, l'état est normalement "Dirty Shutdown", ce qui signifie que des fichiers du journal de transaction manquent. Il faudrait alors restaurer les fichiers manquants et exécuter la commande suivante (en se fondant sur l'exemple présent) :

eseutil /r E00 /d E:\MBXDB-01 /l F:\Logs_MBXDB-01
  • Le paramètre /r signifie "recover"
  • E00 est le préfixe des fichiers de transaction. Dans le cas d'une autre base de données, il pourrait être autre chose comme E01 ou E02. Il faut regarder les fichiers du journal de transaction pour le savoir.
  • Le paramètre /d indique le chemin vers la base de données à réparer.
  • Le paramètre /l indique le chemin vers les fichiers du journal de transaction. C'est ici qu'il faut mettre les fichiers restaurés.

Et voici un exemple des paramètres ML et MK respectivement (sans autre commentaire) :




***

Et maintenant, je veux revoir les commandes New-MailboxRepairRequest et Get-MailboxRepairRequest. A la différence des commandes ESEUTIL, ces commandes n'exigent pas que la base de données soit démontée. Je vais donc remonter la base de données MBXDB-01 et exécuter quelques commandes...

Mount-Database MBXDB-01

La commande New-MailboxRepairRequest est capable de détecter et de corriger quatre types de corruption dans une boîte aux lettres spécifique ou dans toute la base de données.

Voici les quatre paramètres :

- SearchFolder
- AggregateCounts
- ProvisionedFolder
- FolderView

Si nous voulons seulement détecter des éléments endommagés, nous pouvons ajouter le paramètre -DetectOnly.

Essayons quelques exemples...

Pour commencer, analysons toute la base de données MBXDB-01 avec le paramètre -DetectOnly. J'exécute la commande de la manière suivante :

New-MailboxRepairRequest -Database MBXDB-01 -CorruptionType SearchFolder,AggregateCounts,ProvisionedFolder,FolderView -DetectOnly



J'observe le progrès de l'opération avec la commande suivante (il faut copier et coller le GUID d'où l'intérêt de la commande format-list ou "fl") :



Les valeurs possibles sont:
  • Queued
  • Running
  • Succeeded
  • Failed

A mon premier essai, l'opération semblait se coincer à l'état "Queued". Il est possible d'arrêter l'opération avec cette commande (et de recommencer) :

Get-NewMailboxRepairRequest [GUID] | Remove-NewMailboxRepairRequest

Il paraît que le démontage de la base de données arrête l'opération aussi mais cela rendrait les BAL inaccessibles.

Get-NewMailboxRepairRequest - Queued

Même pour une base de données d'essai, pratiquement vide, l'opération a mis 12 minutes pour s'achever.

Quoi qu'il en soit, l'opération termine avec succès :



Je remarque qu'Exchange analyse chaque boîte aux lettres pour chacun des types de corruption, ce qui crée de nombreuses entrées dans l'Observateur d'événements. Par exemple :



A ce sujet, il convient de préciser que, selon la documentation, l'interaction avec la boîte aux lettres risque bien de perturber l'accès pour l'utilisateur. En revanche, la base de données reste montée et seul l'accès à la BAL en cours d'analyse risque d'être perturbé. Dans l'ensemble donc, la disponibilité est tout de même meilleure qu'avec ISINTEG.

Comment savoir si des erreurs ont été détectées ? Ce n'est pas clair. Je dois supposer que la détection d'erreurs donnerait lieu à un avertissement dans l'Observateur d'événements. De plus, Get-MailboxRepairRequest contient un paramètre "Corruptions" où des erreurs seraient peut-être affichées. 

S'il y a des erreurs à réparer, nous pouvons exécuter la commande à nouveau mais sans le paramètre -DetectOnly :

New-MailboxRepairRequest -Database MBXDB-01 -CorruptionType SearchFolder,AggregateCounts,ProvisionedFolder,FolderView



Encore une fois, nous pouvons observer le progrès de l'opération avec la commande Get-MailboxRepairRequest (et limiter la sortie avec "fl jobstatus") :



Nous pouvons cibler des boîtes aux lettres spécifiques, toujours avec les même "tâches" et les mêmes options (avec ou sans le paramètre -DetectOnly).

Par exemple, nous pouvons vérifier la boîte aux lettres de Karen Roberts avec les quatre tâches et l'option -DetectOnly :

New-MailboxRepairRequest -Mailbox Karen.Roberts -CorruptionType SearchFolder,AggregateCounts,ProvisionedFolder,FolderView -DetectOnly



Si nous voulons nous concentrer sur un type spécifique de (possible) corruption, nous mettons seulement ce type-là après le paramètre -CorruptionType (avec ou sans -DetectOnly selon nos objectifs) :

New-MailboxRepairRequest -Mailbox Karen.Roberts -CorruptionType SearchFolder


Friday, February 24, 2017

Exchange 2016 (10) : DLP ou "protection contre la perte des données"

English summary : I take a first look at Exchange (2016) DLP. I create a policy, add a rule with various conditions and actions and then attempt to send a message with confidential data inside (a routable IP address). DLP detects the data in question and prevents the message from being sent. However, DLP was not successful in all the scenarios that I tested. 

***

L'objectif de DLP ("Data Loss Prevention"), ou "protection contre la perte de données" en français, est d'empêcher la divulgation de données sensibles, que ce soit par mégarde ou par malveillance. Les numéros de carte de crédit ou de sécurité sociale ne sont que deux exemples de ces données sensibles.

Note : dans la version française d'Exchange, le terme DLP est traduit par "protection contre la perte de données" mais le sigle anglais est retenu partout dans l'interface.

DLP analyse le contenu des messages en déplacement ainsi que,  le cas échéant, les pièces jointes à ces messages. Par contre, il n'examine pas les messages "au repos" dans les boîtes aux lettres.

Exchange 2016 propose une quarantaine de modèles (templates) fondés sur des exemples de données jugées sensibles dans divers pays et la législation qui les protège éventuellement. Nous pouvons aussi créer nos propres modèles et même prendre "l'empreinte" de certains types de documents et détecter leur envoi au sein du système de messagerie.

***

Comme dans mes autres textes et pour d'autres sujets, je ne vise pas ici à réécrire la documentation officielle de Microsoft mais plutôt à mettre à l'essai certains aspects de DLP. Je vais créer une stratégie DLP, l'appliquer à mon organisation (fictive), envoyer un message avec une séquence numérique mimant des données sensibles et puis examiner les actions qui peuvent se déclencher à la détection de cette séquence numérique.

Note : les critères de détection tiennent souvent compte de certains mots aussi.

Dans un premier essai, j'ai envoyé des messages avec une séquence numérique comparable à celle d'une carte de crédit mais cela n'a pas déclenché d'alerte et le message est arrivé à destination. Il paraît que DLP fait un calcul pour déterminer s'il s'agit d'un numéro de carte de crédit valable. Sinon, il laisse passer le message. Je ne voulais pas trop insister là-dessus (obligé de mener plusieurs projets de front, certains plus pressants que d'autres) et je me suis rabattu sur les adresses IP. En effet, les responsables de la sécurité informatique d'une entreprise pourraient vouloir empêcher la divulgation de ces adresses.

Voici donc les étapes de fabrication d'une stratégie DLP et les résultats de sa mise en oeuvre...


***


Dans l'EAC, nous allons à "gestion de la conformité" et puis à "protection contre la perte de données" où nous cliquons sur le signe " + " et choisissons l'option "Nouvelle stratégie DLP personnalisée" :




Je donne un nom à la stratégie, je la laisse activée (elle l'est par défaut) et je choisis le mode "Appliquer" :


Note : nous pourrions tester la stratégie avec ou sans "conseils de stratégie" ou "policy tips" en version anglaise. Ce sont en substance des "mail tips" qui s'affichent afin d'avertir que le message (ou ses pièces-jointes) contient des données sensibles. Quant à moi, je vais aller droit au but et appliquer la stratégie d'entrée de jeu. 


Cependant, la stratégie n'accomplit encore rien si je ne crée pas une règle et configure des conditions et des actions pour cette règle. A cette fin, je clique sur le signe " + "...




Et dans le menu, je choisis "Bloquer les messages dont le contenu est sensible" :




Et voilà la "nouvelle règle" à configurer. Je lui donne un nom et je décide que la règle concerne les destinataires hors de l'organisation. Encore faut-il choisir le type d'informations sensibles que nous voulons cibler :




Comme j'ai expliqué plus haut, je choisis l'adresse IP comme "type d'informations sensibles" :




Cela réglé, il nous reste à choisir une action. Je veux "bloquer le message"...



Et fournir une explication à l'utilisateur :




Je spécifie la cause du rejet :




Et voilà la nouvelle règle, configurée cette fois-ci :




Nous cliquons sur "Enregistrer" (etc.) et nous passons à la machine d'un utilisateur, Karen Roberts par exemple.

Karen ouvre Outlook (2010) et tente d'envoyer un message contenant une adresse IP à un destinataire hors de l'organisation :



Mais DLP détecte cette séquence numérique caractéristique d'une adresse IP, empêche l'envoi, et avertit l'expéditeur :



Quelques remarques :

  • La règle ne semble pas bloquer les adresses IP non-routables (comme 10.x.x.x ou 192.168.x.x).
  • DLP ne semble pas détecter la présence d'adresses IP dans les pièces-jointes. J'en ai fait l'essai avec un fichier texte contenant l'adresse 8.8.8.8 et le message est parti avec la pièce-jointe. En outre, le destinataire a bel et bien reçu le message et la pièce-jointe.
 

***

Ce qui précède est ma première expérience avec DLP. Toutes les fonctions n'ont pas réussi au premier coup, notamment la détection des numéros de carte de crédit, sans doute parce que les numéros essayés n'étaient pas valables.

Pour les lecteurs qui souhaiteraient de plus amples renseignements, je fournis les deux liens ci-dessous :


La version française de l'article ne semble pas (encore) exister mais il en existe une pour Exchange 2013 (et les concepts sont les mêmes, sinon tous les détails) :





Tuesday, February 21, 2017

Exchange 2016 (9) : MRM et archives

English summary: after a presentation of Messaging Records Management (or "MRM" for short), I create a retention policy tag that sends items older than one day to the archive, create a retention policy (to which I add the retention tag) and then apply the policy to a mailbox. Since the retention tag action is supposed to send messages to the archive, I complete the necessary pre-requisite of creating a mailbox database archive. I test the policy by running the Managed Folder Assistant manually and confirm the movement of the messages from the regular mailbox to the mailbox archive. Lastly, I send a new message to the test user and verify that we can prevent the archiving of items by the application of a personal retention tag.

***

Chaque jour, de nombreux messages s'accumulent dans les boîtes aux lettres de nos systèmes de messagerie ; les messages reçus aussi bien que les copies des messages envoyés. Après des mois et des années, la quantité des messages devient considérable. Selon notre capacité de stockage, cette accumulation de données représente un défi plus ou moins grand pour le fonctionnement efficace des systèmes que nous gérons.

Comme dans les versions précédentes d'Exchange (sous une forme ou une autre), Exchange 2016 propose la "gestion des enregistrements de messagerie", soit la traduction qu'on a faite de l'expression anglaise "messaging records management" (le plus souvent raccourci en "MRM"). 

Ce terme englobe plusieurs aspects dont les "balises" et les "stratégies" de rétention. Il s'agit de faire subir telle ou telle action à un message dans la boîte aux lettres selon l'âge du message en question. L'action pourrait consister à supprimer le message après une certaine durée ou à le déplacer vers une archive.

Dans les lignes suivantes, je vais examiner certains éléments de la gestion des enregistrements de messagerie, utilisant le raccourci "MRM" pour plus de concision. Par principe (comme pour mes autres textes), je n'ai pas l'ambition de réécrire la documentation officielle et je ne reprendrai donc que les éléments qui m'intéressent le plus. Pour une présentation complète, je renvoie le lecteur à la documentation de Microsoft :


Les traductions, parfois automatiques, sont plus ou moins bonnes. Pour ceux qui lisent l'anglais et préfèrent la version originale de l'article, je fournis ce lien aussi :



Note : On a traduit "record" par "enregistrement". Dans ce contexte précis, il s'agit de gérer les objets de messagerie, les messages en particulier, mais aussi les éléments de calendrier et les tâches. Ce sont bel et bien les objets d'origine qu'il s'agit de gérer plutôt que des enregistrements (des copies) de ces objets. J'aurais préféré la traduction "gestion des objets de messagerie", plus juste à mon avis mais aussi plus concise.


Dans notre scénario, je vais me concentrer sur les concepts de "balises" et de "stratégies" de rétention. En outre, je vais profiter de l'expérience pour explorer l'utilisation d'une base de données d'archives. Le plan d'action consiste donc à créer une stratégie de rétention qui déplace les messages âgés de plus d'un jour vers l'archive. Vous aurez compris que j'ai choisi un jour pour vérifier la bonne marche de la stratégie. En réalité, nous choisirions un délai plus raisonnable, peut-être 1 an ou 5 ans selon nos préférences.


***


Nous gérons MRM dans la section "gestion de la conformité" de l'EAC (Centre d'administation Exchange) :




MRM comporte au moins trois éléments :
  1. les balises de rétention.
  2. les stratégies de rétention
  3. les boîtes aux lettres
La balise de rétention associe une action à une certaine durée de temps, par exemple : "supprimer les messages âgés de 5 ans ou plus".

Il y a trois types de balises :
  • Les simples balises de rétention (RPT) qu'on peut appliquer aux dossiers par défaut d'une boîte aux lettres (boîte de réception, messages envoyés, etc.). RPT signifie "retention policy tag" ou "balise de stratégie de rétention".
  • Les balises personnelles mises à la disposition des utilisateurs qui ne peuvent pas les appliquer à des dossiers par défaut mais à des messages individuels.
  • Les balises de rétention par défaut (DPT). Ce genre de balise s'applique à tous les éléments "non-balisés" par une autre balise.

Quelques remarques :

  • Les balises servent surtout à gérer les messages mais peuvent aussi agir sur les autres objets de la boîte aux lettres comme les éléments de calendrier et les tâches. Cependant, les balises n'agissent pas sur les contacts.
  • Une balise de rétention devient une "balise de rétention par défaut" quand nous la désignons comme telle à sa création.
  • Exchange propose un certain nombre de balises "préfabriquées" et nous pouvons en créer d'autres nous-mêmes.

En voici quelques exemples (même dans la localisation française, les noms anglais des balises sont retenus) :




Quand nous avons choisi les balises que nous entendons mettre en oeuvre, nous associons l'ensemble de ces balises de rétention à une stratégie de rétention. Il ne peut y avoir qu'une seule balise de rétention par défaut pour chaque type d'objet : message, tâche, etc..

Note : les stratégies de rétention n'agissent pas sur les contacts.

Enfin, quand nous avons configuré notre stratégie de rétention, nous l'appliquons à des boîtes aux lettres. Si une stratégie peut comporter plusieurs balises, seule une stratégie peut s'appliquer à une boîte à lettres à un moment donné.


***


Maintenant, je vais créer quelques balises de rétention, les réunir dans une stratégie de rétention et appliquer celle-ci à une boîte aux lettres. 

Mais d'abord, comme je veux que les messages âgés de plus d'un jour soient déplacés vers une archive, je dois créer cette archive.

Dans l'EAC, je vais à la rubrique "serveurs" et puis "bases de données" où je clique sur le signe " + " pour créer une nouvelle base de données avec la configuration suivante :




Note : j'ai créé les dossiers contenant la base de données et les journaux de transaction au préalable. En outre, rien de distingue une base de données qui sert d'archive d'une autre base de données. Je n'ai pas besoin de la configurer de manière différente. Il suffit de l'utiliser comme archive. Voilà tout.

Un message s'affiche nous informant qu'il faut faire redémarrer le service "Microsoft Exchange Information Store" :


Nous avons donc notre base de données d'archive. Ensuite, nous devons activer la fonction d'archivage dans les propriétés de la boîte aux lettres d'un de nos utilisateurs (Karen Roberts, dans ce cas-ci). Parmi les paramètres du menu déroulant à droite, nous choisissons "Archive locale" et cliquons sur "Activer" :



Note : nous pouvons activer la fonction pour plusieurs BAL (ou toutes les BAL) avec PowerShell.


Nous cliquons sur "Parcourir" et nous choisissons la base de données créée pour l'archivage :



Voici nos deux choix :






Un avertissement s'affiche indiquant que personne n'a encore accédé à la boîte aux lettres d'archivage (ce qui est normal puisque nous venons de la créer) :





Si Karen Roberts ouvre Outlook, la boîte aux lettres d'archivage se trouve sous l'arborescence de la BAL "normale" : 



Maintenant, je reviens à MRM, Je vais créer une balise de rétention, une stratégie de rétention, les associer l'une à l'autre et puis associer la stratégie à la boîte aux lettres de Karen Roberts. Nous ferons en sorte que tous les messages âgés de plus d'un jour soient déplacés vers la BAL d'archivage.


***

Je reviens donc à la section "gestion de la conformité" de l'EAC et plus précisément à la section "balises de rétention" où je clique sur le signe " + " pour créer une nouvelle balise. Je veux faire de cette balise la "balise par défaut" et choisis la première option (appliqué automatiquement à l'intégralité de la boîte aux lettres (par défaut)) :



Il faut que je nomme la balise et en configure les paramètres. Les balises "préfabriquées" portent des noms anglais et dans le cas où il y aurait une raison pour cela, je donnerai aussi un nom anglais à ma nouvelle balise :



Pour le reste, l'action de rétention consiste à déplacer les messages vers les archives et la période de rétention est d'un jour. Nous avons déjà expliqué que cette période extrêmement courte nous permet de constater l'effet de l'action sans attendre une durée plus typique (1 an, 5 ans, etc.).

Note : je clique sur "enregistrer" (etc.) selon le cas. Comme dans mes autres textes, je ne précise pas ces actions de base. J'espère que les personnes à qui on confie la tâche de gérer Exchange (2016) comprendront qu'il faut cliquer sur "prochain" pour passer à l'étape suivante et ainsi de suite.

Ensuite, je dois créer une nouvelle "stratégie de rétention" qui comprendra un certain nombre de balises de rétention et qu'on assignera plus tard à la boîte aux lettres de nos utilisateurs. Dans la section "stratégies de rétention", je clique sur le signe " + " :



Et je fais le choix des balises de rétention que je veux ajouter à la stratégie :



En d'autres circonstances, nous aurions sans doute ajouté plus de balises mais il s'agit pour moi de démontrer le processus dans ses grandes lignes et sans entrer dans tous les détails. J'ai donc choisi la balise qui déplace les messages âgés d'un jour (ou plus) vers les archives et une "balise personnelle" à laquelle l'utilisateur pourrait recourir pour empêcher certains messages d'aller aux archives. Dans d'autres circonstances, nous pourrions avoir des balises personnelles qui épargnent les messages marqués avec cette balise de la suppression.

Voici donc les balises que j'ai choisies :



Note : NSR1 signifie "nouvelle stratégie de rétention (1)". Je n'ai pas pu faire preuve de plus d'imagination.

Dans les propriétés de la boîte aux lettres de nos utilisateurs, nous assignons à celle-ci la stratégie que nous avons créée :



En pratique, nous aurions recours à PowerShell pour sélectionner plusieurs BAL en même temps et y associer une stratégie de rétention.


***


Et maintenant, mettons la stratégie à l'essai...

Voici l'état de la BAL de Karen Roberts avant que notre stratégie y soit associée :



Plusieurs messages se trouvent dans la boîte de réception et même si la capture d'écran ne le montre pas, le dossier "éléments envoyés" contient aussi quelques messages. Par contre, rien ne se trouve dans l'archive de Karen Roberts :


Note : le dossier "Archive" contient des sous-dossiers mais ils sont vides aussi. Je n'ai pas pris une capture d'écran pour chaque élément de la BAL.


A cette étape de la démarche, j'étais perplexe un moment. J'avais bien appliqué la stratégie de rétention à la BAL de Karen Roberts mais rien ne se passait. Les messages dans la boîte de réception ne bougeaient pas (même après un jour) et la stratégie de rétention par défaut, plutôt que "NSR1", semblait toujours associée à la BAL de Karen Roberts.

J'ai dit plus haut que MRM comporte trois éléments : les balises de rétention, les stratégies de rétention qui réunissent un certain nombre de balises, et puis les boîtes à lettres auxquelles nous appliquons les stratégies. En fait, il y a un quatrième élément : l'Assistant de dossier géré (Managed Folder Assistant).

Que fait-il ?

Selon le document que je cite dans le lien un peu plus bas...

"L’Assistant Dossier géré est un Assistant de boîte aux lettres Exchange qui applique et traite les paramètres de rétention de messages configurés dans les stratégies de rétention."

Il ne suffit donc pas d'appliquer la stratégie de rétention à une BAL. Pour que cette association prenne effet, il faut que l'Assistant s'exécute.

En pratique, nous devons configurer un horaire pour l'exécution de l'Assistant. La commande ci-dessous montre qu'aucun horaire n'a encore été configuré :


Ce document nous guide dans la configuration d'un horaire :


Pour cette expérience, je vais déclencher l'exécution manuelle de l'Assistant avec la commande suivante :



Si nous retournons à la BAL de Karen Roberts, les différences sont faciles à constater.

Il ne reste plus aucun message dans la boîte de réception :



Il en va de même pour les éléments envoyés mais je n'ai pas de capture d'écran pour cela (il faut me faire confiance).

En revanche, les messages se retrouvent dans l'Archive de Karen Roberts, visible dans Outlook et organisée en une arborescence de dossiers similaire à celle de la boîte à lettres de base :




L'application de la stratégie de rétention a donc réussi.


***


Je vais mettre encore un aspect de la stratégie à l'essai. Nous avons ajouté une balise dite "personnelle" que l'utilisateur peut appliquer à des messages qu'il veut garder dans la boîte à lettres et donc empêcher de partir pour l'Archive. Essayons d'appliquer cette balise et d'exécuter l'Assistant de dossier géré juste après afin d'en vérifier la bonne marche.

Mark Patel envoie donc un nouveau message à Karen Roberts :



Karen Roberts affiche les options pour le message et choisit "Assign Policy | Never"



Note : je disposais d'un client Windows 7 en anglais que j'ai utilisé pour cette expérience, d'où la différence de langue.

Nous pouvons vérifier que le message a été marqué avec la balise "Never" :




Et maintenant, je déclenche l'exécution manuelle de l'Assistant (comme avant) :




Le message de Mark Patel reste dans la boîte de réception bien qu'il soit âgé de deux jours (c'est une précision que j'ajoute - ce n'est pas évident dans la capture d'écran qui suit) :



***

Et cela met fin à ce survol de la "gestion des enregistrements de messagerie" que j'aurais appelé plutôt la "gestion des objets de messagerie".