Learning from Exchange 2000 Deployments

Microsoft Exchange 2000 Server hit the shelf about 1 year ago. During the past year, those of us who deployed the new product have learned many lessons—among them, that experience with Exchange Server 5.5 is no guarantee we'll automatically understand Exchange 2000. Something new occurs daily to remind me just how different Exchange 2000 is from Exchange 5.5. (These changes are a good argument for testing new Exchange 2000 deployments before you introduce them into your production environment, as the sidebar "Test First," page 84, explains.)

Nothing teaches like real-world deployment experience, and we can now begin to identify the most important elements in successful Exchange 2000 deployments. If you've been waiting to deploy Exchange 2000, you can benefit from this experience. To keep your Exchange 2000 organization running smoothly, consider the following factors: where you place Global Catalog (GC) servers, how you use the Active Directory Connector (ADC), how add-on products work with Exchange 2000, which Exchange clients you employ, which Windows 2000 features affect Exchange 2000, and whether you can consolidate Exchange servers.

Locate the GC
Each GC is a specially configured Win2K domain controller (DC) that holds full read/write copies of objects in its domain and partial read-only copies of objects in all the other domains in an Active Directory (AD) forest. Exchange 2000 fetches the Global Address List (GAL) from a GC and uses the GC to resolve message addresses during the routing process.

Unless the Exchange server can establish and maintain contact with a GC, Exchange 2000 can't start its services or route messages. Without a GC, Exchange users can't see the GAL, and the Exchange DSAccess component issues countless error messages.

DSAccess is the Exchange component that handles directory access. (In effect, DSAccess replaces the Directory Service—DS—that shipped with earlier versions of Exchange.) In concept, the DSAccess component's work is straightforward: When the Exchange services (e.g., the Routing Engine, the Message Transfer Agent—MTA) start, the component connects (i.e., binds) to a suitable GC and maintains connectivity so long as the Exchange server is running.

When deciding which GC to connect to, the DSAccess component weights site information heavily. Exchange generates a significant load on a GC, which must respond to queries against the directory for routing information, configuration data, and user details. (The exact load depends on the volume of message traffic, but many deployments use a rule of thumb that dictates one GC for every four Exchange servers.) The constant interaction between Exchange and the GC mandates that every Exchange 2000 server connect to the closest—in network terms—GC. To determine which GC an Exchange server connects to, open the Microsoft Management Console (MMC) Exchange System Manager (ESM) console. Select the Exchange server, open the server's Properties dialog box, and go to the General tab, which Figure 1 shows. The name of the GC appears in the Domain controller used by services on this server text box at the bottom of the tab.

Many organizations experience problems (e.g., slow message delivery, Microsoft Outlook clients freezing up) when an Exchange 2000 server connects to a GC in a remote Win2K site (sometimes because an administrator placed the Exchange server in the wrong Win2K site during installation). My personal experience confirms the importance of deploying Exchange 2000 servers close to GCs. In this context, the word close means that the network link between the Exchange and GC servers must be reliable, fast, and resistant to interruption. The safest option is to locate a GC on the same LAN as the Exchange server; stray from this approach only when you're certain that the link you intend to use is reliable.

Clearly, you need to perform some design work during your Win2K implementation to determine how many GCs you need and their optimum locations. If you're lucky enough to have a single domain, then the task is much easier because every DC can function as a GC. However, multidomain implementations are the most common model in the corporate world. Of course, you can still make every DC a GC, but in a multidomain environment, this approach incurs significant replication traffic. Most of us prefer to use valuable network resources for other work, so you must balance Exchange's need for GC proximity with available bandwidth. The choice is simple: Restrict replication and force Exchange to connect over extended links with unpredictable service levels, or bite the bullet and deploy more GCs to ensure that Exchange (and users) can always access the directory.

   Previous  [1]  2  3  4  Next