It has been awhile since I posted about eDiscovery so here is a morsel of know-how on keyword search syntax for SharePoint and Exchange eDiscovery.
Before we get started, here are some related useful resources:
Search engines are usually optimized to return only a few highly relevant results. In eDiscovery, the goal of search is to return all results that match a query, not just the few most relevant results. Both SharePoint Search and FAST Search for SharePoint have been configured to work with SharePoint Server 2010 eDiscovery out of box and return all search results. This provides a rich keyword syntax that helps meet the needs of eDiscovery.
If you are on SharePoint Server 2010 you can use the Search and Add to Hold page to search a site collection by entering keywords in the search criteria section.
SharePoint 2010 Search and Add to Hold Page
eDiscovery capabilities are vastly improved in SharePoint Server 2013 and Office 365, which now has integration with Exchange and Lync 2013, in-place hold to preserve data without affecting users, and beefed up search capabilities such as proximity and support for 500 keywords. You can configure your environment to search SharePoint, Exchange, and Lync data all at once using the SharePoint eDiscovery Center. If SharePoint 2013 search is indexing SharePoint 2010 and 2007 sites, you can use the eDiscovery Center to search all of those sites. Keyword query language (KQL) is the syntax used for SharePoint and is now used in Exchange 2013 eDiscovery. Lync content is archived into Exchange 2013 mailboxes so that uses KQL as well. Exchange 2010 uses Advanced Query Syntax (AQS), and would have to be searched via a separate interface.
See my previous post overview of Microsoft Office eDiscovery with Exchange, SharePoint, and Lync 2013.
SharePoint 2013 eDiscovery Center Query Page
Introduction to Keyword Query Language Syntax
Here are some basic rules to follow when creating a keyword query:
SharePoint and Exchange 2013: The search box in both the SharePoint eDiscovery Center and Exchange Admin Center supports 500 keywords. If you are using additional properties such as the start and end date or author/sender fields, those properties do not count against the 500 keyword limit, nor do the operators between the keywords themselves.
SharePoint 2010 Search and Add to Hold page: The text box for search terms on the Search and Add to Hold page permits a maximum of 255 characters. (If more characters are needed, the .aspx page itself can be modified so that the text box with ID= "m_tbSearchString" has the MaxLength changed up to 2048).
Keywords and Phrases
A query can include words, quoted phrases, and terms that use combinations of keywords and properties. Separate terms with spaces. Spaces are the equivalent of an AND. Pressing enter / line breaks are treated as just a space and are still an AND.
When you enclose a phrase in quotation marks, your search returns content within the chosen scope that contains the exact phrase that you typed. For example "Northwind widget" would return all documents that have the exact phrase "Northwind widget" but not "Northwind team develops new widget".
When you type words separated by spaces, your search returns content that contains all of the words that you typed, in any order. For example, to find both "Fair Value" and "Value Fair" type fair value, but this will find documents where fair and value are positioned anywhere in the document. You could also do "Fair Value" OR "Value Fair" to search for either of the exact phrases.
SharePoint 2013 and Exchange 2013 support proximity search. You can use NEAR, ONEAR, NEAR(X), or ONEAR(X) to find keywords within a certain distance of another keyword. "widget" NEAR "Northwind" will find widget within 8 keywords of Northwind regardless of the ordering. "widget" ONEAR "northwind" will find widget within 8 keywords of Northwind but only when widget appears before Northwind. NEAR(X) and ONEAR(X) lets you specify the allowed distance. "widget" NEAR(30) "Northwind" will find widget within 30 keywords of Northwind.
Stay tuned for an upcoming post on search properties and operators.
Quentin Christensen, Program Manager