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
