Exchange Store Search Folders
Topic Last Modified: 2006-11-30
You can create collections of items that are the results of a Structured Query Language (SQL) search directly in the Exchange store within a search folder when using the WebDAV protocol. Like other folders in the Exchange store, persisted search folders are addressable using a URL and can be accessed and queried.
Using search folders in the Exchange store frees you from having to write your own code to save SQL search results for subsequent use by your clients. You can create search folders in private stores and public folders, except for the public folder tree designated for MAPI clients. Search folders can be created only using the WebDAV protocol. See WebDAV Search Folder Creation Protocol Command.
The items stored in a search folder are those items that exist within the folder scope and match the conditions you specify with an SQL SELECT statement when you create the search folder. That is, the folder does not contain copies of the items, but rather links to the items themselves. This is made possible through the Exchange store's single-instancing technology.
Note
A search folder in a public folder can only search content on the local Microsoft® Exchange server, even though the search folder itself is replicated across all public folders in the organization. In order to make the content of a search folder available to all users through public folders, the content that is being searched must be replicated across all back-end Exchange servers in the organization.
Although search folders are based on an SQL SELECT statement, they provide a mechanism far more powerful than simply storing the results returned by a standard SQL SELECT command. Using persisted search folders, you can arbitrarily group items within a particular folder scope that match the criteria you specify and then place them in another folder for subsequent searching or monitoring by your application.
For example, one part of your application may need to routinely return various property values for all items belonging to the hypothetical content class urn:schemas-myorganization-tld:statusreport that exists within your application's folder hierarchy, which could be many levels deep. Rather than continuously executing a deep traversal search for the property values on items belonging to this content class, you can instead create a search folder for the application folder hierarchy with the condition that each matched item in the folder belongs to the specified content class urn:schemas-myorganization-tld:statusreport. After the search folder is constructed, you can then routinely query it to retrieve property values for these items only. Because the Exchange store SQL engine need not re-traverse the entire folder scope and re-filter these items, search performance is greatly improved.
The Exchange store constructs search folders asynchronously with respect to client requests. That is, when a successful creation request is made and the client receives this response from the service, not all items that match the SQL request have yet been linked to the search folder.