The cluster identity may lack permissions required to update the object

Lucas Peñaloza 671 Reputation points
2025-12-02T20:36:56.19+00:00

Dear;

Hi have the message:

The computer object associated with the cluster network name resource 'Cluster Name'

could not be updated in domain 'xxx.xxx.xxx.xxx.xxx' during the

Password change operation.

The text for the associated error code is: The specified network password is not correct.

The cluster identity 'CLPWGIRSQL$' may lack permissions required to update the object.

Please work with your domain administrator to ensure that the cluster identity can update computer objects in the domain.

Please tell me what I need to check

Thank you so much!!!.

Windows for business | Windows Server | Storage high availability | Clustering and high availability
Answer accepted by question author
VPHAN 44,300 Reputation points Independent Advisor
2025-12-29T21:01:36.1466667+00:00

Hello Lucas Peñaloza,

I wanted to follow up to see if you successfully completed the upgrade of the final node (PWGIRSQL1) and failing back your resources.

To summarize our last discussion regarding your final step:

The Risk: Update-ClusterFunctionalLevel is irreversible, but it is safe as long as all nodes are online, running the new OS, and you have passed the Test-Cluster validation.

The Strategy: There is no rush. You can leave the cluster in "Mixed Mode" for a few days to verify stability before running the command to lock in the new features.

If your cluster is now fully upgraded and stable, please consider accepting the answer as it helps other people sharing the same question benefit too. Thank you!

VP

Was this answer helpful?

1 person found this answer helpful.
0 comments
Answer accepted by question author
VPHAN 44,300 Reputation points Independent Advisor
2025-12-18T15:55:23.51+00:00

Hi Lucas Peñaloza,

You are definitely correct to be cautious about High Availability (HA). While a Windows Cluster can technically run with one node on a new OS and two on the old OS (Mixed Mode), your approach minimizes risk significantly.

By updating both Secondary nodes (PWGIRSQL2 and PWGIRSQL3) before you ever touch the Primary (PWGIRSQL1), you ensure that when you finally perform the failover:

  1. Stability: You are failing over to a new OS node (PWGIRSQL2) that already has another new OS partner (PWGIRSQL3) ready to sync.
  2. Redundancy: If something goes wrong with PWGIRSQL2 immediately after the upgrade, you have PWGIRSQL3 (also upgraded) as a safety net.

The Approved Execution Order:

  1. Update PWGIRSQL2 (OS + SQL).
    • Result: Node 2 is healthy and syncing again.
  2. Update PWGIRSQL3 (OS + SQL).
    • Result: Node 3 is healthy and syncing again.
    • State: Now you have 2 upgraded nodes waiting in the wings.
  3. Failover the Availability Group from Node 1 to Node 2.
    • Result: Your Production is now running on the New OS.
  4. Update PWGIRSQL1 (The old Primary).

This is the safest, most professional way to execute a 3-node cluster upgrade. Proceed with confidence.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

VP

Was this answer helpful?

1 person found this answer helpful.
0 comments
Answer accepted by question author
VPHAN 44,300 Reputation points Independent Advisor
2025-12-15T14:54:40.93+00:00

YES, absolutely. You must always begin your upgrade process with the Secondary Replicas. Since your cluster is now healthy, the safest rolling upgrade workflow is to upgrade the passive nodes first, leaving the active Primary (PWGIRSQL1) untouched until the very end to keep your application online.

Here is the recommended sequence:

Phase 1: Upgrade the Secondary (PWGIRSQL2)

Since PWGIRSQL2 is already a Secondary replica and you just stabilized it, it is the perfect candidate to start with.

  1. Backup: Take a full backup of your databases on the Primary (PWGIRSQL1) just in case.
  2. Suspend Data Movement (Optional but Recommended): In SSMS, you can temporarily suspend data movement for the PWGIRSQL2 replica if the upgrade will take a long time (to prevent the transaction log on the Primary from growing too large while waiting).
  3. Perform the Upgrade: Apply your Operating System updates or SQL Server patches/upgrades on PWGIRSQL2.
  4. Reboot & Validate: Restart PWGIRSQL2. Once it is back online, open SSMS on the Primary and verify that PWGIRSQL2 returns to the Synchronized (or Synchronizing) state. Phase 2: Upgrade the Next Secondary (PWGIRSQL3)

Once Node 2 is green and fully synced, repeat the process for PWGIRSQL3.

Phase 3: The Failover (Switch Roles)

Once both Secondaries (Node 2 and Node 3) are upgraded and healthy:

  1. Change the Availability Mode of PWGIRSQL2 to Synchronous Commit (if it isn't already).
  2. Perform a Manual Failover of the Availability Group from PWGIRSQL1 to PWGIRSQL2.
    • Now PWGIRSQL2 is the Primary and is running the new version.
  3. Verify applications are connecting successfully. Phase 4: Upgrade the Old Primary (PWGIRSQL1)

Now that PWGIRSQL1 is a passive Secondary, you can safely proceed to upgrade it.

VP

Was this answer helpful?

1 person found this answer helpful.
0 comments

49 additional answers

Sort by: Oldest
Most helpful Newest Oldest

  1. AI answer

    2025-12-02T20:37:05.9233333+00:00

    To resolve the issue where the cluster identity may lack permissions required to update the computer object, you should check the following:

    1. Permissions for Cluster Identity: Ensure that the cluster identity (in your case, 'CLPWGIRSQL$') has the necessary permissions to update computer objects in Active Directory. You may need to work with your domain administrator to verify and adjust these permissions.
    2. Password Synchronization: Verify that the password for the cluster name account matches the password stored in Active Directory. If there is a mismatch, you may need to reset the password for the cluster name account.
    3. Active Directory Object Repair: If permissions are correct but the issue persists, consider using the "Repair Active Directory Object" option in the Failover Cluster Manager. This option will help synchronize the Active Directory password for the cluster name account.
    4. Cluster Validation: Run a cluster validation (excluding the storage section) to check for any misconfigurations that might affect the cluster's ability to update the computer object.
    5. Event Logs: Review the system and cluster logs for any additional error messages that might provide more context about the failure. Look for Event IDs 1069 and 1207, as they often indicate issues with cluster resources.

    By following these steps, you should be able to identify and resolve the permission issues affecting your cluster identity.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

    1 person found this answer helpful.
  2. VPHAN 44,300 Reputation points Independent Advisor
    2025-12-02T21:11:26.79+00:00

    Good morning Lucas Peñaloza,

    FYI, this error shows a breakdown in the secure channel between the cluster's computer account (CLPWGIRSQL$) and Active Directory, specifically during the periodic password update process. The cluster name object (CNO) in Active Directory has a password that the cluster service automatically rotates; when the stored password on the cluster nodes becomes desynchronized from the one in AD, or when the CNO lacks the necessary permissions to update its own attributes, this exact error occurs.

    First, verify the cluster identity's permissions in Active Directory. The account CLPWGIRSQL$ must have Reset Password and Write permissions on its own computer object. Using Active Directory Users and Computers with advanced features enabled, locate the computer object for CLPWGIRSQL$, open its Properties > Security > Advanced. Ensure the account itself is listed with at least Reset Password and Write permissions. If not, you or your domain administrator must restore these permissions, which can be done by right-clicking the cluster object in Failover Cluster Manager and selecting Repair Active Directory Object. This action re-engages the default permission grant.

    If permissions are correct, the password itself is likely mismatched. The most direct fix is to use the cluster repair function. In Failover Cluster Manager, navigate to the cluster name resource under Cluster Core Resources. Right-click the cluster name resource (usually named Cluster Name) and choose More Actions > Repair Active Directory Object. This will attempt to reset the password and re-sync the permissions. If the option is grayed out, you may need to bring the cluster name resource offline first.

    Should the repair action fail, manually reset the computer account password from a domain controller. Open an elevated Command Prompt and run:

    text

    netdom resetpwd /s:<DomainController> /ud:<Domain>\<AdminAccount> /pd:*

    You will be prompted for the admin password. Alternatively, you can use PowerShell on a domain controller: Reset-ComputerMachinePassword -Server <DomainController> -Credential <DomainAdminCredential>. After resetting, restart the cluster service on all nodes and bring the cluster name resource back online.

    Additionally, check for duplicate computer objects in AD that might be causing conflict, and ensure the cluster computer account is not disabled. Monitor the cluster logs and AD events for subsequent errors, particularly Event ID 1069 for resource failures and Event ID 1207 for cluster network name updates.

    I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to ACCEPT ANSWER then. Should you have more questions, feel free to leave a message. Have a nice day!

    VPHAN

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.