Are your clients using desktop search engines that index Exchange mailboxes or public folders?

Exchange performance problems are sometimes quite hard to troubleshoot and figure out. Recently, we have seen some performance problems on Exchange servers being caused by “desktop search” products that plug into the Outlook client and then index mailboxes and/or public folders for faster searching. Please note here that not ALL desktop search products index mailboxes and/or public folders.


Two related issues that we have seen the most are:


– The sheer number of RPC requests that those clients can start sending to the server may cause a client-side bottleneck.


– The Exchange server gets hit with a lot of requests while applications are crawling mailboxes, increasing the IOs per user, and creating a bottleneck in the disk subsystem.


I wanted to highlight a KB article that was written on the subject, as it contains some mitigation steps for those issues, as well as troubleshooting tips that can help you identify those problems. It should be understood that I am not saying that ALL Exchange performance problems will be related to Desktop Search engines and of course, nor that the use of Desktop Search engines automatically means that there WILL be performance problems. This is, however, something to keep in mind, as perf issues might show up in the environment that never had such problems before and unless we are thinking of this variable too – it could be hard to figure out what has changed.


The article is here:


905184 Exchange 2000 Server and Exchange Server 2003 performance may be


Nino Bilic

Comments (5)
  1. Jonathan says:

    Um, well, YOUR MS product (Lookout) is a "desktop search agent" that can index Public Folders. Our company tries to use Public Folders as a knowledge base, and since there really isn’t a native (i.e. useful) search client for indexing and searching public folders, Lookout is the only real possibility…

  2. Tony Redmond says:

    Lookout is one of the most useful add-ons I have ever encountered for Outlook, so I would be loathe to discontinue using it. I do take the point that its indexing can stress servers and therefore perhaps the recommendation should be to use these desktop search engines when Outlook is running in cached Exchange mode, where Lookout (at least) can use the local data?

  3. Exchange says:


    Yes, you are making a good point, and it is mentioned in the article that I linked to… cached mode mitigates server-side problems quite a bit as local content gets indexed instead. Not in the case of public folders though, and that is something that needs to be thought of, that’s all.

    BTW, I was a long Lookout user myself but switched to MSN Desktop Search as it indexes PDF files (something I really wanted) :)

  4. Tony Redmond says:

    I prefer Lookout myself as it’s better integrated with Outlook… Google Desktop and MSN Desktop seem to be pretty similar.

  5. Mike Belshe says:

    Interesting article! In the KB it states, "Method 4: Consider enabling Exchange content indexing".

    Can you comment on why this isn’t just defaulted to on and native within exchange already? Obviously, server side generation and maintenance of the index would the most performant. And, given where the industry currently is, its clear that fast search of email is mandatory for most email users. Indexing email at arrival time within the store, if done properly, should have almost no impact to Exchange – especially when compared to the heavy lifting that must be done to alternatively generate the index client side. If it were done this way, how would that work with Outlook 2003 cached mode?

    As you can guess, I’ve never used the content indexing feature in exchange. Does it work well? Does it handle attachments, multiple file types, etc? Does it handle advanced query syntaxes? Does it work for public folders too?

    If its a viable solution, I hope the next generation of Exchange has this feature enabled by default and implements all the same bells and whistles of MSN desktop search.

Comments are closed.