Error "Some or All Identity References Could Not Be Translated" When Adding Members to Exchange Server 2013 Database Availability Group

Update: this issue is now fixed in Cumulative Update 5. Refer to KB2958430 for more information.

When adding members to an Exchange Server 2013 database availability group you may encounter the following error message.

“Some or All Identity References Could Not Be Translated”

This error can occur when adding the first DAG member to a new DAG, or when adding additional members to an existing DAG.

On closer inspection you may notice that the DAG member appears to have been successfully added to the DAG.

[PS] C:\>Get-DatabaseAvailabilityGroup

Name             Member Servers
----             --------------
DAG1             {SYDEX1}

In addition, the existing mailbox databases have been updated to MasterType “DatabaseAvailabilityGroup” and the MasterServerOrAvailabilityGroup value updated to the name of the DAG.

[PS] C:\>Get-MailboxDatabase | fl name,*master*

Name                            : Mailbox Database 1055054279
MasterServerOrAvailabilityGroup : DAG1
MasterType                      : DatabaseAvailabilityGroup

In addition, the failover cluster has been formed. However, it is running in Node Majority quorum configuration instead of Node and File Share Majority.

PS C:\> Get-ClusterQuorum | fl

Cluster        : DAG1
QuorumResource :
QuorumType     : NodeMajority

No file share witness resource exists for the cluster when viewed in Failover Cluster Manager.

And, the file share witness server does not contain a file share witness folder and share for the DAG.

[PS] C:\>Get-DatabaseAvailabilityGroup | fl *witness*

WitnessServer             : syddc1.exchange2013demo.com
WitnessDirectory          : C:\DAGFileShareWitnesses\DAG1.exchange2013demo.com

This appears to be a bug introduced in Exchange Server 2013 Service Pack 1. Explained by Jared Van Leeuewn in this TechNet forums thread:

“The issue isn’t with the FSW or the cluster or anything else; the issue is with the Dag cmdlets trying to auto configure the FSW in Exchange 2013 SP1 in a disjoint namespace. In Exchange 2013 RTM it was setting up the permissions incorrectly in a disjoint namespace, and now it’s just out and out failing. It looks like the cmdlets are able to add nodes to the Dag AD object, and add them to the cluster, but will always fail when trying to get the SID for the CNO objects in a disjoint namespace.

So it’s possible to create and configure the Dag, let the cmdlets fail, and then manually add the FSW cluster resource, for the time being.”

You can read more about disjoint namespace scenarios on TechNet. To summarize, a disjoint namespace could be one of the following scenarios:

” A disjoint namespace scenario is one in which the primary DNS suffix of a computer doesn’t match the DNS domain name where that computer resides. The computer with the primary DNS suffix that doesn’t match is said to be disjoint. Another disjoint namespace scenario occurs if the NetBIOS domain name of a domain controller doesn’t match the DNS domain name.”

In my case the DNS domain name is exchange2013demo.com, and the NetBIOS name is EXDEMO, which is a disjoint namespace scenario as described above.

To follow Jared’s advice:

1. Create the FSW directory on the FSW server, using the naming format suggested by Jared (eg folder name “dag1.exchange2013demo.com”).
2. Share the FSW directory with a share name the matches the folder name “dag1.exchange2013demo.com”.
3. Grant the DAG Cluster Name Object (CNO) computer account Full Control share permissions.
4. Set the cluster quorum to Node and File Share Majority

PS C:\> Set-ClusterQuorum -NodeAndFileShareMajority "\\syddc1\dag1.exchange2013demo.com"

Cluster              QuorumResource
-------              --------------
DAG1                 File Share Witness

The DAG should now function correctly.

Pre-creating and sharing the FSW directory does not seem to avoid the issue. However, it appears that when the error occurs you can perform the steps shown above, then click Save on the Exchange Admin Center dialog to add the DAG member(s) again, and the task will complete successfully.

Note that this issue can occur when adding new members to an established DAG. In these cases the cluster quorum configuration reverts to Node Majority even if it was previously configured correctly. The fix steps above would need to be run each time a new DAG member is added.

Update: this issue is now fixed in Cumulative Update 5. Refer to KB2958430 for more information.

References:

• TechNet forums thread
• Anderson Patricio’s blog