How do you plan for an implementation of Microsoft Exchange Server? What
steps can you take to ensure success, or at least avoid some pitfalls along the
way? I can easily discuss this topic at length, certainly beyond what can fit in
one magazine article. Instead, I'll just focus on the most important aspects of
deployment planning for Microsoft Exchange Server, reflecting on my experience
of the past 18 months working with the product in a variety of corporate
situations. Some ideas I'll discuss here won't be new to anyone who has
installed Exchange, but some ideas might surprise you. You'll know what makes
sense for your environment. My comments are generic whereas your knowledge
isn't, so your own experience will always win out in the end. The four most
important aspects of any Exchange deployment are Windows NT infrastructure,
network connections and bandwidth, the shape of the Exchange organization, and
server connections.
Organizing Exchange in NT
Computers run Exchange within a somewhat inflexible hierarchical arrangement
known as an organization. An organization is subdivided into sites,
which are closely connected groups of server computers that communicate
continually. Screen 1, shows an Exchange organization with 10 sites. An Exchange
organization is mapped on the NT infrastructure and the available network. The
easiest Exchange implementation follows two simple principles:
1. All servers operate inside the same NT domain. In large implementations,
this principle usually means that you create a separate resource domain for
Exchange. You do not create user accounts in the resource domain, only an
account for Exchange administration (the service account).
2. You install and operate Exchange on dedicated servers. In particular, no
potentially contending database-type application such as Systems Management
Server (SMS) or SQL Server runs on the same computer as Exchange. Ensure that
the server is neither a Primary Domain Controller (PDC) nor (less important) a
Backup Domain Controller (BDC). To refine this principle, you can configure some
Exchange servers to handle messaging and some to run connectors.
The real skill in Exchange design comes in knowing when to compromise one
principle to arrive at a pragmatic design that meets your needs and is flexible
enough to permit evolution. For example, you can connect Exchange servers across
multiple NT domains. Many people do so because their NT domain structure wasn't
well planned or they decide to separate users and computers into different
domains.
Exchange's basic method of communication is to send messages between
servers, and as long as a messaging connection is possible (for example, sending
Simple Mail Tranfer Protocol-- SMTP--messages between servers), messages will
flow. Messages include directory replication and public folder hierarchy and
content replication, and interpersonal notes that users send each other.
Having one unified security context is best (the result of placing all
Exchange servers into the same domain) because the finer points of Exchange can
operate without hindrance. These points include single-seat server
administration, public folder affinity, and message tracking.
Public folder replication gets a lot of attention, largely because of the
inevitable comparisons people make with the replication mechanism of Lotus
Notes. However, public folder affinity, which is the ability to direct all
access to public folder contents to one or more predefined (and costed) points
within the Exchange organization, is valuable because it reduces the amount of
duplicated data floating around the network. Public folder affinity also allows
more control over document content that you don't want replicated.
Affinity depends on clients having access to the servers where the content
is stored, which can be outside the client's NT domain. This approach requires a
trust relationship. Or better still, if all of the Exchange servers share a
unified security context, affinity can proceed on automatic pilot because the
client's security credentials are acceptable to all servers within the
organization. Of course, you can establish a unified security context through
two-way trust relationships between NT domains, but this approach is hardly
elegant and not viable when more than three or four domains are involved.
Operating Exchange on dedicated computers is the luxury approach and
valuable when things go wrong. Take email, which is now a mission-critical
application for many companies. When email servers go down, users demand
immediate reinstatement and give little credit to MIS departments that can't
fulfill that demand.
When things go wrong, you want a simple checklist of what to do to restore
service quickly, instead of having to mess around to rebuild a complex server. I
know instances where getting a server back online after hardware failures took
two or more days. Such delay is unacceptable when the CEO is waiting for email.
You can operate dedicated servers and make sure you protect those servers with
UPS and RAID devices.
Accidents happen, computers fail, and software has bugs. These three truths
of computing mean that you need to be sure that you can get the company email
system online quickly after catastrophic hardware failures, minor hardware
failures, and botched software upgrades or other accidents of systems
administration life.