KB4601318 fails to update, fails at 24% Windows Server 2016

Kevin S 96

Hello,

I have 3 virtual servers that have this exact same issue where when I try to update KB4601318, it stalls at 24%. The servers are 2016 servers, I have disabled anti-virus, I have rebooted, followed instructions on this blog, added RAM and enabled and disabled firewall. I have updated 15 other servers in my environment successfully, running the same antivirus software, same kind of setup. The servers all have 2 or 4 processors, 8 GB or 16 GB of RAM and at least 200+ GB of available disk space. No errors in the event viewer that I can see.

I've let the update run on these machines for 2 hours and what happens is that it will install KB890830 and KB4601392 on all of these machines but not KB4601318 on any of them. It gets stuck at 24% and then eventually stops and reads "KB4601318 is available" "Updates are ready" and Download button is enabled. If I click it, it goes through the exact same cycle where it stalls at 24% again.

Any assistance would be appreciated.

AllianceALG 16 Reputation points

2021-02-11T13:55:18.157+00:00

Same situation here, setting up brand new AD environment, ESXi... Both DC and term server both stuck at 24% since yesterday... New servers, no past issues, confused on this as well.
Brandon Haag 1 Reputation point

2021-02-12T02:04:45.903+00:00

Both an older 2016 Hyper-V VM and brand new 2016 Hyper-V VM unable to complete updates! Hope this is fixed soon. I doubt a server with no updates will last for long!

Brandon.
Damon Rodriguez 1 Reputation point

2021-02-12T18:30:05.433+00:00

So if we've already downloaded and installed the SSU we will need to install the CU using the workaround? Or should we wait until a fix is available?

Accepted answer

Zabaga, Robert (King of Prussia) 141 Reputation points

2021-02-11T17:26:11.25+00:00

I've successfully ran the KB on 2 machines at this point. Pretty much the steps other people listed. I can do on a few VMs but dozens or hundreds across an organization would not work for this....too resource intensive for 1 admin!

-Download the update from Microsoft Catalog (.msu file)

-Stop Windows Update Service. For me it didn't stop so I had to set the service to Disabled then go to a command prompt and run "sc queryex wuauserv" then do a "taskkill /f /PID xxxx" (where xxxx is the PID listed from the prior query command).

Delete or rename the C:\Windows\SoftwareDistribution\ folder

Now run the .msu update file. A few times I got a pop-up about a stub file error. What is that? Anyway, I waited a minute and ran the .msu again and it unpacked and ran successfully.

Set Windows Update back to manual

Reboot. KB installed.
Please sign in to rate this answer.

1 person found this answer helpful.

0 comments No comments
Sign in to comment

33 additional answers

John Storbeck 1 Reputation point

2021-02-12T20:35:26.78+00:00

I have a Sev A call open with MS Support. What they are telling me and this is based on internal docs and discussions with the devices team is that the issue with SCCM aka SECM is if you have your Software Updates settings setup to allow Express Updates. If this is turned on and you have deployed the 2016 Feb SSU you get the problem. If you don't do Express Updates you should not see an issue with the Feb 2021 Cumulative Update installing.

We deploy SSUs ahead of our normal scheduled weekend maintenance windows so we have over 3000 systems that already have the Feb 2016 SSU for 2016 KB4601392 installed and are not going to pull the Feb 2021 CU for 2016 KB4601318 from the SUG and see what happens during the early windows to decide if we are going to halt that deployment.
Please sign in to rate this answer.

0 comments No comments
Sign in to comment
Susan Bradley 96 Reputation points MVP

2021-02-13T05:51:57.327+00:00

Windows Server 2016 SSU – has been recalled and been replaced with KB5001078. This fixes the issue where the cumulative update got stuck at 24%.

source: https://learn.microsoft.com/en-us/windows/release-health/status-windows-10-1607-and-windows-server-2016#1559msgdesc
Please sign in to rate this answer.

0 comments No comments
Sign in to comment
Buskey, Lee [USA] 6 Reputation points

2021-02-14T16:17:33.96+00:00

So,

I appreciate all the information. Nice to know I am not on my own here. I am not quite sure how to tell at exactly what percentage they are failing at without catching it at the console, but to me it seems to be at 99%. I have over 60 Windows 2016 Servers failing to install KB4601318.

None have had the old SSU installed,(KB4601392) all have the updated SSU installed (KB5001078), and most are still failing to install KB4601318. They report 100% install of the patch shutting down, reboot, then on start up they go into the "Getting Windows Ready" phase. Start reporting "Working on Updates" and then eventually get to 99% complete, sit there for a while, Then comes back with "We couldn't complete the updates, Undoing changes Don't turn off your computer." We do not have any special builds, and maintain all via standard WSUS.

I haven't tried the manual procedure yet, but there's no way I am doing them all manually, MSFT needs to get this right. Not sure why we are having to do their testing.
Please sign in to rate this answer.
PwshAddict 11 Reputation points

2021-02-14T16:28:45.953+00:00

I'm seeing KB4601318 fail and the new SSU successfully installs prior to reboot. I believe KB4601318 will install correctly after the reboot from our testing.

Buskey, Lee [USA] 6 Reputation points

2021-02-14T18:38:38.17+00:00

Let us know. I have rebooted these servers 3 or 4 times now... Fails every time.

PwshAddict 11 Reputation points

2021-02-14T18:44:41.617+00:00

Our failure rate was under 2% though I could not verify your exact condition.

Buskey, Lee [USA] 6 Reputation points

2021-02-14T21:43:44.973+00:00

So all you needed to do was ensure that KB5001078, the updated SSU got installed, and then your default approach (SCCM or WSUS?) deploying the cumulative update was mostly successful?

PwshAddict 11 Reputation points

2021-02-15T13:51:09.637+00:00

Yes, mostly successful. We were using deployments through Azure Update Management.

Some VMs that were setup to auto-install patches had more issues but I think it's because KB5001078 did not require a reboot. My theory is that KB4601318 would fail, KB5001078 would install and it wouldn't reboot.
Sign in to comment
Buskey, Lee [USA] 6 Reputation points

2021-02-15T14:23:34.567+00:00

Interesting. We are an on-prem virtual environment, but I'd not think the update mechanism would matter. For the Test VM's we run and let the patches auto install on, Cumulative Update KB4601318 was released and installed successfully before either Service Stack Update KB4601392 & KB5001078.

On a Test system:

So based on our admittedly basic patch testing we were good to go. However when we released all the pending patches, it looks like SSU KB4601392 never went out because it was superseded by SSU KB5001078, and unlike the test machine above, SSU KB5001078 went on before CU KB4601318, and that was all she wrote. KB4601318 fails to install across the board, and does so in slightly different and fairly ugly way, failing at 99% complete of the post patch reboot maintenance. Might have just been a coincidence, but we also lost a domain controller during this time as well. Hard to say it was not a result of the failed CU..

On a Prod System:

Converting this to an Answer for more visibility
Please sign in to rate this answer.
Svend Petersen 1 Reputation point

2021-02-17T00:14:00.393+00:00

Yeah that's a worry. I may hold back on the Servicing Stack update till I have the CU out of the way.

Buskey, Lee [USA] 6 Reputation points

2021-02-19T01:03:12.483+00:00

So we figured out our issue. It was totally self inflicted.. Here the whole story in case it catches anyone else by the short hairs..
Part 1:

So, when converting the 2016 servers from MBR to GPT partitions as required to enable a UEFI BIOS, which is required for Secure Boot, which is required for the Windows option "Credential Guard" which is required by the STIG.... (STIG is a government security configuration guide for those who don't know)
Microsoft provides a tool called MBR2GPT.exe which allows the conversion of the disk to a GPT partition without reinstalling the OS. This worked fine, but for the majority of the VM's that needed to be converted, MBR2GPT created a third partition on the disk, and set that as the UFI partition required for GPT.
This totally works, but we had an unanticipated consequence. Because the new partition is created at the end of the disk, it prevents us from growing the main OS disk, something we need to do regularly.

Buskey, Lee [USA] 6 Reputation points

2021-02-19T01:04:05.23+00:00

Part 2:

I was able to use a popular open-source tool called GPARTED Live utility to shift the main partition (2) to the right by 100MB, and the copy the 100 mb EFI partition (3) from the end of the disk to the freshly opened spot between the recovery partition (1) and the main partition (2), and then delete the original EFI partition that was in the way. While a little labor intensive, this worked great as afterward the modified VM's booted just fine.. Check that box and move on the next challenge..
Fast forward a few weeks, the 1.7 GB February Cumulative Update will not install. To further confuse matters, there was a totally separate issue with the February CU which would cause it to stall at 24% installed if install was attempted before a corrected Servicing Stack Update was released. That is a totally separate and unrelated issue to this.

Buskey, Lee [USA] 6 Reputation points

2021-02-19T01:07:08.17+00:00

Part 3:
From the Component Based Servicing log (CBS.log). It's a horrible log and really hard to read, but the "What's wrong with this picture" approach still helps.
<snip>
2021-02-15 23:47:07, Info CSI 000002a4 BFSVC: 'Failed to get system partition! Last Error = 0x3bc3'
<snip>
So, as it turns out, while Windows will boot fine without it, some things, like Component Based Servicing expect to find a specific ID assigned to the UFI partition in order to identify it as the system partition. GPT does stand for Guid Partition Table after all. Seems the process of copying that partition in GPARTED did not also copy the assigned GUID. After finding this error, our buddy google showed how another guy fixed it. After correcting this, all the machines I tested that were failing the update, then took the update.

Buskey, Lee [USA] 6 Reputation points

2021-02-19T01:09:28.533+00:00

Part 4:

You can see the first run of list partition doesn't list a system partition. But after running the command to assign the appropriate value to it, it lists a system partition.
Some may ask, "Can I fix this with PowerShell?" I had very limited luck. I guess diskpart does some work under the hood to maintain the BCD.
This will assign the required GIUD to the partition, but also crashes the server (NOT A bsod) and results in a post crash boot failure. You have to boot to PXE and run a "bootrec /rebuildbcd", then it works fine, and the update will install.

invoke-command -computer testserver01 {

$partition = (Get-Partition -DiskNumber 0 | Where { $_.size -eq " 104857600"}).PartitionNumber
Set-Partition -PartitionNumber $partition -DiskNumber 0 -GptType "{c12a7328-f81f-11d2-ba4b-00a0c93ec93b}"

}

Buskey, Lee [USA] 6 Reputation points

2021-02-19T01:09:55.49+00:00

Part 5:

I guess diskpart does something under the hood to preserve the BCD environment that doesn't happen with set-partition.

I'd be interested in knowing if anyone knows how to make this work in PowerShell. I have had limited luck invoking Diskpart with a script via using the invoke-command cmdlet to remotely use invoke-process to run diskpart.
Sign in to comment