The cluster identity may lack permissions required to update the object

Yes, you can cancel the validation wizard. It is a read-only diagnostic process, and stopping it will not harm your running services or the cluster database.

The validation is stuck because Cluster Eviction was not performed before you removed the computer from the domain. Even though you removed PWGIRSQL2 from the Active Directory domain, the Cluster Database (ClusDB) running on PWGIRSQL1 still lists PWGIRSQL2 as a configured member node. The validation wizard reads the configuration, sees a 3-node cluster, and is attempting to contact PWGIRSQL2 via RPC/WMI to query its "Cluster Core Groups." Since the machine is off the domain and likely unreachable, the wizard is hitting a long TCP timeout (often 5-10 minutes per check) waiting for a response that will never come.

=> Terminate the Validation Cancel the wizard or kill the process. Do not wait for it.

=> Force Evict the "Ghost" Node You must remove the metadata of PWGIRSQL2 from the cluster so PWGIRSQL1 and PWGIRSQL3 stop trying to communicate with it.

Open Failover Cluster Manager on PWGIRSQL1.

Go to Nodes. PWGIRSQL2 should show as "Down" or "Refused connection."

Right-click PWGIRSQL2 > More Actions > Evict.

If the GUI hangs or fails because it cannot contact the node to "gracefully" evict it, use PowerShell with the Force switch to rip it out of the configuration:

Remove-ClusterNode -Name PWGIRSQL2 -Force

=> Verify Quorum Once evicted, verify that your cluster still has Quorum with the remaining nodes (PWGIRSQL1 and PWGIRSQL3). Since you have an even number of nodes (2) remaining, ensure you have a Witness configured (File Share Witness or Disk Witness) to prevent a split-brain scenario, or ensure your NodeWeight settings are correct.

=> Skip Validation for Now Do not run the validation wizard again immediately. Your priority is operational stability. Validation is resource-intensive and sensitive to the network instability caused by the recent changes. Focus on verifying that your SQL resources are online on PWGIRSQL1 or PWGIRSQL3.

VP

Hi Vphan!!!.

Yes, I finish cprepsrv.exe!!!!.

Now;

Next step, add PWGIRSQL2 Node 2 to Cluster?.

I already ran in PWGIRSQL2 sysprep.

What do you Think?

Hi Lucas,

This is excellent progress. Your screenshots confirm that the cluster is currently stable with two nodes (PWGIRSQL1 and PWGIRSQL3) and, most importantly, your SQL Always On Availability Group (GIR_AG) is synchronized and healthy between them.

Now, yes, the next step is to add PWGIRSQL2 back to the cluster. But since you just ran Sysprep, that machine is effectively "brand new" in the eyes of Windows. You can't add it immediately, you must prepare the operating system first.

Here is my suggestion to bring PWGIRSQL2 back safely without breaking the existing stability:

Phase 1: OS Configuration (Post-Sysprep)

Because Sysprep strips configuration, PWGIRSQL2 is currently in an unconfigured state.

Configure Networking: Assign the Static IP addresses (Management, Heartbeat, etc.) to match your original scheme. Ensure DNS points to your domain controllers.

Join the Domain: Join PWGIRSQL2 back to the domain telecom.arg.telecom.com.ar.

After the reboot, open Command Prompt and run whoami /user. Compare the SID (the long alphanumeric string) with the SID of PWGIRSQL3. They must be different now. If they are different, the Sysprep was successful.

Install Prerequisites: Install the Failover Clustering feature via Server Manager or PowerShell: Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools.

Install the NET Framework 3.5 if your SQL Server version requires it.

Phase 2: Add the Node

Do not use the "Validate a Configuration" wizard on the entire cluster yet (to avoid the freezing you saw earlier). We will add the node directly, as we know the other two are healthy.

Open Failover Cluster Manager on PWGIRSQL1.

Right-click the Nodes folder and select Add Node.

Enter PWGIRSQL2 and follow the wizard.

The wizard might ask to run validation. You can choose "No, I do not want to run validation support test" to skip it and add the node immediately. Given the network sensitivity in your environment, skipping validation for now is acceptable to get the node joined, provided you are certain the network settings are correct.

Phase 3: SQL Server Re-installation

Adding the node to the Windows Cluster does not automatically add it back to SQL Server.

Once PWGIRSQL2 is "Up" in Cluster Manager, you must run the SQL Server Installation Center on Node 2.

Select "Add a node to a SQL Server Failover Cluster" (if using FCI) or simply install the Standalone SQL Server instance (if using Always On Availability Groups, which appears to be your case).

Once SQL is running, you will then use SQL Management Studio (SSMS) on the Primary (PWGIRSQL1) to add PWGIRSQL2 back as a Replica in the Availability Group wizard.

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

Vphan!!!.

Yes, We are a little more relieved!!!.

Look:

hostname PWGIRSQL1

PS C:> whoami /user

USER INFORMATION

User Name SID

=============== ==============================================

oneteco\w919857 S-1-5-21-1234520961-3768318638-3525749049-9341

---------------------------------------------------------------------------------------------------------hostname PWGIRSQL2

PS C:> whoami /user

USER INFORMATION

User Name SID

=============== ==============================================

oneteco\w919857 S-1-5-21-1234520961-3768318638-3525749049-9341

PS C:>

hostname PWGIRSQL3

PS C:> whoami /user

USER INFORMATION

User Name SID

=============== ==============================================

oneteco\w919857 S-1-5-21-1234520961-3768318638-3525749049-9341

PS C:>

I can't believe this!!!

What can we do in this case?

It's not a duplicate Machine SID issue. The output you provided is completely normal and expected. You ran the command whoami /user, which returns the Security Identifier (SID) of the currently logged-in user account, not the computer itself. Since you are logging into all three servers with the same domain administrative account (oneteco\w919857), the SID will naturally be identical on every single machine in your domain (S-1-5-21-...-9341). This confirms that your user identity is consistent, but it tells us nothing about the unique identity of the servers.

To see the actual Machine SID, you need to query the SID of a local user account (like the local Administrator), because local accounts are generated using the computer's specific Machine SID as a prefix. Please run the following command on all three nodes (PWGIRSQL1, PWGIRSQL2, and PWGIRSQL3) to see the true difference:

wmic useraccount where "name='Administrator' and localaccount=true" get name,sid

Or using PowerShell: Get-LocalUser -Name Administrator | Select-Object Name, SID

What to Expect:

PWGIRSQL1: Will have a unique SID ending.

PWGIRSQL3: Will have a specific SID (likely the "old" SID from the original clone source).

PWGIRSQL2: Because you successfully ran Sysprep, this machine should now have a completely new, unique SID that is different from both Node 1 and Node 3.

If the SIDs from the command above are different (specifically the long alphanumeric string), you are safe. The "duplicate SID" conflict that caused your original issue was between the old state of PWGIRSQL2 and PWGIRSQL3. Since you Sysprepped PWGIRSQL2, that conflict is resolved. You can proceed with the plan to configure the IP, join the domain, and add Node 2 back to the cluster.

VP