Installing Service Packs / Cumulative Updates on a SQL 2005 cluster
November 20th, 20094
Installing Service Packs / Cumulative Updates on a SQL 2005 cluster
November 20th, 20094

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.

By: Aaron Bertrand

I am a passionate technologist with industry experience dating back to Classic ASP and SQL Server 6.5. I am a long-time Microsoft MVP, write at Simple Talk, SQLPerformance, and MSSQLTips, and have had the honor of speaking at more conferences than I can remember. In non-tech life, I am a husband, a father of two, a huge hockey and football fan, and my pronouns are he/him.

4 Responses

  1. Mark Seares says:

    This is very helpful, my clustered environment was successfully patched

  2. Steven Lee Mahaffey says:

    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?
    [email protected]
    972 663-8540

  3. rajahmundry says:

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

  4. Puran says:

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