Event ID/Source search
Keyword searchExample: Windows cannot unload your registry file
Event ID: 2102 Source: MSExchangeDSAccess
Process MAD.EXE (PID=792). All Domain Controller Servers in use are not responding:
|English: This information is only available to subscribers. An example of English, please!|
|Concepts to understand:|
What is the role of the Microsoft Exchange Directory service?
What is MAD.EXE?
From newsgroup postings it appears that this event can be safely ignored. Apparently, Microsoft PSS confirmed that this error code is a benign error and is a result of running in a single GC/DC environment.
Also, as per ME328646, this issue may occur if the Exchange Enterprise Servers security group does not have "Manage auditing and security logs" permissions on the domain controller.
See "Cisco Support Document ID: 43640" for information about this event.
In our case, this error was followed by other errors: 2114, 1042, 1047, 8213 and 9098, while we were installing the first Exchange 2003 on a site which had an Exchange 5.5 server. (Installation stalled without giving any on-screen errors) The problem was a non-default LDAP port being used by the old Exchange 5.5 server. When we changed the port to 389 and restarted the services, the errors were gone. By the way, we also had to change port in the Connection Agreements of ADC.
As per Microsoft: "This issue may occur if the Exchange Enterprise Servers security group does not have Manage auditing and security logs permissions on the domain controller. The Exchange Enterprise Servers group must have Manage auditing and security logs permissions on all the domain controllers in the domain". See ME328662 and ME321318 to fix this problem.
This issue may also occur if the Exchange server is not listed as a member of the Exchange Domain Servers group. See ME327844 for more details.
From a newsgroup post: "This issue seems related to the DSAccess of Exchange. MSExchangeDSAccess is the core component of Exchange, which detects the AD topology. DSAccess related issues are usually complex and time consuming, as it has multiple causes, such as AD problems, network problems or Exchange miss-configuration. Based on my research, I suggest you try the following steps to narrow down the issue:
Step 1: Verify DSN settings on Exchange.
On the Exchange 2003 server, run "ipconfig /all" command at the command prompt. Verify that the DNS server is correct.
Step 2: Verify the healthy of DCs/GCs.
1. Use LDP to connect to the DCs by port 389. LDP utility is included in Windows 2000/2003 supporting tools. To do this:
- Click Start -> Run, input ldp.exe and press Enter.
- Click Connection -> Connect.
- Type the server name of the domain controller that you want to connect to, and the port 389.
2. Repeat the same steps to use LDP to connect to the GCs at port 3289.
Step 3: Checking Service Principal Names (SPN) for LDAP.
1. Download the Setspn utility.
2. Run the setspn utility to list the registered Services Principal Names on the Exchange Virtual Server:
setspn -l <Exchange Virtual Server name>
3. Verity if you can see entries about Service Principal Names (SPN) for LDAP. If not, please continue with the following steps to register them manually:
setspn -a ldap/<Exchange Virtual Server name> <Exchange Virtual Server name>
setspn -a ldap/<Exchange Virtual Server name>.xxxxxx.local <Exchange Virtual Server name>
The format is much similar to the entries below which you can see by setspn –l <Exchange Virtual Server name> command.
exchangeMDB/<Exchange Virtual Server name>
exchangeMDB/<Exchange Virtual Server name>.xxxxxx.local
Step 4: Verifying DSAccess detection setting.
1. Start the Exchange System Manager.
2. Navigate to the Exchange 2003 server object, and open its Properties.
3. On the Directory Access tab, check if all the DCs/GCs are listed properly. Make sure the option "Automatically discover servers" is checked".
See ME842116, ME896703, and MSEX2K3DB for additional information on this event.
After installing Service Pack 4 on a SBS2000 server, I started to receive this error. The process that complained was in my case INETINFO.EXE. The Exchange System Attendant, MTA and IS services would not start. After trying for a while to fix the problem and having no luck, I removed Service Pack 4, and all the services started up and the error went away.
We had the same problem and fix it by disabling "automatic network topology discovery" in DSAccess tab, but I should note that the problem occurred after I converted Exchange System to native mode. Before conversion all work well.
I've seen this event occur in a multi domain controller/GC environment running on an Exchange 2000 SP3 server. The 9154 error followed closely behind this error. To correct this problem, I re-ran /DOMAINPREP from the Exchange 2000 Service Pack 3 CDROM and the 2102/9154 errors disappeared.
Our environment consist of W2K SP2 / E2K SP3 mailbox servers with SAN backend.
W2K SP3 / E2K SP3 connector and owa servers (local disk only)
Parent Admin Domain WFC.INT (first in forest), Exchange & Users domain CORP.INT
I had been tracking a transient error that appeared on only 1 of 6 servers in a domain. A DSAccess Topology Error 2102 was appearing. This is a report of a topology generation failure. DSAccess issues a service query (every fifteen minutes) and when no responses apparently came back, and the server thinks there is no DC, GC or Configuration Container servers available.
The damage is done now. It blanks the service table. During this time, users can't log onto the store. MAD, MTA, WINMGT and other service begin to complain, and the stores could be dismounted.
On the next query, if the table is successfully generated, the problem disappears, because key authentication and directory requests are processed again.
You could be looking at a lot of help desk calls flooding in, and potentially a dismounted store which you have to explain. And an error which looks innocuous because it doesn't draw attention in many system monitoring services.
We suspect this is happening because the (Compaq) server in question was not built the same way as all the other servers. Specifically, it was not SmartStarted, and Windows was simply reinstalled and a new C partition created during the process. All of the Proliant components and agents were placed on the machine after the build was completed.
The end result, is we have a problem child server, who periodically does this mysterious "I can't see anything on the network" and service is interrupted. It might happen today, then next week, then two days in a row, then 30 days from now… random events.
We're going to rebuild the server and we've changed out the NICs, but in the mean time, we're thinking for hardcoding the DSAccess Tab with the information returned in the 2050 Information messages collected by increased DSAccess/Topology logging. This provides the full table of discovered servers so you can hardcode that info into DSAccess.
The error can occur when you run Exchange 2000 Server in a single domain controller topology. See ME310896.
This can occur after installing Exchange 2000 SP2. See ME322837.
This event may occur if the Manage Auditing and Security Log right (SeSecurityPrivilege) was removed for the Exchange Enterprise Servers domain local group on some or all of the domain controllers. See ME314294 for more details.
This problem may occur if Exchange 2000 is installed on a global catalog server and no domain controller is available. I downloaded and installed Exchange Service Pack 3 and the problem was solved. See ME318067.
|Private comment: Subscribers only. See example of private comment|
|Links: ME310896, ME314294, ME318067, ME321318, ME322837, ME327844, ME328646, ME328662, ME842116, ME896703, The Setspn utility, Cisco Support Document ID: 43640, MSEX2K3DB|
|Search: Google - Bing - Microsoft - Yahoo - EventID.Net Queue (0) - More links...|
|Custom search for *****: Google - Bing - Microsoft - Yahoo|
Send comments or solutions
- Notify me when updated