Security update failed : The baseline msi is not installed Yesterday we had to apply a security update for SQL Server 2008 SP4(
Current version: 10.0.6000.29) (from KB3045311 and MS15-058) and it failed in both the nodes of a Windows failover cluster and both the nodes are of the same version. The log files only say this:


  2015-10-21 02:26:29 Slp: Patch Id KB3045311_sql_engine_core_inst_Cpu64 - NotInstalled on the baseline msi package sql_engine_core_inst_Cpu64.  Detail description of this patch package is: PatchId=KB3045311_sql_engine_core_inst_Cpu64 PatchVersion=10.4.6241.0 BaselinePackageId=sql_engine_core_inst_Cpu64 BaselineVersion=10.4.6000.29; PatchFileName=sql_engine_core_inst.msp PatchCode={511E22C9-E550-4C68-994B-AA3F388A4E2F}
  2015-10-21 02:26:29 Slp: Patch Id: KB3045311_sql_engine_core_inst_Cpu32 - The baseline msi is not installed. The patch package is ignored. 
  [...many more of these for different patchIds and clsids...]


The application event logs has this:


  Product: Microsoft SQL Server 2008 Database Engine Services - Update
   '{511E22C9-E550-4C68-994B-AA3F388A4E2F}' could not be installed. Error 
   code 1642. 


However, the security update for SQL Server 2012 did go through fine which was done at the same time.

Any thoughts about why the SQL Server 2008 SP4 security update is failing?
Edit: I reviewed this a bit further and another cause of this issue has been the Windows Installer cache.  That seems to create a 'file not found' error when looking for the copy of the msi/msp package that's copied into the Windows directory with the update GUID.  We're not seeing that here, but I think it's because we're not seeing the actual log file for the KB.  Aaron's point was good to bypass Windows Update, but also check to see if everything actually exists where it is supposed to if that doesn't work.
Check here for that solution to this issue.  Again, we will know much better when we can get the actual log.

This has came up a few times in prior versions of MS SQL Server.  This blog shows a good way to actually troubleshoot and resolve the issue. His solution of copying a exe from the other node and replacing it in the binn folder then restarting seems too hacky for me.  I like the SQLGuru suggestion of just reinstalling the prior SP.  That might give you some good results.

This problem can be caused by several issues such as using the wrong patch (x64 vs x32, wrong sp cu, etc.) and other scenarios such as the one listed where the version of the exe for whatever reason isn't what it is expecting, or a entry is not found for that patch in the registry, or God knows what else.  I don't.  

The best way to really see what is the root underlying issue would be to review the log files for that particular KB.  It should be in the same section as your other log file you pasted.  From there you should be able to note if the actual patch is the wrong one or out of order, if you need to just reinstall the prior SP and then retry, or if there's another error you'll need to address.  The actual log for those should be named something like sqlversion_KB#.log