Skip navigation
Inconsistent searches all too commonly seen in Exchange

Inconsistent searches all too commonly seen in Exchange

The topic of searching mailboxes came up during the second “Experts Unplugged: Support Issues” session that I had the honor to moderate at MEC (such a long time ago now, but that's the nature of writing about happenings when other events take precedence). In a way it had been covered before at the conference because Microsoft had acknowledged that deficiencies exist in this area and that they are busy developing more precise and effective search capabilities. Apparently the new search will appear in Office 365 towards the end of 2014 and in the next major release of Exchange sometime at the end of 2015.

One of the stories told at the Experts Unplugged session illustrates the problem. An attendee who works at a major financial institution related his frustration at the fact that several hundred of his users insist on forwarding email to their Gmail accounts because Gmail is faster and more accurate than Exchange is at searching. Google is certainly primus inter pares when it comes to search but it’s surprising, at least to me, that any organization would tolerate the forwarding of messages to Gmail, if only because of the compliance issues that this action raises.

In any case, many other attendees agreed that Exchange search basically sucks dirty canal water (to use a phrase that I first heard in the 1980s to describe some email features). This raises the question why the situation exists in a world when the proportion of “filers” (those who file messages into folders) is declining in favour of the “pilers” (who leave everything in the Inbox and depend on search to find messages).

It seems likely that the cause is rooted in inconsistency and change. The inconsistency comes through different behaviour and implementation of search features across multiple clients; the change comes from the switchover from the old MSSearch component in Exchange 2010 to the Search Foundation in Exchange 2013. In passing, I think that the latter change is good because it removes a dependency from Exchange (the Office Filter pack) and introduces common search across Exchange and SharePoint.

The other important difference is that Outlook clients configured in cached mode use Windows Desktop Search to index and search for items. Outlook in online mode uses Exchange, just like Outlook Web App and mobile clients. Windows Desktop Search is convenient because it works when the client is offline) but the results it produces are different to what comes back from Exchange. Microsoft has attempted to explain the various search scopes that exist for Outlook but I don't think the nuances are well understood by many.

You might not be aware of any deficiencies in search. I have been blissfully unaware of any problems until I heard about them at MEC, which then forced me to do some testing of my own. So here’s an example showing the search results against my Office 365 mailbox executed at the same time with Outlook Web App (OWA – left) and Outlook 2013 in cached Exchange mode (right). These searches focus on messages only and ignore items such as RSS feeds and documents that Outlook will index and find if present in a mailbox.

There’s nothing complex about these searches and what’s interesting is that OWA didn’t find the messages dated 9 March 2014, 13 May 2013, and 18 April 2013 (OWA dates are in U.S. format, Outlook in European). On the other hand, Outlook doesn’t show the message dated 17 April 2013. I just can’t explain these results.

A simple user perspective is that search should return the same results no matter what client interrogates a mailbox. This is reasonable because users aren’t aware of the technical differences that exist across client and server. All they want to do is find stuff fast.

The news that searches might not find the expected results is not good for administrators either. If someone “loses” an important message because it is buried deep in their Inbox (past the capacity of an average human to find by scanning) and can’t be located by a search, the user’s next step is to ask IT for support. Hearing about messages that can’t be found is never good because it can lead to that much-loved support activity called database restores. Of course, an administrator can execute an eDiscovery search before taking that step and it’s more than likely that such a search will uncover a missing item, if only because it might turn up a deleted item retained because Single Item Recovery is enabled for the mailbox.

But depending on administrators executing eDiscovery searches to find messages is an unacceptable state of play. Work is needed to bring consistency to this area of functionality with the simple goal of delivering fast, effective, and efficient searches on all clients. I hope that Microsoft’s initiative to develop better (more reliable and understandable) search achieves this goal and that the improvements described in the Office 365 roadmap (search suggestions and search refiners) contribute to more reliable results.

If problems persist and search remains undependable, more people might just be tempted to forward their email to Gmail and that can’t be a good thing.

Follow Tony @12Knocksinna

TAGS: Office 365
Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish