Exchange’s Evolving Strategy

Executive Summary: Microsoft’s Exchange messaging and collaboration platform is evolving, with the next version of Exchange, Exchange 14, expected to be released in 2009. Exchange and Outlook authority Tony Redmond offers an insider view of Microsoft’s Exchange strategy and how that strategy is evolving.

Microsoft developers are working on the code-named “Exchange 14,” the successor to Exchange 2007 that we can expect to see in 2009. Exchange 2007 is the first version in the third generation of Exchange. (The first generation spanned Exchange 4.0 to 5.5; the second spanned Exchange 2000 to 2003.) The next version of Exchange will build on Exchange 2007’s architecture and won’t introduce any major changes, such as becoming a 64-bit application or moving away from the current Jet database to use SQL Server. (The latter change was supposed to occur in a version code-named “Kodiak” and was scheduled to ship after Exchange 2003. Kodiak never appeared, and Microsoft produced Exchange 2007 instead.) You can expect Exchange 14 to introduce some new features, but the majority will be bug fixes and incremental improvements to the product. Microsoft will also have to continue to increase the level of security and overall robustness found in the product.

The version after Exchange 14 should appear in 2011 to 2012; with it, Microsoft has the opportunity to upgrade the server’s architecture more thoroughly. Although 2011 seems a long time away, work has already begun to understand the technology trends that will exert an important influence over the Exchange development team. Given the current situation, competitive pressures, and what I call the “Exchange ecosystem,” what are the major influences that are likely to form Microsoft thinking on the next versions of Exchange? Like all pundits, I have my own theories and favorite technologies. The six areas I think are the most important for Microsoft to focus on are: automation, virtualization, mobility, unified communications (UC), information management, and Software as a Service (SaaS). Let me share my view of Microsoft’s evolving strategy with Exchange with you by beginning with a description of the Exchange ecosystem.

It’s the Ecosystem, not Exchange
Exchange sits in the middle of an ecosystem that has grown up around the application since Microsoft released Exchange 4.0 in 1996. It’s difficult for any software product to gain success on its own. Even with its marketing might, Microsoft couldn’t have sold more than 140 million licenses for Exchange without the presence of a huge number of third-party software companies that develop add-on products for Exchange. These developers have stuck with Exchange even as Microsoft switched APIs and product directions quite dramatically over the past decade. In 1996, third-party products filled in gaps by providing such technologies as messaging connectors to link Exchange to legacy email systems and fax. Today, the emphasis has shifted to areas such as information management and compliance. The change in focus represents new market opportunities that have opened up as technology evolves and as new gaps in Microsoft-provided functionality are exploited.

Microsoft has a complex balancing act to perform as the Exchange development group considers what new features to add in a new release of Exchange. The engineers want to work on new and exciting challenges. The marketing team wants to keep Exchange ultracompetitive against other email servers such as Lotus Notes and open-source messaging servers. Microsoft’s dilemma is that it can’t add features in a way that discourages thirdparty software developers from adding to the Exchange ecosystem. If Microsoft takes over an area, eliminating it as an opportunity for third parties, the ecosystem will degrade. What happened with antivirus is an obvious example. Microsoft bought Sybari, the industry antivirus leader, in 2005 and incorporated its technology— Forefront Security for Exchange—into the enterprise version of Exchange 2007. It’s difficult for a third party to pit its technology against Microsoft, and the once-vibrant antivirus add-on market for Exchange is now deflated. Microsoft has argued that moving into the antivirus space was crucial for providing out-of-the-box protection for Exchange. Given the amount of spam and threat-ridden email that floats around the Internet, it’s hard to argue against this. But my point is that Microsoft can’t move into too many new areas too quickly without negatively affecting the Exchange ecosystem, and this necessity tempers some of the development options the Exchange team can choose. Let’s now look in more depth at the six areas I believe Microsoft will need to focus on in its ongoing development of Exchange.

Automation
Customers have rightly criticized Microsoft in the past because Exchange lacked scripting capability to allow administrators to configure, maintain, and monitor servers. If you wanted to do something such as set the diagnostics level for a server, you looked through the GUI for an option on a property page or a command button, and if a Microsoft engineer hadn’t added the necessary option, you were out of luck. Administrators could enable some options by editing the system registry, and it was sometimes possible to script some options through Windows Management Instrumentation (WMI) or Outlook. All in all, it was a fragmented and unsatisfactory situation, but the introduction of Windows PowerShell support in Exchange 2007 changed all that. As Figure 1 shows, the Exchange development team uses PowerShell as a foundation for a set of nearly 400 commands that encapsulate the business logic for managing Exchange 2007. This logic used to be spread across the product and incorporated into the GUI, but now all of the management components consume the same set of commands and therefore the same business logic. The development team now has one place to make changes to update Exchange, and once made, changes are effective across the entire product.

But life isn’t perfect yet. For one thing, it took Microsoft far too long to introduce a common scripting language for Exchange. Some inconsistencies exist in syntax between different PowerShell commands, and because not all Microsoft development groups have incorporated PowerShell into their product plans, you can’t use native PowerShell commands to manage other parts of Windows that are important to Exchange, such as Active Directory (AD) except through WMI. However, you can expect PowerShell to evolve over time to a point where you’ll be able to perform the vast bulk of administrative tasks for a server and its applications through PowerShell commands.

I expect Microsoft to continue to improve the PowerShell environment by adding commands and the ability to manage more components within the Exchange ecosystem. I also expect that third-party software providers will enhance PowerShell with tools such as IDEs and additional commands. Finally, the power of the Internet will make PowerShell scripts and other code snippets available to the community for free reuse, in the same way people post code samples for other programming languages today. As the Exchange community becomes more proficient and inventive with PowerShell, you’ll see many more examples posted in a form of open-source community for Exchange.

Virtualization
It was easy to configure servers for applications in the early days of Windows because all you had to do was follow the “one application per server” rule. Some administrators still believe that Windows applications run best when they observe this guideline. It’s certainly true that this creates a simple Windows infrastructure that’s easy to manage, but the approach is outdated and wastes valuable computing resources. Server technologies began to outrun the ability of applications to keep them fully utilized some years ago: Server benchmarks for Exchange 5.5 in 1999 scaled up to much the same number of mailboxes that we run today. Workload characteristics have become more demanding, and the latest generation of 64-bit servers can support huge workloads, yet most servers deployed in datacenters are relatively underutilized.

Originally, Microsoft didn’t support virtualized Exchange because the Exchange team hadn’t had the opportunity to fully test Exchange running on a virtual server. Then, Microsoft said it would support a problem that occurred for Exchange on a virtual server if you could reproduce the problem on a standard server. Microsoft’s current support policy is to support Exchange 2003 on a virtual server if you run Microsoft Virtual Server 2005 R2 or later, but not VMware. (For more information, see the Microsoft article “Support policy for Exchange Server 2003 running on hardware virtualization software” at support.microsoft .com/kb/320220.) The situation for Exchange 2007 is more complicated because Exchange 2007 runs only on 64-bit servers and Microsoft doesn’t yet supply virtual server software that supports 64-bit guest systems, a situation that is expected to persist until Microsoft releases a new hypervisor in Windows Server Virtualization, codenamed “Viridian,” which isn’t expected until at least 180 days after the release of Windows 2008. You can run Exchange 2007 (including clusters) on VMware ESX Server as long as you’re willing to live with the restriction that Microsoft won’t support you in fixing a problem unless you can reproduce it on a standard server.

Virtualization will become increasingly important as servers become more powerful, virtualization software becomes more capable, and pressure on reducing IT costs continues. Microsoft is behind VMware in terms of features and performance today, but you can expect that the company will dedicate the necessary amount of focus and investment to make Windows a solid virtualization platform. In five years or so, we’ll likely run all Windows applications on virtual machines, and the notion of dedicating a server to one application will be obsolete.

Mobility
The major problem with mobility that enterprises are facing today is controlling the costs involved with acquiring and managing mobile devices, including securing the personal and corporate data contained in the email, contacts, and other information that the devices hold. Devices connected to Exchange can be grouped into three major families: Research in Motion’s (RIM’s) BlackBerry, Symbian, and Windows Mobile. Many BlackBerry users connect to their mailboxes through the Blackberry Enterprise Server, which handles the communication between Exchange and the device through a Network Operations Center (NOC) managed by a telecommunications provider. Although many devices that run the Symbian OS connect to Exchange through the IMAP4 or POP3 protocols, Symbian licensed the ActiveSync protocol from Microsoft in March 2005, and some newer devices can use ActiveSync to connect to Exchange. ActiveSync is built in to Windows Mobile devices, which can use client-side and server-side software to synchronize a device with Exchange. Serverside ActiveSync is incorporated in Exchange 2007 and Exchange 2003 SP2 and uses Over- The-Air (OTA) communication to synchronize email, calendar, tasks, and contact information through an encrypted HTTP Secure (HTTPS) connection.

You can connect a baffling array of devices to Exchange today. Each device is likely to have its own feature set depending on the device, OS version, and applications that the device vendor bundles with it. Enterprises might try to set corporate standards for mobile devices, but many users view these devices as personal tools and purchase their own. What results is that administrators might be expected to support requests to connect devices that they’ve never heard of to Exchange. The result of user-driven device choice is often poor support, high user frustration, higher corporate expense, and low levels of security. Except for those corporations that take a hard line toward the devices they’ll allow users to attach to their networks, the situation is unlikely to improve in the short term because analysts expect purchases of mobile devices to remain divided across the major device families. (See the sidebar “The Mobile Device Landscape” for a quick look at how market share for the three major device families is predicted to change over the next several years.)

Mobile devices will continue to evolve rapidly, and we can expect improved management capabilities for these devices in the upgraded versions within the 2009 to 2010 timeframe. Although Exchange 2007 includes a new version of ActiveSync that does a good job of synchronizing email, calendar, and tasks from user mailboxes with Windows Mobile devices, the surrounding management framework is weak. Microsoft is unlikely to engineer two competing products to manage Windows Mobile devices; over time, I expect that Microsoft’s focus for enterprise mobility management will be on System Center Mobile Device Management Server (SCMDM). In this scenario, management features available in Exchange will remain limited and will operate solely on policy settings that are required for email.

Unified Communications
To many, "unified communications" means voicemail integration with Exchange. Such integration isn't a new concept—vendors such as Nortel have supported voicemail integration for Exchange since the late 1990s, albeit only for specific PBXs and with some expensive hardware. The idea behind UC—being able to access information from many different sources in an integrated manner and appropriately to the device used—is compelling. Certainly, anyone who has used Exchange Server 2007 Unified Messaging (UM) would be unlikely to want to return to a traditional voicemail system.

What's changing today is the entry of Microsoft into the market with Exchange UM and a new version of Office Communications Server (OCS) in combination with Cisco's determination to leverage its predominance in networks and move into the applications area. Cisco Unity, which connects Exchange to voicemail via Cisco Call Manager, directly competes with Exchange UM. Microsoft is tackling the problem of how to integrate voice, data, and video by incorporating these capabilities into its applications. On the one hand, Microsoft is exploiting its huge installed base by driving down the price of applications like UM to encourage customers to move to those applications. On the other hand, Cisco is evolving its huge base of networking and products to add applications like Unity and powering the transition from older analog-based PBXs to VoIP to introduce customers to the possibilities of UC. Both companies say they're working together, but the reality is that we're likely to see full-blown competition to win market share. Of course, Microsoft and Cisco connect to different people within the overall customer base: Microsoft usually connects with teams responsible for deploying applications such as Exchange, whereas Cisco usually connects with the teams that provide network infrastructure and telephony services. In many cases, these teams aren't well integrated, which causes some tension internally. But competition usually drives innovation. With two heavyweights competing for leadership in UC, we can expect features and functionality in applications to improve, better integration with existing infrastructures, new devices (for example, new generations of VoIP phones), and lower costs.

Information Management
If you've been running Exchange for any length of time, it's likely that you have too much email in your databases. You undoubtedly have some important information locked up in the databases that isn't immediately accessible, and you might find that you need that information to comply with legislative or regulatory requirements. Microsoft designed Exchange to be an email server, not an information archiving and recovery system, and given the increasing demands on corporations to comply with regulations from the Health Insurance Portability and Accountability Act (HIPPA) to the Sarbanes-Oxley (SOX) Act to SEC 17-4a, there's a lot of activity within the Exchange ecosystem to provide information management solutions.

Work to figure out how best to manage the information held in Exchange databases began ten years ago. Symantec's Enterprise Vault product originally began as a project within Digital Equipment in 1997 to offload messages from Exchange and move them into a Hierarchical Storage Management (HSM)-like vault. At that time, storage was expensive and servers were hard-pressed to manage very large databases (and Exchange was restricted to a 16GB database). Over time, storage costs have come down, Exchange now supports huge databases running on 64-bit servers, Microsoft Volume Shadow Copy Service permits online snapshots to back up databases, and the challenge now focuses on mining information from Exchange for corporate purposes such as compliance. A wide variety of products help users and companies control information better. For example, ClearContext offers software to help Outlook users organize messages intelligently. HP, Commvault, Mimosa Systems, and CA all offer products that mine information from Exchange databases.

Microsoft introduced context-based indexing for databases in Exchange 2007. (Earlier attempts to provide similar functionality weren't successful because indexing stole too many system resources.) Outlook 2007 clients that work in cached Exchange mode use Windows Desktop Search (WDS) to initiate connections to PST files from their mailbox, as Figure 2 shows. Although current search technology can index the metadata from voice and graphic messages, it can't index the actual content. I expect this situation to change as R&D investments in new search technology result in the ability to index nontext content.

We can expect the overall volume of email to increase. To create a complete picture of corporate data, repositories other than mailboxes—such as SharePoint portals, team spaces, and public folders—will need to be searchable. I expect Microsoft to improve the search and retrieval capability in Exchange and to forge a closer connection with SharePoint (if only to bridge the gap that occurs around public folder migration), but I don't expect the company to enter the instant messaging (IM) arena.

Software as a Service
Microsoft's biggest challenge, both technically and economically, is to change the way users license and consume software from a closed system wherein users control the OS, server, and clients, to a system wherein users select applications that are delivered via the Internet. Notable examples of successful application delivery, such as Salesforce.com, already exist. Over the coming years, rapid growth in network availability coupled with lower cost and new Web-based programming models will deliver some real alternatives to the classic Windows+Exchange+Outlook solution for enterprise-grade email.

Google is most likely to compete with Microsoft in this space, and that company is already making the necessary investments to build a suite of programs that deliver Exchange-like functionality. Gmail today is a long way from being perfect, but it's already better than many corporate email systems were a few years ago and will benefit from Google's rapid-development model to add features and become more competitive against a full-function client like Outlook. Google may have to develop its own API to compete with the richness of MAPI because Internet protocols such as IMAP4 aren't rich enough to support the range of features that Outlook delivers.

Google is already pitching the prospect of email delivered via the Internet as a service to customers. Initial interest is from the education sector, rather than large enterprises. Universities are attracted by Google's single annual fee to deliver email, calendar, and IM. Breaking into the corporate sector won't be easy for Google because IT teams will ask questions about security, compliance, and management that Google might find difficult to answer today. But given time and development effort, it's likely that Google and perhaps other vendors will find answers that satisfy customers, perhaps first in the small to medium sector and then in large enterprises. Microsoft might respond to the threat by developing its Microsoft Live capabilities to achieve feature and cost parity with Google. The difficulty will be to develop a Microsoft email SaaS offering without decimating the Exchange installed base. In addition, Microsoft has to figure out how Exchange and any future email product will cooperate, interoperate, and coexist seamlessly so that customers will be able to deploy all or part of their organization on either or both platforms and have the ability to move data and mailboxes between them. This is a staggeringly complex challenge, but it's possibly the most important one for the long-term future of Exchange.

Time Will Tell
After some twelve years of development, there's still much for Microsoft to do to maintain Exchange's status. The only thing that you can be sure about technology is that it will change over time; the trick is to understand why technology changes and how the change will influence and affect customer options. The Exchange development group undoubtedly has a few tricks up its sleeve to excite and delight customers, but it would be surprising if it doesn't already have the technologies I've discussed here on its radar screen.

Tony Redmond