--- Exchange Environment --- Exchange 2007 SP1 running on Windows Server 2003 x64Single Copy Cluster modelDomain Controllers (names changed to generics): gc1.contoso.com = Server 2008 x64 R2gc2.contoso.com = Server 2008 x64 SP2dc1.contoso.com = Server 2008 x64 SP2dc2.contoso.com = Server 2008 x64 SP2 * Currently attempting to implement the change described below in a test environment. The unexpected outcome along with not knowing why or how to fix it is preventing us from pushing this to production, for obvious reasons. --- Dilemma we're trying to address --- We run Exchange 2007 SP1 on a college campus where there are 30+ child domains. Exchange runs in the "parent" domain (ex: contoso.com). From time to time - usually after reboots during normal patching cycles - the Offline Address Book stops updating because it can't communicate properly with the Global Catalog it has decided to use. When this happens, Event ID 9330 is generated with the description "OALGen encountered error 80040115 (internal ID 50004ef) accessing Active Directory SERVER_NAME..." is generated. --- Solution we'd like to implement --- We'd like to limit the available GCs Exchange can use to the servers we manage in the parent domain. It looks like we should be able to accomplish this using the "Set-ExchangeServer -Identitiy:EVS1 -StaticGlobalCatalogs:gc1.contoso.com,gc2.contoso.com -StaticDomainControllers:dc1.contoso.com,dc2.contoso.com,gc1.contoso.com,gc2.contoso.com" cmdlet. --- Problem with identified solution --- When I issue the "Set-ExchangeServer -Identitiy:TEVS1 -StaticGlobalCatalogs:gc1.contoso.com,gc2.contoso.com -StaticDomainControllers:dc1.contoso.com,dc2.contoso.com,gc1.contoso.com,gc2.contoso.com" and reboot the server, the following entries are written to the event viewer in order when it starts up. More importantly, when I attempt to move a clustered mailbox server to the node, it fails to come online. *** Informational Event ID 2081 ***Exchange Active Directory Provider will use the servers from the following list: Domain Controllers:Global Catalogs:The Configuration Domain Controller is set to <None>. MY NOTE: If I don't specify DCs and GCs using the Set-ExchangeServer cmdlet, the DCs and GC lists are populated, along with a Configuration Domain Controller. *** Informational Event ID 2080 ***Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=1380). Exchange Active Directory Provider has discovered the following servers with the following characteristics: (Server name | Roles | Enabled | Reachability | Synchronized | GC capable | PDC | SACL right | Critical Data | Netlogon | OS Version) In-site:gc1.contoso.comCDG 1 7 7 1 0 0 1 7 1gc2.contoso.comCDG 1 7 7 1 0 0 1 7 1dc1.contoso.comCD- 1 6 6 0 0 0 1 7 1dc2.contoso.comCD- 1 6 6 0 0 0 1 7 1 Out-of-site: For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. *** Error Event ID 2114 ***Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=1380). Topology discovery failed, error 0x80040a02 (DSC_E_NO_SUITABLE_CDC). Look up the Lightweight Directory Access Protocol (LDAP) error code specified in the event description. To do this, use Microsoft Knowledge Base article 218185, "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. --- Attemped Fixes --- Using the contents of the Error Event 2114, I found some posts saying that adding the Exchange Server computer objects to the Domain Admins group fixed the problem for others. I tried adding both the node and the virtual name of the clustered mailbox server to the Domain Admins group but it didn't help. --- Questions --- 1) Any thoughts on what is causing my problems aboveand how to potentially fix it or troubleshoot it? 2) Does anyone have better suggestions to address the original problem - i.e. how to force Exchange to use a specific set of Domain Controllers and Global Catalogs? Thanks.

Check info: 1. Does the issue disappear if you undo the static server settings? 2. Was the error event 2114 the only one error event that logged after failed cluster movement? 3. Whats the exact symptom of it fails to come online? How about the services on the nodes after failed CMS movement? 4. Please check if Exchange Servers and Exchange Install Servers groups contain all exchange severs 5. Please use the cmdlet below to check the server list Get-ExchangeServer -Status | fl name,current* 6. Please refer method 2 in KB 925825 to troubleshoot the issue 7. Has the IPv6 been disabled on the NICs? If yes, please enable it and check the issue 8. Please run ExBPA against CMS for health check ~~~~~~~~~~~~~~ James Luo TechNet Subscriber Support in forum If you have any feedback on our support, please contact tngfb@microsoft.com ~~~~~~~~~~~~~~

Any update?

Update: Its fixed! Ultimately it was Method 2 in KB925825 (http://support.microsoft.com/kb/925825) that did the trick. Note, however, that in order to access the Group Policy setting, I had to do the following because there wasnt a Domain Controller Security Policy option under Administrative Tools, as the KB article indicated there would be: 1. Open an MMC on the Domain Controller (Server 2008 SP1) 2. Add the Group Policy Management Editor Snap-in. 3. Browse to the Domain Controllers.contoso.com Group Policy Object and select the Local Domain Controllers Policy. 4. Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment and modify the Manage auditing and security log setting as instructed. For good measure, I rebooted the node where I had set the GC and DC settings before trying to move the CMS to it. After rebooting, the move operation worked. I was well into answering the questions you had posted and am including some of the answers I had prepared so they get indexed if someone else ends up researching a similar problem with a slightly different entry point. Anyway, thanks for the response! Theses forums are very helpful. ------ 1. Does the issue disappear if you undo the static server settings? RESPONSE: Yes, if I undo the static server settings, the issue disappears and I am able to move the CMS to the node. 2. Was the error event 2114 the only one error event that logged after failed cluster movement? RESPONSE: In terms of errors, the following errors were logged in order after the failed move-clusteredmailbox operation: Event ID 2114: Process STORE.EXE (PID=3404). Topology discovery failed, error 0x80040a02 (DSC_E_NO_SUITABLE_CDC) Event ID 2102: Process MAD.EXE (PID=1664). All Domain Controller Servers in use are not responding followed by listing of DCs Event ID 2114: Process MAD.EXE (PID=1664). Topology discovery failed, error 0x80040a02 (DSC_E_NO_SUITABLE_CDC) Event ID 2114: Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=1380). Topology discovery failed, error 0x80040a02 (DSC_E_NO_SUITABLE_CDC) Event ID 1121: Error 0x96f connecting to the Microsoft Active Directory. Event ID 5000: Unable to initialize the Microsoft Exchange Information Store service. - Error 0x96f. Event ID 1010: Exchange Information Store Instance (CMS name): Failed to start the service 'MSExchangeIS'. Event ID 1003: Clustered Mailbox Server: CMS Physical Server: Node Failed to bring the resource Exchange Information Store Instance (CMS Name) online. 4. Please check if Exchange Servers and Exchange Install Servers groups contain all exchange severs RESPONSE: The Exchange Servers group contained all physical nodes that can host the CMS and also the virtualized CMSs. The Exchange Install Servers group only contained the physical nodes but not the virtualized CMSs. I added the virtualized CMSs to the Exchange Install Servers group and retired the Move-ClusteredMailboxServer task but it still failed with the same results. 6. Please refer method 2 in KB 925825 to troubleshoot the issue 7. Has the IPv6 been disabled on the NICs? If yes, please enable it and check the issue RESPONSE: We are running Exchange 2007 on Windows Server 2003 x64 servers, which do not have the IPv6 stack installed by default. Are you saying we add IPv6 and retry? For whatever its worth, IPv6 is disabled on the DCs and GCs with which Exchange is trying to communicate.

Glad you solved the issue, and thanks for sharing the knowledge at here. :)

For what its worth I had the same problem. If I filtered my application log I saw that every other day when the OALGen process would run it would fail because it was trying to access a DC on child domain for some reason. That being said I was thinking about putting in a change control for setting an exclusion list. e.g. Set-ExchangeServer -identity E2K7-1.contoso.com -StaticExcludedDomainControllers:dc-1.contoso.com,dc-2.contoso.com,dc-3.contoso.com However since we are moving to a new site, subnet, platform I just put the hostname of the DC in the child domain it kept trying to hit on occasion in the hosts file on the Exchange server. I imagine a DNS suffix search would work too on the adapter cfg, but seriously, how does exchange not no to avoid using child domains !?!