Eradicating EV stubs from Exchange mailboxes isn't easy

I was astonished at the reaction I received from last week’s post about the new Office 365 Import service and how Microsoft had Symantec Enterprise Vault (EV) squarely in its cross-hairs in a crusade to repatriate information back from EV to Exchange. Many people contacted me to seek more details of the service (it’s available now to Office 365 tenants) or with questions. It is clear that a lot of data has been exported from Exchange over the years. And I mean a lot!

I have some sympathy for the folks at Symantec. EV’s origins lie in a project at Digital Equipment Corporation (DEC) in the 1995-98 period when the DEC engineering group responsible for the minicomputer-based ALL-IN-1 mail server was looking for new ways to co-operate with Microsoft around a new server called Exchange 4.0. As originally conceived, EV would offload some of the strain from the puny servers that ran Exchange at the time by arching mailbox data to EV servers running on the DEC Alpha platform.

The EV team struggled with many challenges, including the almost total lack of documentation for MAPI outside Microsoft (the “Inside MAPI” book didn’t appear until late 1996 and tools like MFCMAPI didn’t exist for many years afterwards). They eventually ran into the iceberg of rationalization after Compaq took over DEC and the technology was sold to KVS, a small company formed by some of the engineers who had worked on the original Vault like Nigel Dutt and Derek Allan. Later, KVS was bought by Veritas, which was then bought by Symantec and the circle was closed.

To be fair to EV, it only ever attempted to fill a gaping hole left by Microsoft until archive mailboxes appeared in Exchange 2010. For years, EV provided a good solution used by many companies who wanted to offload mailbox data from expensive SAN storage. Its latest evolution is as a cloud-based service.

But over the years, EV attracted a fair amount of odium from Microsoft, mostly because of the “stubs” EV left behind in user mailboxes to redirect access from Exchange to EV. You can get a flavor of the commentary from this blog by Exchange development VP Perry Clarke from 2010, where he says: “I consider the stubbing approach it (sic) [to] be one of those kluges that occur in the software industry regularly that are done out of necessity.” This is just after Exchange 2010 appeared and Microsoft had started to turn the heat up on Symantec by encouraging customers to keep all of their data in Exchange. The refrain went that there’s no need for external vaults when large mailboxes and massive archive mailboxes allow users to keep everything inside Exchange. And it’s true that many advantages can be gained through this approach in indexing, eDiscovery, and compliance.

What was interesting here is how Microsoft then turned around and used stub items in Exchange 2013 site mailboxes to represent documents stored in SharePoint document libraries. I guess this was a good use of stub items. Not like that EV stuff, you understand.

And encouraged by Microsoft, a reasonably large archive migration sector has grown up around EV. Companies like TransVault, Nuix, Archive360, and QUADROTech have developed tools to help users migrate content from EV to Exchange on-premises and Exchange Online. All of these companies have the ability to generate the PSTs that the new import service requires. Each has some unique selling points to help companies find, collect, and verify PSTs before they are input to the service, and some can completely replace the drive shipping approach of Microsoft with their own methods to get data into Office 365.

Because such a rich ecosystem of third party products has grown up around EV, it pays to review what’s available in the market before rushing to make a decision about what tool set to use to move data from EV to Office 365. Issues to consider include cost, the speed that data is processed, the ease and facility of identifying suitable data to export from EV and other archives, scheduling and automated processing, and perhaps too the identification and collection of PSTs from user drives and file shares (where PSTs shouldn’t be anyway). How to handle the EV stubs in user mailboxes is an interesting question to contemplate, including the question of when and how these stubs will be removed from mailboxes to be replaced by newly imported Office 365 data.

User education is another thing to consider. If your company is a long-time user of EV, users have probably developed a routine for dealing with archived data. That data is now in a different location and is accessed in a different manner, so expect some user questions to flow.

I’d also check out local support for the tools you might want to use. And keep an eye out for new entrants to the market as I expect that Microsoft’s new service will encourage other ISVs to build out their capabilities around migration to Office 365.

The Office 365 Import service might seem like an indication of how Microsoft is deliberately attempting to close down the market for third party archive products. In one respect that's true because Microsoft believes that its customers would be better served if mailbox data was held in one place. In another it's not because you can also argue that this is simply the natural consequence of the expanding functionality within Office 365 and the resulting functionality that Microsoft can offer to customers. 

The opportunities afforded to ISVs by any software ecosystem close and open all the time. If the opportunity for archiving closes or reduces, a company has to react by either increasing its feature set to remain competitive or accepting that this area is no longer viable. In the latter case, the ISV has to find another gap in the ecosystem to leverage and exploit. That is the brutal reality of the capitalist system. The growing influence of Office 365 challenges the ISVs who have grown business around Exchange and SharePoint to consider how they will survive and prosper in a cloud-dominated world.

Microsoft’s import service is free, so it’s got a great price point. On the downside, it does nothing to export data from any other archive and depends on other tools to prepare the PSTs that the import service can ingest. The devil is in the detail…

Follow Tony @12Knocksinna