Installing an Exchange Server is
like taking a hike through the woods. If you have a map and can
accurately follow the directions, you can quickly and safely arrive at
your destination. If you get lost in the process (or try to “wing it”),
you might or might not reach your destination, but even if
you do, it is likely that you will take a lot longer and travel over
more challenging roads.
To those who have
worked with Exchange Server 2010 in the past, the Exchange Server 2013
Installation Wizard will seem familiar. The wizard walks the
administrator through the installation of updates, checks for the
necessary prerequisites and allows for the selection of specific server
roles for deployment. However, the installation wizard does not
cover all twists and turns. There are steps that must be taken to
prepare the Active Directory (AD) environment and steps that must be
taken to prepare the underlying operating system on the server you are
installing on.
1. Understanding the Exchange Server 2013 Server Roles
As
with Exchange Server 2010, Exchange Server 2013 has various roles that
can be installed on the server to perform specific functions. With
Exchange Server 2010, there were five major server roles. The original
design intent dating back to Exchange Server 2007 was to allow the
roles to be modular where they could reside on a single server (for
small environments) or be distributed to multiple servers throughout an
organization.
However, even as the roles
evolved in Exchange Server 2010, the reality was that they remained
tightly coupled, presenting real-world restrictions on how they could
be distributed on servers geographically. With the goal of improving
hardware utilization, deployment simplicity, cross-version
interoperability, and failure isolation, which can serve self-hosted
small organizations to Office 365, Microsoft invested in a major
re-architecture of Exchange to realign the roles into the following two
(primary) roles:
• Client Access server role
• Mailbox server role
Client Access Server Role—Providing User Connectivity and Mail RoutingThe
Exchange Server 2013 Client Access servers assume the roles formerly
handled by the Exchange Server 2010 Client Access and Hub Transport
roles. The Client Access servers are responsible for accepting
connections from clients and proxy requests to the back-end Mailbox
servers. Like the front-end servers found in Exchange Server 2003,
Client Access servers manage connectivity via Outlook Web App (OWA) and
ActiveSync, and like the Client Access servers in Exchange Server 2007,
they also manage connectivity from Post Office Protocol (POP) and
Internet Message Access Protocol (IMAP) users. Exchange Server 2010
Client Access servers added the ability to also manage Messaging
Application Programming Interface (MAPI) (such as Outlook) client
connectivity. In a pure Exchange Server 2010 environment, clients never
had to connect directly to their Mailbox servers—all connectivity was
to the Client Access server. The Exchange Server 2013 Client Access
servers perform authentication, redirection, and proxy services for all
clients, such as Microsoft Office Outlook, Outlook Web App, mobile
devices, Simple Mail Transfer Protocol (SMTP), and POP, as well as
accepting and delivering mail from and to other mail hosts on the
Internet.
Client
Access servers can be organized into Client Access server arrays. By
taking responsibility for managing these additional connections, Client
Access servers allow Mailbox servers to focus on their primary
role—processing messaging requests.
Mailbox Server Role—What It’s All About
The
Mailbox server role is the core role within Exchange Server 2013.
Mailbox servers host the servers that contain mailboxes, mail-enabled
objects such as contacts and distribution lists, as well as public
folder data. In Exchange Server 2013, the public folders architecture
uses mailboxes to store both the hierarchy and public folder content.
Public folder databases have been eliminated. High availability for the
hierarchy and content mailboxes can be provided through database
availability groups (DAGs).
The Mailbox
server runs two Transport services. The Hub Transport service routes
emails within the organization and provides connectivity between the
Front End Transport service, hosted by the Client Access server, and
the Mailbox Transport service. The Mailbox Transport service routes
email messages between the Hub Transport service and the mailbox
database.
In addition, the Mailbox server role includes the Unified Messaging service.
2. Understanding the Prerequisites for Exchange Server 2013
The
prerequisites that are needed will depend on the Exchange role
installed on the server. Before installing Exchange Server 2013, the
administrator should become familiar with the prerequisites for each of
the server roles. This section covers the prerequisites for the
implementation of Exchange Server 2013 in a Windows networking
environment.
Active Directory Infrastructure
Exchange
Server 2013 relies on an Active Directory infrastructure to do its job.
AD Sites and Services, domain name system (DNS), global catalog (GC)
servers, domain controllers—all must be in place and configured
properly for Exchange Server to function well.
Windows Server 2008 R2—64-Bit All the Way
From
inception through Exchange Server 2003, Exchange Server was always a
32-bit application. Although this technology was able to handle the
needs of organizations in the past, organizations today have more
demanding messaging requirements.
In a
world with ever-increasing message traffic, the need for highly
available systems that allow access from multiple client technologies,
through the Internet, and through continuous synchronization with
wireless devices resulted in the desire for increased productivity
through increased performance.
To
address these growing needs, Microsoft released a 64-bit version of its
Exchange Server 2007 server for production environments. Although
Microsoft still produced a 32-bit version of the product, it was
intended primarily for nonproduction environments.
With Exchange Server 2010, 32-bit support went away; likewise Exchange Server 2013 is only being released in a 64-bit version.
By
utilizing 64-bit architecture, Exchange Server has significantly
enhanced processor and memory utilization. This ensures higher
performance gains, the ability to handle an ever-increasing volume of
messages, the capability of supporting more users per server, and more
simultaneously connected mail clients. This last item is critical as
more and more organizations take advantage of the capabilities of OWA
and ActiveSync.
The Exchange Server 2013
application can only be installed on Windows Server 2012, Windows
Server 2008 R2 Standard or Enterprise Editions with Service Pack 1
(SP1) (or later), or Windows Server 2008 R2 Datacenter RTM or later
operating systems. However, if you plan on having the Mailbox server be
a member of a DAG, you must use the Enterprise or Datacenter Edition.
Windows 2008 Server R2 SP1 Standard Edition does not support the
Windows Clustering feature required for DAGs.
Microsoft .NET Framework 4.5
Microsoft
.NET Framework is a Microsoft Windows component that allows the ability
to build, deploy, and run Web Services and other applications. The .NET
Framework is a key offering from Microsoft, and most new applications
created for the Windows platform rely on it in one way or another.
.NET
Framework 4.5 builds on the features added in previous releases,
provides core new features and improvements, and adds a number of new
features to support .NET for Metro style Apps, portable class
libraries, parallel computing, networking, Windows Presentation
Foundation, Windows Communication Foundation, and Windows Workflow
Foundation.
Windows Server 2012 ships with
the .NET Framework 4.5 already installed; however, on Windows Server
2008 R2 SP1 servers, .NET Framework 4.5 must be installed separately.
Exchange Server 2013 requires .NET Framework 4.5.
Windows Management Framework 3.0
Windows
Management Framework 3.0 contains Windows PowerShell v3, Windows
Management Instrumentation (WMI), and Windows Remote Management
(WinRM). Windows Management Framework 3.0 is included with Windows
Server 2012 and does not need to be installed separately as with
Windows Server 2008 R2 SP1.
Windows PowerShell v3
Administrators
who are familiar with Exchange Server 2007 or 2010 have most likely had
some experience with Windows PowerShell. For many, the implementation
of PowerShell addressed one of the most glaring
shortcomings of older Windows installations—the lack of a usable
command-line interface for performing administrative tasks.
PowerShell
is an extensible command-line shell and scripting language from
Microsoft that integrates with the .NET Framework to allow
administrators to perform just about any task in an Exchange
environment from a command line. From simple to complex, scripts can be
written using the PowerShell scripting language to save administrators
from time-consuming and repetitive tasks.
Although
some have found the PowerShell scripting language to be difficult to
learn and challenging to implement, few who have seen the results of
this product being put into action can complain about the results.
Windows PowerShell v3 introduces several new features to PowerShell v2 that extend its capabilities, including the following:
• Workflows—Workflows
allow running of long-running activities in sequence or in parallel to
perform more extensive and complex management tasks. Workflows are
repeatable, interruptible, and recoverable.
• Robust sessions—Windows
PowerShell v3 sessions automatically recover from network failures and
interruptions. Disconnected sessions can be reconnected from a
different computer without interrupting running tasks.
• Scheduled jobs—Schedule jobs to run regularly or as triggered by an event.
• Delegated administration—Delegated
administration allows setup of commands with a delegated set of
credentials that can be run by users with limited permissions.
• Simplified language syntax—Commands and script syntax now appear more like natural language.
Windows Management Instrumentation (WMI)
WMI
is the infrastructure for accessing management data and operations on
Windows operating systems. WMI scripts and applications can be used to
supply management data to operating system components and other
Windows-based products or automate administrative tasks on remote
computers. WMI in Windows Management Framework 3.0 supports an extended
Windows PowerShell semantics application programming interface (API),
allowing the ability to write Windows PowerShell cmdlets in native code.
Windows Remote Management 2.0 (WinRM)
The
Exchange Management Shell is a command-line interface that enables you
to manage your Microsoft Exchange organization without having to rely
on a graphical user interface (GUI).
WinRM
2.0 is the transport mechanism that enables your local version of
Windows PowerShell to connect to remote Exchange servers, whether that
server is in the next rack or across the country. Utilizing WinRM 2.0,
administrators can manage servers, devices, and applications throughout
their organizations from a single management server.
Microsoft Unified Communications Managed API 4.0, Core Runtime 64-Bit
The
Unified Communications Managed API (UCMA) provides a managed-code
multilayer platform for developers to implement communication- and
collaboration-enabled middle tier services that work with Microsoft
Lync Server.
Microsoft Office 2010 Filter Pack 64-Bit and Service Pack 1
The
Microsoft Filter Pack contains a series of IFilters that allow search
services to index specific file type contents. The filters are intended
for the use of the Microsoft search services. Service Pack 1 is a
roll-up of all previously released updates that contain security,
performance, and stability updates.
3. Understanding High Availability and Site Resilience in Exchange Server 2013
In
Exchange Server 2007, Microsoft introduced new technologies that
allowed organizations to deploy their Exchange environments with
improved availability. Known as Continuous Replication, this technology
was offered in three flavors—Local Continuous Replication (LCR),
Cluster Continuous Replication (CCR), and Standby Continuous
Replication (SCR).
Although these options
were a significant improvement over previous technologies,
organizations found that the technologies were challenging to
implement, as they required a significant amount of time and experience
to deploy. This was largely due to the fact that some parts of the
technology were owned by the Windows operating system, and some parts
were owned by Exchange Server.
Exchange
Server 2010 built on these technologies and combined the onsite data
replication features of CCR with the offsite data replication features
of SCR. This combination of technologies is known as a DAG. This
architecture is designed to provide recovery from disk-level,
server-level, and site-level failures. Although Exchange Server 2013
also uses DAGs and mailbox database copies, Microsoft has enhanced the
high-availability platform, using the Exchange Information Store and
the Extensible Storage Engine (ESE) for improved availability, easier
management, and reduced costs. These improvements include the following:
• Managed Store—A
newly rewritten Information Store process that works with the Microsoft
Exchange Replication service to manage mailbox databases
• Managed Availability—Tightly
integrated internal monitoring and recovery-oriented features to help
prevent failures, proactively restore services, initiate server
failovers automatically, and send administrator alerts
• Support for multiple databases per disk—Ability to support a mix of active and passive database copies on the same disk to allow greater disk utilization efficiencies
• Unified namespace for site resilient configurations—Ability to have a unified namespace across multiple Active Directory sites for resilient configuration
