UPDATE: While TechNet article “Create a Database Availability Group” only mentions Windows 2008 R2 domain controllers, I must thank Scott Schnoll for the following clarification: “Creating an Exchange 2013 DAG with Mailbox servers on Windows Server 2012? You must pre-stage CNO before adding first server!”. TechNet documentation will be updated to reflect the same I assume.
If you are in IT long enough, you know the fact that nothing will every work without throwing an issue or two you have to solve. Especially if you are dealing with recently released software such as Exchange 2013.
In my lab, I had installed all Exchange servers I needed in different sites. All my domain controllers and Exchange servers are running Windows Server 2012. Since I am not testing co-existence, it is a green field deployment.
Since everything so far was working as expected, I proceeded with creation of DAG. From EAC, creating DAG itself worked with no issues. I then went ahead and added first mailbox server to DAG. this step, however, refused to complete with error:
A server-side database availability group administrative operation failed. Error The operation failed. CreateCluster errors may result from incorrectly configured static addresses. Error: An error occurred while attempting a cluster operation. Error: Cluster API ‘”CreateCluster() failed with 0x5. Error: Access is denied”‘ failed.. [Server: MBX1.fabrikam.int]
Looking at CNO, I noticed Exchange Trusted Subsystem had special permissions assigned and not “Full Control” on CNO that the process created automatically.
Assigning “Full Control” to Exchange Trusted Subsystem on CNO, I assumed should fix the issue, however, it actually produced a completely different error when I tried to add the mailbox server to DAG again:
An Active Manager operation failed with a transient error. Please retry the operation. Error: The fully qualified domain name for node ‘DAG1’ could not be found.
I also noticed mailbox server account with similar permissions and not “Full Control” on the object.
From reading TechNet forums I knew a solution existed where you can just delete DAG CNO and pre-stage it as described in TechNet article: Pre-Stage the Cluster Network Object for a Database Availability Group.
I was able to fix the issue using one of the following two methods:
- Disable CNO, assign “Full Control” to ETS on the DAG object and remove mailbox server from permissions list on CNO. Add mailbox server to DAG.
- Delete CNO from AD and pre-stage CNO using process described in the article mentioned above. Add mailbox server to DAG.
I am not sure if it is a bug or known issue with Server 2012 domain controllers. It remains to be seen as more guidance become available from Microsoft.
If you are wondering why the last lines above are striked out, please read the update at the top of the page for explanation.
[…] https://www.bhargavs.com/index.php/2012/11/26/createcluster-failed-with-0×5-adding-members-to-da… Share this:StumbleUponDiggRedditLike this:LikeBe the first to like this. […]
All Windows 2012 DAGs “must” have their CNO Prestaged.
Thanks Richard. As you mentioned, this link: http://technet.microsoft.com/en-us/library/dd351172.aspx mentions only Windows 2008 R2 domain controllers. Documentation is misleading as it should also mention Windows Server 2012 or it should work for Windows Server 2012 domain controllers. A luxury of being an outsider. Now I can behave like a regular user. 😉
& few other articles especially from Tony @his blogs was really informative and to know the server 2012 having restriction to stop CNO getting created…on the other side I was wandering if exchange admin had the necessary rights – what we manually do now like prestage and assign permission. Any guess in the change for not getting CNO object created during setup…?
Permissions, especially in large environments is a question. That is why what worked previously was great. ETS already has permissions required to create CNO on AD. What changed that Exchange can’t do what it used to be able to? That’s the question only Microsoft can answer. Until than, while painful, we can only live with regression and use the workaround (which might become official guidance going forward if not fixed by MS).
Thanks! Anywy have to accept 🙂
The only reason what came to my mind “why” is that not only here but I see few more blogs coming up with the troubleshooting DAG cluster in Exchange 2013 and in all found one thing common is that towards resolution.
And I was looking forward to know the reason for the change – prestaging CNO object actually became a process/best practice before creating DAG in Exchange 2013.