With SQL Server 2005, Microsoft tried to be helpful in enabling its installer to apply the service pack or hotfix automatically on the passive node(s) in a cluster. In my own experience, this has not worked out too well.
Very often, when the installer flagged the upgrade status of the service pack ot the hotfix as failure next to Database Service, the information I found in the log file was that attempt to patch the passive node had failed. You could scour the log files, google the internet, and/or open a Microsoft support case to troubleshoot the problem, rectify the root cause for failure to patch the passive node, and move on. But that may be a lengthy process, although sometimes you do not have a choice but to go through it.
In many cases, I have found the following simple solution to work well (the description assumes that we have node A and node B, and node A currently owns the SQL Server resource group):
- Use Cluster Administrator to pause the passive node, i.e. node B
- Re-apply the service pack or the hotfix on node A (i.e. the active node--the node that owns the SQL Server resource group). Because node B is paused, the installer will not try to help you out in applying the service pack or hotfix there. And re-applying the service pack or hotfix will usually succeed.
- Un-pause node B.
- If you need to reboot the patched node A, go ahead and reboot it. After node A has come back online, make sure that the SQL Server resource group is on node B. If not, move it there.
- Pause node A with Cluster Administrator.
- Apply the service pack or hotfix on node B. Again, this should typically succeed (unless there is some other issue).
- Un-pause node A, and reboot node B, if necessary.
In essence, you may want to patch all the nodes manually yourself.
I'm not suggesting that this is a cure all for all the problems of patching a clustered SQL Server 2005. But it has worked quite well for me when the problem was a failed attempt to patch the passive node.