This problem has been bugging me for a while.When using third party email clients that use EWS you can tell that others struggle with this topic aswell.These are the things I've tried so far:
>
Creating a SearchFolder
with Traversal="Deep"
for all items with the class IPM.Note
and the msgfolderroot
-folder as base folder.For a user with a sufficient amount of emails, this is not sustainable, since this operation will throttle immediately, essentially creating a DOS for that particular user.
Same as above, but adding an additional Rectriction
restricting the item:DateTimeReceived
to a week at a time.I guess this works OK when the mail the user is looking is relatively new, but will not work if it is an old email.
Find all the user's folder ids and search all these folders in paralell with the AQS-parameter set to the search query the user gave.This throttles the server as well.
Same as above, but search all the folders in series.This is OK for users with few mails in their mailbox and if they have few folders, but does not html" target="_blank">go fast enough for users with large mailboxes.
Is there a reasonably fast way to search the entire mailbox with EWS?I'm targeting Exchange 2010.
The main problem is that a lot of user mailboxes are a rabble of folders and items and there is no good solution for querying a live a folder of over 100000+ items in 2010 (which is more common then you would think).Search Folders are a good option for static queries as these get populated in the background but aren't going to give you an instant result.Even eDiscovery in 2013 is not fast at delivering really large result sets .A few approaches are make your queries Async (which is the way most searches for files etc work in windows anyway) where you bring the results in gradually (eg start with the Inbox because this is the most likely place to give you hits and then bring the other results in later) most users will live with and understand this experience.Otherwise if you needs a particular response time one way to do that is crawl and index the content yourself (which is doable and adds real value but comes at a cost).Searching large amounts of data always has some trade-off's you need to make.
Cheers Glen