An urgent email: a service pack had installed fine on one node of a SQL Server 2016 cluster, and on the passive node setup kept failing with “The RPC server is too busy”. Nothing was busy. The message was describing a service that was not running at all. The setup log gave it away, and it is worth checking before you start any cluster patch.

What Setup Showed
The setup screen said only “Failed to retrieve data for this request”. That tells you nothing. I asked them to cancel and send the setup log, and the detail was there:
Microsoft.SqlServer.Management.Sdk.Sfc.EnumeratorException: Failed to retrieve
data for this request. ---> Microsoft.SqlServer.Configuration.Sco.SqlRegistryException:
The RPC server is too busy to complete this operation.The second exception is the real one, and its name gives it away: SqlRegistryException. Setup was trying to read the registry, and the failure came from RPC, the mechanism Windows uses to do things on another computer. So setup was reading the registry of a different machine.
Why Setup Reads Another Machine
On a cluster, SQL Server setup does not only look at the node it is running on. It checks the other nodes too, and it does that by reading their registry. That remote read goes through the Remote Registry service on the other node.
If that service is stopped, the remote read fails. And for reasons nobody will ever explain to my satisfaction, Windows reports that as “the RPC server is too busy” rather than “the service you need is not running”.
The Fix
We checked Remote Registry on the other node. It was stopped. We started it, ran setup again, and the patch finished inside the time they had.
On each node, from an elevated PowerShell:
Get-Service RemoteRegistry | Select-Object Name, Status, StartType
Set-Service RemoteRegistry -StartupType Manual
Start-Service RemoteRegistryYou can check every node at once from one place:
Get-ClusterNode | ForEach-Object {
Get-Service RemoteRegistry -ComputerName $_.Name |
Select-Object MachineName, Status, StartType
}Run that one in Windows PowerShell 5.1, not PowerShell 7. I checked both on my machine: Get-Service still has -ComputerName in 5.1, and PowerShell 7 dropped it. I do not have a cluster here, so I have not run the loop itself. The single-machine check above I did run.
Why It Was Stopped
This is the part worth knowing. On my Windows 11 machine, Remote Registry is not just stopped, it is disabled:
Name Status StartType
RemoteRegistry Stopped DisabledMany server hardening baselines switch it off too. A service that lets other machines read your registry is a door worth keeping shut, so that is sensible. It also means a node can be hardened perfectly and then fail its next SQL Server patch.
And notice that the first node patched without trouble. That fits. Setup on one node reads the others, so it is the state of the other nodes that matters. When the second node failed, the stopped service was on the first.
Before the Next Cluster Patch
Add Remote Registry to your checklist, on every node. Start it before the patch window and, if your security team prefers it off, set it back to Disabled afterwards. That keeps both the patch and the hardening happy.
And when a setup dialog shows a vague message, cancel and open the log before you retry. The dialog shows the last thing that failed. The log shows the first. Setup keeps it under the Setup Bootstrap\Log folder of your SQL Server version, one folder per attempt.
The RPC server is not too busy, it is a service on the other node that somebody switched off.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.




