Shavlik/BladeLogic will list all missing patches in a patch analysis (based on the filters and types of patches you selected), but just like it is the case when patching manually, it may take multiple passes (usually no more than 2) to apply them all since some require previous patches to be applied completely (need a reboot) before they too can be applied.
The solution I have found to remediate this is to create a batch job that contains the same Patching Job 3 times in a row, set to run sequentially and continue despite errors. You need to enable the auto-remediation in the patching job options, and set the deploy job options to allow reboots. When you execute the job against a server, it will analyze the patches missing, remediate them once (and possibly fail to apply some of the patches that can't apply yet), then reboot, analyze again, remediate again, reboot, and analyze one last time to confirm no more patches are missing.
It also helps to add known windows update return codes to the Deploy job success exit codes list in the Patch Global Configuration panel so that codes such as -2145124329 (0x80240017 WU_E_NOT_APPLICABLE), which will prevent the job from failing if a patch requires a reboot in order to be applied.
If reboots are actually required in between application of patches then this is fine since its a limitation imposed by Microsoft instead of by Shavlik/Bladelogic. I think most are going to try to reduce the potential for reboots at all costs though and in this case multiple reboots are not required to install the related patches - they just have to be applied in a specific order. It is difficult explaining to external groups that either we are skipping the extra patches or rebooting the servers multiple times as a result of a limitation of our patching tool, especially when our Microsoft rep is saying that everything works fine with SCCM.
I understand, as most customers will not accept to have their servers rebooted more than once because of potential impacts with their application services (i.e SQL services being killed by a second restart when they are not done started after the first reboot).
The customer I currently support resolved this by only allowing one restart, so in essence, patches are completely applied one month after being installed since they are patched and restarted (once) only once a month.
Of course, there are ways to work around this issue by adding the proper scripts in the pre and post commands, to set services to Manual starting mode, and stop them before the patching is done, and to reset them to automatic and start them manually in order afterwards (in the case of application services that are not impervious to multiple-reboots in a short time span for example). One way this can be simplified for example, is to set your global patching job to always look for the same batch script to execute in pre and post commands. If the script is present on a server, it calls it, if not, it does nothing. This leaves the application team the opportunity to define the commands they want to run before and after a reboot so that BladeLogic always does the right thing.
In the end though, unless your customer accepts to do multiple reboots to completely apply the patches of he month, there's not much you can do other than what I explained above... Your hands are tied, and this is not BladeLogic's fault, it's a requirement of Microsoft. You would have the same constraint even if you were not patching with BladeLogic.
Microsoft site also says following:
"Yes. For Internet Explorer 7, Internet Explorer 8, and Internet Explorer 9, update 3074886 is bundled with update 3065822. For more information about this update, please see Microsoft Knowledge Base Article 3074886.
Note For Windows Update, Windows Server Update Services (WSUS), or Microsoft Update Catalog customers:
Update 3074886 is installed automatically and transparently together with security update 3065822. Update 3074886 will appear separately from security update 3065822 in the list of installed updates when viewed in the Add Remove Programs or the Programs and Features item in Control Panel."
Clearly the shipping mechanism and reporting mechanism for these set of patches is different than usual. Clarification should be sought from the Shavlik about how shavlik has handled this case. This should be a support ticket for BMC customers.
"In the end though, unless your customer accepts to do multiple reboots to completely apply the patches of he month, there's not much you can do other than what I explained above... Your hands are tied, and this is not BladeLogic's fault, it's a requirement of Microsoft. You would have the same constraint even if you were not patching with BladeLogic."
To clarify, this is a correct statement about a patch released earlier in the year ( I don't recall the bulletin ) but is not correct with regards to this month's patch. You CAN install all three of the patches without any reboots in between and it is just required that they be installed in a specific order.
Our solution to this was to run standard patching jobs without a reboot on all servers and then construct an ad hoc package to push the additional patches in a BLPackage job with a reboot. However, this required constructing logic to differentiate OS, IE Version, and architecture which is exactly what Shavlik/Bladelogic patching should be doing.
This is now becoming more and more common. Has there been any discussion around a way to accommodate patches that require installation in a certain order without a reboot in between? From the MS15-115 patch released yesterday:
"Note that update 3081320 in MS15-121 and update 3101246 in MS15-122 are releasing concurrently with update 3101746 in this bulletin, MS15-115. Customers who intend to install all three updates manually on Windows 7 Service Pack 1 or Windows Server 2008 R2 Service Pack 1 should install the updates in the following order: 3101246 first, 3081320 second, and 3101746 third (this is taken care of automatically for customers with automatic updating enabled). For more information see the Known Issues section of Microsoft Knowledge Base Article 3105256."
These kinds of patches are now coming out almost monthly and we are having to decide between using manual bldeploy jobs to do what the patch analysis remediation engine is incapable of handling or skipping patch deployments so that they can be done in subsequent months.
this is something we have to go back to shavlik about. did you have a ticket on this ?
I don't have a ticket. It didn't seem like a bug per se and I was hoping at the time this was a one-off patch. I don't recall Microsoft doing anything like this in the past but they have started releasing patches like this frequently now.
I’d open a ticket and we can follow up w/ shavlik
Her is what Shavlik have to say about it:
Understanding Detection And Deployment Logic For MS15-065
This document explains how Shavlik handles the detection and deployment of MS15-065 3065822 and 3074886. This will help explain why when you you perform a Security Patch scan and it only shows 3065822 missing when you expect 3074886 to also be detected as missing.
The following is from the Microsoft Security Bulletin MS15-065 - Critical
Note For Download Center customers: If you download and install updates manually, you must first install update 3065822 before installing update 3074886. Failure to follow the install order or failure to install 3074886 after installing 3065822 can lead to degraded functionality.
Due to this, Shavlik Protect will detect the prerequisite patch 3065822 missing and allow you to deploy it. After the install and reboot occurs you will need to scan the machine a second time. The remaining MS15-065 patch 3074886 will show as missing and can be deployed. This is the expected behavior from Protect.
BSA implements the same logic as Protect via the Shavlik SDK
Further comment from Shavlik on MS15-115
You can thank Microsoft for this.
MS15-022, MS15-115 and MS15-121 need to be installed in a specific order. Protect will detect the correct ordered patch missing and once it is deployed the next patch will show as missing. Since we are unable to string together patches in a specific order. it could take 3 scan and deployments to install the patches.
ah - it does seem like it's a microsoft problem - the successive patches don't show up as applicable until the prior ones are installed right ?
I'm sure these are not the only cases where that's true. Shavlik will give the complete list of missing patches, without knowing which ones are pre-reqs of others, so BSA will try to push them all and the ones that are not applicable just return an error saying so. The patches themselves don't superseded each other, they are cumulative, so that's why they all appear in the same analysis result.
So from what I get, the main difference between what BSA/Shavlik will display compared to what Microsoft/Windows Update will display is that Microsoft will only show the missing updates that are immediately applicable and will show new ones after a reboot, while Shavlik will show all missing updates, including the ones that can't be immediately applied, and will just show less and less missing patches after reboots until all patches were applied.
Yanick Girouard wrote:
Shavlik will give the complete list of missing patches, without knowing which ones are pre-reqs of others, so BSA will try to push them all and the ones that are not applicable just return an error saying so.
That's not quite right. Shavlik detection log for 3074886 is that it must find the install key for 3065822 before it proceeds with any further checks.
So, 3074886 should not show up as "missing" until 3065822 is installed