Keyword queries and search conditions for eDiscovery

This article describes the properties available to help find content across email and chat in Exchange Online and documents and files stored on SharePoint and OneDrive for Business using the eDiscovery search tools in the Microsoft Purview compliance portal.

This includes Content search, Microsoft Purview eDiscovery (Standard), and Microsoft Purview eDiscovery (Premium) (eDiscovery searches in eDiscovery (Premium) are called collections). You can also use the *-ComplianceSearch cmdlets in Security & Compliance PowerShell to search for these properties.

This article also describes:

• Using Boolean search operators, search conditions, and other search query techniques to refine your search results.
• Searching for communications of various types related to specific employees and projects during a specific time frame.
• Searching for site content that is related to a specific project, employees and/or subjects during a specific time period.

For step-by-step instructions on how to create different eDiscovery searches, see:

• Content search
• Search for content in eDiscovery (Standard)
• Create a collection estimate in eDiscovery (Premium)

Search tips and tricks

• The time zone for all searches is Coordinated Universal Time (UTC). Changing time zones for your organization isn't currently supported. Time zone display settings in the search view are only for applicable for values in Data column and don't affect time stamps on collected items.
• Keyword searches aren't case-sensitive. For example, cat and CAT return the same results.
• The Boolean operators AND, OR, NOT, and NEAR must be uppercase.
• Using quotes stops wild cards and any operations inside the quotes.
• A space between two keywords or two property:value expressions is the same as using OR. For example, from:"Sara Davis" subject:reorganization returns all messages sent by Sara Davis or messages that contain the word reorganization in the subject line. However, using a mix of spaces and OR conditionals in a single query may lead to unexpected results. We recommend using either spaces or OR in a single query.
• Use syntax that matches the property:value format. Values aren't case-sensitive, and they can't have a space after the operator. If there's a space, your intended value is a full-text search. For example to: pilarp searches for "pilarp" as a keyword, rather than for messages sent to pilarp.
• When searching a recipient property, such as To, From, Cc, or Recipients, you can use an SMTP address, alias, or display name to denote a recipient. For example, you can use [email protected], pilarp, or "Pilar Pinilla."
• You can use only prefix searches; for example, cat* or set*. Suffix searches (*cat), infix searches (c*t), and substring searches (*cat*) aren't supported.
• When searching a property, use double quotation marks (" ") if the search value consists of multiple words. For example, subject:budget Q1 returns messages that contain budget in the subject line and that contain Q1 anywhere in the message or in any of the message properties. Using subject:"budget Q1" returns all messages that contain budget Q1 anywhere in the subject line.
• To exclude content marked with a certain property value from your search results, place a minus sign (-) before the name of the property. For example, -from:"Sara Davis" excludes any messages sent by Sara Davis.
• You can export items based on message type. For example, to export Skype conversations and chats in Microsoft Teams, use the syntax kind:im. To return only email messages, you would use kind:email. To return chats, meetings, and calls in Microsoft Teams, use kind:microsoftteams.
• When searching sites, you have to add the trailing / to the end of the URL when using the path property to return only items in a specified site. If you don't include the trailing /, items from a site with a similar path name are also returned. For example, if you use path:sites/HelloWorld then items from sites named sites/HelloWorld_East or sites/HelloWorld_West would also be returned. To return items only from the HelloWorld site, you have to use path:sites/HelloWorld/.
• The Query language-country/region must be defined in your search query prior to collecting content.
• When searching the Sent folders for emails, using the SMTP address for the sender isn't supported. Items in the Sent folder contain only display names.

Finding content in Exchange Online

Admins are often charged with finding out who knew what when in the most efficient and effective way possible to respond to requests concerning ongoing or potential litigation, internal investigations, and other scenarios. These requests are often urgent, involve multiple stakeholder teams, and have significant impact if not completed in a timely manner. Knowing how to find the right information is critical for admins to complete searches successfully and help their organizations to manage the risk and cost associated with eDiscovery requirements.

When an eDiscovery request is submitted, often there's only partial information available for the admin to start to collect content that may be related to a particular investigation. The request may include employee names, project titles, rough date ranges when the project was active, and not much more. From this information, the admin needs to create queries to find relevant content across Microsoft 365 services to determine the information needed for a particular project or subject. Understanding how information is stored and managed for these services help admins more efficiently find what they need quickly and in an effective manner.

Email, chat, meeting, and Microsoft 365 Copilot and Microsoft Copilot activity data (user prompts and Copilot responses) are all stored in Exchange Online. Many communication properties are available for searching items included in Exchange Online. Some properties such as From, Sent, Subject, and To are unique to certain items and aren't relevant when searching for files or documents in SharePoint and OneDrive for Business. Including these types of properties when searching across workloads can sometimes lead to unexpected results.

For example, to find content related to specific employees (User 1 and User 2), associated with a project called Tradewinds, and during January 2020 through January 2022, you might use a query with the following properties:

• Add User 1 and User 2's Exchange Online locations as data sources to the case
• Select User 1 and User 2's Exchange Online locations as collection locations
• For Keyword, use Tradewinds
• For Date Range, use the January 1, 2020 to January 31, 2022 range

Searchable email properties

The following table lists the email message properties that can be searched by using the eDiscovery search tools in the compliance portal or by using the New-ComplianceSearch or the Set-ComplianceSearch cmdlet.

The table includes an example of the property:value syntax for each property and a description of the search results returned by the examples. You can enter these property:value pairs in the keywords box for an eDiscovery search.

Recipient expansion

When searching any of the recipient properties (From, To, Cc, Bcc, Participants, and Recipients), Microsoft 365 attempts to expand the identity of each user by looking them up in Microsoft Entra ID. If the user is found in Microsoft Entra ID, the query is expanded to include the user's email address (or UPN), alias, display name, and LegacyExchangeDN. For example, a query such as participants:[email protected] expands to participants:[email protected] OR participants:ronnie OR participants:"Ronald Nelson" OR participants:"<LegacyExchangeDN>".

To prevent recipient expansion, add a wild card character (asterisk) to the end of the email address and use a reduced domain name; for example, participants:"ronnie@contoso*" Be sure to surround the email address with double quotation marks.

However, be aware that preventing recipient expansion in the search query may result in relevant items not being returned in the search results. Email messages in Exchange can be saved with different text formats in the recipient fields. Recipient expansion is intended to help mitigate this fact by returning messages that may contain different text formats. So preventing recipient expansion may result in the search query not returning all items that may be relevant to your investigation.

Finding content in SharePoint and OneDrive

When searching for documents and files located in SharePoint or OneDrive for Business, it may make sense to adjust the query approach based on the metadata for the documents and files of interest. Files and documents have relevant properties like Author, Created, CreatedBy, FileName, LastModifiedTime, and Title. Most of these proprieties aren't relevant when searching for communications content in Exchange Online, and using these properties may lead to unexpected results if used across both documents and communications. Additionally, FileName and Title of a document may not be the same and using one or the other to try to find a file with specific content may lead to different or inaccurate results. Keep these properties in mind when searching for specific document and file content in SharePoint and OneDrive for Business.

For example, to find content related to documents created by User 1, for a project called Tradewinds, for specific files named Financials, and from January 2020 to January 2022, you might use a query with the following properties:

• Add User 1's OneDrive for Business site as a data sources to the case
• Select User 1's OneDrive for Business site as a collection location
• Add additional SharePoint site locations related to the project as collection locations
• For FileName, use Financials
• For Keyword, use Tradewinds
• For Date Range, use the January 1, 2020 to January 31, 2022 range

Searchable site properties

The following table lists the SharePoint and OneDrive for Business properties that can be searched by using the eDiscovery search tools in the Microsoft Purview compliance portal or by using the New-ComplianceSearch or the Set-ComplianceSearch cmdlet.

The table includes an example of the property:value syntax for each property and a description of the search results returned by the examples.

Searchable contact properties

The following table lists the contact properties that are indexed and that you can search for using eDiscovery search tools. These are the properties that are available for users to configure for the contacts (also called personal contacts) that are located in the personal address book of a user's mailbox. To search for contacts, you can select the mailboxes to search and then use one or more contact properties in the keyword query.

Search operators

Boolean search operators, such as AND, OR, and NOT, help you define more-precise searches by including or excluding specific words in the search query. Other techniques, such as using property operators (such as >= or ..), quotation marks, parentheses, and wildcards, help you refine a search query. The following table lists the operators that you can use to narrow or broaden search results.

Search conditions

You can add conditions to a search query to narrow a search and return a more refined set of results. Each condition adds a clause to the KQL search query that is created and run when you start the search.

• Conditions for common properties
• Conditions for mail properties
• Conditions for document properties
• Operators used with conditions
• Guidelines for using conditions
• Examples of using conditions in search queries

Conditions for common properties

Create a condition using common properties when searching mailboxes and sites in the same search. The following table lists the available properties to use when adding a condition.

Conditions for mail properties

Create a condition using mail properties when searching mailboxes or public folders in Exchange Online. The following table lists the email properties that you can use for a condition. These properties are a subset of the email properties that were previously described. These descriptions are repeated for your convenience.

Conditions for document properties

Create a condition using document properties when searching for documents on SharePoint and OneDrive for Business sites. The following table lists the document properties that you can use for a condition. These properties are a subset of the site properties that were previously described. These descriptions are repeated for your convenience.

Operators used with conditions

When you add a condition, you can select an operator that is relevant to type of property for the condition. The following table describes the operators that are used with conditions and lists the equivalent that is used in the search query.

Guidelines for using conditions

Keep the following in mind when using search conditions.

• A condition is logically connected to the keyword query (specified in the keyword box) by the AND operator. That means that items have to satisfy both the keyword query and the condition to be included in the results. This is how conditions help to narrow your results.

• If you add two or more unique conditions to a search query (conditions that specify different properties), those conditions are logically connected by the AND operator. That means only items that satisfy all the conditions (in addition to any keyword query) are returned.

• If you add more than one condition for the same property, those conditions are logically connected by the OR operator. That means items that satisfy the keyword query and any one of the conditions are returned. So, groups of the same conditions are connected to each other by the OR operator and then sets of unique conditions are connected by the AND operator.

• If you add multiple values (separated by commas or semi-colons) to a single condition, those values are connected by the OR operator. That means items are returned if they contain any of the specified values for the property in the condition.

• Any condition that uses an operator with Contains and Equals logic will return similar search results for simple string searches. A simple string search is a string in the condition that doesn't include a wildcard). For example, a condition that uses Equals any of will return the same items as a condition that uses Contains any of.

• The search query that is created by using the keywords box and conditions is displayed on the Search page, in the details pane for the selected search. In a query, everything to the right of the notation (c:c) indicates conditions that are added to the query. (c:c) shouldn't be used in manually enetered queries and isn't equal to AND or OR.

• Conditions only add properties to the search query; they don't add operators. This is why the query displayed in the detail pane doesn't show operators to the right of the (c:c) notation. KQL adds the logical operators (according to the previously explained rules) when the executing the query.

• You can use the drag and drop control to resequence the order of conditions. Select the control for a condition and move it up or down.

• As previously explained, some condition properties allow you to type multiple values (separated by semi-colons). Each value is logically connected by the OR operator, and results in the query (filetype=docx) OR (filetype=pptx) OR (filetype=xlsx). The following illustration shows an example of a condition with multiple values.

  

  Note

  You can't add multiple conditions (by selecting Add condition for the same property). Instead, you have to provide multiple values for the condition (separated by semi-colons), as shown in the previous example.

Examples of using conditions in search queries

The following examples show the GUI-based version of a search query with conditions, the search query syntax that is displayed in the details pane of the selected search (which is also returned by the Get-ComplianceSearch cmdlet), and the logic of the corresponding KQL query.

Example 1

This example returns email items or documents that contain the keyword "report", that were sent or created before April 1, 2021, and that contain the word "northwind" in the subject field of email messages or in the title property of documents. The query excludes Web pages that meet the other search criteria.

GUI:

Search query syntax:

report(c:c)(date<2021-04-01)(subjecttitle:"northwind")(-filetype:aspx)

Search query logic:

report AND (date<2021-04-01) AND (subjecttitle:"northwind") NOT (filetype:aspx)

Example 2

This example returns email messages or calendar meetings that were sent between December 1, 2019 and November 30, 2020 and that contain words that start with "phone" or "smartphone".

GUI:

Search query syntax:

phone* OR smartphone*(c:c)(sent=2019-12-01..2020-11-30)(kind="email")(kind="meetings")

Search query logic:

phone* OR smartphone* AND (sent=2019-12-01..2020-11-30) AND ((kind="email") OR (kind="meetings"))

Special characters

Some special characters aren't included in the search index and therefore aren't searchable. This also includes the special characters that represent search operators in the search query. Here's a list of special characters that are either replaced by a blank space in the actual search query or cause a search error.

+ - = : ! @ # % ^ & ; _ / ? ( ) [ ] { }

Searchable sensitive data types

You can use eDiscovery search tools in the compliance portal to search for sensitive data, such as credit card numbers or social security numbers, that is stored in documents on SharePoint and OneDrive for Business sites. You can do this by using the SensitiveType property and the name (or ID) of a sensitive information type in a keyword query. For example, the query SensitiveType:"Credit Card Number" returns documents that contain a credit card number. The query SensitiveType:"U.S. Social Security Number (SSN)" returns documents that contain a U.S. social security number.

To see a list of the sensitive information types that you can search for, go to Data classifications > Sensitive info types in the compliance portal. Or you can use the Get-DlpSensitiveInformationType cmdlet in Security & Compliance PowerShell to display a list of sensitive information types.

Limitations for searching sensitive data types

• To search for custom sensitive information types, you have to specify the ID of the sensitive information type in the SensitiveType property. Using the name of a custom sensitive information type (as shown in the example for built-in sensitive information types in the previous section) will return no results. Use the Publisher column on the Sensitive info types page in the compliance portal (or the Publisher property in PowerShell) to differentiate between built-in and custom sensitive information types. Built-in sensitive data types have a value of Microsoft Corporation for the Publisher property.

  To display the name and ID for the custom sensitive data types in your organization, run the following command in Security & Compliance PowerShell:

  Get-DlpSensitiveInformationType | Where-Object {$_.Publisher -ne "Microsoft Corporation"} | FT Name,Id
  

  Then you can use the ID in the SensitiveType search property to return documents that contain the custom sensitive data type; for example, SensitiveType:7e13277e-6b04-3b68-94ed-1aeb9d47de37

• You can't use sensitive information types and the SensitiveType search property to search for sensitive data at-rest in Exchange Online mailboxes. This includes 1:1 chat messages, 1:N group chat messages, and team channel conversations in Microsoft Teams because all of this content is stored in mailboxes. However, you can use data loss prevention (DLP) policies to protect sensitive email data in transit. For more information, see Learn about data loss prevention and Search for and find personal data.

Searching for site content shared with external users

You can also use eDiscovery search tools in the compliance portal to search for documents stored on SharePoint and OneDrive for Business sites that have been shared with people outside of your organization. This can help you identify sensitive or proprietary information that's being shared outside your organization. You can do this by using the ViewableByExternalUsers property in a keyword query. This property returns documents or sites that have been shared with external users by using one of the following sharing methods:

• A sharing invitation that requires users to sign in to your organization as an authenticated user.
• An anonymous guest link, which allows anyone with this link to access the resource without having to be authenticated.

Here are some examples:

• The query ViewableByExternalUsers:true AND SensitiveType:"Credit Card Number" returns all items that have been shared with people outside your organization and contain a credit card number.
• The query ViewableByExternalUsers:true AND ContentType:document AND site:"https://contoso.sharepoint.com/Sites/Teams" returns a list of documents on all team sites in the organization that have been shared with external users.

What is considered content that is shared with people outside your organization? Documents in your organization's SharePoint and OneDrive for Business sites that are shared by sending a sharing invitation or that are shared in public locations. For example, the following user activities result in content that is viewable by external users:

• A user shares a file or folder with a person outside your organization.
• A user creates and sends a link to a shared file to a person outside your organization. This link allows the external user to view (or edit) the file.
• A user sends a sharing invitation or a guest link to a person outside your organization to view (or edit) a shared file.

Issues using the ViewableByExternalUsers property

While the ViewableByExternalUsers property represents the status of whether a document or site is shared with external users, there are some caveats to what this property does and doesn't reflect. In the following scenarios, the value of the ViewableByExternalUsers property won't be updated, and the results of a search query that uses this property may be inaccurate.

• Changes to sharing policy, such as turning off external sharing for a site or for the organization. The property will still show previously shared documents as being externally accessible even though external access might have been revoked.
• Changes to group membership, such as adding or removing external users to Microsoft 365 Groups or Microsoft 365 security groups. The property won't automatically be updated for items the group has access to.
• Sending sharing invitations to external users where the recipient hasn't accepted the invitation, and therefore doesn't yet have access to the content.

In these scenarios, the ViewableByExternalUsers property won't reflect the current sharing status until the site or document library is recrawled and reindexed.

Searching for site content shared within your organization

As previously explained, you can use the SharedWithUsersOWSUser property so search for documents that have been shared between people in your organization. When a person shares a file (or folder) with another user inside your organization, a link to the shared file appears on the Shared with me page in the OneDrive for Business account of the person who the file was shared with. For example, to search for the documents that have been shared with Sara Davis, you can use the query SharedWithUsersOWSUser:"[email protected]". If you export the results of this search, the original documents (located in the content location of the person who shared the documents with Sara) will be downloaded.

Documents must be explicitly shared with a specific user to be returned in search results when using the SharedWithUsersOWSUser property. For example, when a person shares a document in their OneDrive account, they have the option to share it with anyone (inside or outside the organization), share it only with people inside the organization, or share it with a specific person. Here's a screenshot of the Share window in OneDrive that shows the three sharing options.

Only documents that are shared by using the third option (shared with Specific people) will be returned by a search query that uses the SharedWithUsersOWSUser property.

Searching for Skype for Business conversations

You can use the following keyword query to specifically search for content in Skype for Business conversations:

kind:im

The previous search query also returns chats from Microsoft Teams. To prevent this, you can narrow the search results to include only Skype for Business conversations by using the following keyword query:

kind:im AND subject:conversation

The previous keyword query excludes chats in Microsoft Teams because Skype for Business conversations are saved as email messages with a Subject line that starts with the word "Conversation".

To search for Skype for Business conversations that occurred within a specific date range, use the following keyword query:

kind:im AND subject:conversation AND (received=startdate..enddate)

Character limits for searches

There's a 4,000 character limit for search queries when searching for content in SharePoint sites and OneDrive accounts. Here's how the total number of characters in the search query are calculated:

• The characters in keyword search query (including both user and filter fields) count against this limit.
• The characters in any location property (such as the URLs for all the SharePoint sites or OneDrive locations being searched) count against this limit.
• The characters in all the search permissions filters that are applied to the user running the search count against the limit.

For more information about character limits, see eDiscovery search limits.