Stop the "Windows update madness" on WS2016!
Dear Microsoft Windows Server team. We would like complete control over when we would like our our WS2016 to install windows updates! No more slow / timeconsuming server restarts because of "Getting Windows ready. Do not turn off your computer" messages when we just would like a quick restart of a production server.. No more TiWorker.exe using 100% of a CPU core during "*********" and so on.. And please fix the issues with '2017-08 Update for Windows Server 2016 for x64-based Systems (KB4035631)' asap. Thank you.
KjB
shared this idea
89 comments
-
Freddie
commented
Yeah we run Linux **** and it hangs almost always takes hours to updates for a few servers and do not even try to use it for DR, so stop the MS non-sense it works and why Fortune 500 companies make it the choice OS and some flavors of Linux because they get stuck with a vendor app to support that everyone is scared to even reboot?
So I guess there are ton of high level Corporate Excecs making decisions on ease of use and what works pretty much..
-
Gary Turner
commented
Every time I go through the pain of updates on Windows Servers I start to think about switching to Linux for the core infra.
We run a good number of Hyper-V hosts, today one just decided to install updates and reboot during the defined 'active hours' causing major disruption to the users at a site.
In terms of server product, especially a hyper-v hosts I have no idea what active hours is. You are allowed a maximum of 18 active hours in a day on a server whose role naturally will be 24x7. Otherwise al of the VMs on the host must share its active hours.
The whole thing is madness.
We also run VMware as a Hypervisor, that runs solidly and does not require anything like the same level of updates.
I agreed with the comments here MS need to learn that a desktop update system cannot be used on a server.
-
Adrian
commented
Win2016 and KB4550947 taking aagggeeeeeeessss, tbh I'm absolutely embarrassed I've recommended this piece of garbage to some clients back in 2018, it's simply unmanageable.
Do something M$ about this, it's a shambles. -
Mike
commented
Guys, I have a friend who works at MS. Nobody uses Windows Server there.
They all run Linux. Not kidding. Everyone knows it's a pile of garbage. We need to abandon this architecture NOW. Stop paying MS millions in per-month license fees charged based on the amount of RAM you have in your machine. Guess what: Windows Server is for suckers!
You've been HAD!
-
Delcio
commented
2020 an still not fixed, Microsoft getting worse !!!!
-
Anonymous
commented
See the following discussion here: https://social.technet.microsoft.com/Forums/en-US/250914a1-b013-434a-baa0-639e31a839dd/whats-with-the-really-slow-windows-updates-on-2016?forum=ws2016
Removing Windows Defender gave me a boost in installing the updates.
Hopefully this can help somebody else as well. -
Anonymous
commented
2 years and still not fixed ...
-
Paul Anderson
commented
So at least two years have passed since this problem was first observed and MS haven't fixed it. In my experience with MS systems, if an issue remains unresolved for this long it will never be resolved. Give up folks. Microsoft don't care. I'm going to recommend we switch our new server baseline from 2016 to 2019.
-
van der Zwaan VOF
commented
When will this ever get solved :-(
It's so frustrating! With 1 host server and 4 Hypver-V servers, it takes almost a day to update. And I have several confugrations like these! >:( -
AZSmitty
commented
It's hard to believe that MS has let this issue fester for so long. There are major corporations, like mine, who have hundreds if not thousands of Windows 2016 servers in their fleet of servers. Having a system down for 1 or 2+ hours simply to apply patches is totally unacceptable. MS fix this issue now!
-
Anonymous
commented
It is a new descent with the update process in Server 2016. First, after migration from 2012R2 to 2016 on a new SDD - on the same machine - i thought that must be a joke. Reboot after cumulative Update Package lasts usually more than 1 hour. Today the patch 09-2019 takes one and a half.... Now I am not laughing anymore, I am only happy that the machine comes alive at all yet....
-
Adam Duce
commented
We play roulette with if the server will even reboot.
Host is 2016 GUI Running Hyper-V
4 Sub Servers
DC
FILES
SQL
RDSJune 2019 Update. Host didn't reboot. Was stuck with the boot logo going round for an entire night. 2 Of the VMs Updated normally. 2 Sat stuck at Working on updates 100% for an entire night
July 2019 Update. Host updated normally. Two VMs updated normally. Two didn't at all, One stuck booting going round and round all night. One stuck at Working on updates 100%.
How can Microsoft do this I just don't understand. Everyone saying going to 2019 is the solution is deluded. Microsoft Corp is a cash cow and thats all it ever will be. Pushing Azure and subscription based infrastructure is getting beyond a joke. I'm waiting for Windows pop up ads saying have you tried Azure.
I want the 2003/2008 days back.
-
Richard VENCU
commented
Still same nightmare
-
Karl Wester-Ebbinghaus (@tweet_alqamar)
commented
There was a discussion about a workaround on patchmanagement.org Google Group
here it is - read the outcome below."%SystemRoot%\System32\sfc.exe" /scannow
"%SystemRoot%\System32\Dism.exe" /online /Cleanup-Image /AnalyzeComponentStore
"%SystemRoot%\System32\Dism.exe" /online /Cleanup-Image /CheckHealth
"%SystemRoot%\System32\Dism.exe" /online /Cleanup-Image /ScanHealth
"%SystemRoot%\System32\Dism.exe" /online /Cleanup-Image /RestoreHealth /Source:WIM:<your install.wim location and index>
"%SystemRoot%\System32\Dism.exe" /online /Cleanup-Image /StartComponentCleanup"Optional: "%SystemRoot%\System32\Dism.exe" /online /Cleanup-Image /StartComponentCleanup /resetbase
Verdict: The workaround – as above - appear to work just on GUI based servers, that are default and never had run a cleanup, or install / uninstall of features.
Advice: check the notes [1]-[4] before making early conclusionsGood news: it will speed update update process
Bad news: it will still take ages compared to later Server 2016 releases, just as 1703 or 1803 or later (SAC) or 2019 1809 LTSC / SAC or laterAt a glance:
Sfc + dism healthchecks and clean-ups (as commands below)2016 1607 LTSC GUI: 2 hours 9 minutes 18 seconds[1]
2016 1607 LTSC Core: 40 minutes 49 seconds[1]Patching after clean-ups and restart:
Searching for updates:
2016 1607 LTSC GUI: no time – update list was already cached (usually 13-20 seconds)
2016 1607 LTSC Core: 20 seconds (VM Uptime 1:21) [3]Download:
2016 1607 LTSC GUI: 8 minutes 34 seconds (start VM Uptime 1:05, end 9:39) [2][3]
2016 1607 LTSC Core: 12 minutes 8 seconds (start VM Uptime 1:26, end 13:34) [2][3]Install:
2016 1607 LTSC GUI: 8 minutes 20 seconds (start VM Uptime 9:39, end 17:54)
2016 1607 LTSC Core: 13 minutes 22 seconds (start VM Uptime 13:34 end 26:56)Restart + Logon:
2016 1607 LTSC GUI: 6 minutes 44 seconds (start VM 18:08, end 23:18+1:34)
2016 1607 LTSC Core: 6 minutes 50 seconds (start VM Uptime 27:51, end 34:06+0:35)Total Time:
2016 1607 LTSC GUI: with cleanup: 23 minutes 58 seconds / without cleanup: 44 minutes 28 seconds, as tested in February with latest SSU[1][4]
2016 1607 LTSC Core: with cleanup: 32 minutes 40 seconds / without cleanup: 23 minutes 26 seconds, as tested in February with latest SSU[1][4]2016 1803 LTSC Core: without cleanup: 6 minutes 56 seconds, as tested in February with latest SSU[1][4]
2019 1809 LTSC Core: without cleanup: 3 minutes 56 seconds, as tested in February with latest SSU[1][4]
2019 1809 LTSC GUI: without cleanup: 4 minutes 40 seconds, as tested in February with latest SSU[1][4][1]Note this process will very like take a lot longer in usual virtual environments. I’ve 4 cores + HT at 4.6 GHz and full NVMe Flash! (usual Hyper-V scheduling, full spectre / NG enabled)
[2] note that DL is bugged in Server 2016 1607. Taskmanager will not show any network activity and the TIworker Process will run after download and already prepare update installation
While it is still saying “download”. The download is fairly finished in a few time (450 Mbits downstream).
[3] VM Uptime are mentioned for time measure references and later video editing
[4]https://www.askwoody.com/2019/server-2016-ltsc-patches-take-for-e-ver-there-are-numerous-reasons-why-and-not-much-you-can-do-about-it/Interesting facts: Note that Server 2016 1607 Core, unlike its GUI pendant does not benefit from the cleanup. Likely because its component store is less overloaded with pre-installed roles / features.
In junction the cleanup was much faster ready than on the GUI pendant, as there was apparently less to do.Best regards,
Karl (@tweet_alqamar) -
Karl Wester-Ebbinghaus (@tweet_alqamar)
commented
Hi Koen,
I've suggested that long ago. You need Software assurance and also take care of your RDP and user / device CALS for Windows Server being updated. Most upgrade servers and forget about these CALs. -
Koen
commented
Just updated my server to 1809 so server 2019(inplace upgrade). This is the fastest way to get updates :-) took les then an hour !
installing updates afterword just works as it should. -
Koen
commented
Happy I found this site. I thought there was a problem with the hardware of my machine :-) then I found out that there is a high disk usage to get the files into the c: \windows\softwaredistribution\ folder so constantly working on updates.
regeards,
Microsoft should get us a free license to upgrade to 1809!
-
Anonymous
commented
On our server the March 12, 2019 CU (KB4489882) took nearly *four hours* to install. Microsoft, please, please fix this.
-
Anonymous
commented
We peaked at 3 hours last month with installing a single Cumulative update patch during our Server downtime. That is unacceptable. We have server environments that are three or four dependencies deep. We can't afford to be down for that kind of time especially given we only have a 6 hour downtime window to patch over 1,000 servers in our datacenter. Also, the file size is much too large. Last month it clocked in a 1.37 GB!
We need Microsoft to find a way to reset this with Windows 2016 server the way they do with Win 10 versions (patch size gets "reset" to a smaller size with each version upgrade) Why can't Microsoft find a way to port that same functionality into Windows 2016?
-
Jerem
commented
2 or 3 hours with this fu****** Getting Ready after reboot when we install update on 2016 LTSC
Thanks Microsoft !!!