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.
Stuck at 95% solved after manual update of KB4467691
Thanks for your help Karl W-E, but yes, servers have last SSU installed, 4465659.
On the matter: I have hopes that MS has heard us and will implement express updates (not the same as in WSUS options), to greatly reduce size and install time. First they only wanted to bring this for Server 2019 (1809) but I've heard that this is going to be ported backwards.
anonym have you made sure to install the latest SSU before installing the latest CU?
The latest SSU was released on 11. Nov.
find a comprehensive list of all SSUs here: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV990001
We have 3 identical VMs with Windows 2016 (installed from same template)... Everyone have had a different update process, last one is stuck in 95% downloading. No clear log of anything, I can believe this happens in 2018, what a shame!!!
Agreed! Windows Server maintenance should not be so time consuming. Microsoft should allow as much downloading/recompiling/installation as possible before taking the server and services offline. These optimized procedures should also be clearly documented to minimize downtime.
My Windows Server 2016 guests updated all in 20 minutes. The Hyper-V 2016 Host, takes over an hour to install and over an hour to reboot. No solution available. I have better things to do Microsoft. I can't believe they even released this as a Server OS.
edit: 10 2012 R2 server installed (not upgraded) their 09-2019 updates during the same time in a piece of that time residing on the same SAN / VMware Hosts.
Last patchday 06.10. 09-2018 September CUs:
2 VMs on VMware: 2016 (LTSC)
update duration 7:30 pm to 11:30 pm.
Why? The VMs did download the 05-2018 CUs in the local cache from WSUS.
You cannot deny this installation via usoclient or PShell.
After the installation of the 05-2018 patches, the 09-2018 were obtained and installed via WSUS.
Please know that this behaviour won't be the same with Server 2016 1703 (SAC) or later or even 2019 Server.
So it provingly is a servicing stack issue / TIworker.exe issue despite all current SSU were installed. Please fix your code Microsoft.
No company will upgrade to 2019 (currently paused), or use SAC branch just for sake of having FAST updates.
In the meantime I've upgraded 10 Server 2012 R2 machines + 3 clients from 1803 to 1809.
Just to give you an idea HOW F... slow this Server 2016 1607 does do its updates. I am feeling desperate that you do not comment or solve this major issue.
It takes over 2 hours to update a single 2016 VM and it doesn't give you an progress.
Patch your Server has become a great problem with 2016. We have about 90 VMs, on a Hyper-V cluster and on standalone Hosts. In the past patching took 12 to 14 hours for all servers, now we need 4-5 days. Patching a server under 2 hours would be real luck.
In addition 20 to 30 percent of the updates fail randomly. In the most cases retrying works, if not download the update and install it manually (normally works).
It is a lot of work to ensure that business critical machines are really running when you need them.
Secure and automatic patching does not work this way.
Good grief Microsoft... Cumulative updates on 2016 are ridiculous and take FOREVER. They fail OVER AND OVER AGAIN. After a dozen reboots and several attempts AND HOURS AND HOURS to get things patched then the restart takes 20-30 minutes. Im using fully patched and up to date VMWare 6.5 and Windows Server 2016 Std Ed. and running on G8 HP Proliant hardware, this seems to be a deadly combination for patching and staying up to date. Make Windows Server great again.. PLEASE... Fix the slow update problem. You'll be a hero to THOUSANDS of admins that dont have time for this stuff anyway.
Patrick I hear you, let's hope that Server 2019 will be better. Infact Server 2016 is a bit like vista and technically old, based on Windows 10 1607, which was not their best release base anyway.
I have good hopes for Windows 10 1809 / Server 2019
Truly a madness.
I manage about 200 Servers myself, 50% 2016 now.
Better go with VMware as a host in the future since MS doesn’t care anymore. You can see this with the massive bugs in 2016:
- DC on 2012R2 backup errors
- 2016 Cluster Crashes because of nics
- Defender and HyperV Replica Bluescreen
We have a lot more MS cases opened with 2016 but they solve nothing, it’s like jumping from one 1st Level to the next 1st Level ... without solutions
Chris Bailiss commented
Windows Server has definitely taken a step backwards with 2016 in terms of performance of system updates. Taking more than an hour prior to reboot, then a further hour for reboot and update completion, is poor.
^^ they probably know but don't have the personel and time to do that. Still I think it has become easier with Windows 10 and 201x Server
I can't believe there are so many people who do not know how to control patch management. What a shame.
I also recommend to install the most recent SSU first before installing any other CU or update.
Steve I absolutely agree I am sure that Server 2016 won't be addressed and MS will focus to fix this in Server 2019 aka 1809 and which is probably also the next LTSB.
This is a sad thing but I doubt they will can handle this using a servcing stack update. BTW have you installed the Servicing stack update on any 2016 Server yet to test if this ease the process? There was a very unknown advisory in the Update History.
Prerequisite: When installing both the servicing stack update (SSU) (KB4132216) and the latest cumulative update (LCU) from the Microsoft Update Catalog, install the SSU before installing the LCU.
Note these SSU (servicing stack update do not come automatically to any Windows Version, neither 1507 (and LTSC), 1511, 1607 (and Server and LTSC), 1703. 1709 and 1803 are not affected
Please give it a try if this fixes your issues.
On my behalf MS should automatically deploy these to anyone needed and code a prerequisite check. Cannot be that hard Microsoft, can it?
Dear Microsoft updates team,
First and foremost, the blind eye that is turned on this issue is VERY poorly received by the community, I work for a larger company with a huge Microsoft server OS contingent 9000+ Microsoft servers 40+ domains and hundreds of thousands of clients, and thousands of admins, patching 2016 VIA WSUS, by using deadlines to auto patch servers, we have the deadlines setup to patch various servers within a system to avoid complete outages, since 2016 has been introduced we can no longer use the patching windows that were initially established, but the push was not a half an hour, it's more along the lines of 3 hours to avoid the service outages, because servers can and will do strange things, like be unavailable, or when they restart they take 20+ minutes to complete the updating windows at startup, the growth of the WSUS database is also problematic, since it is in excess of 500 GB now, going from singular patches to rollups has added a lot of volume to the process and longer patching times, but a rollup applied to a 2012 machine completes in 1/4th the time the same cycle rollup applied to a 2016 machine, I get that the OS is different, but these issues do not go unnoticed by us (your customer) or by our customer, because it introduces a productivity hit to my customer, my co-workers, and all of this is generated by what appears to be a poor patch handling within the 2016 architecture.
I would say that the rollup process for companies that are heavily security minded, might point out that one patch within a rollup that requires an entire rollup to be backed out causes a greater security risk just removing a single patch to correct the issue, but that voice I think has spoken up a few times.
My own PFE told me that he had never heard this before, when we have been talking about it after every patch cycle, which is disparaging to say the least.
Thanks for your attention in this matter