Steps to bring the Quorum back online:
Generate recent Cluster Log:
Step 1: Failover Cluster Manager
- Cluster Core Resources, File Share Witness, right click and select "Bring Online"
Step 2: Powershelll
- Get-ClusterLog –UseLocalTime -TimeSpan 5 -Destination 'E:\Cluster Logs';
- This will output the Cluster Log for the last 5 minutes (thus containing the error from Step 1)
Cluster Log:
INFO [RES] Network Name: [NNLIB] Logon failed for user SQLCluster01$ (Error 1326), DC \\DC01.ops.com, domain ops.com
ERR [RCM] Arbitrating resource 'File Share Witness' returned error 1326
INFO [QUORUM] Node 2: quorum is not owned by anyone
Issue:
The Failover Cluster Virtual Network Name Account - ex. SQLCluster01$ - a Cluster Name Object (CNO), which is an Active Directory (AD) account for a Failover Cluster, was not able to bring the Quorum (File Share Witness) online due to a permissions issue.
The CNO is automatically created during cluster setup. The Create Cluster Wizard creates all the Active Directory computer accounts the cluster requires and grants each account specific permissions. The wizard also creates a computer account for the failover cluster itself - this account is called the cluster name object. The CNO is critical because other cluster accounts are created by it. If the CNO is removed or permissions are modified for the account, other computer accounts required by the cluster can't be created until the CNO and it's permissions are restored.
Fix:
1. Log into the Cluster Node 1 as Domain Admin
2. Delete the existing File Share Witness
3. Re-Create the File Share Witness
4. Bring the File Share Witness Online
If 4. did not work, proceed to below steps:
5. Take the Cluster Name offline
6. Cluster Name..right click and select "More Actions" and then "Repair"
7. Bring the File Share Witness Online
Resources:
Understanding the Repair Active Directory Object Recovery Action
"...To run Repair, the Network Name resource must be in a “Failed” or “Offline” state. Otherwise the option will be grayed out.
Repair is only available through the Failover Cluster Manager snap-in, there is no Powershell cmdlet available to script the action.
If you are running Windows Server 2012 and find that you are having to repeatidly run Repair every ~30 days, ensure you have hotfix KB2838043 installed..."
Cluster Name/Permissions Issue
"...the 1206 error often is the CNO permission issue, please check the following options was correct configured, you must be a member of the local Administrators group on each clustered server, and the account you use must be a domain account, or you must have been delegated the equivalent authority. If the options is correct base on my experience the 1206 error some times cause by the firewall or AV soft, please disable them then monitor the status.
•Check whether there is a computer object for the new clustered service or application. If there is, check the permissions associated with that object, and make sure that the computer object for the cluster itself has Full control permission. Also, when viewing the properties for the computer object for the new clustered service or application, confirm that the Account is disabled box is cleared (the account must be enabled, not disabled).
•Check the permissions assigned to the computer object (computer account) for the cluster itself. This computer object has the same name as the cluster. It must have the Create Computer Objects permission in the domain.
•Check that the domain settings are not preventing a new computer object from being created. By default all computer objects are created in the Computers container. Consult with the domain administrator if this location has been changed.
•Check that the domain-wide quota for creating computer objects (by default, 10) has not been reached. If it has, it might be appropriate to consult with the domain administrator about increasing the quota, although this is a domain-wide setting and should be changed only after careful consideration, and only after trying the previous items in this list.
To change the quota, run ADSIEdit.msc, click ADSI Edit, click Action, click Connect to, and then click OK. The Default naming context is added to the console tree. Double-click Default naming context, right-click the domain object underneath it, and then click Properties. Scroll to ms-DS-MachineAccountQuota, click Edit, change the value, and then click OK."
Prestage cluster computer objects in Active Directory Domain Services
Event ID 1206 — Active Directory Permissions for Cluster Accounts
Clustering: What exactly is a File Share Witness and when should I use one?
What is a FSW and how does it differ from a disk?
All this discussion about votes is a perfect segue into what a File Share Witness (FSW) is and how it differs from a witness disk. A FSW is simply a file share that you may create on a completely separate server from the cluster to act like a disk for tie-breaker scenarios when quorum needs to be established. The share could reside on a file server, domain controller, or even a completely different cluster. A witness share needs to be available for a single connection, and available for all nodes of the cluster to be able to connect to – if you are using the FSW option for quorum. The purpose of the FSW is to have something else that can count as a vote in situations where the number of configured nodes isn’t quite enough for determining quorum. A FSW is more likely to be used in multi-site clusters or where there is no common storage. A FSW does not store cluster configuration data like a disk. It does, however, contain information about which version of the cluster configuration database is most recent. Other than that, the FSW is just a share. Resources cannot fail to it, nor can the share act as a communications hub or alternate brain to make decisions in the event cluster nodes cannot communicate.
|
|
|
|
|
|