Office Delve, Exchange mailboxes and even perhaps public folders

From the perspective of a platform to enable collaboration, public folders are crude and unwieldy. Unsurprisingly, because public folders have received relatively little development since their introduction in Exchange 4.0 in 1996, they really don’t deliver a very good collaboration experience. You put stuff into folders to share it with others; they access the items and maybe update them, and that’s about it.

The best thing about public folders is that they are included in every version of Exchange. A free solution is much better than a solution that you have to pay for unless the paid-for solution delivers obvious business and technical benefits. And when you get down to it, many solutions provide put-it-in-and-share-it functionality that isn’t much better than public folders, even if wrapped in a bright new sparkling interface.

So the cockroaches of Exchange persist, unloved by Microsoft and many users but used in so many places. I believe that Microsoft has had two obvious opportunities to kill (sorry, replace) public folders in the past but didn’t do it. The first was at the switch of architecture in Exchange 2000; the second was at the introduction of high availability in Exchange 2010. Neither chance was taken because no obvious replacement was available that was both free of charge and an easy migration target. For instance, SharePoint was never a reasonable alternative because of its cost and complexity.

Exchange 2013 and Exchange Online support “modern” public folders, an implementation that delivers the major benefit of moving away from separate pubic folder databases to embracing Exchange’s high availability model by storing public folders in mailbox databases. Held back by the manual nature of the migration and flawed by horrible performance limitations, Microsoft improved public folder scalability in Exchange 2013 CU6 and is due to deliver more improvements in Exchange 2013 CU7, at which point it might be possible for some of the larger deployments to begin a migration to modern public folders.

Which brings me to Office Delve, now rolling out to Office 365 tenants near you (but no plans yet exist for an on-premises release). As the name implies, Delve is all about finding information that already exists inside corporate repositories. It accomplishes this goal by using machine learning to understand the connections that exist between people and the work that they do, including information that is important because it is “trending” within the organization. Right now, Delve doesn’t extract much from Exchange and the information that it displays through its card-like interface is mostly derived from SharePoint sites and OneDrive for Business. The items displayed by Delve have to be shared before they appear as Delve doesn't show anything to users unless they have permission to see the content.

According to Microsoft “For each user, a personal cache is created for the top people who they communicate with in Exchange Online. Content from people who are in the personal cache of a user gets a boost in Delve. “ My interpretation is that Delve is using the same information that is exposed through OWA as People View to identify the individuals who correspond most frequently with a  user. An additional refinement is made so that only internal correspondents are shown rather than listing external people with whom you can't share documents in the sense understood by Delve. Leveraging a common set of "people" information makes a ton of sense but I’m rather more interested in thinking about how Delve and the Office Graph might weave some better connections using Exchange.

I assume that eventually Delve will link up with Exchange Online to make better use of the information contained in mailboxes – the lack of commitment to an on-premises version probably also rules out hybrid scenarios. Connecting Delve to Exchange makes a lot of sense because much of the information held by organizations is in email. After all, email remains the single most popular way to share documents with co-workers. The question then is what information in Exchange mailboxes will Delve be able to access?

Remember that information has to be explicitly shared before Delve displays it to a user. In other words, if you can’t see a document or other item in the underlying application because its owner has not shared it with you, it won’t show up in Delve. To me, this means that Delve won’t be “delving” through personal mailboxes, even if those mailboxes contain all sorts of interesting items. After all, a personal mailbox is just that - personal!

Unless of course users have assigned permissions over the mailbox to others, as in the case when an executive allows an administrative assistant to process items in the Calendar and Inbox folders and to send messages on their behalf. In this case, I think it would be acceptable for the assistant to see an item through Delve if it is in the Inbox folder in the executive’s mailbox. I assume that Microsoft will enhance mailbox auditing to report instances when delegated access resulted in an item being read through Delve, but we’ll have to wait and see the details of the implementation.

Shared mailboxes and site mailboxes should be straightforward enough because permissions are used to grant access to these repositories and the same permissions can be used to restrict access to their contents through Delve. The same might be true for the new Office 365 Groups, which also use an Exchange mailbox to hold some content.

And coming back to public folders, I assume that Delve will want to be able to access the information held in modern public folders (but not their ancient counterparts). After all, some companies have many terabytes of information stored in hundreds of thousands of folders. The aim, after all, of Delve is to make people more aware of information and knowledge that exists within a corporation, and it seems to make sense to exploit what’s there and available.

The rather nice interface that Delve presents to bring information to the attention of users won’t make public folders a better platform for collaboration, but it will exploit an existing asset, which is always a good thing. And if people realize what is stored in public folders (“aha, I had wondered where the corporate planning spreadsheet for 2006 was located”), then some clean-up might be done. Or maybe not. Why spoil the habit of dumping stuff into public folders that’s existed since 1996?

Follow Tony @12Knocksinna