Getting started with Exchange 2013 and Exchange Online
You can implement Exchange services in several ways, including:
-
On-premises
. With an on-premises implementation, you deploy
Exchange server hardware on your network and manage all aspects of the
implementation, including server configuration, organization
configuration, and recipient configuration.
-
Online
. With an online (or cloud-only) implementation, you
rely on hardware and services provided by Microsoft. All aspects of the
server configuration are managed by Microsoft. You manage the
service-level settings, organization configuration, and recipient
configuration.
-
Hybrid
. With a hybrid implementation, you integrate
on-premises and online implementations. The on-premises and Exchange
Online organizations use a shared domain namespace, so mail is securely
routed between them, and you can easily share data between the
implementations.
When you use an online implementation, Microsoft manages the
hardware configuration and ensures availability. Otherwise, you are
responsible for any on-premises hardware.
Exchange Server 2013 builds on the radical changes in Exchange
Server 2010 but is vastly different from Exchange Server 2010. Like
Exchange Server 2010, Exchange Server 2013 does away with the concepts
of storage groups, Local Continuous Replication (LCR), Single Copy
Clusters (SCC), and clustered mailbox servers. This means that:
-
Databases are no longer associated with storage groups.
-
Database availability groups are used to group databases for high availability.
-
Databases are managed at the organization level instead of at the server level.
Exchange Server 2013 integrates high availability into the core
architecture by enhancing aspects of Cluster Continuous Replication
(CCR) and Standby Continuous Replication (SCR) and combining them into
a single, high-availability solution for both on-site and off-site data
replication. Exchange Server 2013 also provides for automatic failover
and recovery without requiring clusters when you deploy multiple
mailbox servers. Because of these changes, building a high-availability
mailbox server solution doesn’t require cluster hardware or advanced
cluster configuration. Instead, database availability groups provide
the base component for high availability. Failover is automatic for
mailbox databases that are part of the same database availability group.
The
basic rules for database availability groups have not changed since
implementation in Exchange Server 2010. Each mailbox server can have
multiple data-bases, and each database can have as many as 16 copies. A
single database availability group can have up to 16 mailbox servers
that provide automatic database-level recovery. Any server in a
database availability group can host a copy of a mailbox database from
any other server in the database availability group.
This seamless high-availability functionality is possible because
mailbox databases are disconnected from servers and the same globally
unique identifier (GUID) is assigned to every copy of a mailbox
database. Because there are no storage groups, continuous replication
occurs at the database level. Transaction logs are replicated to each
member of a database availability group that has a copy of a mailbox
database and are replayed into the copy of the mailbox database.
Failover can occur at either the database level or the server level.
Exchange Server 2013 has a significantly different architecture than
its predecessors. While Exchange 2007 and Exchange 2010 components were
split into different server roles for scaling out Exchange
organizations, Exchange 2013 streamlines the server roles and
architecture while still allowing you to fully scale Exchange
organizations to meet the needs of enterprises of all sizes.
Specifically, Exchange 2013 does not have separate server roles for Hub
Transport servers or Unified Messaging servers. The related components
are now part of the Mailbox Server role. This results in significant
changes to mail flow and is one of many reasons the Information Store
processes were rewritten in Exchange 2013. The new Information Store
(Microsoft.Exchange.Store.Service.exe) is written in C# and is fully
integrated with the Microsoft Exchange Replication service
(MSExchangeRepl.exe) and the Microsoft Exchange DAG Management service
(MSExchangeDagMgmt.exe). Additionally, each database now runs under its
own process, which helps to isolate any issues with the Managed Store
to a particular database.
Other than the Mailbox Sever role, the only other installable role
for Exchange 2013 is the Client Access server role, which also can be
installed on a Mailbox server. Every Exchange 2013 organization needs
at least one Mailbox server and at least one Client Access server.
While you can install both roles on a single server, you cannot later
uninstall one role without uninstalling the other role. Further,
Exchange 2013 as originally released doesn’t include an Edge Transport
role or functionality (though this may be released in a future update
to Exchange 2013).
Although you can continue to use separate Client Access servers, the
related architecture has changed considerably as well. The Mailbox
server role includes the client access protocols and handles all
activity for mailboxes. Client Access servers, on the other hand, are
thin and stateless. They don’t queue any data. They don’t process or
render data. They serve only to provide authentication, limited
redirection, and proxy services.
These
architecture changes mean that Exchange 2013 server roles are now
loosely coupled rather than tightly coupled, which eliminates any
previous session affinity requirements. The Mailbox server that stores
the active database copy for a mailbox performs all the data
processing, data rendering, and data transformation required. The
Client Access server connects the client to the Mailbox server and
performs authentication, redirection, and proxying only as needed.
Because there is no required session affinity between the Mailbox
server and the Client Access server, connections proxied by a Client
Access server can be balanced using basic load-balancing technologies
such as round robin Domain Name System (DNS) and least connection.
Supported protocols for client connections include HTTP, POP, IMAP, RPC
over HTTP, and SMTP. As RPC is no longer supported as a direct access
protocol, all Outlook client connections must take place using RPC over
HTTP.
It’s important to point out that Exchange 2013 is designed to work
with Outlook 2007 and more recent versions and also continues to
support Outlook Web App for mobile access. Rather than connecting to
servers using Fully Qualified Domain Names as was done in the past,
Outlook 2007 and more recent versions use Auto-discover to create
connection points based on the domain portion of the user’s primary
SMTP address and each mailbox’s Globally Unique Identifier (GUID).
The simplified architecture reduces the namespace requirements for
Exchange site designs. If you’re coexisting with Exchange 2010 or
you’re installing a new Exchange 2013 organization, you need only one
namespace for client protocols and one namespace for Autodiscover. To
continue to support SMTP, you also need an SMTP namespace.
For Exchange 2013, you’ll ideally want to deploy Mailbox
servers on hardware that easily scales up while building Client Access
servers with scaling out in mind.
