November 20, 2009 | SQL Server

Installing Service Packs / Cumulative Updates on a SQL 2005 cluster

In our environment, we run the task scheduler as a cluster resource, so that scheduled tasks always run on the active node.  (In ancient history, we would have scheduled tasks that weren't cluster aware – in the event of a failover, we'd have to manually disable task scheduler on the now passive node, and manually enable it on the active node.)

Unfortunately, when you run in this mode, the service pack or hotfix can't patch both nodes, because the patching of the passive node is achieved by remotely creating a scheduled task.  When it tries to create the task on the passive node(s), the log records this error:

Task Scheduler: Error, cannot create new scheduled task for product instance target \\<PSVNodeName>
Task Scheduler: Error, cannot create scheduled task for product instance target \\<PSVNodeName>
Task Scheduler: Removed remote folder for product instance target \\<PSVNodeName>
Error, remote process failed for product instance target
Exit code for passive node: <PSVNodeName> = 1603
The following exception occurred: No passive nodes were successfully patched  
  Date: <date/time>
  File: \depot\sqlvault\stable\setupmainl1\setup\sqlse\sqlsedll\instance.cpp  Line: 3510

The workaround Grasshopper posted in this SQLServerCentral thread might work, but it seems like a lot of hassle to me.

What I did to get around the problem was as follows (and I'll use a 2-node, single instance cluster as the example):

  1. establish remote desktop sessions on the individual nodes (not through the cluster) 
  2. in Cluster Administrator on the active node (say, node1), pause the passive node (say, node2)
  3. install the hotfix on node1
  4. un-pause node2
  5. failover to node2 (since you can't install a patch from a passive node)
  6. reboot node1
  7. from node2, wait for node1 to come back online, and then pause node1
  8. install the hotfix on node2
  9. un-pause node1
  10. reboot node2, failing back over to node1 

[Yes, this requires two brief outages, so you should do this during a maintenance window.]

So, is this more or less hassle than Grasshopper's solution?  I think the answer is very subjective.  His also requires restarting nodes, so the service downtime during failover is unavoidable at least with these two approaches.  I am just offering an alternative "solution" so you can pick your own poison.

4 comments on this post

    • Puran - May 13, 2011, 7:30 PM

      This worked perfectly. Thanks for the fix. Who would have thunk abt pausing a node. 🙂

    • rajahmundry - June 8, 2011, 4:31 AM

      This works for me on SQL Server 2008 R2 CU1 on cluster environment. Thank you.

    • Steven Lee Mahaffey - September 23, 2014, 6:05 PM

      Aaron,
      In the environment we are working in now, I have a large instance on node 1 and 4 small instances on node2. since both are active for their respective instances, would this change your recommended procedure?
      Thanks
      steven.mahaffey@usap.com
      972 663-8540

    • Mark Seares - November 9, 2014, 5:59 AM

      This is very helpful, my clustered environment was successfully patched

Comments are closed.