2. Determining Hardware and Software Components
Justifying
hardware and software purchases is often a difficult task for
organizations of any size. It is, therefore, important to balance the
need for performance and redundancy with the available funds in the
budget, and, thus, deploy the optimal Exchange Server hardware and
software configuration.
Unlike some of the
older versions of Exchange Server, Exchange Server 2013 requires the
use of 64-bit capable systems, so it is critical to order the
appropriate equipment when deploying Exchange Server 2013 systems.
Designing Server Number and Placement
Exchange
Server scales very well to a large number of mailboxes on a single
machine, depending on the hardware chosen for the Exchange server.
Subsequently, Exchange Server 2013 is optimal for organizations that
want to limit the amount of servers that are deployed and supported in
an environment.
Some of the older versions
of Exchange Server required a local Exchange presence in each office
location, as they didn’t support cross-WAN mailbox access very
efficiently. Exchange Server 2013, on the other hand, expands upon the
concept of site consolidation, introduced in Exchange Server 2003. This
concept enables smaller sites to use the Exchange servers in the larger
sites through the more efficient bandwidth usage present in Outlook
2007 and Outlook 2003 and other mobile technologies. It also allows for
the previously unheard of scenario of separating out Client Access
servers from their equivalent Mailbox servers in situations where it
makes sense to have those roles in separate geographical locations.
Providing for Server Redundancy and Optimization
The
ability of the Exchange server to recover from hardware failures is
more than just a “nice-to-have” feature. Many server models come with
an array of redundancy features, such as multiple fans and power
supplies and mirrored disk capabilities. These features incur
additional costs, however, so it is wise to perform a cost-benefit
analysis to determine what redundancy features are required. Midsize
and larger organizations should seriously consider robust redundancy
options, however, because the increased reliability and uptime is often
well worth the up-front costs.
Exchange
Server 2013 further expands the redundancy options with the concept of
database availability groups (DAGs), which enable a mailbox database to
reside in up to 16 different locations at one time. This allows for
unprecedented levels of redundancy and frees the
architect from the requirement of focusing heavily on server-level
redundancy because the loss of a single server is no longer a
catastrophic event.
One of the most
critical but overlooked performance strategies for Exchange Server is
the concept of separating the Exchange Server logs and database onto
separate physical drive sets. Because Exchange Server logs are very
write-intensive, and the database is read-intensive, having these
components on the same disk set would degrade performance. Separating
these components onto different disk sets, however, is the best way to
get the most out of Exchange Server.
Reviewing Server Memory and Processor Recommendations
Exchange
Server is a resource-hungry application that, left to its own devices,
will consume a good portion of any amount of processor or memory that
is given to it. The amount of processors and random access memory (RAM)
required should reflect the budgetary needs of the organization. In
general, midsize and larger organizations should consider
multiprocessor servers and greater amounts of RAM—16GB or 32GB or more.
This helps increase the amount of mailboxes that can be homed to any
particular server.
Outlining Server Operating System Considerations
The
base operating system (OS) for Exchange Server, Windows Server, comes
in two versions, Enterprise and Standard. Some midsize and larger
organizations could deploy the Enterprise Edition of the Windows Server
product, namely for clustering support for database availability
groups. If this functionality is not required, the Standard Edition of
the OS is sufficient.
3. Designing Exchange Server Roles in an Exchange Server Environment
Exchange
Server 2013 was designed to be resilient and be able to adapt to a wide
variety of deployment scenarios. Part of this design revolves around
the concept that individual servers can play one or more roles for an
organization. Each of these roles provides for specific functionality
that is commonly performed by Exchange servers, such as the Mailbox
server or Client Access server (CAS). You’ll also immediately note that
the Unified Messaging and Hub Transport roles have been retired, as
their functionality has been rolled up into the CAS and Mailbox roles.
Central
to the understanding of Exchange Server 2013 and how to design and
architect it is the understanding of these individual roles. During the
design process, understanding server roles is central to proper server
placement.
The individual server roles in Exchange Server 2013 are as follows:
• Mailbox server role
• Client Access server role
Each of these roles is described in more detail in the subsequent sections.
Planning for the Mailbox Server Role
The
Mailbox server role is the central role in an Exchange Server topology
as it is the server that stores the actual mailboxes of the user.
Therefore, Mailbox servers are often the most critical for an
organization, and are given the most attention.
With
the Enterprise Edition of Exchange Server, a Mailbox server can hold
anywhere from one to thousands of databases on it. Each of the
databases are theoretically unlimited in size, although it is wise to
keep an individual database limited to 100GB or less for performance
and recovery scenarios.
Note
In large organizations, a single server or a
cluster of servers is often dedicated to individual server roles. That
said, a single server can also be assigned other roles, such as the
Client Access server role, in the interest of consolidating the number
of servers deployed.
Planning for the Client Access Server Role
The
Client Access server role in Exchange Server is the role that controls
access to mailboxes from all clients, including the full version of
Outlook. It is the component that controls access to mailboxes via the
following mechanisms:
• Outlook Web App (OWA)
• Exchange ActiveSync
• Outlook Anywhere (formerly RPC over HTTP), which is now Outlook’s preferred connection method now that MAPI RPC is gone
• Post Office Protocol 3 (POP3)
• Internet Message Access Protocol (IMAP4)
• The Exchange Administration Center (EAC) that is used to administer Exchange mailboxes and settings
•
Exchange Web Services provides support to Outlook 2011 for Mac,
Entourage 2008 Web Services Edition, and other similar client and
application software
In addition, CAS systems also handle the following two special services in an Exchange Server topology:
• Autodiscover service—The
Autodiscover service allows clients to determine their synchronization
settings (such as Mailbox server and so on) by entering in their Simple
Mail Transfer Protocol (SMTP) address and their credentials. It is
supported across standard OWA connections.
• Availability service—The
Availability service is the replacement for free/busy functionality in
Exchange Server 2000/2003. It is responsible for making a user’s
calendar availability visible to other users making meeting requests.
Client
Access servers in Exchange Server 2013 are the only way that clients
can access their mailbox in Exchange Server 2013, which differs from
previous versions of Exchange Server that required direct access to
Mailbox servers. By separating client traffic to a load-balanced array
of CAS servers, Exchange Server architects have more flexibility in
design and failover; using concepts such as DAGs becomes easier and
more efficient.
Finally, the CAS role has
been made to be completely stateless in this version of Exchange, which
means that architects have the flexibility to use software-based load
balancing, hardware-based load balancing, or even potentially simple
solutions, such as DNS Round Robin. That said, it’s still not very
effective to use concepts like DNS Round Robin, and a good
hardware-based load balancer is required, though it is no longer
required to use session-based affinity (stickiness) for the traffic.
Understanding a Sample Deployment Scenario
A
better understanding of Exchange Server roles can be achieved by
looking at sample deployment scenarios that utilize these roles. For
example, Figure 2 illustrates a large enterprise deployment of Exchange Server that takes advantage of all of the unique server roles.
Figure 2. Examining an Enterprise Exchange Server deployment.
In this design, the following key deployment features are illustrated:
•
DAGs are distributed across multiple Mailbox servers, with at least
three copies of each mailbox database across the organization.
• Mailbox servers automatically distribute mail between the two major sites in San Francisco and Zurich.
• Medium-sized sites such as Kiev and Lisbon make use of combined CAS/Mailbox server systems.
• Dedicated Client Access servers are set up in the two main sites, to provide for client access mechanisms in those sites.
•
Smaller sites, such as Minneapolis, Odessa, and Singapore, have their
mailboxes hosted in the two hub locations and use the Client Access
servers with Outlook Anywhere to access their mailboxes remotely.
