If you’re finding this post, it’s possible (or maybe even likely) that you’ve tried to install KB2871690 onto a Generation 2 Windows Server 2012 virtual machine on a Hyper-V host, and the installation failed. For those of you that haven’t run into this issue yet, you will if you attempt to install this particular update on a Windows Server 2012 (or Windows 8.0) Gen2 VM. It’s very frustrating to have a few hundred VMs patch, reboot, and fail to install a particular update and restart again… and then have the update offered again, and go through the cycle yet again because the admin installing updates was unaware this update wasn’t going to work, the update wasn’t pulled from WSUS or SCCM, etc. It happens.
Why is it failing you ask? Well, in reading the security advisory for this particular update, it appears that the revocation list (which isn’t public) was for nine particular non-Microsoft, aka 3rd party, UEFI modules that were previously signed. Since the UEFI modules used in booting a Windows Server 2012 VM in a Hyper-V Gen2 VM are all Microsoft, they’re not on the list of revoked modules, and thus the install fails (there’s nothing to revoke, so there’s nothing to install). It’d be awesome if the people who wrote the hotfix package put some logic into it so it wasn’t offered on Hyper-V VMs, but apparently they did not. C’est la vie.
So, now we know why it fails to install… now what? What can be done to avoid the failure in the first place? Well, that depends on how you deploy your OS, your patches, or create your images. In my world, images are built via MDT, and deployed and patched via a mixture of SCCM (production) and WSUS (lab) servers. In MDT, I added the update package to the Packages node in the folder for Windows 2012 and Windows 8, so that any new images built have the update pre-staged during deployment – this image is hardware-neutral, and is used in both virtual and physical environments, so I want the update in the image going forward. In SCCM and WSUS, I’ve already got groups that map to Server 2012 VMs on physical hosts, and another that exist as Hyper-V VMs, so I’ve disapproved this update for those VM server groups so it won’t be offered going forward to any existing 2012 Hyper-V VMs.
So, in a nutshell, that’s what I’m doing right now to avoid the issue. Your mileage may vary, of course, but the above would be what I would tell you to do if you asked me my opinion!