If you missed the first part in this article series please read A Closer Look At Directory Service Access (DSAccess) – Part 1.
In part 1 of this two-part article we covered what DSAccess is and how it chooses domain controllers and global catalog servers for use by Exchange.
DSAccess Test Results
If you want to see what’s going on with the DSAccess server selection process, then you’ll first need to increase the diagnostics logging on DSAccess. In Exchange System Manager, go to the properties of your Exchange server and then click the Diagnostics Logging tab. You’ll then see that there is a separate category for DSAccess as shown below in Figure 1.
Figure 1: DSAccess Diagnostics Logging
If you change the diagnostics logging for the Topology category to Medium or Maximum, you should get to see the results of the testing that DSAccess performs on your global catalog servers and domain controllers. The event to look for is event 2080 from the source MSExchangeDSAccess and category Topology. An example event is shown below in Figure 2. This event will help you to diagnose any problems you have that are related to the topology.
Figure 2: Sample DSAccess Topology Event
Here you can see that DSAccess has discovered two servers and their associated characteristics. The associated characteristics are the results of the tests that I described previously. You’ll see from Figure 2 that DSAccess has discovered two servers, DCEXCH1 and DC2 that are in the same Active Directory site as the Exchange server. No out-of-site servers were detected.
I have already discussed what the various tests are that DSAccess performs; the letters and numbers that follow each server name in Figure 2 above are the results of these tests. So how do these letters and numbers correspond to the tests? Table 1 shows a breakdown, in order, of what the various columns mean:
Column Name
Description
Server name
This is the Fully Qualified Domain Name (FQDN) of the server that has been detected and tested.
Roles
Here you can see whether the server being tested can be used for the various roles assigned by DSAccess. Three letters are used: C, D and G. C is used to represent the configuration domain controller, D for a domain controller and G for a global catalog server. So from Figure 2 above, you can tell from the presence of the hyphen and absence of the letter G that DC2 can not be used as a global catalog server, for example. Remember, you must have at least one server available that can service each of the three roles.
Reachability
This is the third column and shows a numerical value that represents the total of three different tests as to whether the server is reachable, via TCP, in the various server roles. If the server is reachable as a global catalog server, you can add 1. If the server is reachable as a domain controller, you can add 2 whilst if the server is reachable as the configuration domain controller you can add 4. Therefore, if the server is reachable for all 3 roles as is the case with DCEXCH1, the final total is 1+2+4=7. Since DC2 is not a global catalog server, the final total for this server is 0+2+4=6.
Synchronized
The synchronized column again uses the same numerical value system as the previous test and signifies that the server being tested is synchronized as far as Active Directory is concerned.
GC capable
This column will show a 1 if the server is a global catalog and a 0 if it is not. Figure 2 above confirms that DC2 is not a global catalog server.
PDC
The sixth column will show a 1 if the server is the primary domain controller for the domain and a 0 if it is not.
SACL right
If DSAccess has the ability to read the Security Access Control List (SACL) for the configuration naming context, you’ll see a 1 here. Otherwise, you’ll see a 0.
Critical Data
A 1 in this column simply means that DSAccess confirms that this server exists in a domain where Exchange DomainPrep has completed successfully.
Netlogon
The Netlogon test is performed against the configuration domain controller, domain controller and global catalog roles and again uses the same numerical system as previously discussed in the reachability and synchronized tests. You can therefore see from Figure 2 above that a 7 in the column for DCEXCH1 means that this server passed all three tests, whilst DC2, which has a 6 shown, did not pass the global catalog test.
OS Version
A 1 in this column signifies that the two servers pass the operating system version test. In other words, they are either running Windows Server 2003 or Windows 2000 SP3 (or higher).
Table 1: DSAccess Test Results
Hard Coding
Of course, it’s great that DSAccess can automatically select servers for you but there may be troubleshooting situations where you wish to manually choose which domain controller or global catalog server is to be used. This is possible via the Directory Access tab as shown in Figure 3.
Figure 3: Directory Access Properties Tab
Notice the Automatically discover servers check box. I should point out that in Figure 3, this check box is actually greyed-out due to the fact that I’ve selected to show all domain controllers; this is not the case if only global catalog servers or only configuration domain controllers are shown. Removing this check box allows you to manually specify your chosen servers. However, note that if this is removed, you will receive the warning dialog box as shown below in Figure 4:
Figure 4: DSAccess Discovery Warning
Once this check box has been cleared, you are then free to click the Add and Remove buttons as shown in Figure 3 to manually specify your domain controllers and global catalog servers. Note, though, that if you do manually specify domain controllers and global catalog servers, DSAccess will no longer failover to use alternative servers if your chosen servers fail; additionally the topology discovery feature will no longer be performed.
DSAccess Cache
As I mentioned earlier, DSAccess maintains a cache that effectively reduces the number of LDAP queries the Exchange server makes to Active Directory. The cache is actually split into two sections: one for user objects and the other for configuration information. User objects are objects from the domain naming context of Active Directory, whilst configuration information is sourced from the configuration naming context of Active Directory.
In Exchange 2000 the DSAccess cache was split equally between the two sections, with both sections allocated 25MB; manual tuning options were available. According to the Exchange 2003 Deployment Guide, the cache sizes have changed in Exchange 2003; the user object cache now stands at 140MB, with the configuration information cache standing at 3MB.
Additionally, the Exchange Deployment Guide states that if you manually tuned the DSAccess cache sizes in Exchange 2000, these changes should be removed on your Exchange 2003 server. This can be performed by removing the following registry key:
Key: HKLM\System\CurrentControlSet\Services\MSExchangeDSAccess\Instance0
Value: MaxMemoryUser
Type: REG_DWORD
DSAccess Performance
Perhaps the most important performance counter to monitor for DSAccess performance is the LDAP Search Time counter from the performance object MSExchangeDSAccess Processes. This counter measures the time, in milliseconds, to send an LDAP search query that originates from DSAccess. Microsoft Operations Manager 2005 (MOM) monitors this performance counter every 60 seconds for you and sends a warning alert if the value exceeds 50ms over a 5 minute (5 samples) period. This is an indication that global catalog issues could be affecting the performance of your Exchange server environment.
MOM also contains 45 rules configured to monitor the event log for specific DSAccess problems, together with useful knowledge base information on what troubleshooting steps to take next.
Summary
Hopefully within this two-part article you’ve see how important the DSAccess component is to an Exchange server infrastructure. It’s not difficult to imagine what would happen without DSAccess – many Exchange components and services all communicating directly with Active Directory would soon lead to an inundated domain controller. Make sure you keep an eye on your event logs for events relating to DSAccess.
If you missed the first part in this article series please read A Closer Look At Directory Service Access (DSAccess) – Part 1.
