The canaries are really singing around Redmond to reveal details of the upcoming Office 15 product releases. At one level it’s kind of irritating to be bound by various Non-Disclosure Agreements (NDAs) that are strictly enforced by Microsoft only to see how Microsoft clearly plants details with journalists in the obvious knowledge that this information will end up in the public domain in short order. But then you realize that this activity is all part of the game that plays out around the launch of any new product. It’s called marketing.
One of the details that slipped out last week was the fact that Office 15 marks the introduction of FAST-based search technology into the Office 15 server products to provide a single, consistent, enterprise-class search capability across repositories managed by Exchange, SharePoint, and Lync.
Microsoft announced their intention to acquire the Norwegian-based FAST company in January 2008 for $1.2 billion. The deal was completed in May 2008 and since then Microsoft has been working to integrate FAST into its line-up in products such as FAST Search Server 2010 for SharePoint. The FAST engineering team remains based in Norway.
Exchange has used different search capabilities over the years. Originally, it used MSSearch in Exchange 2003 and then upgraded to use its own content indexing search in Exchange 2007 and Exchange 2010. The search feature has improved over the years through closer integration with the different parts of Exchange. For example, when the Exchange 2010 Mailbox Replication Service (MRS) moves a mailbox’s content behind the scenes, the data in the new mailbox is fully indexed and ready to go immediately MRS switches the user’s Active Directory account to point to the new mailbox. However, many Exchange users never use the server’s search capabilities because they rely on Outlook’s Windows client-side search capabilities to interrogate information in the Offline Storage File (OST), a feature that works well both offline and online. Exchange’s server-based content indexes are always used to search archive mailboxes as these are never replicated to OST files.
The combination of Outlook client-side search and Exchange server-side search works well as long as you’re only interested in tracking down a mail message. Things get more complicated when you’re not quite sure whether a document that you’re looking for is an attachment to a message or stored in a SharePoint site. Two separate searches are now required. And if the desired information is connected to a Lync conversation, the search process is even more complex.
Microsoft poured much effort into compliance features in Exchange 2010, including multi-mailbox discovery searches. These depend on the server content indexes and are effective at locating information held in user mailboxes, including deleted items that reside in the “dumpster”. But like user searches, discovery searches don’t work quite so well when SharePoint comes into the picture.
Providing a single integrated search capability across multiple repositories that’s based on proven search technology seems like an excellent step forward. The nagging question that’s in my mind is the client issue. In short, what clients will be able to execute searches across multiple repositories? I imagine that Outlook Web App will be able to perform this trick because it solely relies on server search capabilities. But will the same be possible for users equipped with Outlook 2007 or Outlook 2010? Being forced to upgrade to Outlook 2013 would take some of the shine off the brand-new search capability. I guess we’ll just have to wait and see when Exchange 2013 and its clients hove into view.
Follow Tony @12Knocksinna
