Microsoft® Exchange Server 2003 Scalability with SP1 and SP2

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 sufficient 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

firewalls, 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

Chapter 4

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 firewalls 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 unified

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).

4.3.2 DNS

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.