To improve Windows Server I suggest you ...

Windows Updates shouldn't fail constantly or take hours to complete

I have a number of 2016 servers. It seems like 99% of them fail when doing automatic updates. I am able to install them manually by going through sconfig and selecting option 6 but it takes FOREVER. During installation, the CPU or Memory isn't maxed out at 100% so I have no idea what is causing it to take forever. All other previous versions of Windows run and install updates just fine in the same VMware environment.

237 votes
Sign in
Sign in with: facebook google
Signed in as (Sign out)

We’ll send you updates on this idea

Ross shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: facebook google
Signed in as (Sign out)
  • Karl W-E. commented  ·   ·  Flag as inappropriate

    There was a discussion about a workaround on 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 conclusions

    Good 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 later

    At 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]

    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]

    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

    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)

  • Fuck Microsoft commented  ·   ·  Flag as inappropriate

    **** Microcunts. ********* all the way to Redmond. If Billy Gay ******* Goat wasn't such a ********...after all, we know how this whole **** fest started.
    Back when BillGay ****** said, "who could possibly need more than 640k of ram.

    I think what he meant was.....lets **** every user in the world **********, ***** them over, offer zero ******* help and support, never ******* answer question and hire only the BEST ******* 3rd world fuckwits that can't speak a word of ******* english.

    Garbage Company....Garbage Software Garbage Updates, Garbage Garbage Garbage.

    Talke it all to the roadside and punt it down the ******* hill into Billy Gay ****** Goat lips Pool.

  • Karl W-E. commented  ·   ·  Flag as inappropriate

    Hi Eric,
    I will try if this helps with the 03-2019 updates and repost results.
    do you issue them before running the updates? I guess so.

  • Erik Carlseen commented  ·   ·  Flag as inappropriate

    I agree 100% that this situation is absolutely atrocious, but the worst of it can be managed with proper container store maintenance. If you were to reply that the container store is an absolute trash fire and that such a thing should not need frequent administrator attention, I would also agree 100%. This is not intended in any way to let Microsoft off of the hook for this mess, but to provide a path forward for dealing with the terrible hand they've dealt us. The following commands are your friends:

    "%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

  • Costel Ono commented  ·   ·  Flag as inappropriate

    I manage hundreds of servers at my company and indeed the Windows 2016 patching is atrocious ! Extremely long

  • Stephen Kovacsiss commented  ·   ·  Flag as inappropriate

    We have a number of 2012 R2 servers at AWS and the updates are super fast and since moving to 2016, they take 5 to 10 times longer to complete. It make no sense as to why the update process is so slow. Right now they are all done using the built-in Windows Update functions, although I would like to setup a WSUS for this setup. That is another task that will happen as needed. The updates though, cannot be taking 20-30 (or longer) minutes to complete.

    Karl W-E shows it quite clearly in a recent post. Maybe Server 2019 is better, need to see if it is as good as 2012 R2.

  • Anonymous commented  ·   ·  Flag as inappropriate

    Same massive issues and problems here with Windows Server 2016 (inside virtual machines with 2016 as well as on the hypervisor side with Hyper-V based on 2016)

  • Karl W-E. commented  ·   ·  Flag as inappropriate

    Updating 02-2019 2016 & 2019 Core comparison


    Server 2019 LTSC Core
    Search Updates > 6 sec
    Download Updates > 33 sec
    install Updates > 2 min 30 sec
    Restart / Apply Updates + Logon > 45 sec

    Total Patch Time 02-2019 CU > 3 mins 56 sec

    Server 2016 LTSC Core
    Search Updates > 28 sec
    Download / (install*) Updates > 13 mins 52 sec
    install Updates > 6 mins 8 sec
    Restart / Apply Updates + Logon > 2 min 57 sec

    Total Patch Time 02-2019 CU > 23 mins +/- 26 sec

  • Karl W-E. commented  ·   ·  Flag as inappropriate

    I was wrong with my post from 16th Feb.

    Video via Onedrive for evidence Please share video / post until fixed.!ApTx3d3fhinPgpkfpt3eIZ6rVJZwaw

    Windows 10 19H1 Hyper-V
    Test: Server Patches 2016 LTSC vs 2019 LTSC GUI.
    "Baremetal" installation

    2 vCore - Host i7700k @ 4,8 GHz
    32 GB RAM
    2x NVMe 970 EVO 1 TB (Storage Spaces, Mirror, Thin Provisioning)

    Server 2019 LTSC GUI
    Search Updates > 11 secs
    Download Updates > 21 secs
    Install Updates > 3 mins 16 secs
    Restart / Apply Updates + Logon > 52 sec
    Total Patch Time 02-2019 CU + .net > 4 mins 40 sec

    Server 2016 LTSC GUI
    Download / (install*) Updates > 22 minutes 10 secs
    install Updates > 7 mins 7 seconds + 20 secs another search
    Restart / Apply Updates + Logon > 14 mins 50 secs

    Total Patch Time 02-2019 CU
    without .net patches available > 44 mins 28 secs

    this translates to storage with no NVME to patch times of several hours as reported in uservoice

    *the progress bar is wrong altogether on W2016 it reports to download but is already installing for minutes as there is no network traffic and tiworker is consuming a whole core

    if you imagine to patch 20-100 servers on VMWare or Hyper-V you can literally feel the CPU pressure and time consumed comparing to Server 2019.

  • Karl W-E. commented  ·   ·  Flag as inappropriate

    hi everyone, it seems the latest Servicing Stack Update from 02-2019 will finally fix the issue. I will try to test it further or alternatively provide proove as video comparing 2016 vs 2019 GUI + Core update speeds and tweet to Microsoft with reference of two uservoice.

  • Anonymous commented  ·   ·  Flag as inappropriate

    We’re a small non-profit with about 20 PCs and one physical Windows 2016 server. Updates that used to take an hour or so on a Friday evening with Server 2008R2 now take an entire day or longer with Windows Server 2016. Most recently I tried installing KB4480961 (the January 2019 cumulative update)—it ran for nearly four hours, failed, and then took another hour to roll itself back. Ugh.
    Not sure what our long-term plan is yet, but a Synology NAS is starting to look better and better. Windows Server 2019 is available to us through software assurance but I’m reluctant to move to a server OS that was only released a few months ago.
    Microsoft, please fix!

  • Josh commented  ·   ·  Flag as inappropriate

    My 3 hour patch window is now a 1-2 day process with our Windows Server 2016 systems. Planning around backup windows is hard enough with the limited amount of time I have.. this is becoming a nightmare and a waste of my time to monitor these systems all weekend.

  • Anonymous commented  ·   ·  Flag as inappropriate

    This is standard for Microsoft to release one bad operating system in between each viable operating system release. I’ve watch this become their modus operandi since Windows 95. Just go back through every Windows OS and you’ll see that it is a genius system to sell more software.

  • Anonymous commented  ·   ·  Flag as inappropriate

    Updating a Server 2016 server takes FOREVER, unacceptable when you are talking production systems.

  • Alan Schuh commented  ·   ·  Flag as inappropriate

    Chris commented · October 31, 2018 7:29 AM

    "...How is that acceptable?"

    By definition, it is acceptable. The windows community's continued use of Server 20xx, and all other MS products, is proof of acceptance.

    There are are Linux flavors that can be configured as strong, stable, and secure servers, and there are alternatives to MS applications. You (plural) choose to accept your ride on the Whirligig Update ride.

  • Anonymous commented  ·   ·  Flag as inappropriate

    I have to agree with everyone. Mine do not fail (yet) but it does take hours going from WU or WSUS. From WU I am not counting the time it takes to download because frankly these updates are huge but the time to apply gets about 10-15 minutes longer each month. I am up to about 1.5 hours per server.from the time preparing to install hits.

  • Will commented  ·   ·  Flag as inappropriate

    I can only confirm we have the exact same issue as mentioned in the comments below.. (I wonder if Joe Patterson is onto something - has anyone else tried his suggestion - and did it work?)

← Previous 1 3

Feedback and Knowledge Base