Known Issues: Windows Server 2012 Failover Clustering

  • Article

This article includes information that can help you troubleshoot known issues that are associated with the Failover Clustering feature (including Cluster-Aware Updating or CAU) in Windows Server 2012.
 
For information about known issues in File and Storage Services, see Known Issues: Windows Server 2012 File and Storage Services.

Failover Clustering - General

*Issue:
*After you create a failover cluster or configure high availability for a role in Failover Cluster Manager (for example the File Server role), you notice the following:

  1. The new server name of the failover cluster or the high availability role does not immediately appear in Server Manager when you click File and Storage Services, and then click Servers. If you right-click one of the cluster nodes, and then click Add other servers in the cluster to the server pool, nothing appears to happen.
  2. If you then click All Servers in Server Manager, the new server name of the cluster or the high availability role is listed. However, the Manageability column displays a status of Target name resolution error.

Cause:
*This behavior occurs because of delays that are associated with Domain Name System (DNS) replication. For the new object to appear on the Servers page in File and Storage Services, Server Manager must complete a successful inventory. To do this, Server Manager must wait for the new server name to register and resolve in DNS. Depending on the size of your environment, this can take some time.

*Resolution:
*Wait until DNS replication completes and the status in the Manageability column on the All Servers page changes to Online. When Server Manager can successfully resolve the server name, the name of the cluster or of the high availability role will automatically appear in the Servers page of File and Storage Services.

Tip   Server Manager completes an inventory pass every 10 minutes. If you can successfully ping the DNS name of the cluster or the high availability role, you can click Refresh to force an immediate inventory.

Cluster-Aware Updating (CAU)

Issue:
During a Cluster-Aware Updating run, if you click Cancel while a node is being put into maintenance mode, the update status changes to Canceling, and, under Cluster Actions, the options to apply updates or to preview updates are available. However, after approximately 10 seconds, the update run might continue.

Cause:
This issue occurs if the node that is being put into maintenance mode owns the IP address for the cluster. A Cancel operation does not work when the cluster is migrating the cluster IP address from one node to another.

Workaround:
Try the Cancel operation again. The cluster IP address is only offline for a short period of time.

*
Issue:*
When Cluster-Aware Updating (CAU) is enabled, the CAU feature creates two resources (a Distributed Network Name resource and a ClusterAwareUpdatingResource resource).
 
If you use the following Windows PowerShell cmdlets to delete these resources, you can no longer add or remove the CAU role. 

  • Remove-ClusterResource <CauResourceName>
  • Remove-ClusterResourceType “ClusterAwareUpdatingResource”

For example, if you run the cmdlets Remove-CauClusterRole or Add-CauClusterRole, you receive the error message:
 
Could not get the state of resource “<CauResourceName>”: (Win32Exception) The cluster resource could not be found.

Cause:
The deletion of CAU cluster resource type or resource instance by using clustering cmdlets is not supported. Because the resources and resource type are deleted, the Remove-CauClusterRole and Add-CauClusterRole cmdlets cannot remove or add the CAU cluster role as these cmdlets continue to look for the deleted resources.

Resolution:
If you have accidently deleted the CAU resource or resource type for the CAU clustered role by using clustering cmdlets, follow these steps to delete all references so that you can remove or add the CAU role:

  1. Start Windows PowerShell (as an administrator). Check for cluster parameters with the names CauResourceName and CauVCOName. To do this, run the following command:
     
    Get-Cluster <clustername> |  Get-ClusterParameter

    If the parameter values exist, note the values.

  2. Delete the virtual computer object (VCO) from Active Directory Domain Services. The name of the VCO is the value of the CauVCOName parameter that you determined in step 1. By default, the VCO is located in the Computers container in Active Directory Users and Computers.

  3. Using Windows PowerShell (as an administrator), delete the cluster parameters with the names CauResourceName and CAUVCOName. To do this, run the following commands:

Get-Cluster <Clustername> | Set-ClusterParameter "CauResourceName" -Delete
Get-Cluster <Clustername> | Set-ClusterParameter "CauVCOName" -Delete

Tip   The recommended way to delete the CAU cluster resource is to use the Remove-CauClusterRole cmdlet.

 

Issue:
When you try to remove the Cluster-Aware Updating (CAU) clustered role by using the Remove-CauClusterRole cmdlet or the Configure Self-Updating Options Wizard, removal may fail with an error message that is similar to the following:

Failed to remove the computer account (also known as the virtual computer object or VCO) 'objectname' from the domain.

Cause:
This issue may occur if the user who is removing the CAU clustered role does not have permission to remove the virtual computer object (VCO). This may include the domain administrator.

Workaround:
In Active Directory Users and Computers, a domain administrator must manually delete the VCO. If you cannot delete the VCO as a domain administrator, make sure that the Deny access control entry (ACE) is not set for a group that the domain administrator is a member of.

Tip   If you did not use a pre-staged VCO when you added the CAU clustered role, you can verify the VCO name by running the Windows PowerShell command Get-Cluster <clustername> |  Get-ClusterParameter as an administrator. In the output, check the value of the CauVCOName parameter.

To view the permissions for the VCO, in Active Directory Users and Computers, on the View menu, click Advanced Features. When you view the properties of the VCO, click the Security tab. (By default, the VCO is created in the Computers container.)

Issue:
If you rename a failover cluster that is configured with the Cluster-Aware Updating (CAU) clustered role, and then try to use the Configure Self-Updating Options Wizard to configure self-updating mode settings, you may receive an error message that is similar to the following:

[<Cluster_Name>] Connecting to remote server <Cluster_Name> failed with the following error message: WinRM cannot process the request. The following error occurred while using Kerberos authentication: Cannot find the computer <Cluster_Name>. Verify that the computer exists on the network and that the name provided is spelled correctly. For more information, see the about_Remote_Troubleshooting Help topic.

Workaround:
To work around this issue, do the following:

  1. Rename the Active Directory object for the cluster (the failover cluster virtual network name account) from the old name to the new name by using the Rename-ADObject Windows PowerShell cmdlet. For example, for a failover cluster that was renamed from CLUSTEROLD to CLUSTERNEW, run the following command as an administrator who has permissions to modify Active Directory objects:

    Rename-ADObject -Identity “CN=CLUSTEROLD,CN=Computers,DC=Contoso,DC=com” –NewName “CLUSTERNEW”

  2. Change the value of the dnsHostName attribute for the Active Directory object to the new name. To do this, in Active Directory Users and Computers, click View, and then make sure that Advanced Features is selected. Locate and then right-click the newly-renamed Active Directory object, and then click Properties. On the Attribute Editor tab, locate the dnsHostName attribute, and then edit the value to the new failover cluster name.

  3. Restart the cluster nodes. This ensures that the failover cluster and Active Directory are synchronized, and refreshes the values for the Service Principal Name on the Active Directory object.

Additional References