CoNetrix

Blog: windows update

At the beginning of 2018, news broke regarding "Meltdown" and "Spectre"; two vulnerabilities that took advantage of speculative execution in Intel CPUs to retrieve sensitive information. This quickly expanded some from the initial report as OS vendors would release patches for their respective systems, but the basic vulnerability remained the same.

Microsoft released an out-of-band patch to mitigate the vulnerability from the software side with a caveat; several antivirus vendors were taking advantage of kernel processing in ways that were not best practice. When the Microsoft patch is installed, the system would get a "blue screen of death" (BSOD) due to the antivirus software.

In response Microsoft implemented a check for a registry key before installing the patch - antivirus vendors would need to add this key to show they were compatible with the release. Vendors that did not add this (despite the compatibility) caused IT administrators to manually add the key in order to continue receiving patches following the January release.

Over the next several months, issues with CPU firmware caused software patches to be re-released, rolled back, and released again across a variety of vendors. Only recently have these firmware releases stabilized enough that software vendors can re-release and support their mitigation patches.

More recently, the March Monthly Rollup for Server 2008 R2 (KB 4088875/4088878) had an issue that affected many virtual servers with static IP addresses. Upon reboot, these servers would "lose" and "rediscover" the NIC, forcing administrators to delete the "disconnected" and hidden NIC driver and reconfigure the new NIC. Around a week after the initial release, Microsoft published workaround instructions for administrators to run some VBScript code, that would clear some registry settings, prior to installing this patch.

A few days later, information came out regarding "Total Meltdown" - a new vulnerability created from the patches of the original Meltdown/Spectre patches - that required an out-of-band kernel update in addition to the buggy March Monthly Rollup for Server 2008 R2.

Finally, a week before the April Patch Tuesday release, Microsoft released a patch that would execute the VBScript via Windows Update, and configured the metadata of the patches so that this patch should install prior to the buggy KB4088875 and the follow-up kernel update (KB4100480). As of the April Patch Tuesday, these patches appear to have been rolled up into the single Monthly Rollup release in order to take care of all the prerequisites automatically.

There are several other examples of patches in the past that require additional manual work following install. A few examples are below:

  • KB2871997 - Released October 2014, requires registry key to force clear leaked logon session credentials
  • KB3159706 - Released May 2016, requires post-installation command line for Server 2012 R2 WSUS to properly decrypt Windows 10 upgrades
  • KB4034879 - Released July 2017, requires registry keys to make LDAP authentication over SSL\TLS more secure

Needless to say, it is prudent that IT administrators remain on top of patching and vulnerabilities reported across your infrastructure. Many of these additional steps can easily slip through the cracks for someone who is blindly approving and installing patches - even though that appears to be the recommended best practice for Windows 10 / Windows Server 2016 going forward.

Networking, windows update,
 

I was investigating a problem with Windows Updates on a laptop with a lot of software on it from a previous user. The updates having problems were the Windows 7 Monthly Cumulative Security patches.

Windows Update would download the patch, install the patch, and then ask to reboot Windows to complete the install.  Once the PC rebooted, the screen would show that Windows was installing updates and sit there at 32%.  The system would eventually reboot itself and change the status to "Failure Configuring Windows Updates. Reverting Changes. Do Not Turn Off Your Computer."  This whole process would take anywhere between 60 - 90 minutes before changes were reverted and I could get back into the system.

Through a  remote console, I connected to the system and wrote down what I observed, including the time.  What I saw were 3 reboots 15 minutes apart with the screen sitting at 32%.  The 15 minutes apart seemed to be consistent.  It was also observed that the Trusted Installer process had high CPU utilization.

From this information, I searched more specifically at CBS log error "Startup: A possible hang was detected on the last boot. [HRESULT = 0x800705b4 - ERROR_TIMEOUT].  I figured that the 15 minutes might end up being a timeout period since it was consistent.

I came across a single article where someone saw something similar with a Windows 2008 R2 domain controller getting stuck at 42% and had opened a premier case with Microsoft: https://social.technet.microsoft.com/Forums/office/en-US/f8fe7d4c-af64-4e65-a007-1f557518628e/windows-2008-r2-sp1-fails-to-install-on-domain-controller-errortimeout-at-42?forum=winservergen

As a solution, they modified the registry value for BlockTimeIncrement in the Trusted Installer service key: HKLM\System\CurrentControlSet\Services\TrustedInstaller.  This appears to be a timeout used for driver enumeration, and by default this is set to 15 minutes.  Increasing this value from 384 (15 Minutes) to 2a30 (3 hours) gave it enough time to wait for whichever component was taking longer than 15 minutes, and eventually the update installed successfully.

 

Networking, windows update,
 

I was recently doing a maintenance window for a customer and had an issue with several of their servers giving me an Error Code 80243004 – Windows Update encountered an unknow error when I was trying to install updates.  After researching, I came across an article with a very simple and weird fix for the issue. 

  1. Right click on the taskbar and select Properties.
  2. Click the Customize… button on the Taskbar and Start Menu Properties window.
  3. On the Notification Area Icons window, make sure Always show all icons and notifications on the taskbar is checked and click OK.

After turning on the notifications for Windows Update, I was able to successfully install all Windows Updates.

Networking, windows update, Windows,
 

Recently I worked on a desktop system that was having issues connecting to WSUS and installing patches. This was a Windows 10 system (upgraded from Win 8.1) with Office 2016 (upgraded from Office 2013). Every time that I opened the Windows Update app, it listed several Office 2013 updates that couldn’t install. You could press the Retry Now button and it would run for a minute or two, but always fail with a non-specific and non-helpful error.

After running through troubleshooting steps of resetting the Windows Update agent, I finally started looking at the Office 2013 aspect. I decided to uninstall whatever 2013 components were still there and reinstall, if necessary. I loaded Programs and Features and Office 2013 was not listed.

I found a Microsoft utility to forcibly uninstall Office 2013/2016 products (link) and ran it on this PC. On the first run (and subsequent reboot), Office 2016 was removed, but 2013 was still detected by the Windows Update agent. On the second run (and subsequent reboot), Windows Update installed all of its normal patches without the Office patches listed.

I reinstalled Office 2016 and was able to bring the computer up to date. It really appears as if the 2016 upgrade didn’t fully remove all of the 2013 components as a part of the upgrade.

 

 

Networking, Microsoft Office, Windows 10, windows update,
 

I was recently working with a customer and they had been prompted to reboot their server mid-day because of Windows updates. I told them to click “Restart Later” and forget about it because it should initiate the restart that night. However when I logged on to the server a few days later I got the notification that the server would reboot in 5 minutes.  I disabled the Windows Update service to prevent the reboot, then followed the steps below to force a reboot after updates are installed regardless if someone is logged into the server or the session is locked.
 
To change the AlwaysAutoRebootAtScheduledTime registry key value to enable automatic Windows Update restarts, follow these steps:

  1. Install Windows Update 2822241
  2. Start Registry Editor. To do this, follow these steps:
    1. Swipe in from the right edge of the screen, and then tap Search. Or, if you are using a mouse, point to the lower-right corner of the screen, and then click Search.
    2. In the search box, type "regedit.exe".
    3. Tap or click the displayed regedit.exe icon.
  3. Locate the following registry subkey:
    HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
  4. Swipe across or right-click AlwaysAutoRebootAtScheduledTime, and then tap or click Modify. Note If the entry does not exist, follow these steps to add it:
    1. On the Edit menu, point to New, and then tap or click DWORD Value.
    2. Type "AlwaysAutoRebootAtScheduledTime" in the Name field, and then press Enter.
  5. In the Value data box for this registry key, enter "1".
  6. Click OK.
  7. Exit the Registry Editor.

https://support.microsoft.com/en-us/kb/2835627
 

Networking, Windows Server 2012 R2, windows update, Windows 8,