Skip navigation
Another opportunity for automation in eDiscovery for SharePoint 2013 and Exchange 2013

Another opportunity for automation in eDiscovery for SharePoint 2013 and Exchange 2013

Why is it that anything that involves co-operation between Exchange 2013 and SharePoint 2013 is quite so hard to setup and fragile to manage? It’s almost as if the two products are the result of work done by two very different development groups rather than part of one great big happy “Office Servers” family.

I suspect that the problem lies more on the SharePoint side than it does with Exchange. You might very well assume that I exhibit a certain bias here but I rebut that charge on the basis that Exchange learned long ago that automation is a great way of removing frustration and the potential for administrator screw-ups from the product. SharePoint doesn’t seem to have quite understood that concept. Or perhaps SharePoint administrators are happy enough to go through pages of instructions telling them to click here, do that there, and eventually hope that everything hangs together.

Last year I wrote about some similar frustration that I encountered when attempting to configure the bits necessary for Exchange and SharePoint to talk nice to each other and make site mailboxes possible. My conclusion then was that Microsoft should automate the configuration process as much as they could to remove all the manual steps that are needed. In this respect, the work done to create the Exchange Hybrid Configuration Wizard (HCW) in Exchange 2010 SP2 is a model of what can be done to transform a situation where 40+ separate actions were necessary to create a working configuration into a few wizard-driven steps.

My latest frustration came about when I investigated the eDiscovery Center, or the ability to conduct compliance searches across Exchange 2013 and SharePoint 2013. This capability is underpinned by the fact that both products now share the Search Foundation and so have a common understanding of how to index content in the respective repositories. Exchange 2013 is perfectly capable of running its own compliance searches, in which case only the contents of mailbox databases are scanned, but if you have both products, you can execute searches that span both mailbox databases and SharePoint sites and turn up even more items for lawyers to review.

Common searches are driven through SharePoint (this diagram helps to explain the connections between SharePoint, Exchange, and Lync). If you listen to Microsoft people talk about this feature, you’ll probably hear them refer to the eDiscovery Center, which might lull you into the false expectation that SharePoint 2013 comes with a prominent option of the same name. But that’s not true. Instead, you have to create a new site collection using the eDiscovery Center template.

Such a process might be second-nature to the average SharePoint administrator. It came as a surprise to me, as did the long list of steps necessary to create the site collection from the right template, make Exchange a known source, ensure that the right permissions were in place, and eventually come to the point where searching can commence.

At this point you find that SharePoint and Exchange use different terminology for searches. SharePoint refers to them as “cases” whereas the new Exchange term is “eDiscovery searches.” It would be nice if a common term was used. In any case, it’s reasonably easy to set up new cases and examine what comes back from Exchange, as long as you don’t fall into the same trap as I did, which is to leave the default text in the Query Transform box when configuring Exchange as a source for SharePoint (this article helped to solve the issue). Once everything works, in-place holds can also be set on mailboxes (but only if they are on an Exchange 2013 server). This process seems more prone to failure than searching as it often resulted in a failed status when I attempted to set an in-place hold from SharePoint.

As is normal in these matters, it is much easier to make everything work on Office 365 because Microsoft takes care of all the behind-the-scenes plumbing to make Exchange and SharePoint talk nicely to each other. You’ll need an E1 subscription (or better) to make the magic happen. And some pixie dust – always helpful when integration is required.

Follow Tony @12Knocksinna

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