As some of you might know, I quite like Office Delve, the Office 365 feature introduced in September 2014 for English-speaking countries, even if Microsoft created some confusion when they updated Delve with “Boards” (or tagging to use another term) in January. Don’t get me wrong – being able to tag documents unearthed by Delve with project names and other useful terms is a very useful facility. It’s just that no management capability exists today to control the terms being used. One man’s “ProjectA” is another person’s “Project Alpha”, and so on. It's also true that Microsoft has some work to do to improve the useful facility to expose Exchange email attachments.
In any case, over the last few weeks I’ve run into some other issues that demonstrate the difficulty of engineering something like Delve into an ecosystem that’s up and running, especially a complex infrastructure like Office 365 where many moving parts must be orchestrated to deliver functionality. Even though Microsoft runs all of Office 365, many different project teams are involved and the evidence is that not all of them talk to each other as often as they should, at least not about how to integrate software together to form a coherent whole.
Take the screen shot shown below, showing Delve’s “My Work” view comprised of different items that I have recently worked on that are stored in SharePoint document libraries. Two of the cards that represent documents look just fine, but the other two are “different” – and not for a good reason.
The first is the “Facebook @Work” document. As you can see, the preview of the text (which I never really find useful, mostly because of my bad eyes) is missing. The card underneath tells me about a document with a weird name, one that only a computer would find satisfying. Some investigation was needed.
The issue with first document wasn’t too difficult to deduce. I opened the document and found it was protected with rights management. Obviously the Word Online component used to build the preview can’t get the necessary permission or license from rights management to access the document, so we end up with a blank screen.
The problem surfaces in other quarters as well. If you select a protected file in a SharePoint document library, you see the full error. This happens with the document libraries used by Office 365 Groups, which is where I first met the problem and reported it to Microsoft. A fix is apparently being worked on.
The issue with the first document is not one that can be attributed to Delve, but the second one can. In this case, clicking the link brings us to a “Preservation Hold Library”, part of one of the SharePoint sites in which I had been working. As it turns out, this site was under an in-place hold, and when that happens, SharePoint creates the special preservation hold library to store content that is modified or deleted. The library is not usually visible to end users but it is to a site collections administrator, which I am for my Office 365 tenant.
All of the files with the horrible names appear to have been created because items in the document library were modified. I guess the file names are acceptable on the basis that only computer software has to make sense of them, but they obviously should not have appeared in the Delve “My Work” view. Fortunately, a fix for this kind of thing might be pretty easy because you can hide documents from Delve by creating a new managed property for a site and using it to prevent the search crawler from processing the files. A good blog by MVP Mikael Svenson explains what to do in detail.
It seems like my issues are down to a mixture of Delve, SharePoint compliance features, Azure Active Directory rights management, and software engineering. I expect that some of the problems will be fixed by the time you read this article because that’s the way things seem to happen in the cloud.
One thing that hasn’t been fixed for a while is Delve’s annoying inability to locate anything in a document library owned by a private Office 365 group. I never expected items in the group mailbox (the conversations or calendar) to show up in Delve because it doesn’t yet consume any Exchange data but I rather thought that documents were a good bet, especially because Delve would ensure that it would only show documents that I am allowed to view.
As it turns out, Delve (and SharePoint searching – including eDiscovery) has a problem accessing the content of private group document libraries (you could argue a case that they are, after all, private). According to some sources in Microsoft, access controls seem to be the root cause. I hope that this problem is solved soon. It’s annoying to have Delve ignore some perfectly good work that I’m doing just because the files are stored in a private group document library, but more importantly, it’s a compliance issue when eDiscovery can’t unearth them through searches.
Naturally all of this only works with Office 365 because Delve is very much an Office 365 feature, but it's a great one to have - if you're in the cloud.
Follow Tony @12Knocksinna
