The fundamental capabilities of
Microsoft Exchange Server 2013 are impressive. Improvements to
security, reliability, and scalability enhance an already road-tested
and stable Exchange Server platform. Along with these impressive
credentials comes an equally impressive design task. Proper design of
an Exchange Server 2013 platform will do more than practically anything
to reduce headaches and support calls in the future. Many complexities
of Exchange Server might seem daunting, but with a full understanding
of the fundamental components and improvements, the task of designing
the Exchange Server 2013 environment becomes manageable.
1. Planning for Exchange Server 2013
Designing
Exchange Server used to be a fairly simple task. When an organization
needed email and the decision was made to go with Exchange Server, the
only real decision to make was how many Exchange
servers were needed. Primarily, organizations really needed only email
and eschewed any “bells and whistles.”
Exchange
Server 2013, on the other hand, takes messaging to a whole new level.
No longer do organizations require only an email system, but they now
require a high level of system availability and resilience and other
messaging and unified communications functionality. After the
productivity capabilities of an enterprise email platform have been
demonstrated, the need for more productivity improvements arises.
Consequently, it is wise to understand the integral design components
of Exchange Server before beginning a design project.
1.1 The Evolution of Exchange Server 2013
Exchange
Server 2013 is the evolution of a product that has consistently been
improving over the years from its roots. Since the Exchange 5.x days,
Microsoft has released dramatic improvements with the 2000 and 2003
versions of the product. Microsoft then followed upon the success of
Exchange Server 2003 with some major architectural changes with
Exchange Server 2007 and Exchange Server 2010. This latest version,
Exchange Server 2013, uses a similar architecture to both Exchange
Server 2007 and 2010, but adds further improvements in key areas and
simplifies others.
The major areas of
improvement in Exchange Server 2013 include many of the concepts and
technologies introduced in Exchange Server 2007 and Exchange Server
2010 but expand upon them and include additional improvements. Key
areas improved upon in Exchange Server 2013 architecture include the
following:
• Simplified and streamlined role architecture—Exchange
Server 2013 simplifies the roles that were introduced in Exchange
Server 2007 and Exchange Server 2010, collapsing the Transport roles
and Unified Messaging roles into the Mailbox and Client Access Server
(CAS) roles, simplifying architecture and providing for design options
that were previously unavailable, such as the ability to separate CAS
and Mailbox servers geographically. In addition, CAS servers are now
stateless, which allows them to be used by any type of load balancer.
• Database availability groups (DAGs)—The
Exchange Server 2007 concept of Cluster Continuous Replication (CCR)
was replaced with a concept called database availability groups in
Exchange Server 2010. DAGs, as they are known, remain available in
Exchange Server 2013, and allow a copy of an Exchange Server mailbox
database to exist in up to 16 locations within an Exchange Server
organization.
• Transport and access improvements—All
client access continues to be funneled through the CAS role in an
organization, which allows for improvements in client access and
limited end-user disruption during mailbox moves and maintenance.
• Integrated archiving capabilities—Exchange
Server 2013 users and administrators have the ability to archive
messages for the purpose of cleaning up a mailbox of old messages, as
well as for legal reasons for applying a retention policy on key messages.
Users can simply drag and drop messages into their archive folders, or
a policy or rule can be set to have messages automatically moved to the
archive folder.
• “Access anywhere” improvements—Microsoft
has focused a great deal of Exchange Server 2013 development time on
new access methods for Exchange Server, including a greatly enhanced
Outlook Web App (OWA) that works with Microsoft and a variety of
third-party browsers, Microsoft ActiveSync improvements, Unified
Messaging built in, and Outlook Anywhere enhancements. Having these
multiple access methods greatly increases the design flexibility of
Exchange Server because end users can access email via multiple methods.
• Protection and compliance enhancements—Exchange
Server 2013 now has antispam and anti-malware protection built in
natively, protecting end users from malicious content. Compliance
policies can also be more easily created.
• Admin tools improvements and Exchange PowerShell scripting—Introduced
as the primary management tool for Exchange Server 2007, Exchange
Server 2013 improves upon PowerShell capabilities and adds additional
PowerShell applets and functions. The main graphical user interface
(GUI) has also been moved to a Metro UI–style Web console that is
accessed through the CAS role. Finally, new split permissions models
can be created, which allows Active Directory (AD) and Exchange
administrators to have completely separate admin models.
It
is important to incorporate the concepts of these improvements into any
Exchange Server design project because their principles often drive the
design process.
1.2 Reviewing Exchange Server and Operating System Requirements
Exchange
Server 2013 has some specific requirements, both hardware and software,
that must be taken into account when designing. These requirements fall
into several categories:
• Hardware
• Operating system
• Active Directory
• Exchange Server version
Each requirement must be addressed before Exchange Server 2013 can be deployed.
Reviewing Hardware Requirements
It
is important to design Exchange Server hardware to scale out to the
user load, which is expected for at least three years from the date of
implementation. This helps retain the value of the investment put into
Exchange Server.
Reviewing Operating System (OS) Requirements
Exchange
Server 2013 is optimized for installation on Windows Server 2008 R2
with Service Pack 1 (SP1) or Windows Server 2012. These versions of
Windows provide the basis for many of the improvements in Exchange
Server 2013. The specific compatibility matrix, which indicates
compatibility between Exchange Server versions and operating systems,
is illustrated in Table 1.
Table 1. Exchange Server Version Compatibility
Understanding Active Directory Domain Services (AD DS) Requirements
Exchange
Server originally maintained its own directory. With the advent of
Exchange 2000 Server, however, the directory for Exchange Server was
moved to Microsoft Active Directory Domain Services, the enterprise
directory system for Windows. This gave greater flexibility and
consolidated directories but at the same time increased the complexity
and dependencies for Exchange Server. Exchange Server 2013 uses the
same model but requires specific AD functional levels and domain
controller specifics to run properly.
Exchange
Server 2013, while requiring an AD forest in all deployment scenarios,
has certain flexibility when it comes to the type of AD it uses. It
also provides for new capabilities to completely separate domain
administrative rights from Exchange rights, a new feature that will be
well appreciated by those organizations that have those administrative
duties separated.
From an AD DS design perspective, it is possible to deploy Exchange Server in the following scenarios:
• Single forest—The
simplest and most traditional design for Exchange Server is one where
Exchange Server is installed within the same forest used for user
accounts. This design also has the least amount of complexity and
synchronization concerns to worry about.
• Resource forest—The
Resource forest model in Exchange Server 2013 involves the deployment
of a dedicated forest exclusively used for Exchange Server itself, and
the only user accounts within it are those that serve as a placeholder
for a mailbox. These user accounts are not logged on to by the end
users, but rather the end users are given access to them across
cross-forest trusts from their particular user forest to the Exchange
Server forest.
• Multiple forests—Different
multiple forest models for Exchange Server are presently available, but
they do require a greater degree of administration and synchronization.
In these models, different Exchange Server organizations live in
different forests across an organization. These different Exchange
Server organizations are periodically synchronized to maintain a common
Global Address List (GAL).
It
is important to determine which design model will be chosen before
proceeding with an Exchange Server deployment because you cannot rename
a domain that contains an Exchange server and cannot move an Exchange
server to another domain.
Outlining Exchange Server Version Requirements
As
with previous versions of Exchange Server, there are separate
Enterprise and Standard versions of the Exchange Server 2013 product.
The Standard Edition supports all Exchange Server 2013 functionality
with the exception of the fact that it is limited to no more than five
databases on a single server.
Note
Unlike many of the other previous
versions of the software, Microsoft provides only a single set of media
for Exchange Server 2013. When installed, server version can be set by
simply entering a license key. A server can be upgraded from the Trial
version to Standard or Enterprise or from Standard to Enterprise.
Downgrading the version is not supported.
1.3 Scaling Exchange Server 2013
Exchange
2000 Server originally provided the basis for servers that could easily
scale out to thousands of users in a single site, if necessary.
Exchange Server 2003 further improved the situation by introducing
Messaging Application Programming Interface (MAPI) compression and RPC
over HTTP. Exchange Server 2007 and Exchange Server 2010 and their
64-bit architecture allowed for even further scalability and reduced
I/O levels. Finally, Exchange Server 2013 and the separation of client
traffic to load-balanced client access servers enable the client tier
to be much more scalable than with previous versions.
Site
consolidation concepts enable organizations that might have previously
deployed Exchange servers in remote locations to have those clients
access their mailboxes across wide area network
(WAN) links or dial-up connections by using the enhanced Outlook or OWA
clients. This solves the problem that previously existed of having to
deploy Exchange servers and global catalog (GC) servers in remote
locations, with only a handful of users, and greatly reduces the
infrastructure costs of setting up Exchange Server.
1.4 Having Exchange Server 2013 Coexist with an Existing Network Infrastructure
In
a design scenario, it is necessary to identify any systems that require
access to email data or services. For example, it might be necessary to
enable a third-party monitoring application to relay mail off the
Simple Mail Transfer Protocol (SMTP) engine of Exchange Server so that
alerts can be sent. Identifying these needs during the design portion
of a project is subsequently important.
1.5 Identifying Third-Party Product Functionality
Microsoft
built specific hooks into Exchange Server 2013 to enable third-party
applications to improve upon the built-in functionality provided by the
system. For example, built-in support for antivirus scanning, backups,
and Unified Messaging exist right out of the box, although
functionality is limited without the addition of third-party software.
The most common additions to Exchange Server implementation are the
following:
• Antivirus (though it is important to note that Exchange Server 2013 now has these features built in)
• Backup
• Phone/PBX/Unified Messaging integration
• Fax software
• Archiving software
