The cluster identity may lack permissions required to update the object

Hi Vphan!!!.

In all Nodes is the same, Look:

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

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

In Cluster:

What do you Think?.

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

Hi Vphan!!!.

So;

But;

The error persists!!!.

So, I tried the following:

From Vcenter, in PWGIRSQL3, Disconnect!!!.

And everything went to hell.

Why is that?

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

What dou You Think?

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