Rapid evolution in Exchange compliance features causes some problems

I have written previously to suggest a framework that can be used to debate the relative merits of the compliance products available for Exchange. In summary, the debate often boils down to the close integration (across clients and server) and perceived low cost available in Microsoft’s offerings versus the industry knowledge and track record of the third-party vendors.

There is no doubt that Microsoft has poured enormous engineering and marketing resources into its compliance efforts and that its technology has evolved quickly. However, rapid evolution sometimes has a downside.

Take the content indexes used by Exchange eDiscovery searches as an example. The indexes are created and maintained by the MSSearch component in Exchange 2010 but that role is taken by the Search Foundation in Exchange 2013. The change makes perfect economic sense because Microsoft paid a great deal of money in 2008 for the FAST technology now shipped as the Search Foundation and clearly want to get value for their purchase. It also makes engineering sense to rationalize on the number of search engines in use and to establish a common platform across Exchange and SharePoint, the two Office application servers that host most user data.

But the fact that Exchange 2010 and Exchange 2013 use two radically different search engines means that it is impossible to perform a single integrated discovery search across mailboxes distributed across the two versions. Microsoft is up-front about this issue but it’s the kind of detail that is often missed until the time comes in a deployment to perform the first eDiscovery search only to discover that some of the pertinent mailboxes are on Exchange 2010 and some have been moved to Exchange 2013 – and some might still be on Exchange 2007. Separate search mailboxes are also needed for searches performed by the two versions. The solution is to get important mailboxes (those that might need to be searched) onto a common platform.

Then there’s the different behavior in resource management for searches. Exchange 2010 is happy to search up to 25,000 mailboxes and the limit can be increased by making a magical change to the system registry. Exchange 2013 takes a different tack and uses throttling policies to control the amount of resources that a search can consume. All logical, but certainly a point to take into account during a migration.

Another interesting point is that Microsoft advise companies that run in hybrid configurations that they should launch eDiscovery searches from their on-premises console and that any search results that need to be copied to a search mailbox should be directed to an on-premises mailbox. Hmmm… imagine a search that discovers twenty gigabytes of relevant data in cloud mailboxes. Now ask yourself why this data should be sent over the Internet to an on-premises mailbox. The only answer I can come up with is that the data is easier to review and process once it’s on-premises, but if this is true isn’t it a bad sign for cloud systems?

Software incompatibility due to upgrades has been a fact of IT life for as long as I can remember. Transport rules are another example of Exchange’s compliance armory that has evolved quickly. A deployment spanning Exchange 2007, 2010, and 2013 might have three separate and distinct set of transport rules to manage. The 2007 rules are pretty basic while Microsoft did a good job of upgrading the capabilities of transport rules for Exchange 2010 and have since changed them again (largely to accommodate data loss prevention features) in Exchange 2013. Good reasons exist for each upgrade but the resulting mish-mash of rules spread across three versions can be confusing. The installation of a new version of Exchange into an existing organization forces existing rules to be copied so that they can be used by the new software, but it’s easy to see how gaps open in this particular strategy.

None of the issues that I have described here is earth-shattering. All can be dealt with through solid testing and attention to detail. However, they illustrate the challenge of maintaining maximum backwards compatibility that software developers face as they grapple with the need to match the capabilities of the competition. I'm pretty sure that the other vendors of compliance software for Exchange make the case that their software is tried and tested and can be used with multiple versions of Exchange. After all, they would be foolish were they to overlook the chance to score an open goal.

Exchange now has a pretty comprehensive set of email compliance features – as long as you use the right version. No doubt things will settle down in time as new versions of Exchange roll out, but if your company uses the compliance features and is in the middle of an Exchange 2013 deployment project, you might just keep an eye out for these small but important details.

Follow Tony @12Knocksinna

Discuss this Blog Entry 4

on Jul 4, 2013

Be also worth mentioning the ongoing changes to retention policies and holds in the recent versions (sometimes even major changes to these features in Service Pack releases). Microsoft has to realize that this makes organizations hesitant to invest. It is a big effort for organizations to settle their information governance and ediscovery policies and practices on functionality, and I've heard it is a headache and deterrent when the functionality you've invested in works a different way or is deprecated in the next release (especially when the functionality was new in the past version).

on Jul 4, 2013

@geoffbourgois, absolutely true... as an example, even though the original MRM (Exchange 2007) was not well received by most organizations, its deprecation in Exchange 2013 has upset those who invested in developing processes and procedures around that functionality. That being said, MRM 2.0 is much better all round than MRM 1...

on Jul 10, 2013

Upset ??? What if you had a fairly complex setup ... oopps ...
You may be better off having IBM Domino server as a front/add-on for compliance. Great functionality for at least 3 generations, or simply use 3rd party.

on Jul 10, 2013

Whatever about having to figure out the issues of enabling compliance across Exchange 2010 and 2013, my guess is that introducing Domino into the mix would drive the level of complexity and cost to significantly higher levels. It would not be my recommendation.

Please or Register to post comments.

What's Tony Redmond's Exchange Unwashed Blog?

On-premises and cloud-based Microsoft Exchange Server and all the associated technology that runs alongside Microsoft's enterprise messaging server.

Contributors

Tony Redmond

Tony Redmond is a senior contributing editor for Windows IT Pro and the author of Microsoft Exchange Server 2010 Inside Out (Microsoft Press) and Microsoft Exchange Server 2013 Inside Out: Mailbox...
Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×