exchnage services are not starting after Transferring of FSMO roles to ADC
dear friends,i am stuck in a situation, I have primary domain controller and additional domain controller and also I have exchange front end and back end environment configured in member servers. I am unhappy with primary domain controller hardware. So I transferred all FSMO roles to Backup Domain controller, after that I has demoted the old Active Directory server. Active Directory is working fine after Transferring FSMO roles to Backup Domain controller. Now i am facing problem with exchange servers. And finally my question is what are the things I need to check in exchange servers side? Thanks in advance.Any immediate help will be highly appreciated.Regards,gowtham
November 13th, 2008 12:33am

Check event logs.. dcdiag /v netdiag /v perform metadata cleanup if required, Exchange may still be seeing old demoted DC for Directory information. http://technet.microsoft.com/en-us/library/cc736378.aspx support.microsoft.com/kb/216498 run exbpa, it'll let you know what is wrong and how to fix that. -M
Free Windows Admin Tool Kit Click here and download it now
November 13th, 2008 6:07am

Hi Gowtham,I would like to know what kind of problems are you facing after transferring FSMO roles?take steps suggested by Mukeshmake sure DSAccess has auto discovered and listed the right Domain Controller and Global Catalog Server, you can see DSAccess tab by opening the properties of your exchange server. also post the errors in the evenlog.Thanks
November 13th, 2008 9:47am

Hello Gowtham, Have you rebooted your Exchange server after this operation? Exchange normally detects new DC/GC automatically otherwise you need to restart the Exchange services or reboot the server. Additionally, look for the 2080 event in application event log and make sure that Exchange server is able to communicate with DC/GCs as per below KB. http://support.microsoft.com/kb/316300 Run ExBPA and check for any error.
Free Windows Admin Tool Kit Click here and download it now
November 13th, 2008 10:00am

Hello Chinni,As Amit said you need to reboot the exchange and if needed you need to re-run the domainprep once again to ensure all the permission where inplace.Little more information about DSAccess.DSAccess is probably the most critical. The DSAccess service's primary job is to discover the Active Directory topology, and then provide that information to Exchange Server. The DSAccess service is dynamic and completely automated. Once every 15 minutes, it analyzes your Active Directory topology looking for any changes since the last discovery poll. More specifically, the DSAccess service is looking for: Changes to the site structure The addition or removal of domain controllers Changes in domain controller placement Available global catalog serversTechnically speaking, the DSAccess service is part of Exchange Server; it is contained within the DSACCESS.DLL file. Instead of collecting information through an LDAP query against AD, Microsoft chose to break DSAccess out into a separate service in order to increase efficiency. Each time DSAccess queries are performed, the information is stored in the DSAccess cache. This means Exchange Server doesn't have to perform a fresh query every time it needs to access a domain controller, or every time a Microsoft Outlook client needs to access a global catalog server. DSAccess can dynamically detect domain controller and global catalog failures. When it detects a failure, it helps Exchange to fail over to an alternate domain controller or global catalog server (assuming that one exists), thus reducing potential downtime. The DSAccess service also maintains a second cache to store the results of LDAP queries. That way, if another user makes a similar request, Exchange can save time by just returning the cached query result. The DSProxy service is a mechanism that helps make Exchange Server 2003 backward-compatible with Microsoft Outlook versions before Outlook 2000. Because Exchange 5.0 and Exchange 5.5. used their own built-in directory (the Exchange Directory) instead of storing information in Active Directory, older Microsoft Outlook clients can experience problems when run with Exchange 2003. Versions prior to Outlook 2000 use MAPI to query the Exchange Directory for information about mailboxes in the organization. Since newer versions of Exchange Server do not contain an Exchange Directory, the DSProxy service acts as a directory emulator. When older versions of Microsoft Outlook make MAPI calls directed toward the Exchange Directory, the DSProxy service intercepts the calls. It then reads the requested information from Active Directory and passes it back to the requesting client. When the DSProxy service retrieves information from a global catalog server, it does not use LDAP queries, even though global catalog servers are in fact domain controllers. Instead, DSProxy uses the Name Service Provider Interface (NSPI) protocol for global catalog server communications. NSPI is more efficient than LDAP, but is only supported by global catalog servers. Therefore, Exchange Server uses DSAccess to get the name of the global catalog server (via an LDAP query), and then uses NSPI to retrieve information from the global catalog. For clients running newer versions of Microsoft Outlook, DSProxy acts as a referral service. This is important because the Global Address List (GAL) is derived from a global catalog server, and Microsoft Outlook does not contain a mechanism for contacting a global catalog server directly. When Microsoft Outlook clients contact Exchange Server looking for a GAL, Exchange Server uses the DSProxy service to provide the client with a referral to a global catalog server. Once Microsoft Outlook receives this referral, it is able to communicate with the global catalog server directly. Arun Kumar | MCSE - 2K3 + Messaging | ITIL-F V3
April 23rd, 2009 9:02pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics