The cluster identity may lack permissions required to update the object

Lucas Peñaloza 101 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
{count} votes

23 answers

Sort by: Most helpful
  1. Lucas Peñaloza 101 Reputation points
    2025-12-12T04:13:22.6233333+00:00

    Hi Vphan!!!.

    In all Nodes is the same, Look:

    User's image

    User's image

    User's image

    User's image

    User's image

    User's image

    The only difference is that in PWGIRSQL2 in Ethernet1, it says Ethernet Adapter without #!!!.

    PWGIRSQL1 and PWGIRSQL3, says, Ethernet Adapter #2!!!.

    In Cluster:

    User's image

    What do you Think?.

    0 comments No comments

  2. VPHAN 10,640 Reputation points Independent Advisor
    2025-12-12T06:40:44.2733333+00:00

    Hi,

    You have a very sharp eye, but I can assure you: The difference in the name ("Ethernet Adapter" vs "Ethernet Adapter #2") is completely cosmetic and irrelevant. It simply means the network driver was reinstalled or the virtual NIC was removed and re-added on the other nodes at some point. Windows just increments the number (#2, #3) to avoid duplicates. It has zero impact on the cluster.

    The real problem is confirmed in your screenshot of PWGIRSQL2: NetworkCategory: Public

    Why is this killing Node 2? When a network is set to Public, the Windows Firewall applies its strictest policy: "Block all unsolicited inbound traffic." Even though Node 1 and Node 3 might be showing "Up" (likely due to existing cached sessions or specific rule exceptions from when they were built), Node 2 is a "new" member. It is trying to establish a new handshake on port UDP 3343, and the Public Firewall profile on Node 2 is silently dropping those packets.

    So here is the fix:

    You must force Windows to trust this network on the new node: Open PowerShell (Administrator) on PWGIRSQL2.

    Run this exact command to flip the switch:

    Set-NetConnectionProfile -InterfaceAlias "Ethernet1" -NetworkCategory Private

    Wait 30 seconds. Go back to Failover Cluster Manager (Image 4). You should see the status for PWGIRSQL2 on Cluster Network 2 change from Failed to Up.

    Optional: I noticed in that PWGIRSQL3 also has this network set to Public. While it is currently "working," this is risky. If that node reboots or resets its connection, it might get blocked too. Once Node 2 is fixed, I highly recommend running the same command on Node 1 and Node 3 to ensure all Heartbeat networks are correctly set to Private.

    VP

    0 comments No comments

  3. Lucas Peñaloza 101 Reputation points
    2025-12-12T20:51:31.48+00:00

    Hi Vphan!!!.

    So;

    User's image

    But;

    User's image

    The error persists!!!.

    So, I tried the following:

    From Vcenter, in PWGIRSQL3, Disconnect!!!.

    User's image

    And everything went to hell.

    User's image

    Why is that?

    I only, Disconnect a NIC from Vcenter!!!.

    What dou You Think?

    0 comments No 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.