How ESM discovers domain controllers
Published Feb 16 2004 12:40 PM 1,894 Views

Something that comes as a surprise to many Exchange administrators is that the Exchange System Management (ESM) tool does not use DSAccess to discover the DC it will talk to.  Instead it discovers the DC it will use on its own, using ADSI to do a server-less binding to the directory.  The reason behind this is because of ESM's extensive use of and queries to Active Directory. 

This is not of any concern and normally it's not a problem.  However, if you do get into the scenario where your Active Directory is out of sync and it so happens that the DC referred to your server by DSAccess does end up being different than the DC ESM has bound itself to (ESM & server in different sites for instance), you could find that settings modified are delayed being picked up by the server while waiting for replication to take place.  This could also account for an apparent difference in the setting you view and what the server appears to be using, although this shouldn't happen unless you have just modified the setting or your AD replication between the DCs being used is behind.

Amanda Langowski

9 Comments
Not applicable
This is one thing that really annoys me about ESM.

I miss the feature in 5.5 where you can choose from a pull down menu the server (directory) you wish to view.

I realize that you can accomplish the same thing with ESM, it's just a little more difficult to do so.
Not applicable
That's a good idea, Rick... I've opened a DCR (Design change request) in our database to track this suggestion.
Not applicable
I was under the impression that ESM required a GC, like Exchange. Does the ESM actually not require this?

For example, when I build an address list in ESM, I then use the Preview button to test it. Is ESM actually querying a GC here (because a DC wouldn't necessarily be sufficient), or is ESM doing some RPC with an Exchange server (which is in turn communicating with a GC)?
Not applicable
Exchange-faq.dk - Din portal til Microsoft Exchange Server information
Not applicable
You can still select manually your dc or change it using dsadiag (for exchange 2000)
Not applicable
You are correct, ESM does use GCs as well. Certain attributes, for instance, are only available on GCs. However, I used the term DC in the problem description to mean DC regardless of whether it is a "plain" domain controller or a domain controller with the GC role.
Not applicable
FYI, you can choose what DC is used by ESM.

1. Start, Run, MMC
2. File, Add/Remove Snap-In
3. Click Add.
4. Choose Exchange System Management and click Add
5. A dialog is presented to choose a DC
Click OK or Close until you're back to MMC

Viola! Your System Manager is now using the DC you chose.
Not applicable
Better yet, I wish we could simply right click on the ORG object and choose a different DC/GC, like you can in practically every other AD administration tool...

}-]
Copper Contributor

ESM (Exchange System Management) is a tool used by Exchange administrators to manage Exchange servers. One surprising fact about ESM is that it doesn't rely on DSAccess (Directory Service Access) to discover the domain controller (DC) it will communicate with. Instead, ESM independently discovers the DC by using ADSI (Active Directory Service Interfaces) to establish a connection to the directory.

The reason behind this approach is that ESM heavily relies on Active Directory for its operations and queries. By directly binding to the directory, ESM ensures it can efficiently access and interact with Active Directory.

Under normal circumstances, this method of DC discovery doesn't cause any issues or concerns. However, if your Active Directory experiences synchronization problems and the DC identified by DSAccess differs from the DC ESM has bound itself to (for example, when ESM and the server are in different sites), you may encounter delays in the server picking up modified settings. This delay occurs because the changes made by ESM on one DC may take some time to replicate to the other DC, resulting in an apparent difference between the settings you view and the settings the server appears to be using. This situation is unlikely to happen unless you have recently modified a setting or if there is a delay in AD replication between the DCs being utilized.

Version history
Last update:
‎Jul 01 2019 02:52 PM
Updated by: