THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Linchi Shea

Checking out SQL Server via empirical data points

Pause the passive node to apply SQL2005 Service Pack or hotfix

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.


Published Sunday, October 4, 2009 10:55 PM by Linchi Shea



Trayce Jordan said:

I believe you meant to state "Un-pause Node _B_"  in the third bullet.   It was B that was paused while you were installing on node A, but you mentioned to un-pause A.

October 5, 2009 1:13 AM

Aaron Bertrand said:

I have followed this exact procedure multiple times.  We have one fussy cluster where this always happens for every SP and CU.  Now it is just standard practice to not bother letting the "smart" installer be dumb.

October 5, 2009 7:50 AM

Linchi Shea said:


Yea,it should be "Un-paue node B". I have made the cotrrection. Thanks!

October 5, 2009 10:15 PM

Saggi Neumann said:

Hi Linchi,

Good post! Maybe you should label it "Best Practices" as well :-)

Do you happen to know whether a reboot is required on clustered environments even after we've made sure that all locking processes were stopped?


S. Neumann

October 21, 2009 10:10 AM

Rick said: may become relevant to this discussion too. See the /passive switch in "More Information"

November 7, 2009 11:45 AM

Edgar Amarillas said:

Hi! I'm From Sinaloa México.

Many thanks by your help. My problem is solved

August 19, 2010 11:35 AM

jignesh said:


I have a question, while installing i got the below error:

No passive nodes were successfully patched , error 11009

I have 3 sql server active nodes.

can you please help me..

April 23, 2012 4:38 AM
New Comments to this post are disabled

About Linchi Shea

Checking out SQL Server via empirical data points

This Blog


Privacy Statement