Microsoft Patch Alert: December patches hang Win7 Pro endpoints and force Server 2012 reboots
Credit to Author: Woody Leonhard| Date: Mon, 06 Jan 2020 09:55:00 -0800
It was the kind of month admins dread: Mysterious problems on hundreds of machines, with no apparent cause or cure. Toss in the holidays, and we had a whole lot of Mr. and Ms. Grinches in the industry.
Fortunately, it looks like the problems have been sorted out at this point. Individual users had many fewer problems. Microsoft’s left and right hands still aren’t talking on the 1909 team, but what else is new…
Microsoft dropped a new Servicing Stack Update for Windows 7 on Dec. 10, and it gummed up the works for many. Here’s a good summary on Reddit from poster Djaesthetic:
“We had over 100 Windows 7 Professional endpoints all stuck on “Preparing to configure windows” screen. We couldn’t get beyond that error in any simplistic manner. We eventually got a remediation to get beyond that error (involving booting each one from an ISO and making several registry hive edits to TrustedInstaller). Unfortunately, even after we were able to log in, the entire OS is functionally broken….
“…We are having this same issue on 111 different Windows 7 machines, each one consistently having the same environment problems. We are unable to roll back the KB4530734 Windows Update, likely because the Windows Module Installer (TrustedInstaller.exe) service itself is broken… I’ve been working non-stop all weekend. Currently waiting for (yet another) callback from Microsoft….
As Djaesthetic later posts, the problem is triggered by the Dec. 10 Servicing Stack Update, KB 4531786:
“In our investigation we confirmed the problem having to do with KB4530734 (December Monthly Rollup for Windows 7 Service Pack 1). More specifically, we believe it had something to do with KB4531786 (Servicing stack update for Windows 7 SP1 and Server 2008 R2 SP1: December 10, 2019) applying out of order. Interestingly, if you look at the notes for the December rollup it specifies a recommendation to install the SSU afterward (not a requirement). Lastly, we found some (not all) machines in various states of “Uninstall_Pending” regarding the November Monthly Rollup….”
Those of you using plain old single-system Monthly Rollups won’t encounter the problem. But if you or your system’s admin is manually installing patches, getting them in the wrong order can cause all sorts of problems. Manually installing the Servicing Stack Update can be particularly vexing because SSUs won’t show up until you’ve installed (or hidden) all outstanding patches.
There were lots of reports of Server 2012 (not R2) servers going into reboot loops after last month’s updates. I originally reported on AskWoody that the problem appeared to be with KB 4533096, the “Security and Quality Rollup for .NET Framework 3.5, 4.5.2, 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1, 4.7.2, 4.8 for Windows Server 2012.” But I now think that a bad Malicious Software Removal Tool (MSRT) version may have been at fault.
Manually rebooting cleared up the issue. And the mid-December version of MSRT is long gone. There’s no official confirmation or explanation that I can find.
The December patch didn’t fix the long-decried File Explorer Search bug in Win10 version 1909. You may recall that Microsoft’s known about the bug – which makes Search in File Explorer unusable – since 1909 shipped. They fixed the bug in a Win10 version 2004 beta test version
Microsoft still hasn’t confirmed the bug in the official Release Information Status page. I’ve seen Twitter threads where Microsoft employees claim no knowledge of the problem – in spite of the fact that the bug’s been reported over and over again in many different places (including the Feedback Hub) for months. @navh2009 nails it:
“If they are going to keep half baking these new changes, then they should stop making changes to things [that] were never broken. File Explorer search didn’t need windows search. Delete key still doesn’t work. How does basic functionality like this get forgotten every time?”
@railmeat goes on to say:
“These kinds of problems reoccur [due] to inadequate testing. These should be found in regression and functionality testing. Microsoft has the resources to do that testing, but apparently chooses not to.”
@abbodi86 has an explanation:
“In 1909, the upper bar of File Explorer (address + search box) no longer belongs to the Win32 platform. It’s a hybrid WinRT (UWP) feature. It’s half-baked, ugly, slow, and requires some prerequisite tasks to even semi-function (clipboard and other services including the MsCtfMonitor task schedule).”
I still recommend that folks avoid 1909 for precisely this reason.
Join us for the latest on AskWoody.com.