To expand on this concept, suppose you
had four Exchange servers, each with two
single-core processors. Collectively, the servers would have eight processor cores, so you
would need two GC server cores to support
them. This could be one server with two single-core processors or one dual-core processor, or
it could be two separate servers.
Microsoft has adopted the same basic technique for determining the number of GC servers
needed to support Exchange 2007, but the ratio
has changed to one GC server core for every
eight Exchange 2007 cores. Of course, this is just
a guideline. In the real world, the actual number
of cores you'll need might vary because some
cores are faster than others and because you
want to avoid having a single point of failure.
There are two important criteria that your
GC servers must meet in order for this 8 to 1 ratio to be valid. First, your GC
servers must be running a 64-bit
Windows OS. As I'm sure you probably know, 64-bit OSs can address
a much larger amount of memory
than 32-bit OSs. This is important
because of the second requirement
for an 8 to 1 core ratio: The server
must have enough physical memory installed that it can cache the
entire AD database in RAM. You can
find the size of your AD database by navigating
through your GC server's hard disk to the \windows\ntds folder and looking for the Ntds.dit
file. If your GC servers don't meet these criteria,
you're better off using the 4 to 1 ratio that was
used with Exchange 2003.
AD Site Topology
One of the more significant features of
Exchange 2007 with regard to AD is that routing groups no longer exist. Exchange 2003 lets
you route messages by creating routing groups
on an as-needed basis. In contrast, Exchange
2007 is designed to let Mailbox servers connect
directly to Hub Transport servers, which can
connect to any other Hub Transport server. If
a Hub Transport server is down in a site, the
Mailbox server will use AD site topology as an
alternative to routing groups to find the next
closest Hub Transport server.
With Exchange 2003, it's a common practice to place Exchange servers and some
DCs or GC servers into a dedicated site. This
method prevents demanding applications
from flooding GC servers or DCs with excessive requests and thereby reducing Exchange's
performance. By placing these resources into
a dedicated site alongside the Exchange servers, you can effectively isolate Exchange from
other demanding applications—and prevent
Exchange from consuming resources required
by your other applications—with only minimal
effect on mail flow. Remember that Exchange
2003 uses its own internal routing groups to
control mail flow and that these routing groups
work independently of AD sites.
You could place Exchange 2007 into a
dedicated site, but doing so could negatively
affect mail flow, particularly in organizations
with five or more AD sites. In complex organizations, it's almost impossible to get mail flow
to perform optimally when Exchange is in a
dedicated site without creating a management
headache in the process. For more information about message routing in Exchange 2007, see
"Exchange 2007 Transforms Message Routing,"
March 2007, InstantDoc ID 94859.
DNS Requirements
Just as Exchange 2007 depends on AD, AD
depends on a properly configured DNS server.
In previous versions of Exchange, configuring
DNS entries was a fairly straightforward task.
In Exchange 2007, things work a bit differently
than what you might be used to.
As you probably know, each Exchange
2007 server can be assigned one or more of
five available roles: Mailbox, Client Access,
Hub Transport, Edge Transport, and Unified
Messaging (UM). Servers running the Mailbox,
Client Access, Hub Transport, or UM roles
must be domain members and must therefore
have their IP addresses registered with the
organization's internal DNS server.
The Client Access server is essentially just a
Microsoft IIS server that hosts Microsoft Outlook
Web Access (OWA). As such, users need to be
able to access the Client Access server from
outside the organization. Theoretically, administrators could register the Client Access server's IP
address with an external DNS server, but doing so
would be a security risk. More often, the address
that's registered with an external DNS server is
the firewall's external IP address. The firewall
can then be configured to use port forwarding
to send HTTP traffic to the Client Access server,
which can then service OWA clients without
exposing the server to the outside world.
The most significant new feature of
Exchange 2007 from a DNS standpoint is the
creation of the Edge Transport role, a special Exchange server designed to sit at the edge
of your network and receive messages from
the outside world. The organization's mail
exchanger (MX) record would typically contain
the IP address of the Edge Transport server.
When messages arrive at the Edge Transport
server, it performs various levels of message
hygiene, then forwards the messages to the
Hub Transport server. Because the Edge Transport server sits at the network perimeter, it's
running a hardened Exchange implementation and isn't even a member of a domain.
Plan Ahead for
Performance
Exchange 2007 brings with it new features, new
architecture, and new management methods—and along with all that, new headaches
for Exchange administrators. You can help
alleviate some of your headaches, at least,
by designing your AD with Exchange 2007 in
mind. A carefully implemented AD is one way
to ensure good performance of your servers.
Check out the sidebar, "AD Considerations
for Exchange 2007," for a checklist of things to
remember in your design.