Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Les administrateurs ont souvent besoin de savoir qui savait quoi et quand. Ils doivent répondre aux demandes concernant les litiges en cours ou potentiels, les enquêtes internes et d’autres scénarios de la manière la plus efficace possible. Ces demandes sont souvent urgentes, impliquent plusieurs équipes de parties prenantes et ont un impact significatif si elles ne sont pas effectuées en temps voulu. Il est essentiel de savoir comment trouver les informations appropriées pour permettre aux administrateurs d’effectuer correctement les recherches et d’aider leurs organisations à gérer les risques et les coûts associés aux exigences d’eDiscovery.
Pour en savoir plus sur la recherche de contenu dans les boîtes aux lettres dans eDiscovery, regardez la vidéo suivante :
Conseil
Bien démarrer avec Microsoft Security Copilot pour explorer de nouvelles façons de travailler plus intelligemment et plus rapidement à l’aide de la puissance de l’IA. En savoir plus sur Microsoft Security Copilot dans Microsoft Purview.
Lorsqu’une demande eDiscovery est envoyée, les administrateurs reçoivent souvent uniquement des informations partielles pour commencer à collecter du contenu susceptible d’être lié à une investigation particulière. La demande peut inclure des noms d’utilisateur, des titres de projet, des plages de dates approximatives lorsque le projet était actif, et pas beaucoup plus. À partir de ces informations, les administrateurs doivent créer des requêtes pour trouver du contenu pertinent dans les services Microsoft 365 afin de déterminer les informations nécessaires pour un projet ou un sujet particulier. Comprendre comment les informations sont stockées et gérées pour ces services aide les administrateurs à trouver plus efficacement ce dont ils ont besoin rapidement et de manière efficace.
Exchange Online stocke les e-mails, les conversations, les réunions et les données d’activité Microsoft 365 Copilot et Microsoft 365 Copilot Chat (invites utilisateur et réponses Copilot). De nombreuses propriétés de communication sont disponibles pour la recherche d’éléments inclus dans Exchange Online. Certaines propriétés telles que From, Sent, Subject et To sont propres à certains éléments et ne sont pas pertinentes lors de la recherche de fichiers ou de documents dans SharePoint et OneDrive. L’inclusion de ces types de propriétés lors de la recherche entre les charges de travail peut parfois entraîner des résultats inattendus.
Par exemple, pour rechercher du contenu lié à des utilisateurs spécifiques (Utilisateur 1 et Utilisateur 2), associé à un projet appelé Tradewinds, et entre janvier 2020 et janvier 2022, vous pouvez utiliser une requête avec les propriétés suivantes :
- Ajouter les emplacements Exchange Online de l’utilisateur 1 et de l’utilisateur 2 en tant que sources de données au cas
- Sélectionnez Les emplacements Exchange Online de l’utilisateur 1 et de l’utilisateur 2 comme source de données.
- Pour Mot clé, utilisez Tradewinds
- Pour Plage de dates, utilisez la plage du 1er janvier 2020 au 31 janvier 2022
Lors de la recherche d’e-mails ou d’autres contenus de boîte aux lettres pouvant inclure des pièces jointes cloud, le lien de pièce jointe cloud vers un emplacement de stockage dans SharePoint ou OneDrive doit être considéré comme des pièces jointes du fichier message plutôt que comme des documents distincts.
Ce comportement est similaire à la façon dont une recherche retourne des e-mails avec des pièces jointes locales incorporées. Ces pièces jointes sont récupérées comme si elles faisaient partie des e-mails. Les limites de conformité pour SharePoint ou OneDrive ne sont pas reflétées dans la collection de pièces jointes cloud incluses dans les messages réactifs.
Importante
Pour les e-mails, lorsque vous utilisez un mot clé, la recherche inclut l’objet, le corps et de nombreuses propriétés liées aux participants. Toutefois, en raison de l’expansion du destinataire, la recherche peut ne pas retourner les résultats attendus lors de l’utilisation de l’alias ou d’une partie de l’alias. Par conséquent, utilisez l’UPN complet.
Propriétés d’e-mail pouvant faire l’objet d’une recherche dans KeyQL
Importante
Bien que les e-mails puissent avoir d’autres propriétés prises en charge dans d’autres services Microsoft 365, les outils de recherche eDiscovery prennent uniquement en charge les propriétés d’e-mail répertoriées dans ce tableau. Vous ne pouvez pas inclure d’autres propriétés de message électronique dans les recherches.
Le tableau suivant répertorie les propriétés de message électronique prises en charge dans la recherche à l’aide de l’éditeur de KeyQL eDiscovery dans le portail Microsoft Purview ou à l’aide des applets de commande New-ComplianceSearch ou Set-ComplianceSearch. Pour obtenir la liste des propriétés du générateur de conditions prises en charge, consultez Utiliser le générateur de conditions pour créer des requêtes de recherche dans eDiscovery.
Le tableau inclut un exemple de la syntaxe property :value pour chaque propriété et une description des résultats de recherche retournés par les exemples. Vous pouvez entrer ces property:value paires dans la zone mots clés pour une recherche eDiscovery.
Remarque
Lorsque vous recherchez des propriétés d’e-mail, vous ne pouvez pas rechercher d’en-têtes de message. Les informations d’en-tête ne sont pas indexées pour les recherches. En outre, vous ne pouvez pas rechercher les éléments dans lesquels la propriété spécifiée est vide ou vide. Par exemple, l’utilisation de la paire property :value de subject :" » pour rechercher des messages électroniques avec une ligne d’objet vide retourne zéro résultat. Cette limitation s’applique également lors de la recherche de propriétés de site et de contact.
| Propriété | Description de la propriété | Exemples | Résultats de recherche renvoyés par les exemples |
|---|---|---|---|
| AttachmentNames | Nom des fichiers joints à un message électronique. | attachmentnames:annualreport.ppt |
Messages qui ont un fichier joint nommé annualreport.ppt. Dans le deuxième exemple, l’utilisation du caractère générique ( * ) retourne des messages avec le mot annual dans le nom de fichier d’une pièce jointe. 1 |
| Cci | Champ Cci d’un e-mail. 1 | bcc:pilarp@contoso.com |
Tous les exemples retournent des messages avec Pilar Pinilla inclus dans le champ Cci. (Voir Extension de destinataire) |
| Catégorie | Catégories à rechercher. Les utilisateurs peuvent définir des catégories à l’aide d’Outlook ou d’Outlook sur le web (anciennement Outlook Web App). Les valeurs possibles sont les suivantes :
|
category:"Red Category" |
Messages auxquels la catégorie rouge est affectée dans les boîtes aux lettres sources. |
| Cc | Champ Cc d’un e-mail. 1 | cc:pilarp@contoso.com |
Dans les deux exemples, les messages avec Pilar Pinilla spécifiés dans le champ Cc. (Voir Extension de destinataire) |
| From | Expéditeur d'un message électronique.1 | from:pilarp@contoso.com |
Messages envoyés par l’utilisateur spécifié. (Voir Extension de destinataire) |
| HasAttachment | Indique si un message contient une pièce jointe. Utilisez les valeurs true ou false. | from:pilar@contoso.com AND hasattachment:true |
Messages envoyés par l’utilisateur spécifié qui ont des pièces jointes. |
| Importance | Importance d'un message électronique, que l'expéditeur peut préciser lors de l'envoi. Par défaut, les messages sont envoyés avec une importance normale, à moins que l'expéditeur préfère une importance haute ou faible. | importance:high |
Messages marqués comme ayant une importance haute, normale ou faible. |
| IsRead | Indique si les messages sont lus. Utilisez les valeurs true ou false. | isread:true |
Le premier exemple retourne des messages avec la propriété IsRead définie sur True. Le deuxième exemple retourne des messages avec la propriété IsRead définie sur False. |
| ItemClass | Utilisez cette propriété pour rechercher des types de données tiers spécifiques que votre organization importé dans Office 365. Utilisez la syntaxe suivante pour cette propriété : itemclass:ipm.externaldata.<third-party data type>* |
itemclass:ipm.externaldata.Facebook* AND subject:contoso |
Le premier exemple retourne Facebook éléments qui contiennent le mot « contoso » dans la propriété Subject. Le deuxième exemple renvoie des éléments Twitter qui ont été publiés par Ann Beebe et qui contiennent l’expression mot clé « Northwind Traders ». |
| Kind | Type de message électronique à rechercher. Valeurs possibles : contacts docs externaldata faxes im journals meetings microsoftteams (retourne des éléments à partir de conversations, de réunions et d’appels dans Microsoft Teams) notes posts rssfeeds tasks voicemail |
kind:email |
Le premier exemple retourne des messages électroniques qui répondent aux critères de recherche. Le deuxième exemple renvoie les messages électroniques, les conversations de messagerie instantanée (y compris les conversations Skype Entreprise et les conversations dans Microsoft Teams) et les messages vocaux qui répondent aux critères de recherche. Le troisième exemple retourne des éléments qui ont été importés dans des boîtes aux lettres dans Microsoft 365 à partir de sources de données tierces, telles que Twitter, Facebook et Cisco Jabber qui répondent aux critères de recherche. Pour plus d’informations, consultez Archivage de données tierces dans Office 365. |
| Participants | Tous les champs de personnes dans un e-mail. Ces champs sont From, To, Cc et Bcc.1 | participants:garthf@contoso.com |
Messages envoyés par ou envoyés à garthf@contoso.com. Le deuxième exemple renvoie tous les messages envoyés à ou par un utilisateur du domaine contoso.com. (Voir Extension de destinataire) |
| Received | Date de réception d’un e-mail par un destinataire. | received:2021-04-15 |
Messages reçus le 15 avril 2021. Le deuxième exemple retourne tous les messages reçus entre le 1er janvier 2021 et le 31 mars 2021. |
| Recipients | Tous les champs de destinataire dans un e-mail. Ces champs sont To, Cc et Bcc.1 | recipients:garthf@contoso.com |
Messages envoyés à garthf@contoso.com. Le deuxième exemple renvoie les messages envoyés à tous les destinataires du domaine contoso.com. (Voir Extension de destinataire) |
| Sent | Date à laquelle un e-mail est envoyé par l’expéditeur. | sent:2021-07-01 |
Messages envoyés à la date spécifiée ou dans la plage de dates spécifiée. |
| Taille | Taille d'un élément, en octets. | size>26214400 |
Messages de plus de 25 Mo. Le deuxième exemple renvoie les messages dont la taille est comprise entre 1 et 1 048 567 octets (1 Mo). |
| Sujet | Texte de la ligne d’objet d’un message électronique.
Note: Lorsque vous utilisez la propriété Subject dans une requête, la recherche renvoie tous les messages dans lesquels la ligne d’objet contient le texte que vous recherchez. En d’autres termes, la requête ne retourne pas uniquement les messages qui ont une correspondance exacte. Par exemple, si vous recherchez |
subject:"Quarterly Financials" |
Messages qui contiennent l’expression « Quarterly Financials » n’importe où dans le texte de la ligne d’objet. Le deuxième exemple renvoie tous les messages contenant le mot « northwind » dans la ligne d'objet. |
| To | Champ À d'un message électronique.1 | to:annb@contoso.com |
Tous les exemples renvoient les messages dans lesquels « Ann Beebe » est indiqué sur la ligne À. |
Remarque
1 Pour la valeur d’une propriété de destinataire, vous pouvez utiliser l’adresse e-mail (également appelée nom d’utilisateur principal), le nom d’affichage ou l’alias pour spécifier un utilisateur. Par exemple, vous pouvez utiliser annb@contoso.com, annb ou « Ann Beebe » pour spécifier l’utilisateur Ann Beebe.
Types de données sensibles utilisables dans une requête
Vous pouvez utiliser les outils de recherche eDiscovery dans le portail Microsoft Purview pour rechercher des données sensibles, telles que des numéros de carte de crédit ou de sécurité sociale, stockées dans des documents dans des boîtes aux lettres. Pour ce faire, utilisez la SensitiveType propriété et le nom (ou l’ID) d’un type d’informations sensibles dans une requête mot clé. Par exemple, la requête SensitiveType:"Credit Card Number" retourne des documents qui contiennent un numéro de carte de crédit. La requête SensitiveType:"U.S. Social Security Number (SSN)" retourne des documents qui contiennent un numéro de sécurité sociale américain.
Pour afficher la liste des types d’informations sensibles que vous pouvez rechercher, accédez à Classifications> de donnéesTypes d’informations sensibles dans le portail Microsoft Purview. Vous pouvez également utiliser l’applet de commande Get-DlpSensitiveInformationType dans Security & Compliance PowerShell pour afficher la liste des types d’informations sensibles.
Extension du destinataire
Les boîtes aux lettres sont un stockage flexible, et les clients qui se connectent à une boîte aux lettres contrôlent certains aspects des informations de destinataire, en particulier pour l’expéditeur. Les clients peuvent choisir les propriétés SMTP, Name ou LegacyDN comme adresse de l’expéditeur. Pour compenser les variations dans le comportement du client et la façon dont les données sont stockées, l’extension de destinataire de la recherche eDiscovery est une fonctionnalité utile.
Souvent, les informations d’expéditeur créées par certains clients stockent uniquement le nom de l’expéditeur, par exemple John Doe, sans inclure l’adresse SMTP comme johndoe@contoso.com. En outre, les éléments fédérés avec des systèmes hérités peuvent uniquement stocker le legacyExchangeDN, qui est un identificateur unique utilisé dans les versions antérieures d’Exchange pour représenter une boîte aux lettres ou une liste de distribution. Les systèmes fédérés font référence à des messages ou des données intégrés à partir de différents systèmes ou organisations, impliquant souvent des systèmes hérités qui utilisent des formats ou des identificateurs plus anciens.
La fonction d’extension de destinataire résout le problème de l’insétérité de la recherche en développant la recherche pour capturer le contenu stocké avec ces variantes. L’interrogation de l’ID de Microsoft Entra développe toutes les valeurs spécifiées dans le filtre de participant. Cette extension inclut l’adresse e-mail, l’UPN, l’alias, le nom d’affichage et LegacyExchangeDN de l’utilisateur. Cette extension garantit que les recherches sont plus larges, en capturant tout le contenu pertinent, quelle que soit la façon dont les informations des participants sont stockées, et améliore la précision et l’exhaustivité des recherches eDiscovery.
Remarque
L’extension de destinataire ne résout pas les cas où l’utilisateur quitte et n’est plus présent dans Microsoft Entra ID. Dans ce scénario, le système ne peut pas développer l’identité pour inclure des variantes telles que UPN, alias ou LegacyExchangeDN. Pour garantir des résultats de recherche complets, vous devez inclure manuellement tous les identificateurs connus (par exemple, adresses SMTP, alias ou noms d’affichage précédents) pour l’utilisateur parti dans votre requête.
Lorsque vous recherchez l’une des propriétés du destinataire (From, To, Cc, Cci, Participants et Recipients), Microsoft 365 tente de développer l’identité de chaque utilisateur en le recherchant dans Microsoft Entra’ID. Si l’utilisateur se trouve dans Microsoft Entra’ID, la requête est développée pour inclure l’adresse de messagerie (ou UPN) de l’utilisateur, son alias, son nom d’affichage et legacyExchangeDN. Par exemple, une requête telle que participants:ronnie@contoso.com se développe en participants:ronnie@contoso.com OR participants:ronnie OR participants:"Ronald Nelson" OR participants:"<LegacyExchangeDN>".
Pour empêcher l’expansion du destinataire, ajoutez un caractère générique (astérisque) à la fin de l’adresse e-mail et utilisez un nom de domaine réduit ; Par exemple, participants:"ronnie@contoco*" veillez à entourer l’adresse e-mail de guillemets doubles.
En empêchant l’expansion du destinataire dans la requête de recherche, les éléments pertinents ne sont pas retournés dans les résultats de la recherche. Email messages dans Exchange peuvent être enregistrés avec différents formats de texte dans les champs du destinataire. L’extension de destinataire est destinée à atténuer ce fait en renvoyant des messages qui peuvent contenir des formats de texte différents. Par conséquent, si vous empêchez l’expansion du destinataire, la requête de recherche ne retourne pas tous les éléments susceptibles d’être pertinents pour votre investigation.
L’extension de destinataire n’est pas conçue pour prendre en charge les scénarios impliquant des modifications de nom d’utilisateur et d’alias. Si le SMTP/UPN d’un utilisateur change, Microsoft Entra’ID risque de ne pas trouver l’utilisateur, ce qui entraîne des résultats de recherche incomplets. En outre, LegacyExchangeDN, qui change rarement, peut ne pas être présent dans le substrat pour tous les éléments de courrier électronique. L’extension de destinataire gère uniquement les cas où le client utilise LegacyExchangeDN au lieu de SMTP. Si l’adresse SMTP change, contrairement à LegacyExchangeDN, l’extension de destinataire n’aide pas et vous devez rechercher et utiliser manuellement toutes les variantes de ces adresses. Cette limitation peut amener les utilisateurs à croire à tort que l’extension de destinataire intercepte toutes les variantes, y compris les modifications de nom et SMTP.
Lorsque vous utilisez la condition From avec la condition égale (=), seul le nom d’affichage peut être interrogé dans l’index. Cela signifie que si vous utilisez une adresse SMTP dans les conditions From ou Sender , la recherche retourne un résultat si les deux conditions suivantes sont remplies :
- L’adresse SMTP utilisée dans la condition correspond à un utilisateur actif ou inactif dans Microsoft Entra.
- Le nom d’affichage de l’utilisateur actif ou inactif n’a pas changé depuis l’envoi ou la réception de l’élément ciblé.
Lorsque vous utilisez les conditions Sender ou From dans une recherche eDiscovery, le système tente d’étendre le destinataire et développe la requête pour inclure le nom d’affichage. Si elle réussit, la requête inclut toutes les adresses e-mail affectées à l’adresse SMTP de l’utilisateur et au nom d’affichage Exchange hérité. Si l’expansion du destinataire échoue, la recherche utilise uniquement la valeur fournie dans les conditions De et Expéditeur pour rechercher l’index. Les conditions qui peuvent entraîner l’échec de l’expansion du destinataire sont les suivantes :
- Utilisateurs quittés sans boîte aux lettres inactive conservée.
- Utilisateurs actifs ou inactifs où l’adresse SMTP n’est plus présente sur un objet.
- Utilisateurs actifs ou inactifs pour lesquels le nom d’affichage a été modifié (lorsque le nom d’affichage est utilisé avec les conditions Expéditeur ou De ).
Dans certains scénarios, l’extension de destinataire peut également provoquer des accès sur des éléments supplémentaires lorsque organization recherches sont utilisées. Par exemple, le nom d’affichage d’un utilisateur peut faire partie du nom d’affichage d’un autre utilisateur. Par exemple, un utilisateur peut avoir un nom d’affichage John Doe et un autre utilisateur peut avoir un nom d’affichage de John Doe Jr. Une recherche à l’échelle organization peut renvoyer des résultats à partir des deux boîtes aux lettres. Envisagez de supprimer l’expansion du destinataire dans ce scénario en ajoutant un point à la fin de l’adresse SMTP.
Parmi les autres considérations à prendre en compte, l’extension de destinataire prend uniquement en charge l’envoi à partir de votre propre boîte aux lettres et aucune activité déléguée ou d’envoi en tant que. Veillez à passer en revue les limites pertinentes, notamment la précision du nombre maximal de membres du groupe de distribution et le niveau maximal d’imbrication pour les groupes de distribution. Les groupes de sécurité sont pris en charge, et seuls les groupes de distribution et le groupe de distribution doivent être valides lors de l’envoi de l’e-mail.
Remarque
Si vous avez besoin d’examiner ou de réduire les éléments retournés par une requête de recherche en raison de l’expansion du destinataire, envisagez d’utiliser les fonctionnalités eDiscovery Premium. Vous pouvez rechercher des messages (en tirant parti de l’extension des destinataires), les ajouter à un jeu de révision, puis utiliser des requêtes ou des filtres d’ensemble de révision pour examiner ou affiner les résultats.
Contenu stocké dans des boîtes aux lettres Exchange Online pour eDiscovery
Vous utilisez principalement une boîte aux lettres dans Exchange Online pour stocker les éléments liés aux e-mails tels que les messages, les éléments de calendrier, les tâches et les notes. Mais cela change, car de plus en plus d’applications basées sur le cloud stockent également leurs données dans la boîte aux lettres d’un utilisateur. L’un des avantages du stockage des données dans une boîte aux lettres est que vous pouvez utiliser les outils de recherche dans eDiscovery pour rechercher, afficher et exporter les données à partir de ces applications cloud.
Les données de certaines de ces applications sont stockées dans des dossiers masqués situés dans une sous-arborescence de message non-personnel (non-IPM) dans la boîte aux lettres. Les données d’autres applications cloud peuvent ne pas être stockées dans la boîte aux lettres, mais elles sont associées à la boîte aux lettres et sont retournées dans les recherches si ces données correspondent à la requête de recherche. Que les données basées sur le cloud soient stockées ou associées à une boîte aux lettres utilisateur, les données ne sont généralement pas visibles dans un client de messagerie lorsqu’un utilisateur ouvre sa boîte aux lettres.
Le tableau suivant répertorie les applications qui stockent ou associent des données à une boîte aux lettres basée sur le cloud. Le tableau décrit également le type de contenu produit par chaque application.
| Application Microsoft 365 | Description |
|---|---|
| Planification des classes | Les plans que vous créez dans planification de classes sont stockés dans la boîte aux lettres du groupe Microsoft 365 correspondant qui est provisionné lorsque vous créez un plan. L’alias de la boîte aux lettres de groupe est le nom du plan. |
| Formulaires* | Forms et les réponses à un formulaire sont stockées dans des fichiers joints à des messages électroniques et stockés dans un dossier masqué de la boîte aux lettres de l’utilisateur qui a créé le formulaire. Forms créées avant avril 2020 sont stockées sous forme de fichier PDF. Forms créées après 2020 sont stockées sous forme de fichier JSON. Les réponses à un formulaire sont stockées dans un fichier CSV. Lorsque vous exportez du contenu à partir de Forms dans un fichier PST, ces données se trouvent dans le dossier ApplicationDataRoot dans un sous-dossier nommé avec le GUID (global unique identifié) suivant : c9a559d2-7aab-4f13-a6ed-e7e9c52aec87. |
| Microsoft 365 Copilot et Microsoft 365 Copilot Chat | Toutes les données d’activité Copilot (invites utilisateur et réponses Copilot) générées dans les applications et services Microsoft 365 pris en charge sont stockées dans les boîtes aux lettres du consignataire. |
| Groupes Microsoft 365 | Email messages, éléments de calendrier, contacts (Personnes), notes et tâches sont stockés dans la boîte aux lettres associée à un groupe Microsoft 365. |
| Outlook/Exchange Online | Email les messages, les éléments de calendrier, les contacts (Personnes), les notes et les tâches sont stockés dans la boîte aux lettres d’un utilisateur. |
| Personnes | Les contacts de l’application Personnes (qui sont les mêmes que ceux accessibles dans Outlook) sont stockés dans la boîte aux lettres d’un utilisateur. |
| Skype Entreprise | Les conversations dans Skype Entreprise sont stockées dans le dossier Historique des conversations de la boîte aux lettres d’un utilisateur. Si la boîte aux lettres d’un participant à une réunion Skype est placée en attente pour litige ou affectée à une stratégie de rétention, les fichiers joints à une réunion sont conservés dans la boîte aux lettres des participants. |
| Sway* | Les Sways sont stockés sous la forme d’un fichier HTML joint à un e-mail et stockés dans un dossier masqué dans la boîte aux lettres de l’utilisateur qui a créé le sway. Lorsque vous exportez du contenu à partir de Sway dans un fichier PST, ces données se trouvent dans le dossier ApplicationDataRoot dans un sous-dossier nommé avec le GUID suivant : 905fcf26-4eb7-48a0-9ff0-8dcc7194b5ba. |
| Tâches | Les tâches de l’application Tâches (qui sont les mêmes que celles accessibles dans Outlook) sont stockées dans la boîte aux lettres d’un utilisateur. |
| Teams | Les conversations qui font partie d’un canal Teams sont associées à la boîte aux lettres Teams. Les conversations qui font partie de la liste des conversations dans Teams (également appelées 1 x N conversations) sont associées à la boîte aux lettres des utilisateurs qui participent à la conversation. En outre, les informations récapitulatives pour les réunions et les appels dans un canal Teams sont associées aux boîtes aux lettres des utilisateurs qui se sont connectés à la réunion ou à l’appel. Par conséquent, lors de la recherche de contenu Teams, vous recherchez dans la boîte aux lettres Teams du contenu dans les conversations de canal et recherchez dans les boîtes aux lettres des utilisateurs du contenu dans 1 x N conversations. |
| À faire | Les tâches ( appelées tâches, qui sont enregistrées dans des listes de tâches) dans l’application To-Do sont stockées dans la boîte aux lettres d’un utilisateur. |
| Viva Engage | Les conversations et les commentaires au sein d’une communauté Viva Engage sont associés à la boîte aux lettres de groupe Microsoft 365, ainsi qu’à la boîte aux lettres utilisateur de l’auteur et des destinataires nommés (utilisateurs @ mentionnés ou cc). Les messages privés envoyés en dehors d’une communauté Viva Engage sont stockés dans la boîte aux lettres des utilisateurs qui participent au message privé. |
Remarque
* À ce stade, si vous placez une conservation sur une boîte aux lettres à l’aide de conservations dans les cas eDiscovery, la conservation ne conserve pas le contenu de cette application.