The benefit of hindsight is a wonderful gift to technologists. It lets us understand how changes that were made in the past laid the foundation for
current capabilities. In the case of Microsoft Exchange Server, three types of deployment are now possible: classic on-premises, cloud with Microsoft
Office 365, and hybrid, in which some parts of the infrastructure reside on premises and some reside in the cloud.
Exchange didn't arrive at this point by accident. The Exchange development group has done a lot of heavy lifting over the past decade so that customers
can enjoy the choices they have today. Looking back, I see seven important areas in which innovation has liberated Exchange from its origins as a
LAN-based email server running on Windows NT. Apart from all else, I think that these areas represent the most crucial areas for Exchange
administrators to master in the foreseeable future.
The Magnificent Seven
Perhaps it's unfair to focus on just seven areas, when Exchange is now a huge product that spans well over 20 million lines of code. I freely admit
that other areas of innovation within Exchange deserve consideration.
For example, there's the elegance of single page patching within a database availability group (DAG). This implementation allows the Information Store
to detect page corruptions and then broadcast requests to other database copies to retrieve the data necessary to fix the problem, all while keeping
the database online and serving users.
Even so, I'm happy to stay with the group that I've selected. In no particular order of importance, these are my chosen areas of innovation:
1. Remote Procedure Call (RPC) over HTTP
2. Windows PowerShell
3. Autodiscover service
4. Mailbox Replication Service (MRS)
5. Multibrowser interfaces
6. Storage improvements
7. Client Access server
Now, let me explain my logic.
#1: RPC over HTTP: Eliminating VPNs
In the early days of Exchange, remote access was characterized by synchronization woes, slow dial-up connections, and VPNs. Improvements in client
technology -- such as the drizzle-mode synchronization that Microsoft Office Outlook 2003 introduced -- and the now-ubiquitous nature of fast wireless
connections have eliminated the first two issues. And the need to establish a VPN before connecting to Exchange was firmly whacked on the head by the
introduction of RPC over HTTP in Exchange Server 2003.
Now known as Outlook Anywhere, RPC over HTTP was initially difficult to configure. Those who persisted and published the necessary public connectivity
points discovered that Outlook could connect easily. Furthermore, it could use the public Internet to transport, safely encapsulated in HTTP packets,
the Messaging API (MAPI) remote procedure calls (RPCs) that form the basis of any communication between Outlook and Exchange. Administrators loved the
fact that ports 80 and 443 were the only ones that they needed to open in the firewall, especially because these ports are usually open to support
other web-based applications.
Since Exchange 2003, Microsoft has gradually improved the configuration and management of this component. Now, Outlook Anywhere is a real strength of
the product, so much so that it provides the fundamental underpinning of both Microsoft Business Productivity Online Standard Suite (BPOS) and Office
365.
After all, requiring every customer to create a VPN to access Microsoft Exchange Online would be impossible and too expensive to create and maintain
for many small-to-midsized businesses (SMBs). Such a requirement would also create a huge burden for Microsoft, which would need to manage the incoming
VPN connections.
Simply put, Outlook Anywhere allows everyone to connect across the Internet. Plus, the $6 per month price point for Office 365 is feasible. That's why
RPC over HTTP is #1 on my list.
#2: PowerShell: Delivering a Common Management Platform
PowerShell might seem a strange choice for #2. But its introduction in Exchange Server 2007 and subsequent upgrade to remote PowerShell in Exchange
Server 2010 have delivered many benefits. First, PowerShell provides consistency across the management interfaces within Exchange. In other words, you
can use the Exchange Control Panel (ECP) to update a mailbox's properties in Office 365, or you can run the Set-Mailbox cmdlet by using PowerShell.
Both routes lead to the execution of the same logic.
But my main reason for selecting this component is that the advent of remote PowerShell delivers the ability to manage Exchange Online without needing
to log on to the servers on which Exchange runs. Obviously, Microsoft couldn't permit thousands of Office 365 customers access to mailbox or Hub
Transport servers. But remote PowerShell allows domain administrators to connect across the Internet and validate their credentials for a tailored
session that contains the exact set of cmdlets that they're allowed to run. And because PowerShell forces all paths to the same logic, the user can
connect by running Exchange Management Shell (EMS), or through ECP, or through the Microsoft Management Console (MMC)-based Exchange Management Console
(EMC): Everything works in the same way. That's why PowerShell is my #2 choice.
#3: Autodiscover: Solving User Pain
Microsoft introduced the Autodiscover service in Exchange 2007 as a solution for the perennial problem in which users had trouble configuring Outlook
with the parameters that were necessary to connect to Exchange. The basic difficulty: Server names that make perfect sense to administrators put users
into a deep sleep. Apparently, regular users have problems coping with names such as EXSERVER1 or MBXHUB-LONDON.
Microsoft figured out that the issue could be solved by making computers communicate to figure out a user's mailbox location. That's what Autodiscover
does, by consulting signposts such as a service connection point (SCP) in Active Directory (AD) to retrieve information about Exchange and to discover
a mailbox's current location. Of course, AD is available only inside a firewall, but Autodiscover can use URLs that are published to the public
Internet to retrieve what it needs. This capability laid the foundation to allow easy connection to Exchange Online in BPOS and Office 365. Without
Autodiscover, administrators would face far more complexity and cost when they configured user PCs to connect to the cloud.