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?.
This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
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!!!.
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?