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.disjoint5
  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.


About the Author

Paul Cunningham

Paul is a former Microsoft MVP for Office Apps and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul no longer writes for Practical365.com.


  1. Angelos Demetriou

    Hi there,
    landed onto this, and silly enough I didn’t have the update5 on it…

    would it be better if I just deleted the dag (there is nothing there yet) and recreate it? or would it be complicating things? I guess I will try your solution first, and then how do I test it really worked?

    I will then take the servers out of the dag one by one and rejoin then. Perhaps best?

  2. Pete Connell

    Wow! Just bumped into this. I’m going to try this solution and see if it works. Thanks Paul

  3. John Smith

    Hi Paul,
    Thank you for taking time responding to my question. Unfortunately, the same fix doesn’t work because we are not suppose to use cluster related command to manage IP Less DAGs. When Set-ClusterQuorum -NodeAndFileShareMajority has been issued, it created a proper file share with GUID and configuration files in specified file share location. However, when we run get-databaseavailabilitygroup -status |fl EMS spits out the error indicating that FSW configuration is invalid now and suggests us to use set-databaseavailabilitygroup to specify FSW again. So we did and it won’t make a different and EMC continues to give the same error until we set the clusterquorum back to Node majority. Then this error went away. So as you can see one command fixed something but broke another completely. Thank you for your time.

    1. Paul Cunningham

      I that case I recommend contacting MS Support, or removing your DAG and waiting for CU5 before recreating it.

  4. John Smith

    We ran into same FSW problem with Windows 2012 R2 with Exchange 2013 SP1 using IP less DAG and disjoined name space. For IP less DAG what would you suggest what the fix is going to be with FSW since there is no CNO involved? Thank you so much for your answer in advance.

    1. Paul Cunningham

      Same fix should work. IP-less DAGs still have a FSW.

      Or, wait for CU5 which is likely to include the fix for this bug.

Leave a Reply