What should you do to reduce the LDAP traffic sent across the VPN?

You are the network administrator for your company. The company operates a main office and one branch office.

Both offices are connected to the Internet and use a VPN for interoffice communications. The relevant portion of the network is configured as shown in the exhibit.

The network consists of a single Active Directory domain. Each office has one domain controller. Each office also has one Exchange Server 2003 computer, which hosts all mailboxes for users in that office.
Users in the branch office report that sending email messages from Mail2 sometimes requires several minutes.

However, the problem does not occur consistently. You discover that a large quantity of LDAP queries are passed from the branch office to DC1.
You verify that DC2 is configured as a global catalog server. You need to reduce the LDAP traffic sent across the VPN.

What should you do?

A.
Promote Mail2 to domain controller.

B.
Configure Mail2 to force the selection of DC2 as a global catalog server.

C.
Add the fully qualified domain name (FQDN) and IP address of DC2 to the Hosts file on Mail2.

D.
Modify Active Directory to place both office networks in the same site.

Explanation:
Exchange use Dsaccess service to find a set of available directory service servers. For each available directory service server, DSAccess opens LDAP connections dedicated solely on behalf of each process that is using DSAccess. DSAccess updates these LDAP connections with directory service state information (Up, Slow, or Down) that it detects, and channels requests based on this state information. The set of LDAP connections to those available domain controllers and global catalogs and their associated states forms the profile of the process. For reliability and scalability, DSAccess supports a load-balancing mechanism to distribute user context directory service requests in a round-robin fashion among these LDAP connections. Only one Recipient Update Service is active within each Active Directory domain; the others remain idle. The Recipient Update Service is fully integrated with the Exchange System Attendant (Mad.exe). According to the schedule you’ve set or by means of the Update Now option, the service contacts a local domain controller and proceeds to update address lists based on the rules set. By default DSAccess is configured to perform the “automatically discover servers” Company2 is not included in the same site as DC1 and DSAccess is already configured with DC1 as the configuration server for the Company.com domain. It is thus querying to DC1 server across the wan link and generating a large quantity of LDAP queries To fix this issue you can change dcsaccess order and point to DC2 by changing the automatically discover server to manually although is not a MS recommended practice.

Incorrect Answer
A: Can FIX the problem but is not a good option
C: If company2 can resolve DC1 you can suppose that resolve DC2, but the problem is not resolve the name is resolve who the
global catalog and configuration domain controller for Exchange
D: If you put both DC’s in the same site, Exchange mad.exe will be still querying to DC1 as Configuration Domain Controller

References
Understanding and Troubleshooting Directory Access MS Book Online Microsoft Exchange 2000 Server
Service Pack 2 Deployment Guide Event ID 2080 from MSExchangeDSAccess KB article 316300