Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

patching an MSCS SQL cluster

Created: 29 Mar 2013 | 5 comments

We've been having issues patching Microsoft SQL clusters (SQL 2008/2008R2) using patch management.  What I have been doing is to make sure the patches are downloaded to the machines.  I don't have the machines setup to automatically patch.  I've scripted out the failover of the cluster and the patching of the machine with aexpatchutil.exe and use jobs and tasks to launch the script.  When it runs the script works appropriately and the resources failover to the passive node and then patching begins.  The problem we are having is that the SQL service packs are not installing on the machines.  Other Operating System based patches are installing fine.  Our dba's looked at SQL and the SQL tools are being patched but SQL itself is not.  There are no errors messages indicating why it's failing to install.  The account that is used to launch the script is a administrator of the box and has administrative access to SQL.  Additionally, we've added the system accounts of the machines to have administrative access. 

How do other people patch SQL clusters with this tool?

Operating Systems:

Comments 5 CommentsJump to latest comment

Rajaganesh's picture

Did you check the SQL service packs actually got staged in the patch remediation center.

Also check whether the actual package is available on the package servers for the SQL server to download the package.If the SQL service packs are not available in the package servers then it might not have staged properly.

If the package is available on the package servers and has got guid assigned to it,then you can try the aexpatchutil.exe /f (The package guid) to check the issue is with the installation or the package availability.

Joshua Rasmussen's picture

Hello Rusgiv,

I haven't tested the process you are utilizing, but here is my best guess:

1. Ensure the Software Update Package is listed on the Client's Altiris Agent GUI > Software Updates Tab as 'Scheduled' status before running the script.

2. Confirm the client is not in need of a reboot; normally I would direct you to the Patch Management 'RebootRequired' regkey; however, you are running these updates via a script and not through Patch Management, so try running an update manually from the downloaded exe on the client and see if any errors are thrown.

It may be the other updates are able to install without a reboot, but the SQL updates require a reboot of the client to refresh the registry before they will install.

3. Check scripts for those updates, for they may require that specific account is logged on, or some other caveat needs to be filled before executing.

In regards to your question: "How do other people patch SQL clusters with this tool?"; The process is ran as detailed on KM: HOWTO56242 like any other client:

     In summary:

  • The Bulletin is staged on the PRC
  • The Software Update Policy is created and targets the vulnerable client
  • The client downloads the software update packages
  • The client runs the scheduled Software Update Cycle detailed on the Default Software Update Plug-in Policy, or a clone of this policy to specify special parameters for the SQL Cluster filter.
  • The client reboots at the end of the schedule, or on environment schedule, to ensure any updates completing with 3010 exit code (reboot required) are installed.

Hope this helps,

Joshua

rusgiv's picture

1. Ensure the Software Update Package is listed on the Client's Altiris Agent GUI > Software Updates Tab as 'Scheduled' status before running the script. - yes it is

2. Confirm the client is not in need of a reboot; normally I would direct you to the Patch Management 'RebootRequired' regkey; however, you are running these updates via a script and not through Patch Management, so try running an update manually from the downloaded exe on the client and see if any errors are thrown. - clients do not need reboots.  We are resorting to patching our SQL servers that are clustered manually now because it's not able to patch them appropriately.

It may be the other updates are able to install without a reboot, but the SQL updates require a reboot of the client to refresh the registry before they will install.

3. Check scripts for those updates, for they may require that specific account is logged on, or some other caveat needs to be filled before executing. - the scripts call altiris (aexpatchutil.exe) so altiris is doing the patching.  The script is just handling failover of the cluster.  Symantec normally uses the system account when it patches and we've ensure that this account has the appropriate access.

What is troublesome is that for things like SQL 2008 R2 SP2 it's installing a portion of the service pack but not all of it and I'm concerned that it is going to both something up.

Your process is exactly how I am patching.

Joshua Rasmussen's picture

When executing the Software Update Cycle via the Default Software Update Plug-in Policy; do the Client Logs show anything regarding the failure, or are you able to see any exit / error codes thrown on the Altiris Agent GUI > Software Updates tab; double-click the Software Update and view the Run History tab?

There should be something that directs us to why/how the update is failing to install through Patch Management Solution.

Brandon's picture

You may want to try running the patch manually on one of them. We found a "known issue" for SQL in one case when we did it that way.

On a side note, if you want to use patch management solution instead of jobs you could try it this way:

I have all the primary clusters in our normal server patching phase/schedule. I made a second group for the secondary nodes and we assign them a different installation schedule (2 hours laters). The node is still in the generic server phase for the update task. This works pretty well for clusters because then you only have to maintain the list of extra nodes, everything else follows the normal patching process. Additionally you can just make the schedule manual, then allow the DBA to initiate the job from the software update tab on their own schedule.

March Software Update Task Sample
 - Phase0-Testing > Manually defined Filter
- Phase1-Production > All Windows Servers (excluding Phase 0)
Software Update Agent Configuration
Default Software Update Agent Config Policy for Standard Servers > Standard Servers Filter (excludes Server manual reboot filter and secondary cluster filter)
Default Software Update Agent Config Policy for Secondary Cluster Servers (+2h reboot delay) > Secondary Clusters Filter (excludes Server manual reboot filter)
Default Software Update Agent Config Policy > allow user iniation and set the install date to 2099

patching.png