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: Most helpful
Most helpful Newest Oldest
  1. VPHAN 44,300 Reputation points Independent Advisor
    2025-12-15T18:56:29.5233333+00:00

    YES, provided you are performing an In-Place Upgrade (e.g., running the Windows Setup to go from Server 2016 to Server 2019/2022) and not a "Clean Install" (formatting the disk).

    Microsoft supports a feature called Cluster OS Rolling Upgrade (introduced in Server 2012 R2), which allows you to upgrade the Operating System of a node while it remains a member of the cluster.

    1. Mixed-OS Mode: When you upgrade PWGIRSQL2 to the new OS version and it rejoins the cluster, the cluster will temporarily operate in a "Mixed Mode." It will tolerate having Node 1 on the old OS and Node 2 on the new OS simultaneously.

    The Cluster Role Persists: The Failover Clustering feature and your configuration are preserved during the Windows upgrade process. You do not need to reinstall the Failover Clustering role or re-add the node manually if you choose "Keep personal files and apps" during the OS setup.

    SQL Server Upgrade: Similarly, for the Database Engine, you can perform an In-Place upgrade of the SQL instance on Node 2. Since it is currently a Secondary replica, this will not affect the production database on Node 1.

    Important Warning: While the cluster is in this "Mixed OS" state, you generally cannot perform management operations that require features only present in the new OS version. CRITICAL: Do NOT run the PowerShell command Update-ClusterFunctionalLevel until ALL nodes (PWGIRSQL1, 2, and 3) have been upgraded to the new Operating System version. If you run this command while Node 1 is still on the old version, the cluster service on Node 1 may fail permanently.

    So:

    Pause & Drain PWGIRSQL2.

    Upgrade Windows OS (In-Place) on Node 2 -> Reboot.

    Upgrade SQL Server on Node 2 -> Reboot.

    Resume Node 2 (Wait for SQL Synchronization).

    Failover to Node 2.

    Repeat for other nodes.

    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
  2. VPHAN 44,300 Reputation points Independent Advisor
    2025-12-13T02:34:10.96+00:00

    This situation looks alarming, but it is recoverable. You are seeing a classic Cluster Partition event because you severed the communication link on PWGIRSQL3.

    By disconnecting the network adapter on PWGIRSQL3 via vCenter, you created a split-brain scenario for that specific network path. It mean you killed the physical link for Cluster Network 2 on Node 3.

    => The cluster service on Node 1 and Node 2 immediately saw Node 3 vanish from that network.

    Because Cluster Network 2 was already unstable/failed on Node 2 (due to the firewall issue we discussed), removing Node 3's link caused the entire network resource (Cluster Network 2) to collapse into a Partitioned state. The cluster now believes no one can talk to anyone reliably on that backup network.

    This is how to recover:

    Step 1: Reconnect the NIC immediately: Go back to vCenter for PWGIRSQL3 and check the box "Connected" (Conectado) for Adaptador de red 2. This will restore the physical link.

    Step 2: Fix the Firewall on ALL Nodes (The Root Cause): The reason the error persisted initially, and why the network is so fragile, is that Set-NetConnectionProfile likely needs to be run on ALL nodes, not just Node 2. Your screenshots show that even Node 1 has Ethernet1 as "Unidentified network".

    You must ensure that UDP 3343 is open on this network for every single server. Please run this command on PWGIRSQL1, PWGIRSQL2, AND PWGIRSQL3:

    Set-NetConnectionProfile -InterfaceAlias "Ethernet1" -NetworkCategory Private

    Step 3: Force a Cluster Refresh: After reconnecting the NIC and running the command on all three nodes:

    Go to Failover Cluster Manager on Node 1.

    Right-click Cluster Networks.

    This usually refreshes automatically, but if it stays "Partitioned," you may need to restart the Cluster Service on the passive node (PWGIRSQL3) to force it to re-handshake.

    Once Cluster Network 2 returns to Up, your redundancy is restored.

    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 then. 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

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.