I’m going to take some time to outline my general process here for troubleshooting patch installation issues which has helped me to cut down on my research time and get these issues resolved more quickly. Hopefully this will help you, too.
Rule #1 – Check for the simple stuff. You’d think people would learn not to put OSes on drives smaller than 40GB, but they still do. I just found a slew of them today still on 20 and 25GB drives, and these are 2008 R2 boxes. I could slightly understand if they were 2003 and yes, you’d be surprised at how many of those there are still chugging along hosting production workloads. Shame.
Rule #2 – The WindowsUpdate.log file is your friend. Invest in a good log file viewer, such as CMTrace so your eyes won’t bleed when reading these guys. In server 2016 and Windows 10 Microsoft did and didn’t do you any favors. You’ll need PowerShell to generate the log file so you can read it:
Get-WindowsUpdateLog -LogPath %systemdrive\Temp\WindowsUpdate.log
Now you have a text log you can view. This log is great for finding issues with reaching an update point such as a WSUS server or Microsoft itself. If it can’t reach the site it’ll log an error. Check your proxy settings and make sure you can reach the URL. Check the WSUS registry and verify the URL matches where it should be going, including and especially the port number. If you are still having issues with scans coming back failed, try resetting the update components. this has worked miracles for me and it’s faster than manually doing the job.
If a patch fails to install you’ll see an error here, too, but nothing really actionable other than Googling. Sometimes, if you go to Windows Update under the control panel, you can view the update history. Are you seeing failed update attempts? If so, this guy is what you want:
Rule #3 – %systemdrive%\Logs\CBS\CBS.log
This guy still exists in Windows 10 and most of the time it’ll tell you what’s going on. Open it up and search for “CBS_E_”. You’ll see some lines where it can’t open or resolve a package, but if you keep looking it’ll tell you what package it can’t open.
In this case the manifest was corrupted and it was flagging the entire CBS store as corrupt. When you find the KB causing the updates to fail (always the first one in the list), manually download and install it. After that whatever automated process you are using will work.
But what if you manually download it and it still doesn’t work?
Well, there’s a tool for that from Microsoft. Download and install it. When you install it, it will take forever. This is because it is running scans and repairs at the end of the install. Once the install has completed rerun the update you were trying to install.
I’ve had some servers delivered by vendors with no patches on them, just a base OS install from media. When we placed the SCCM agent on it and scan it would come back clean – no errors, no updates, nothing. The fix in this case ended up being to install a security update from 2014 that includes a Windows Update Agent update. Once the update agent was on a later version it could then properly scan itself against SCCM/WSUS and retrieve updates. But instead of going through all that like I did, just go here and get it. Updating the Windows Update agent solves a lot of problems. If you are seeing issues with prolonged and excessive CPU utilization during scans, check the agent version. Most of the time it’ll be the culprit.
When things get really hairy:
You can also try sfc /scannow and dskchk /R.
There’s more out there, but this isn’t intended to be comprehensive. it should be a good start and help get you on your way a little more quickly.