DSAccess also uses automatic topology detection to build a list of suitable GCs for retrieving AD information. Fast access to recipient information is necessary for Exchange components such as the routing engine to resolve addresses, expand group membership, and route messages. Clients also need fast response when they look for a recipient in the Global Address List (GAL) or through a Lightweight Directory Access Protocol (LDAP) query. DSAccess looks for GCs in the same Win2K site as the Exchange 2000 server; the topology-detection process looks outside the site only if it can't find a local GC. Note that unlike in DC selection, Windows domains play no role in identifying suitable GCs; every GC in the forest holds the recipient data that Exchange needs.
DSAccess rebuilds the GC list automatically every 10 hours (an interval based on the standard Kerberos timeout) or when a change is made to the GC in the local site. After building the list, DSAccess attempts to balance the request load across all available GCs and uses a cache to hold the results of recipient lookups. You can also tweak the rebuild interval through the registry, as "Manually Setting DSAccess Parameters" explains.
When you understand how automatic topology detection works, which Exchange components rely on DC and GC availability, the size of the load placed on DCs and GCs, and the performance problems that occur if network glitches prevent servers from communicating, you can derive a simple set of best practices for placing GCs on your network. Those practices are as follows:
- Make sure to put at least one GC and one DC in every Win2K site that hosts an Exchange server (one computer can handle both roles).
- Make sure that every Exchange 2000 server is in close network proximity to a DC and a GC. In other words, if you can't ensure that Exchange will have fast access over a network link to a DC or GC that's in another physical location, install a DC or GC locally.
- Make sure that a GC is available for every four Exchange servers that you deploy in a site. As the number of Exchange servers grows, monitor the load on the GCs and take steps to ensure that performance isn't slowed because a GC is unavailable or has an excessive load.
- Ensure that a suitable DC or GC is available to handle a failover should the preferred DC or GC experience a problem.
Determining the Servers Used
How can you determine what AD servers an Exchange server is using? Before SP2, the answer was to use the Dsadiag utility, an unsupported command-line utility that reports some basic information about available DCs and GCs.
SP2 provides a new Directory Access tab on the Exchange server's properties page, as Figure 1 shows. This new tab is a significant improvement over the Dsadiag utility, which you no longer need to use. Now, you can simply access the properties page through ESM, click the Directory Access tab, and view and set the DCs and GCs that DSAccess uses.
DSAccess Changes in SP2
In addition to the longer timeout for configuration lookups and the new Directory Access tab on a server's Properties page, SP2 has made other improvements to DSAccess. Some of the more significant changes are as follows:
- If more than 10 DCs and GCs exist in the local Win2K site, you can load-balance requests across all of them.
- SP2 better handles failover to another DC or GC, so controller outages have a smaller impact on Exchange 2000 and on clients. This improvement is partly because of an improvement in the way DSAccess selects an out-of-site controller. Previously, DSAccess could choose any controller in the network to fail over to, whereas SP2 uses Windows site links and costs to determine the best controller.
- Under SP2, DSAccess monitors a failed local DC or GC. If the controller comes back online within 5 minutes, DSAccess automatically reconnects to the controller.
- In an especially welcome improvement, SP2 provides diagnostic logging to help you troubleshoot problems.
- SP2 better supports front-end and back-end configurations by eliminating the requirement that Exchange servers use remote procedure calls (RPCs) to connect to DCs and GCs that are hosted outside the demilitarized zone (DMZ).
- Suitability testing determines whether selected DCs and GCs are functioning correctly before DSAccess uses them. This enhancement deserves a little more discussion.
Suitability Tests
SP2's suitability tests help Exchange 2000 decide whether an AD server (a DC or a GC) is suitable for DSAccess to use. Before SP2, DSAccess used a simple test (i.e., a query to port 389 or 3268) to determine whether a server was offering AD service. DSAccess would use any server that responded to the test, even if the server was a heavily loaded GC, a DC in a remote site across a slow connection, or a server that hadn't fully replicated the contents of AD. All these scenarios cause problems for Exchange—message routing slows, users experience timeouts when clients attempt to access the GAL, and messages might even be sent to outdated addresses.
Register
