Sql-server – Applying Service Pack 3 in SQL 2012 in Windows 2012 R2

The Setup.exe will do the dirty work for you and take the passive node (currently upgrading node) away from being a possible owner of the SQL FCI's virtual network name (VNN). But if you want to ensure that this is happening (which I recommend, it's what I always do), then you can manually take the passive node you're about to upgrade off of the possible owners list for the FCI's VNN.

You could use the GUI (failover cluster admin) or PowerShell to accomplish this task. Below is an example of the latter:

Get-Cluster -Name "your cluster name" |
    Get-ClusterGroup -Name "SQL Server (your instance name)" | 
    Get-ClusterResource -Name "SQL Network Name (your FCI's VNN)" | 
    Set-ClusterOwnerNode -Owners "current active node"

All of the parameter strings there need to be specific to your environment. Note, calling Set-ClusterOwnerNode will set the list of possible owners for that cluster resource. Depending on how many nodes are in your cluster, that could contain more than one string (i.e. Set-ClusterOwnerNode -Owners "ACTIVENODE", "SOMEOTHERNODE", "ETC.").

Something to be knowledgeable about, there is a KB for a fix for a failover cluster instance upgrade from SQL Server 2008 [R2] to SQL Server 2012. I recommend you review it before the operation.

As for other tips and tricks, I would recommend you read this BOL reference on upgrading a SQL Server Failover Cluster Instance. There is a lot of great information in that article that should be considered.

The logs led us to review our Cluster services:

There was an error to lookup cluster resources. Error: There was a failure to call cluster code from a provider. Exception message: Generic failure . Status code: 4104. Description: .
HResult : 0x86d80014
FacilityCode : 1752 (6d8)
ErrorCode : 20 (0014)
Data:
    errorMessage = There was a failure to call cluster code from a provider. Exception message: Generic failure . Status code: 4104. Description: .

We determined that the replication agent service was the cause of the incomplete installation.

We removed the service from Cluster Resources and re-applied SP2 without success. We stopped the service on the node and re-applied SP2 without success.

Error: Failed to run patch request for instance: MSSQLSERVER (exit code: -2032664552)

We uninstalled the service from the server nodes, and then successfully "re-applied" SP2.

Follow-up actions:

1. We'll be contacting the replication agent vendor to discuss why this was required.
2. Review the Microsoft document "Patching SQL Server Failover Cluster Instances with Cluster-Aware Updating (CAU)", available here, which I discovered today.