My understanding of the issue has changed as we've been attempting to troubleshoot. It may make more sense to scroll down and read 'Update 6' first before reading through the entire body.
We appear to be having some major Windows Update issues on newer machines running 1803.
KB4483234 fails to install in a loop. If you remove it from WSUS it still attempts to install to local PCs.
After some research, my best guess is because KB4483234 is part of SSU KB4477137. In the Windows Support page for KB4483234 it says
"If you are using Windows Update, the latest SSU (KB4477137) will be
offered to you automatically. To get the stand-alone package for the
latest SSU, go to the Microsoft Update Catalog."
https://support.microsoft.com/en-us/help/4483234/december192018kb4483234osbuild17134472
However, WSUS had individual entries for 4477137 and 4483234. I'm not entirely sure how that works, as one was released on 12/11 and the other on 12/19. But based on what I can tell, we currently have 4483234 marked as Approved for Removal and that didn't seem to take.
Even if I do
dism /online /remove-package /PackageName:Package_for_RollupFix~31bf3856ad364e35~amd64~~17134.472.1.0
and then mark it as declined in WSUS this updated still shows up when I prompt Windows Update to query for updates.
So I decided to try and start removing 4477137. When I try to remove it manually with
dism /online /remove-package /PackageName:Package_for_KB4477137~31bf3856ad364e35~amd64~~17134.464.1.0
it fails and a thorough read through the logs reveals this line:
DISM DISM Package Manager: PID=4600 TID=5116 Permanent package
cannot be uninstalled. – GetCbsErrorMsg
I realize I can edit some MUM files to remove it, but I question whether that will cause more issues. I need to install it eventually to get the next rollup, no?
So, I am curious if anyone else is having issues with these two updates. I'm looking for clarification on how the two updates are connected – in that the KB article seems to suggest they should be nested under the one update, but I clearly have two updates. Ultimately, I want to know the best approach to fix this. At the moment this is affecting some of our production machines as we cannot install a windows feature when there are updates pending, but those updates just fail and go back to pending. I am at a loss!
UPDATE 1:
The only error message that seems to come up in the Windows Update logs is 0x800F0922. This seems to be a very generic message. As a result we've attempted the following:
Ran SFC Scannow and all DISM cleanup-image commands, no change.
I assigned a drive letter to the system reserved partition – is is hilariously not full (430+MB free of 500MB)
I reset the Windows Update components by renamed Windows/SoftwareDistribution and Windows/System32/catroot2, no change.
I enabled all unchecked features for .NET Framework 3.5 and .NET Framework 4.7, no change.
I completely removed all .NET Framework features, no change
I reinstalled the normal .NET features, no change.
I've run the Windows Update troubleshooter.
I've tried to install the update directly from the windows Catalog.
UPDATE 2:
A comment suggested I clean out the temp folders. I did a methodical cleaning;
I let the update fail, so there was no pending update in Windows Updates, I cleaned out my %temp% folder and windows/temp. Restarted, downloaded updates, installed, same behavior.
I did the same but throwing disk cleanup into the mix, no change.
I let the Updates download and install until they were pending restart, THEN I went through and cleaned the temp folders and ran disk cleanup again. Still no change in the behavior.
UPDATE 3:
One more thing I wanted to mention: I just re-read my original post and there is a slight omission.
KB4471324 is also failing to install. So, KB4477137 installed fine – I misinterpreted this as being connected to KB4483234 which one of the replies pointed out – but KB483234 and KB4471324 are both stuck in this loop.
UPDATE 4:
Some lines from the CBS log
Before this bit with the hash error is a long chain of registry overlap and its followed by a short block of directory overlaps. What would be modifying these files to change the hashes? Is it more likely a corruption, or something more nefarious?
2019-01-08 17:05:25, Info CSI 0000328a Warning: Overlap: Registry value collision found under key \REGISTRY\MACHINE\SOFTWARE\Classes\DeviceDisplayObject\AllItems\shellex\PropertySheetHandlers\{61F7B364-432C-4D04-BBC1-7FC1BF3807A8}\ for , only one component should set this value
2019-01-08 17:05:25, Info CSI 0000328b One of the components setting this value is Microsoft-Windows-FDBTH, version 10.0.17134.471, arch Host= amd64 Guest= x86, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2019-01-08 17:05:25, Info CSI 0000328c Previously seen component setting this value is Microsoft-Windows-FDBTH, version 10.0.17134.471, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2019-01-08 17:05:25, Info CSI 0000328d Hashes for file member [l:11]'install.ins' do not match.
Expected: {l:32 ml:4096 b:89df13e3b32a99da5730f0f3af7cef50d1eecb068ea58c377a5b797c5f592708}.
Actual: {l:32 b:775a0c4e6371ec5b3371866cae8a52e180594178c84ae96030d367a4afa2020f}.
2019-01-08 17:05:25, Info CSI 0000328e Hashes for file member [l:11]'install.ins' do not match.
Expected: {l:32 ml:4096 b:89df13e3b32a99da5730f0f3af7cef50d1eecb068ea58c377a5b797c5f592708}.
Actual: {l:32 b:775a0c4e6371ec5b3371866cae8a52e180594178c84ae96030d367a4afa2020f}.
2019-01-08 17:05:25, Info CSI 0000328f CSIPERF - RegistryPI Queue 446ms
2019-01-08 17:05:25, Info CSI 00003290 Registry installer wrote 2291 values
2019-01-08 17:05:25, Info CSI 00003291 CSIPERF - FilePI Queue 159ms
2019-01-08 17:05:25, Info CSI 00003292 Error: Overlap: Duplicate ownership for directory \??\C:\windows\SysWOW64\spp\tokens\pkeyconfig in component Microsoft-Windows-Security-SPP-Component-SKU-csvlk-pack-License, version 10.0.17134.441, arch x86, nonSxS, pkt {l:8 b:31bf3856ad364e35}
UPDATE 5:
Inspected the install.ins files. There are 8 of them, 4 sets of pairs for a x64 and x86 flavor. The most recent is
C:\Windows\WinSxS\amd64_microsoft-windows-ie-adminkitbranding_31bf3856ad364e35_11.0.17134.407_none_99e01535d6e245c0\install.ins
and was last modified 11/9/2018.
[Branding]
CompanyName=Microsoft Corporation
Wizard_Version=11.00.17134.407
Version=11,00,17134,407
Custom_Key=MICROSO
Global=1
IE4 Welcome Msg=1
Platform=2
GUID={7211FFE6-C149-11D0-AFF0-00AA003758BB}
Type=0
NoClear=1
UPDATE 6 & POSSIBLE CAUSE
So, the initial parameters we were working off of were wrong. This was not effecting all machines on 1803. We only had a few random machines that were on 1803, plus a large batch of identical new machines. Our two laptops running 1803 ended up having some other update issue entirely. The issue described above is entirely unique to the new batch of machines.
The new machines were purchased for two reasons, one to upgrade our two higher-end departments and the other as a final proof of concept of automating PC deployments with MDT. Since they were all the same hardware, and we didn't have a VLSC license yet (we wanted to justify the purchase first), I capture their OEM base image, threw a Chocolatey install into it, hit it a with a chocolatey batch script, and popped it into a deploy OU with GPOs for deployment all through MDT. This was the first cumulative update those machines encountered after being deployed this way.
We now have the VLSC base images and I redeployed to the same tasks to the same hardware with the new base image and everything seems to work without issue.
I still have a great interest in seeing if I can fix the currently deployed image. I have 13 PCs deployed and two spares, but I rather not interrupt all our web developers and graphic designers by doing another full swap. But I at least have one 'fix' on the table.
I've altered the post title to reflect some of the changing parameters
Best Answer
You have misunderstood the support article, which says:
In other words, you should install KB4477137 before installing KB4483234, and this will happen automatically if you are using Windows Update. You still need to install both updates in order to be up to date.
Even if it were possible to remove KB4477137 it would not be helpful to do so, if anything it would be more likely to make things worse.
Instead, you need to resolve the problem that is causing KB4483234 to fail to install. I suggest you start by downloading the manual installer from the Windows Update Catalog and see if that works, and if not, what error message it gives you.
(As to why it continued to attempt to install even after you revoked the approval in WSUS, this is unfortunately typical of Windows 10. Once an update has been downloaded, the Windows Update client becomes very single-minded about installing it, and is likely to ignore any instructions to the contrary. You may also find that the "last reported" date on the WSUS server for these clients isn't changing.)