210 4.3 Networking services
Beyond the actual “guts” of a server, you should consider the environ-
mental aspects that will trigger your options. Blade server computing can be
a strategy for decreasing cost of operation: it is much faster (and requires
fewer skills) to replace a blade server than a high-density server; it may,
however, impact your server deployment standards. Think about it when
considering the operating model of your environment.
4.3 Networking services
Networking services are of course critical for proper operations of Exchange
200x deployments, including the largest ones. From my deployment experi-
ences, Exchange 2003 relies on the following network services.
4.3.1 Data networks
Data networks establish the connection not only between the Windows
infrastructure servers and the Exchange servers, but also between the mes-
saging clients of all kinds (Outlook, Outlook Web Access, or mobile cli-
ents) and possibly some back-end storage components when using NAS for
Exchange 2003 or iSCSI target devices.
Solid data network services imply redundancy when availability is
required as well as sufﬁcient bandwidth and low latency. In highly central-
ized environments, this becomes even more critical: in the move to concen-
trate operations and servers and consolidate infrastructure, more accesses
are done across wide-area network links, which sometimes can be a cause
for slow response time and unavailability. Network aspects can be very
straightforward in corporate environments, where every computing
resource can connect to each other happily and with no barriers. Nonethe-
less, Exchange 2003 must sometimes be deployed in environments where
ﬁrewalls, Virtual Private Networks, and other such advanced networking
techniques have to be deployed or are already implemented.
The classic example is the interconnection of two companies that are
just merging. In the beginning, you need to establish basic connectivity,
which can be as basic and as simple as SMTP protocol handling. In the
longer run, however, you need to merge data networks together, often going
through the intermediate steps of establishing VPNs and trusted connec-
tions, and only later end up in one single WAN that can ease the deploy-
ment of Exchange 2003 and related applications.
There are many references in the literature and in customer experiences
where such steps are looked into and advice given for how best to implement
4.3 Networking services 211
them. Don’t always assume that you can deploy Exchange 2003 in a transpar-
ent and straightforward manner as you would in a LAN environment.
Sometimes, indeed, the connectivity is just summarized by mail
exchanged and Free/Busy calendaring replication. Microsoft provides tools
that can enable multiple organizations to connect together. The Active
Directory Connector is one example, and the Exchange 2003 resource kit
contains additional utilities; do take the time to study them before making
any decision on what you can and will actually implement and deploy.
In many cases, this particular topic is addressed by infrastructure teams,
and usually in the course of the planning and design of the key Windows
Server services, such as directory and authentication. By the time you
approach your Exchange 2003 design, those considerations for networking
topologies will have been addressed, to a certain extent.
We have seen many environments, however, where ﬁrewalls between
islands of wide-area networks are implemented, thus creating disjointed Win-
dows environments and implying disjointed Exchange 2003 environments.
In such situations, my advice is to utilize inter-organizational replication tools
for the directory services, the calendaring information, and possibly, the pub-
lic folder replication. SMTP is by far the simplest way to address the exchange
of messaging data. Do note that in that case, there are certain aspects of
Exchange 2003 that you won’t be able to take advantage of, such as a uniﬁed
management console and some routing topology intelligence built inside the
SMTP routing layer of Exchange 2003. Kieran McCorry has written an
excellent book on this topic: Microsoft
Exchange Server 2003 Deployment
and Migration, First Edition (ISBN: 1555583164).
The Domain Naming Services provided by (or for) the Windows 200x
infrastructure are key for Exchange 2003 to be able to route messages,
enable communications, and look up between Exchange 2003 servers.
Don’t forget that in a multisite, multidomain Windows 2000 environ-
ment, DNS is key for retrieving site topology and appropriate Global Cata-
log servers and Domain Controllers from the Windows 2000
infrastructure. Unavailability or bogus information in DNS can bring your
Exchange 2003 service down, no matter how much effort you put into
building robust back-end or front-end services. The challenge with DNS is
that very often, customers already have DNS services in place, mostly run-
ning on UNIX platforms, and are not necessarily willing to switch com-
pletely over to Windows 2000–based DNS services.