Event ID 2114 Source MSExchangeDSAccess
| Event ID | 2114 |
| Source | MSExchangeDSAccess |
| Type | Error |
| Description | Process INETINFO.EXE (PID=241).Topology Discovery failed, error 0x80040a02. |
| English, please! | 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? |
| Comments |
Adrian Grigorof
(Last update 4/16/2009): 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: 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 (M327843) - Troubleshooting OWA when the contents frame displays “Loading” (M280823) - Applied Hot Fix (Se the link for KB898060) - Re-booted OWA Server and the problem was gone. Various processes reported: - WMIPRVSE.EXE -EMBEDDING - INETINFO.EXE - EMSMTA.EXE - MAD.EXE - EMSMTS.EXE - STORE.EXE - EXMGMT.EXE - IISIPM... "EXCHANGEAPPLICATIONPOOL - IISIPM... "MSEXCHANGEOWAAPPPOOL Anonymous (Last update 1/28/2009): 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. Ray Andrade (Last update 7/30/2008): 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. Anonymous (Last update 7/10/2008): 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. J. LoSpinoso (Last update 12/4/2006): 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 M275554 for additional information. Why bother deciphering Event logs when GFI EventsManager can do everything for you? Free trial here! David Page (Last update 8/29/2006): 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. Mihai Andrei (Last update 6/13/2006): - 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 M919089 to solve this problem. Anonymous (Last update 5/6/2006): In our case, an older version of GFI Mail Essentials caused the problem. After we uninstalled it, the Exchange Server worked again. Marty (Last update 6/10/2005): 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. Ionut Marin (Last update 6/10/2005): - 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 M823722 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. Joe Richards (Last update 6/10/2005): - 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. Anonymous (Last update 3/4/2005): 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. Mauro Patrucco (Last update 9/13/2004): 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: ”ldap/[exchange_virtual_server_name]” ”ldap/[exchange_virtual_server_FullQualifiedDomainName]”, then add it manually ”setspn -a ldap/[exchange_virtual_server_name]” ”setspn -a ldap/[exchange_virtual_server_FQDN]”. Elliott Fields Jr (Last update 5/6/2003): No Domain Controllers could be located for Directory Access. Why bother deciphering Event logs when GFI EventsManager can do everything for you? Free trial here! |
| Links | M275554, M823722, M919089, MSEX2K3DB, Guide to Monitoring the Performance of your Exchange Server, MSExchangeADTopology failed to start, M898060, M280823, KB898060 |
| Search | Google Web - Microsoft Support - Bing - EventID.Net Queue - More links... |
| Custom search | The custom search information is available to subscribers only. |
| Feedback | Send comments - Notify me when updated |
| Print version |