The Future of Exchange Server in the .NET Era

This week, I share some speculations and observations about Exchange Server's future (and therefore, our future) and some general observations about Microsoft .NET.

First, let's look at the next version of Exchange—codenamed Mercury. Although Microsoft has released few details about Mercury (it's more a minor release than a major release—Exchange 2000.5), it appears to target three areas. First, Mercury adds the features that didn't make it into Exchange 2000, such as large memory support and 32-way scalability (although these features might be difficult to achieve under Exchange's current architecture) and other capabilities that Microsoft cut from the final release.

Next, Microsoft wants to take advantage of some features that will be available in the upcoming Whistler release of Windows 2000, which should ship at the end of this year or early 2002. The current thinking seems to be that Mercury won't depend on Whistler but will leverage some of Whistler's features when running on the OS.

The final target area for Mercury is perhaps the most important—the application service provider (ASP) market. Most ASPs agree that, where their needs are concerned, Exchange 2000 is definitely an improvement over previous versions. However, most also have a long list of things they want that didn't come with Exchange 2000. One of Mercury's main focuses is to address the ASP market's specific needs. In fact, this week in Redmond, Microsoft is hosting key ASP and corporate Joint Development Program (JDP) customers for a Mercury Technical Design Review meeting where these customers can review Microsoft's plans for Mercury and hear an update on the overall direction for the Exchange technology future.

Where is Exchange going? The obvious first point is that Exchange is definitely heading for absorption into .NET. We can glean some directional information based on some changes in Redmond. The major change is in the Exchange marketing and development reporting structure and recent reorganizations. The Exchange marketing team now reports to a joint marketing organization shared with the SQL Server team. Microsoft seems to be aligning these two teams very closely. A major indication of this alignment came last month when a large portion of Exchange development was reorganized into the SQL Server team. Gordon Mangione (former vice president of Exchange Development) now heads SQL Server development and took the entire JET/Extensible Storage Engine (ESE) development team with him. This move indicates a key storage and database engine directional decision. Microsoft has wanted to create a unified storage paradigm for the Windows platform for several years but has failed in several other initiatives to accomplish this goal (there's always been a war between SQL and ESE development about whose technology is better). The first indication of direction came last year when rumors surfaced that newly self-appointed Chief Software Architect Bill Gates had decided that the next generation of Active Directory (AD) would be SQL Server based (instead of based on current ESE technology). The decision to roll ESE development into the SQL Server team seems to have solidified this direction (although, this realignment ultimately and unfortunately means the demise of technologies such as the long-awaited local store in Office 10).

For me, these changes are motivational. I need to work diligently to understand this whole .NET initiative and where the Exchange plumbing fits into it. To stay competitive, we'll all have to expand our scope—the days of managing just a messaging server are over. I better get going!