Hi, I see at https://technet.microsoft.com/library/security/MS15-122 that there is a particular installation order required for successful installation of the patches required to address MS15-115, MS15-121 and MS15-122, as some of the same files are included in each patch but with differing version numbers.
" Note that update 3081320 in MS15-121 and update 3101746 in MS15-115 are releasing concurrently with 3101246 in this bulletin, MS15-122. 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)."
Can Kaseya's patch management system handle this?
If not, how can we put the necessary logic in place to ensure a correctly ordered installation?
Surprised I haven't got any response on this yet.. I'm not keen on approving these, finding Kaseya applies them in a random incorrect order and then having to roll back thousands of endpoints to apply them in the correct order.
I also notice now that the order for the above patches is different for 8 / 2012 and 7 / 2008 R2.
Note that update 3101746 in MS15-115 and update 3101246 in MS15-122 are releasing concurrently with update 3081320 in this bulletin, MS15-121. 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.
Note that update 3101746 in MS15-115 and update 3101246 in MS15-122 are releasing concurrently with update 3081320 in this bulletin, MS15-121. Customers who intend to install all three updates manually on Windows 8 or Windows Server 2012 should install the updates in the following order: 3101246 first, 3101746 second, and 3081320 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.
How are others tackling this?
I saw your post on this and was going to ask the same thing. I currently have all three in pending status until I can get an answer on this.
I'm sorry to not have responded earlier. I didn't see the original post. The answer is both a yes and a no. It depends on your file source installation and method of invoking the install.
If your file source is "download from internet" and IF you invoke the install using either Patch > Automatic Update or Initial Update, then Kaseya will call WUA through its .api. Given that MS WUA would then be responsible for the installation, WUA should install in the required order.
If your file source is anything other than "download from internet" OR if you use any method other than AU or IU to invoke the install, then Kaseya will download the single-file executable (.exe, .msi, or .msu), if one is available and will execute via command line. In these cases, unless MS has included prereqs in the patches themselves (which I gather from the various literature and other user experiences is NOT the case), then the patches will not necessarily be installed in the MS-recommended/required order. Essentially, unless MS is enforcing an order via the coding itself, third-parties are not likely to be able to 'know' there's an uncoded requirement.
So - what can you do? I don't have a machine missing these three specific patches, so I can't test this...but if you can identify a couple of machines to test on, here's my suggestion:
--Using a machine missing these three patches, change the to a file source of "download from internet". Execute Patch > Automatic Update (you'll need to schedule it, but schedule it for now or a few minutes from now), then check whether the install order was honored. My understanding from reading about these patches is that if they're installed in an incorrect order, some may install, but others will fail and subsequent attempts to install will fail until the incorrectly-installed ones have been removed. Therefore, to verify if the install worked, log into the local machine and run Control Panel > Windows Update > Check for Updates to see if any of the three patches are still reported as missing (or validate they're installed under the Control Panel > Installed Updates section).
If that works, you have a couple of options via Kaseya (in no particular order):
Option 1: Configure all machines needing these patches to a file source of "download from internet". There are drawbacks to this: lots of machines going to the internet, having to change the file source back later, etc. But it's an option.
Option 2 (on-prem Master admin only): Navigate to Patch > Patch Location. Find these three patches and remove the URL. This will force the patches to "internet-based install only". All machines will honor the assigned file source for distributable patches, but will get these three (and any other "internet-based install only" patches) via WUA. This happens seemlessly, as long as the endpoint has access to the internet. You could make note of the current patch location and then switch it back to the URL, if you wanted to, though any future installs may occur out of order if you do restore the original URL.
The next options would work, regardless of whether the Kasyea-invoked WUA.api install lead to proper-order install:
Option 3: Use Patch Update to push the first patch to all machines. Once it's installed, push the second patch to all machines. Finally push the third patch to all machines. This method doesn't require any changes to your system, but does mean you'd need to make sure that each machine had the prior patch before starting the next set of install. You could create views for machines with specific patches installed to make sure you're only pushing subsequent patches to those that have the prior patch installed.
Option 4: Use patch policies. First, approve all of these patches in all patch policies using Approval by Patch. Next, create three patch policies. Let's call them 1, 2, and 3, where patch policy 1 is responsible for the first patch in the list, 2 for patch 2, 3 for patch #3. In policy 1, deny patch 2 and 3. Approve everything else in this policy. Apply the policy to all endpoints. Allow Automatic Update to run on all machines. After all machines have the first patch, remove policy 1 and apply policy 2. Run Automatic Update on all machines. Once machines have patches 1 and 2, remove policy 2 and apply patch policy 3. Consider creating patch policy 4 to deny these three patches but approve everything else so you can use policy #4 to prevent any machines that need the patches at some point in the future from getting the patches in the wrong order. Periodically check for machines missing these patches and apply policies 1, 2, and 3 accordingly.
Option 5: Deny the patches altogether. I'm not saying this is a valid option for everyone, but if you don't need them, don't bother with them. Admins should make the determination based on what they feel is best/most secure for their individual environments.
Option 6: Create a custom script (or scripts) to execute each patch, check for existence, then execute the next. You could use the Patch Deploy wizard to create the scripts (or build your own from scratch) and then string them together to check for the prior and, using the scheduleProcedure() step, schedule the next patch in the series.
Each of these have various benefits and challenges, so it's really up to the admin to figure out what's best for his/her environment. Microsoft doesn't generally release patches like this. In fact, I don't recall seeing this behavior at any point in the past. Usually, if there is a prereq, the patches that need some other patch installed first don't even show as missing until the prior patch is installed, but it's quite possible it's happened before and just missed my radar. If MS is changing how they release patches, we'll likely look at ways we can adjust to situations such as this. However, if this is just a one-off exception, it might not make sense to include this kind of processing into the KPatch product (particularly if MS does not provide a programmatic way of identifying such prereqs). In either case, I'll bring this to the attention of our devs so they can keep an eye out for the trend. In the short term, anything we may do in the future doesn't help today, so the above options should provide a functional way to deploy these for most folks. If you've found other ways to manage these, please post ideas here for the benefit of the community-at-large.
Hope this helps.
Hi Brande, thanks for the (very) comprehensive reply.
Most of our customer sites are set up with a LAN cache so it's going to be a bit challenging. I will try option 2 first (forcing the endpoints to use WUA for those particular updates), if that doesn't work as expected I suspect I'll write a script to handle these patches per OS.