Server roles
In Exchange 2003 there were only two "official" roles of a
server. Those were a front-end and back-end server. When a server was
designated as a front-end server certain services could be disabled and the
system could be locked down in a more secure fashion. The primary role of a
front-end server was to proxy or forwarding request from clients to a back-end
server. Those request included HTTP (OWA, OMA, and RPC over HTTP), POP3, IMAP,
and SMTP connections. A back-end server's primary role was to host databases
for mailboxes and public folders. Back-end servers could also be configured to
just route messages in larger environments, but Exchange looked at all back-end
servers as the same type. In addition, the initial setup of both roles was the
same and all binaries got installed on them.
With E2k7 Microsoft introduced five distinct roles that are
selected as setup time. Based on the roles selected different binaries and
services are actually installed during the setup process. Those roles are Edge Transport
(ET), Hub
Transport (UT), Unified
Messaging (UM), Client Access
(CA), and Mailbox
(MB). Each of these roles service a very difference purpose and allow for much
more flexibility, a higher level of security, and better management. All of
these roles, with the exception of the Edge Transport role, can be installed on
a single box. This type of configuration maybe desired for smaller
organizations or remote sites. The ET role is designed to be placed in a DMZ
or between the external and internal firewall. The ET is also designed to be
installed on a standalone or member server, the server should not be a member
of the AD forest for Exchange. The ET role is basically to provide message
hygiene services and a minimum footprint for attackers.
Hub Transport
The Hub Transport role replaces back-end servers, which were
configured as bridgehead servers, which only routed mail in larger
organizations. There are some major differences between a "bridgehead" server
in Exchange 2003 and a server with the HT role in Exchange 2007. First ALL
messages between E2k7 users MUST pass though a HT in the same
AD site as the MB server the users are on. In E2k3 if a user on SERVER1
sent an e-mail to another user on SERVER1 the SMTP stack and message routing
would never process the message. If a user from SERVER1 sent a message to a
user in SERVER2 the message may pass though multiple servers or just between
these two servers, depending on how routing was configured. With E2k7 every
message sent by any E2k7 user must be processed by a server with the HT role. The next feature that is different or new in E2k7 is Transport Rules
and Transport
Agents, which replace transport event hooks or Event Sinks. I will go into
this area in a little more detail in the next section. As mentioned early
message routing has also completely changed and servers with the HT role are
the only ones that will process messages.
Client Access
In previous version of Exchange all clients connected to
either a front-end server or a back-end server directly. Remote clients using
HTTP (RPC over HTTP), SMTP, IMAP, POP3, etc connected to a front-end server and
their request were then relayed or proxied to a back-end server. Internal
clients would either connect directly to a back-end server or a front-end
server, with the exception of MAPI\Outlook client which would connect only to a
back-end server. In E2k7 all non-MAPI clients connect to a server with the CA
role installed. The CA then relays their request to the server that hosts
their mailbox, at least in a very basic environment. Outlook clients, those
not using RPC over HTTP (Outlook Anywhere), still connect directly to the
server hosting their mailbox. Besides replacing the functionality of an E2k3
front-end server the CA role also provides the Autodiscover
service, Exchange
Web services, HTTP access to the Off-line Address Book (OAB) [used by
Outlook 2007 clients]. Any customizations or add-ons to OWA or other
functionality provided by E2k3 will need to be rewritten or replaced since OWA
and other services provided by the CA are completely different, or gone, in
E2k7. Like the HT role a CA role must exist in every AD site
that contains a server with the MB role installed on it.
Scalability planning for a CA will vary greatly depending
upon the number of EAS, OWA, Outlook Anywhere, and non-MAPI clients connecting.
The Microsoft recommendation is 4 MailBox CPU cores for every 1 CA CPU
core, if a high percentage of client will be connecting via EAS, OWA, Outlook
anywhere, etc more CA cores will be needed then the default recommendation.
The last major factor that needs to be taken into consideration is
limitations of using a single external name space, like mail.company.com, for
external, non-MAPI clients, connections.
There are a few major limitations with this.
First only OWA supports redirection to a CA in the same site as the
user’s mailbox, if the CA in the site can be accessed externally.
Second, EAS, IMAP, and POP3 clients don’t support redirection and must be
connect directly to the CA server in the same site as the user’s mailbox.
Both OWA and EAS DO support requests
being proxied to the correct CA, but with the next limitation.
The final limitation if external clients do not connect to a CA server in
the same AD site as their mailbox OWA & EAS w/
WMA6 file access (UNC and SharePoint) will not work.
Therefore, regional namespaces like mail.emea.company.com need to be
created so external clients can connect directly to a CA in the site where their
mailbox is located. For more
information see this
EHLO blog post and
Understanding
Proxying and Redirection.
Mailbox
The Mailbox role, which also includes support for public
folders, hosts the Exchange databases, previous called stores. As mentioned
above non-MAPI clients can no longer connect to an Exchange server running this
role, unless it also has the CA role installed. The MB role is also the only role
that can be clustered; via CCR or SCC. One limitation of CCR and SCC
clustering is that the only the MB role can be hosted on a cluster. Therefore,
a minimum of three severs are required for clustering. Those included, two for
hosting the clustered MB role and at least one more for hosting the HT, CA, an
UM roles. LCR and SCR can be used on a multi-role server
Unified Messaging
Completely new to Exchange 2007 is unified
messaging support. Out of the box E2k7 will be able to accept incoming
(only) faxes and voice mails. In addition, UM provides the ability to listen
to both voice mails & e-mails over the phone and make changes to calendar
items, reply & compose e-mails, and more. By "Out of the box" I mean that
Exchange will not require any additional 3rd party software but
IP/PBX and/or VoIP gateway hardware will be required. UM provides some great
benefits to organizations but requires a great understanding of telephony
technologies and expertise. The language and terms used by telephony engineers
are very different than those messaging engineers are familiar with. So a lot
of learning and testing will be needed to implement UM in any organization. Because
of this, I would suggest looking at UM as a separate, post E2k7 implementation
project.
Transport rules and agents
In E2k3 there were transport event hooks (Event Sinks) that
could be used to call custom code or 3rd party applications when
messages where received or sent via SMTP or NNTP. This support has been
removed in E2k7 and replaced by Transport Rules and Transport
Agents. Therefore, any application that used Event Sinks will need to be
rewritten to use a transport agent or replaced with a transport rule. Transport rule can be created in the EMC using a wizard similar to the one used
for Outlook Inbox rules. Unlike Outlook Inbox rules, transport rules fire on every
message received. Therefore, care should be taken when creating rules and the
number of rules should be kept to a minimum to prevent performance issues.
|
