Possible bug in Exchange 2013 CU5 Setup.exe /PrepareAD

Recently ran into an issue when attempting to run Setup.exe /PrepareAD for Exchange 2013 Cu5.  As with all new Exchange updates, the expectation is that there will be schema updates included.

Upon running the Setup.exe /IAcceptExchangeServerLicenseTerms /PrepareAD command I get this error.

Performing Microsoft Exchange Server Prerequisite Check

Prerequisite Analysis COMPLETED

Configuring Microsoft Exchange Server

Organization Preparation FAILED
The following error was generated when "$error.Clear();
initialize-ExchangeUniversalGroups -DomainController $RoleDomainController -ActiveDirectorySplitPermissions $Rol

" was run: "Microsoft.Exchange.Data.Directory.SuitabilityDirectoryException: An Active Directory error 0x51 occurred whe
n trying to check the suitability of server 'DC01.Example.com'. Error: 'Active directory response: The LDAP server
is unavailable.' ---> System.DirectoryServices.Protocols.LdapException: The LDAP server is unavailable.
at System.DirectoryServices.Protocols.LdapConnection.Connect()
at System.DirectoryServices.Protocols.LdapConnection.BindHelper(NetworkCredential newCredential, Boolean needSetCrede
at Microsoft.Exchange.Data.Directory.PooledLdapConnection.BindWithLogging()
at Microsoft.Exchange.Data.Directory.PooledLdapConnection.TryBindWithRetry(Int32 maxRetries, ADErrorRecord& errorReco
--- End of inner exception stack trace ---
at Microsoft.Exchange.Data.Directory.TopologyDiscovery.SuitabilityVerifier.CheckIsServerSuitable(String fqdn, Boolean
isGlobalCatalog, NetworkCredential credentials, String& writableNC)
at Microsoft.Exchange.Data.Directory.ConnectionPoolManager.GetConnection(ConnectionType connectionType, String partit
ionFqdn, ADObjectId domain, String serverName, Int32 port, NetworkCredential credential)
at Microsoft.Exchange.Data.Directory.ConnectionPoolManager.GetConnection(ConnectionType connectionType, String partit
ionFqdn, NetworkCredential networkCredential, String serverName, Int32 port)
at Microsoft.Exchange.Data.Directory.ADDataSession.GetConnection(String preferredServer, Boolean isWriteOperation, St
ring optionalBaseDN, ADObjectId& rootId, ADScope scope)
at Microsoft.Exchange.Data.Directory.ADDataSession.GetReadConnection(String preferredServer, String optionalBaseDN, A
DObjectId& rootId, ADRawEntry scopeDeteriminingObject, DualSearchMode dualSearchMode)
at Microsoft.Exchange.Data.Directory.ADGenericReader.GetNextResultCollection(Type controlType, DirectoryControl& resp
at Microsoft.Exchange.Data.Directory.ADPagedReader`1.GetNextResultCollection()
at Microsoft.Exchange.Data.Directory.ADGenericPagedReader`1.GetNextPage()
at Microsoft.Exchange.Data.Directory.ADGenericPagedReader`1.<GetEnumerator>d__0.MoveNext()
at Microsoft.Exchange.Data.Directory.Recipient.ADRecipientObjectSession.<FindByAccountName>d__2`1.MoveNext()
at Microsoft.Exchange.Data.Directory.Recipient.ADRecipientObjectSession.FindByAccountName[T](String domainName, Strin
g accountName)
at Microsoft.Exchange.Management.Tasks.InitializeExchangeUniversalGroups.InternalProcessRecord()
at Microsoft.Exchange.Configuration.Tasks.Task.<ProcessRecord>b__b()
at Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePip

The Exchange Server setup operation didn't complete. More details can be found in ExchangeSetup.log located in the
<SystemDrive>:\ExchangeSetupLogs folder.

I looked at a network capture while attempting to run it again and saw something odd. Right at the time of the failure in the ExchangeSetup.log there’s an attempt to contact DC01.example.com a non-GC Domain Controller on port 3268.  Which obviously fails.

The problem appears to occur during the execution of the command:
initialize-ExchangeUniversalGroups -DomainController $RoleDomainController -ActiveDirectorySplitPermissions $RoleActiveDirectorySplitPermissions

Looking in the log file it identifies a Preferred GC (DC02) and Preferred DC (DC01 which is the Schema Master). They are used successfully it seems earlier in earlier portions of the update.  But when initialize-ExchangeUniversalGroups runs, for some reason it doesn’t use the identified GC, doesn’t even try before attempting a connection to the non-GC.

In trying to fix this, I moved the Schema Master role from DC01 to DC02 (the GC).  The next time /PrepareAD worked fine.  Presumably making the Schema Master a GC would have also worked.  Strange problem though as I’ve done the rest of the schema updates involved in the previous 2013 CUs without any problem.



8 responses to “Possible bug in Exchange 2013 CU5 Setup.exe /PrepareAD”

  1. Jennifer Mocherman says :

    Thank you. I was stuck trying to install the update.

  2. Uglymike says :

    Thanks this really helped me out. The possible bug is in CU6 too.

  3. MikeyRod1981 says :

    Hi There! Uglymike is correct about CU6 as that was the installation media I used today and I was presented with the same problem.

    Ril3y, you’re correct in your assumption about making the particular DC a GC using Active Directory Sites & Services versus transferring the Schema master role, as that is how I got around this error today.

    Just wanted to note though, if you do what I did, monitor the event viewer of the particular DC you just finished making a GC, under the Active Directory Web Services Log specifically, and make sure you get event ID 1200:

    Active Directory Web Services is now servicing the specified directory instance.

    Directory instance: GC
    Directory instance LDAP port: 3268
    Directory instance SSL port: 3269

    As soon as I made the change via AD Sites & Services, I was getting Event ID 1202 once a minute for 5 minutes until I finally got Event ID 1200, mentioned above. Below is Event ID 1202 for reference:

    This computer is now hosting the specified directory instance, but Active Directory Web Services could not service it. Active Directory Web Services will retry this operation periodically.

    Directory instance: GC
    Directory instance LDAP port: 3268
    Directory instance SSL port: 3269

    You should also see Event ID 1119 under the Directory Service event log:
    This domain controller is now a global catalog.

    Thanks for your help!

  4. Tomek says :

    Same in CU7

  5. Matt Green says :

    This is still an issue in CU8, as well.

  6. Jean-Bernard ROUX says :

    Same in CU11 ;-(

    • ril3y says :

      I brought this up a few times, via support cases and such and I’m told that the issue is not going to be fixed, as the workaround is “easy”. Dissapointing, but I’ll deal.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: