In our case, the only DC in the site where Exchange 2003 was located had gone down. We had to remove the IP of this DC from DNS settings and also move that subnet (in AD Sites and Services) to the remote site whose DCs were available.
Look up the Lightweight Directory Access Protocol (LDAP) error code specified in the event description. To do this use ME218185
(Microsoft LDAP Error Codes). Use the information in that article to learn more about the cause and resolution to this error. Use the Ping or PathPing command-line tools to test network connectivity to local domain controllers.
Different processes and different errors can be reported with this event and one should carefully consider the troubleshooting as they may apply to different instances of this problem. The PID (process ID) is irrelevant as it is specific to that running session of Exchange.
Process: MSEXCHANGEADTOPOLOGYSERVICE.EXE, error: 0x80040a02 (DSC_E_NO_SUITABLE_CDC). - Error translates to 'The wait operation timed out.' It is possible that the Exchange component was unable to reach the Active Directory or the computer running Exchange is not powerfull enough to meet the demands of Exchange (see the "Guide to Monitoring the Performance of your Exchange Server" blog for suggestions on monitoring the Exchange performance. An interesting discussion about this can be found on Technet - see the "MSExchangeADTopology failed to start" link.
Process: EXMGMT.EXE, Error code 0x8007077f
. From a support forum:
- Corrected OWA and IIS configuration based on the following articles.
- Troubleshooting Outlook Web Access logon failures in Exchange 2000 and in Exchange 2003 (ME327843
- Troubleshooting OWA when the contents frame displays “Loading” (ME280823
- Applied Hot Fix (Se the link for KB898060)
- Re-booted OWA Server and the problem was gone.
Various processes reported:
- WMIPRVSE.EXE -EMBEDDING
- IISIPM... "EXCHANGEAPPLICATIONPOOL
- IISIPM... "MSEXCHANGEOWAAPPPOOL
I have a SBS 2008 and disabled IPv6 in the network settings was also causing this issue for me. Re-enabling it fixed the problem.
I have Exchange 2007 running on a Windows 2008 domain controller. I disabled IPv6 in the network settings, which caused this problem to appear. Re-enabling it fixed the problem.
I ran into this problem when applying a "All in one" security lock down update our company had developed. In the package, they decided to change the startup of the "NetLogon" service to "Manual". In this configuration, the Netlogon service will not be started and cause this event. Simply starting the NetLogon service (and setting to startup type of Automatic) fixed this issue for me. I was then able to start our Exchange Services.
A possible root cause is an additional DNS A record for a DC in the Exchange Servers Site, record that happens to be for an interface for which the Exchange Server has no connectivity.
In our case, all of our servers have a secondary NIC that is used for tape backup traffic. This interface has no routing to the real network that AD and Exchange live on. So here's what, even though DNS registration is disabled on this secondary NIC, it still registers itself. If a system has DNS installed, each time the DNS Server starts or a zone is reloaded, it registers all interfaces that are configured to answer DNS queries. To determine if the Exchange server (or any member server or client) has resolved an IP for a DC, use nltest /dsgetdc:"domain". See ME275554
for additional information.
This error, combined with other numerous MU, SA and IS errors may be due to incorrect permissions in the default domain controllers policy either by miss-configuration or use of the dcgpofix command. The Exchange Enterprise Servers group must be defined in the default domain controller’s policy under Manage Auditing and Security Log. This can be found in the User Rights Assignment area of the GPO. Once rights are established, restart SA and IS.
- Error code 0x80040a02
- This problem can occur because the Exchange security groups do no have the appropriate user rights to enable the Directory Service Access (DSAccess) component to communicate with Active Directory. See ME919089
to solve this problem.
In our case, an older version of GFI Mail Essentials caused the problem. After we uninstalled it, the Exchange Server worked again.
Check that the "Exchange servers" group has the rights to "manage audit and security logs". On a working DC, go to Start -> Programs -> Admin tools -> Domain controller security -> Local settings -> User Rights and find the manage audit and security logs option. Add the group if necessary.
- Error code 0x80040a02
- This event can be caused by the evaluation version of SharePoint Portal Server. After this evaluation period has expired this event along with others are logged in your event log. See ME823722
for more details.
As per Microsoft: "This event indicates that new topology could not be generated. If this is NOT the first topology discovery since system startup, the previously discovered topology will be used. However, topology discovery failure is usually a sign of a serious problem and needs to be investigated immediately". See MSEX2K3DB
for more details on this event.
- Error code 0x8007077F
- This means that no site/subnet has been defined for the Exchange server. Check the IP address of the Exchange server, define a subnet in Active Directory, and assign that subnet to the proper site.
We found this event popping up in a system with Windows 2003 Standard Server and Exchange Server 2003 Service Pack 1. It was followed by event 2102 stating that the Exchange server is not able to discover the topology of our AD.
To solve it we activated the MSExchangeDSAccess diagnostic logging. We set the Topology section to maximum logging. The next topology discovery cycle revealed that it was trying to get AD information from a public DNS instead of our internal AD DNS servers.
This problem appeared because our TCP/IP local configuration included two internal DNS servers and two public DNS and the exchange topology discovery engine took the list and used it in the reverse order, therefore it was searching the Internet for private information.
This problem can appear because the service principal name for ldap is not registered for the Exchange virtual server. You can verify this with the setspn utility (Windows 2003 resource Kit). Enter the following command:
setspn -l [exchange_virtual_server_name]
If you do not see:
then add it manually
setspn -a ldap/[exchange_virtual_server_name]
setspn -a ldap/[exchange_virtual_server_FQDN]
No Domain Controllers could be located for Directory Access.