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.
Previous
Register
