1 Exchange Server coexistence
It is very likely that large
organizations will gradually move from an earlier version of Exchange
Server to Exchange Server 2010, and Exchange Server 2010 can coexist, in
the same forest, with (both) Exchange Server 2007 and Exchange Server
2003.
Please note that it is not
possible to have a coexistence scenario where Exchange Server 2000 and
Exchange Server 2010 are installed in the same Exchange Organization.
This is enforced in the setup of Exchange Server 2010. If the setup
detects an Exchange Server 2000 installation the setup application is
halted and an error is raised.
Integrating Exchange Server
2010 into an existing Exchange Server 2003 or Exchange Server 2007
environment is called a "transition" scenario. A "migration" scenario is
where a new Active Directory forest is created where Exchange Server
2010 is installed. This new Active Directory forest is running in
parallel with the "old" Active Directory with a previous version of
Exchange Server. Special care has to be taken in this scenario,
especially when both organizations coexist for any significant amount of
time. Directories have to be synchronized during the coexistence phase,
and the free/busy information will need to be constantly synchronized
as well, since you'll still want to offer this service to users during
the coexistence period.
2 Exchange Server 2010 server roles
Up until Exchange Server 2003,
all roles were installed on one server and administrators were unable
to select which features were available. It was possible to designate an
Exchange 2000 or Exchange 2003 server as a so called "front-end
server", but this server was just like an ordinary Exchange server
acting as a protocol proxy. It still had a Mailbox Database and a Public
Folder database installed by default.
Exchange Server 2007
introduced the concept of "server roles" and this concept is maintained
in Exchange Server 2010. The following server roles, each with a
specific function, are available in Exchange Server 2010:
Mailbox Server (MB) role
Client Access Server (CAS) role
Hub Transport Server (HT) role
Edge Transport Server (Edge) role
Unified Messaging Server (UM) role.
These server roles can be
installed on dedicated hardware, where each machine has its own role,
but they can also be combined. A typical server installation, for
example in the setup program, combines the Mailbox, Client Access and
Hub Transport Server role. The Management Tools are always installed
during installation, irrespective of which server role is installed.
By contrast, the Edge Transport Server role cannot be combined with any
other role. In fact, the Edge Transport Server role cannot even be part
of the (internal) domain, since it is designed to be installed in the
network's Demilitarized Zone (DMZ).
There are multiple reasons for separating Exchange Server into multiple server roles:
Enhanced scalability
– since one server can be dedicated for one server role, the
scalability profits are huge. This specific server can be configured and
optimized for one particular Role, resulting in a high performance
server.
Improved security
– one dedicated server can be hardened for security using the Security
Configuration Wizard (SCW). Since only one Server Role is used on a
particular server, all other functions and ports are disabled, resulting
in a more secure system.
Simplified deployment and administration – a dedicated server is easier to configure, easier to secure and easier to administer.
I will explain each server role in detail, in the following sections.
2.1 Mailbox Server role
The Mailbox Server role is
the heart of your Exchange Server 2010 environment. This is where the
Mailbox Database and Public Folder Database are installed. The sole
purpose of the Mailbox Server role is to host Mailboxes and Public
Folders; nothing more. In previous versions of Exchange Server,
including Exchange Server 2007, Outlook clients using MAPI still
connected directly to the Mailbox Server Role, but with Exchange Server
2010 this is no longer the case. MAPI clients now connect to a service
called "RPC Client Access," running on the Client Access Server. (The
original code name of RPC Client Access was "MAPI on the Middle Tier" or
MoMT.)
The Mailbox Server Role does
not route any messages, it only stores messages in mailboxes. For
routing messages, the Hub Transport Server role is needed. This latter
role is responsible for routing all messages, even between mailboxes
that are on the same server, and even between mailboxes that are in the
same mailbox database.
For accessing mailboxes, a
Client Access Server is also always needed; it is just not possible to
access any mailbox without a Client Access Server.
As I mentioned, Storage Groups
no longer exist in Exchange Server 2010, but mailboxes are still stored
in databases, just like in Exchange Server 2007. Although rumors have
been circulating for more than ten years that the database engine used
in Exchange Server will be replaced by a SQL Server engine, it has not
happened yet. Just as in earlier versions of Exchange Server, the
Extensible Storage Engine (ESE) is still being used, although major
changes have been made to the database and the database schema.
By default, the first database on a server will be installed in the directory:
The
<<identifier>> is a unique number to make sure that the
Mailbox Database name is unique within the Exchange organization.
It is best practice, from both a
performance and a recovery perspective, to place the database and the
accompanying log files on a dedicated disk. This disk can be on a Fiber
Channel SAN, on an iSCSI SAN, or on a Direct Attached Storage (DAS)
solution. Whilst it was a design goal to limit the amount of disk I/O to
a level where both the database and the log files could be installed on
a 1TB SATA disk, this is only an option if Database Copies are
configured and you have at least two copies of the Mailbox Database, in
order to avoid a single point of failure.
2.2 Client Access Server role
The Client Access Server
role offers access to the mailboxes for all available protocols. In
Exchange Server 2003, Microsoft introduced the concept of "front-end"
and "back-end" servers, and the Client Access Server role is comparable
to an Exchange Server 2003 front-end server.
All clients connect to the
Client Access Server and, after authentication, the requests are proxied
to the appropriate Mailbox Server. Communication between the client and
the Client Access Server is via the normal protocols (HTTP, IMAP4, POP3
and MAPI), and communication between the Client Access Server and the
Mailbox Server is via Remote Procedure Calls (RPC).
The following functionality is provided by the Exchange Server 2010 Client Access Server:
HTTP for Outlook Web App
Outlook Anywhere (formerly known as RPC/HTTP) for Outlook 2003, Outlook 2007 and Outlook 2010
ActiveSync for (Windows Mobile) PDAs
Internet protocols POP3 and IMAP4
MAPI on the Middle Tier (MoMT)
Availability
Service, Autodiscover and Exchange Web Services – these services are
offered to Outlook 2007 clients and provide free/busy information,
automatic configuration of the Outlook 2007 and Outlook 2010 client, the
Offline Address Book downloads and Out-of-Office functionality.
NOTE
SMTP Services are not offered by the Client Access Server. All SMTP Services are handled by the Hub Transport Server.
At least one Client
Access Server is needed for each Mailbox Server in an Active Directory
site, as well as a fast connection between the Client Access Server and
the Mailbox Server. The Client Access Server also needs a fast
connection to a Global Catalog Server.
The Client Access Server
should be deployed on the internal network and NOT in the network's
Demilitarized Zone (DMZ). In order to access a Client Access Server from
the Internet, a Microsoft Internet Security and Acceleration (ISA)
Server should be installed in the DMZ. All necessary Exchange services
should be "published" to the Internet, on this ISA Server.
2.3 Hub Transport Server role
The Hub Transport Server role
is responsible for routing messaging, not only between the Internet and
the Exchange organization, but also between Exchange servers within your
organization.
All messages are always
routed via the Hub Transport Server role, even if the source and the
destination mailbox are on the same server, and even if the source and
the destination mailbox are in the same Mailbox Database. For example,
in Figure 8, the Hub Transport Server is responsible for routing all messages:
Step 1: A message is sent to the Hub Transport Server.
Step 2: A recipient on the same server as the sender means the message is sent back.
Step 3:
When the recipient is on another mailbox server, the message is routed
to the appropriate Hub Transport Server. This is then followed by...
...Step 4: The second Hub Transport Server delivers the message to the Mailbox Server of the recipient.
The reason for routing all
messages through the Hub Transport Server is simply compliancy. Using
the Hub Transport Server, it is possible to track all messaging flowing
through the Exchange organization and to take appropriate action if
needed (legal requirements, HIPAA, Sarbanes-Oxley, and so on). On the
Hub Transport Server the following agents can be configured for
compliancy purposes:
Transport Rule agents
– using Transport Rules, all kinds of actions can be applied to
messages according to the Rule's filter or conditions. Rules can be
applied to internal messages, external messages or both.
Journaling agents – using the journaling agent, it is possible to save a copy of every message sent or received by a particular recipient.
Since a Mailbox Server does
not deliver any messages, every Mailbox Server in an Active Directory
site requires a Hub Transport Server in that site. The Hub Transport
Server also needs a fast connection to a Global Catalog server for
querying Active Directory. This Global Catalog server should be in the
same Active Directory site as the Hub Transport Server.
When a message has an
external destination, i.e. a recipient on the Internet, the message is
sent from the Hub Transport Server to the "outside world." This may be
via an Exchange Server 2010 Edge Transport Server in the DMZ, but the
Hub Transport Server can also deliver messages directly to the Internet.
Optionally, the Hub Transport
Server can be configured to deal with anti-spam and anti-virus
functions. The anti-spam services are not enabled on a Hub Transport
Server by default, since this service is intended to be run on an Edge
Transport Service in the DMZ. Microsoft has supplied a script on every
Hub Transport Server that can be used to enable their anti-spam services
if necessary.
Anti-virus services can
be achieved by installing the Microsoft Forefront for Exchange software.
The anti-virus software on the Hub Transport Server will scan inbound
and outbound SMTP traffic, whereas anti-virus software on the Mailbox
Server will scan the contents of a Mailbox Database, providing a double
layer of security.
2.4 Edge Transport Server (Edge) role
The Edge Server role was
introduced with Exchange Server 2007, and provides an extra layer of
message hygiene. The Edge Transport Server role is typically installed
as an SMTP gateway in the network's "Demilitarized Zone" or DMZ.
Messages from the Internet are delivered to the Edge Transport Server
role and, after anti-spam and anti-virus services, the messages are
forwarded to a Hub Transport Server on the internal network.
The Edge Transport Server can also provide the following services:
Edge Transport Rules
– like the Transport Rules on the Hub Transport Server, these rules can
also control the flow of messages that are sent to, or received from,
the Internet when they meet a certain condition.
Address rewriting
– with address rewriting, the SMTP address of messages sent to, or
received from, the Internet can be changed. This can be useful for
hiding internal domains, for example after a merger of two companies,
but before one Active Directory and Exchange organization is created.
The Edge Transport Server is
installed in the DMZ and cannot be a member of the company's internal
Active Directory and Exchange Server 2010 organization. The Edge
Transport Server uses the Active Directory Lightweight Directory
Services (AD LDS) to store all information. In previous versions of
Windows this service was called Active Directory Application Mode
(ADAM). Basic information regarding the Exchange infrastructure is
stored in the AD LDS, like the recipients and the Hub Transport Server
to which the Edge Transport Server is sending its messages.
To keep the AD LDS
database up to date, a synchronization feature called EdgeSync is used,
which pushes information from the Hub Transport Server to the Edge
Transport Server at regular intervals.
2.5 Unified Messaging Server role
The Exchange Server
2010 Unified Messaging Server role combines the mailbox database and
both voice messages and email messages into one store. Using the Unified
Messaging Server role it is possible to access all messages in the
mailbox using either a telephone or a computer.
The phone system can be an IP-based
system or a "classical" analog PBX system although, in the latter case, a
special Unified Messaging IP Gateway is needed to connect the two.
The Unified Messaging Server role provides users with the following features:
Call Answering
– this feature acts as an answering machine. When somebody cannot
answer the phone, a personal message can be played after which a caller
can leave a message. The message will be recorded and sent to the
recipient's mailbox as an .mp3 file.
Subscriber Access
– sometimes referred to as "Outlook Voice Access." Using Subscriber
Access, users can access their mailbox using a normal phone line and
listen to their voicemail messages. It is also possible to access
regular mailbox items like messages and calendar items, and even
reschedule appointments in the calendar.
Auto Attendant
– using the Auto Attendant, it is possible to create a custom menu in
the Unified Messaging system using voice prompts. A caller can use
either the telephone keypad or his or her voice to navigate through the
menu.
The Unified Messaging
service installed on the Unified Messaging Server role works closely
with the Microsoft Exchange Speech Engine Service. This Speech Engine
Service provides the following services:
Dual Tone Multi Frequency (DTMF) also referred to as the touch-tone (the beeps you hear when dialing a phone number or accessing a menu).
Automatic Speech Recognition.
Text-to-Speech service that's responsible for reading mailbox items and reading the voice menus.
The Unified Messaging Server role
should be installed in an Active Directory site together with a Hub
Transport Server, since this latter server is responsible for routing
messaging to the Mailbox Servers. It also should have a fast connection
to a Global Catalog server. If possible, the Mailbox Server role should
be installed as close as possible to the Unified Messaging Server role,
preferably in the same site and with a decent network connection.
