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 2010, on the other hand, takes messaging to a whole new level.
No longer do organizations require only an email system, but 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.
Outlining Significant Changes in Exchange Server 2010
Exchange Server 2010 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 Exchange 2000 Server and later
Exchange Server 2003. Microsoft then followed upon the success of
Exchange Server 2003 with some major architectural changes with Exchange
Server 2007. This latest version, Exchange Server 2010, uses a similar
architecture to Exchange Server 2007 but adds, extends, and perfects
elements of Exchange Server design.
The major areas of
improvement in Exchange Server 2010 include many of the concepts and
technologies introduced in Exchange Server 2007 but expand upon them and
include additional improvements. Key areas improved upon in Exchange
Server 2010 architecture include the following:
Database Availability Groups (DAGs)—
The Exchange Server 2007 concept of Clustered Continuous Replication
(CCR) has been greatly improved and replaced with a concept called
Database Availability Groups (DAGs), which allow a copy of an Exchange
Server mailbox database to exist in up to 16 locations within an
Exchange Server organization. Because Continuous Replication is no
longer limited to two servers, there is no longer any need for concepts
such as Standby Continuous Replication (SCR) or Local Continuous
Replication (LCR) because they are all superseded by DAG technology.
Transport and access improvements—
All client access is now funneled through the Client Access server
(CAS) role in an organization, which allows for improvements in client
access and limited end-user disruption during mailbox moves and
maintenance. In addition, Exchange Server 2010 guards against lost
emails due to hardware failures by keeping “shadow copies” of mail data
on Hub and Edge Transport servers that can be re-sent in the event of
loss.
Integrated archiving capabilities—
Exchange Server 2010 provides users and administrators 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. In addition, a second archive mailbox can be associated
with a user’s primary mailbox, allowing seamless access to the archived
messages from OWA or full Outlook. Users can simply drag and drop
messages into their archive folder, 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 2010 development
time on new access methods for Exchange Server, including an enhanced
Outlook Web App (OWA) that works with a variety of Microsoft and
third-party browsers, Microsoft ActiveSync improvements, improved Outlook
Voice Access (OVA), unified messaging support, 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 2010 now includes a variety of antispam, antivirus, and
compliance mechanisms to protect the integrity of messaging data.
Exchange Server 2010 also includes the capability to establish a second,
integrated archive mailbox for users that is made available through all
traditional access mechanisms, including OWA. This allows for older
archived items to be available to users without the mail actually being
stored in the individual’s mailbox, enabling an organization to do
better storage management and content management of mail messages
throughout the enterprise.
Admin tools improvements and Exchange PowerShell scripting—
Introduced as the primary management tool for Exchange Server 2007,
Exchange Server 2010 improves upon PowerShell capabilities and adds
additional PowerShell applets and functions. Indeed, the graphical user
interface (GUI) itself sits on top of the scripting engine and simply
fires scripts based on the task that an administrator chooses in the
GUI. This allows for an unprecedented level of control.
It is important
to incorporate the concepts of these improvements into any Exchange
Server design project because their principles often drive the design
process.
Reviewing Exchange Server and Operating System Requirements
Exchange Server 2010
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 2010 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 up to 3 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
2010 is optimized for installation on Windows Server 2008 (Service Pack 2
or later) or Windows Server 2008 R2. The increases in security and the
fundamental changes to Internet Information Services (IIS) in Windows
Server 2008 provide the basis for many of the improvements in Exchange
Server 2010. 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
Version | Win NT 4.0 | Windows 2000 | Windows 2003 | Windows 2003 R2 | Windows 2008 | Windows 2008 R2 |
---|
Exchange Server 5.5 | Yes | Yes | No | No | No | No |
Exchange 2000 Server | No | Yes | No | No | No | No |
Exchange Server 2003 | No | Yes | Yes | Yes | No | No |
Exchange Server 2007 | No | No | Yes | Yes | Yes | Yes |
Exchange Server 2010 | No | No | No | No | Yes | Yes |
Understanding Active Directory (AD) Requirements
Exchange Server
originally maintained its own directory. With the advent of Exchange
2000 Server, however, the directory for Exchange Server was moved to the
Microsoft Active Directory, 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 2010 uses the same model but requires specific
AD functional levels and domain controller specifics to run properly.
Exchange Server 2010, while
requiring an AD forest in all deployment scenarios, has certain
flexibility when it comes to the type of AD it uses. 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 2010 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 onto 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 it is complex and expensive to
change the AD structure of Exchange Server after it has been deployed.
Outlining Exchange Server Version Requirements
As with previous
versions of Exchange Server, there are separate Enterprise and Standard
versions of the Exchange Server 2010 product. The Standard Edition
supports all Exchange Server 2010 functionality with the exception of
the fact that it is limited to no more than five databases on a single
server.
Note
Unlike previous
versions of the software, Microsoft provides only a single set of media
for Exchange Server 2010. When installed, server version can be set by
simply inputting a licensed key. A server can be upgraded from the Trial
version to Standard/Enterprise or from Standard to Enterprise. It
cannot, however, be downgraded.
Scaling Exchange Server 2010
Exchange 2000 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
its 64-bit architecture allowed for even further scalability and
reduced IO levels. Finally, Exchange Server 2010 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 2007/2010 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.
Having Exchange Server 2010 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.
Identifying Third-Party Product Functionality
Microsoft
built specific hooks into Exchange Server 2010 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
Backup
Phone/PBX integration
Fax software