Troubleshooting Failover Cluster Creation: Resolving Event ID 1222 in Windows Server

Table of Contents

When attempting to establish a Windows Server 2012 failover cluster, administrators may encounter errors logged in the system event log. A specific event that can appear during this process is Event ID 1222. This event indicates a problem related to the configuration or permissions required for the cluster to properly register itself within the Active Directory domain. Understanding the root cause and the necessary steps is crucial for a successful cluster deployment.

Event ID 1222 signifies a failure to perform a specific action related to the cluster’s identity in Active Directory. While the cluster creation wizard progresses, this event serves as a critical warning that a necessary security setting could not be applied. This particular issue is tied to the automatic creation and configuration of the Cluster Name Object (CNO), a vital component for the failover cluster’s functionality within the domain environment. Proper resolution ensures the cluster is correctly configured and protected.

Understanding the Cluster Name Object (CNO)¶

A Windows Server failover cluster requires an identity within Active Directory Domain Services (AD DS). This identity is represented by a computer object known as the Cluster Name Object (CNO). The CNO is created automatically in Active Directory during the initial cluster formation process.

The CNO serves as a security principal for the cluster. It is used to register Service Principal Names (SPNs) for the cluster name and any clustered services or applications, allowing clients to authenticate to the cluster using Kerberos. Without a properly functioning CNO, various cluster resources might fail to come online or function correctly, particularly those requiring Active Directory integration or client authentication.

The creation of the CNO typically occurs in the same Organizational Unit (OU) or container where the server computer objects reside. However, administrators can pre-stage the CNO object or specify a different location during the cluster creation wizard. Regardless of the location, the account performing the cluster creation must possess sufficient permissions within Active Directory to create and configure this object.

The Role of Active Directory Permissions¶

The successful creation and configuration of the CNO are highly dependent on the Active Directory permissions assigned to the user account executing the cluster creation wizard. This account needs the necessary rights in the target OU or container where the CNO will reside. Key permissions required include Create Computer objects and potentially Write All Properties or specific write permissions needed to configure attributes on the newly created computer object.

Inherited permissions from parent OUs or domain-level permissions can influence the effective permissions. However, explicit Deny permissions or permission inheritance blocking can override inherited Allow permissions, leading to access denied errors even if broader permissions seem sufficient. Careful review of the Access Control List (ACL) for the target OU is essential when troubleshooting permission-related issues.

Windows Server 2012: Accidental Deletion Protection¶

Windows Server 2012 introduced an important security feature in Active Directory: the ability to protect objects from accidental deletion. When this protection is enabled on an object (like a user, group, OU, or computer), attempts to delete it through standard management tools like Active Directory Users and Computers or Active Directory Administrative Center will fail with a permissions error unless the protection flag is explicitly unchecked first.

During the failover cluster creation process in Windows Server 2012 and later, the system attempts to automatically enable this “Protect from accidental deletion” flag on the newly created CNO object. This is a proactive measure to prevent critical cluster infrastructure components from being inadvertently removed from the domain. However, setting this flag requires specific write permissions on the computer object itself, specifically the Write dSHeuristics property (which controls the protection flag).

If the account performing the cluster creation has permissions only to create the computer object (the CNO) but lacks the permissions required to modify its properties, specifically to set the accidental deletion protection flag, the creation process will continue but will log Event ID 1222. This event signals that the attempt to protect the CNO failed due to insufficient permissions.

Symptoms: Identifying Event ID 1222¶

The primary symptom is the appearance of Event ID 1222 in the System event log on the server where the cluster creation wizard is being run, or potentially on one of the cluster nodes involved. The event details will typically include information about the source (often Microsoft-Windows-FailoverClustering or a related component) and a description indicating a failure related to modifying the CNO or setting a specific property on it.

The full event message might provide clues, such as the Distinguished Name (DN) of the CNO object it attempted to modify. While the cluster creation might seemingly complete, the presence of this event indicates that the CNO object is not protected from accidental deletion as intended by the operating system during the automated setup process. This leaves the cluster’s identity in AD vulnerable to accidental removal, which could have significant consequences for cluster operations and client access.

Troubleshooting Steps for Event ID 1222¶

Diagnosing Event ID 1222 primarily involves verifying permissions within Active Directory. Follow these steps to pinpoint the cause:

1. Examine the Event Details: Open Event Viewer on a cluster node, navigate to “Windows Logs” -> “System,” and filter or locate Event ID 1222. Read the full description carefully. Note the time of the event and correlate it with the time of the cluster creation attempt. Look for any mention of the specific object or operation that failed.
2. Identify the Account Performing Creation: Determine which user account was used to run the failover cluster creation wizard. This is the account whose permissions need to be checked.
3. Locate the Target OU/Container: Identify where the CNO object was intended to be created. By default, this is usually the “Computers” container or the OU where the server computer objects are located. If a specific OU was designated during setup or if the CNO was pre-staged, check that location.
4. Check Permissions on the Target OU:
   • Open “Active Directory Users and Computers” (dsa.msc).
   • Enable “Advanced Features” from the “View” menu.
   • Navigate to the target OU or container.
   • Right-click the OU/container and select “Properties.”
   • Go to the “Security” tab.
   • Click “Advanced” to view the advanced security settings and effective permissions.
   • Review the permissions for the user account that ran the cluster creation wizard. Specifically, look for “Allow” permissions for Create Computer objects and Write All Properties or granular write permissions required to modify attributes on computer objects. These permissions should apply to “This object and all descendant objects” or at least “Computer objects.”

Insufficient permissions for the creating account on the target OU or container are the most common reason for Event ID 1222 related to the accidental deletion flag. The account has permission to create the CNO but not to modify it to set the necessary protective flag.

Resolving the Issue¶

There are two primary approaches to resolving the underlying cause of Event ID 1222 during cluster creation: the preventative approach (recommended) and the post-creation remediation.

Method 1: Grant Necessary Permissions Before Cluster Creation (Recommended)¶

The best way to prevent Event ID 1222 is to ensure the user account performing the cluster creation has adequate permissions in Active Directory before you start the wizard.

1. Identify the target OU or container for the CNO.
2. Identify the user account that will run the cluster creation wizard.
3. As a domain administrator or someone with sufficient rights on the OU, open “Active Directory Users and Users” with “Advanced Features” enabled.
4. Navigate to the target OU/container, right-click it, and select “Properties.”
5. Go to the “Security” tab, then click “Advanced.”
6. Click “Add” to add the user account.
7. Ensure the permission entry applies to “This object and all descendant objects.”
8. Grant the following permissions:
   • Create Computer objects: This allows the account to create the CNO.
   • Write All Properties: This broad permission includes the right to set the accidental deletion flag (Write dSHeuristics). Alternatively, you could grant only the specific write permission for dSHeuristics if you prefer more granular control, but Write All Properties is often simpler for this context if appropriate for the security policy.
9. Apply the changes.
10. Now, run the failover cluster creation wizard using this account. The wizard should be able to create the CNO and successfully apply the accidental deletion protection flag without logging Event ID 1222.

Method 2: Manually Enable Protection After Cluster Creation (If CNO Exists)¶

If the cluster creation completed but Event ID 1222 was logged, it means the CNO was likely created, but the “Protect from accidental deletion” flag was not set. You can manually apply this protection after the cluster is operational.

1. Log in to a machine with the Active Directory Administrative Center installed (or a domain controller).
2. Start Active Directory Administrative Center.
3. In the tree view, navigate to the OU or container where the CNO for your cluster is located.
4. Locate and right-click the CNO object (it will have the same name as your cluster).
5. Click Properties.
6. In the properties pane, scroll down to the bottom section (often labeled “Extensions” or similar, though it’s a built-in property).
7. Locate the Protect from accidental deletion check box.
8. Click to select the Protect from accidental deletion check box.
9. Click OK to save the change.

This action manually applies the protection flag that the cluster creation wizard failed to set automatically due to insufficient permissions. While it resolves the vulnerability, the Event ID 1222 itself reflects the initial failure, and fixing permissions before creation is the preventative measure.

Best Practices for Managing Cluster Name Objects¶

To avoid future issues with CNOs and other cluster-related objects in Active Directory, consider implementing these best practices:

• Dedicated OU: Create a specific Organizational Unit solely for Cluster Name Objects. This makes it easier to manage permissions and apply group policies relevant to cluster identities.
• Delegate Control: Instead of using a highly privileged account for daily cluster management tasks (like bringing resources online/offline), delegate specific permissions on the CNOs or the dedicated OU to service accounts or less privileged administrator accounts.
• Understand CNO Passwords: The cluster service automatically manages the password for the CNO. Do not manually reset or change the CNO password in Active Directory Users and Computers, as this will break the cluster’s ability to use its identity. If the password gets out of sync, specific cluster PowerShell commands are available to reset and synchronize it.
• Enable Active Directory Recycle Bin: While the “Protect from accidental deletion” flag is helpful, it can be unchecked by anyone with sufficient permissions. The Active Directory Recycle Bin provides a safety net, allowing easy restoration of deleted AD objects (including CNOs) without requiring a full AD restore.

Leveraging Active Directory Recycle Bin¶

The original information briefly mentions the Active Directory Recycle Bin as a way to improve recovery from accidental deletion. This feature is highly recommended for any Active Directory environment and is particularly valuable for protecting critical objects like CNOs.

Enabling the Recycle Bin requires raising the forest functional level to at least Windows Server 2008 R2. Once enabled, deleted objects are retained in a special container for a configurable period (default is 180 days) and can be restored using Active Directory Administrative Center or PowerShell cmdlets (Restore-ADObject). This provides a significantly more robust recovery option compared to relying solely on the accidental deletion protection flag or requiring a full Active Directory backup restore. Implementing the Recycle Bin provides an extra layer of assurance that accidental deletion of a CNO, which would halt cluster operations, is easily recoverable.

Conclusion¶

Event ID 1222 during Windows Server 2012 failover cluster creation is typically caused by insufficient Active Directory permissions. Specifically, the account attempting to create the cluster lacks the necessary rights on the target OU or container to set the “Protect from accidental deletion” flag on the newly created Cluster Name Object (CNO). By ensuring the account has Create Computer objects and Write All Properties (or equivalent granular write permissions) on the target OU before running the wizard, you can prevent this event and ensure the CNO is properly protected. Alternatively, the protection can be manually applied using Active Directory Administrative Center after the CNO has been created. Implementing best practices like dedicated CNO OUs and enabling the Active Directory Recycle Bin further enhances the manageability and resilience of your failover cluster deployment within Active Directory.

Have you encountered Event ID 1222 during your cluster deployments? How did you resolve it? Share your experiences and troubleshooting tips in the comments below!