Karl Wester-Ebbinghaus (@tweet_alqamar)

My feedback

  1. 7 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    investigating  ·  3 comments  ·  Management Tools » Windows Admin Center  ·  Flag idea as inappropriate…  ·  Admin →
    Karl Wester-Ebbinghaus (@tweet_alqamar) commented  · 

    happened to me too sometimes. Reinstalling or upgrading helped. Seems to be fixed in current Insider release.

    Karl Wester-Ebbinghaus (@tweet_alqamar) supported this idea  · 
  2. 1 vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Management Tools » Windows Admin Center  ·  Flag idea as inappropriate…  ·  Admin →
    Karl Wester-Ebbinghaus (@tweet_alqamar) commented  · 

    can confirm Jeffs comment. PS-connection will be terminated

  3. 10 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  Management Tools » Windows Admin Center  ·  Flag idea as inappropriate…  ·  Admin →
    Karl Wester-Ebbinghaus (@tweet_alqamar) commented  · 

    Jeff sometimes it does make a difference whether you enter domain\username machinename\username or in case of a domain joined device using the UPN
    username@contoso.com

    If one sets up SSO this >usually< works without issues except with RDP.
    Please recheck domain joined devices with or without SSO (delegated ...) for WAC. and make sure that UPN will be accepted.

    domainname\username is pretty oldschool for me as O365 user / promoter:)

    Karl Wester-Ebbinghaus (@tweet_alqamar) supported this idea  · 
  4. 3 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Management Tools » Windows Admin Center  ·  Flag idea as inappropriate…  ·  Admin →
    Karl Wester-Ebbinghaus (@tweet_alqamar) supported this idea  · 
  5. 47 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Management Tools » Windows Admin Center  ·  Flag idea as inappropriate…  ·  Admin →
    Karl Wester-Ebbinghaus (@tweet_alqamar) supported this idea  · 
  6. 63 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    11 comments  ·  Management Tools » Windows Admin Center  ·  Flag idea as inappropriate…  ·  Admin →
    Karl Wester-Ebbinghaus (@tweet_alqamar) supported this idea  · 
  7. 74 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    3 comments  ·  Management Tools » Windows Admin Center  ·  Flag idea as inappropriate…  ·  Admin →
    Karl Wester-Ebbinghaus (@tweet_alqamar) supported this idea  · 
  8. 601 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    started  ·  55 comments  ·  Management Tools » Windows Admin Center  ·  Flag idea as inappropriate…  ·  Admin →
    Karl Wester-Ebbinghaus (@tweet_alqamar) supported this idea  · 
  9. 44 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Management Tools » Windows Admin Center  ·  Flag idea as inappropriate…  ·  Admin →
    Karl Wester-Ebbinghaus (@tweet_alqamar) supported this idea  · 
  10. 24 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Karl Wester-Ebbinghaus (@tweet_alqamar) commented  · 

    Windows Admin Center is a per machine based administration view - unlike to Server Manager where you could see administrate one thing for many servers at once, except updates

    Karl Wester-Ebbinghaus (@tweet_alqamar) supported this idea  · 
  11. 369 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    81 comments  ·  General Feedback » Configuration  ·  Flag idea as inappropriate…  ·  Admin →
    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 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]

    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.

    Karl Wester-Ebbinghaus (@tweet_alqamar) commented  · 

    Hi John, I cannot agree there is any improvement on my lab.

    I've tried following:

    2016 1607 LTSC GUI patched to 2019-02, incl. SSU - not ok
    2016 1607 LTSC Core patched to 2019-02, incl. SSU - not ok

    2016 1803 SAC Core patched to 2019-02, incl. SSU - ok
    2019 1809 LTSC Core patched to 2019-02, incl. SSU - ok
    2019 1809 LTSC GUI patched to 2019-02, incl. SSU - ok

    all trying to update to 2019-03. not ok mean - not improvment in speed compared to my previous benchmarks / comparisons.

    another thing that I noticed while comparing. During "download", when it is really downloading, there is no network activity in the VM taskmanager in 1607 LTSC GUI only.

    2019 LTSC GUI shows correct network activity while downloading.Imho 2016 is "limited" in many aspects. Windows Update is just one of them.

    https://twitter.com/tweet_alqamar/status/1107188019268849664

    Karl Wester-Ebbinghaus (@tweet_alqamar) commented  · 

    Hi John,
    I will recap the situation with the 2019-03 updates. All VMs I've measured had previous updates. I currently doubt there will be any improvement but I really want to double check your findings.

    Yesterday updated 2016 1607 2x GUI 2xCore at a customer 4 VMs from 2018-08 to 2019-02 via Windows Admin Center. The process took about about 45 Minutes including restarts

    Karl Wester-Ebbinghaus (@tweet_alqamar) commented  · 

    " a fix to the current Service Stack might have fixed it in those who are still using 1607 if I'm reading what you said, though on reread it seems this only fixed a DL and not the install/reboot."

    Currently there is no fix. It can happen though on fresh installs that the display of download / installing phase are displayed correctly without affecting the total time.

    "Do you have more information on the procedure you were using to update the OS of the existing 1607 boxes to 1809? A link to documentation or perhaps what exactly to look for?"

    There is no documentation for this as this does not work. GUI <> Core switch is no longer possible (was with 2012R2 but got removed with 2016).

    If you need GUI and have a license or active SA for CALs and Server you can easily mount your 2019 ISO and do an inplace upgrade. (Backup / temporarily snapshot in backhand)

    Ironically this upgrade wents nearly faster than any monthly CU installation ;)

    Not telling there won't be a fix at all in future - while I doubt it - as it disagrees with the LTSC terminology - but all efforts to get MS involved directly failed so far.
    Maybe being a GOLD partner is not enough.

    Thanks for everyone your feedback and appreciations of my works. It helps a lot get equal the investments of free time into this topic.

    Karl Wester-Ebbinghaus (@tweet_alqamar) commented  · 

    "Not seeing a 180* version of 2016 with GUI at all. :( So guessing we either need core instances or start using 2019. :/"

    Yes it is like this it is definitely fixed in Server 2016 1809 Core, which means there is no transition from GUI to Core without reinstalling + you may have limitations with apps - lesser of these with 2019 Core (due to Feature on Demand package).

    However you need an active Software Assurance for the Server 2016 Core 1809 as it is an SAC branch. you may not use it without active SA. On top SAC Server Core branch has only 18 months support but inplace upgrades are the way to get up just as with GUI from 2016 > 2019 etc.

    tl;dr So either you can transist to 2016 or 2019 Core with Software Assurance or use 2019 GUI to workaround this issue.
    We have had IT press coverage already and I am trying to get more involved.

    please note by terms of use it says Server Uservoice is NOT for bug reporting - so reporting here might not be the right place. Reporting via the MS Support however they likely let you down to tell you it is an isolated issue - which it is not.

    Karl Wester-Ebbinghaus (@tweet_alqamar) commented  · 

    John / EFD no need to argue. Please check my stats. The issue is any Windows 10 / Server 2016 1607 alone. Any later does not have any issues with updating and Performance.
    Belongs to Server 2019 GUI / Core (1809) as well as Server 2016 Core 1803 etc.

    Karl Wester-Ebbinghaus (@tweet_alqamar) commented  · 

    Another example. It is in the code. Proven.

    Patching Server 2016 LTSC Core 1607 vs Server 2016 SAC Core 1803 + 2 installations from scratch (each about 3 minutes)

    Watch yourself: https://1drv.ms/v/s!ApTx3d3fhinPgpk-2l8Vku1C26Pz7A

    Server 2016 LTSC Core 1607
    Size 1393,5 MB
    Search Updates > 13 sec
    “downloading” Updates > aborted after 28 minutes

    Server 2016 SAC Core 1803
    Size 835,8 MB + SSU 1,2 MB + Delta Update 287,6
    Search Updates > 19 sec
    Downloading Updates > 2 min
    Installing Updates > 2 min 45 sec
    Reboot / Applying Updates / logon > 48 sec (typo password measured 57)

    Total Patch Times > 6 min 56 sec

    Transscript:
    Server 2016 LTSC shows the usual behaviour to report download while already installing the update. The status is not consistent with the actual process. This is valid for GUI and core and was fixed later in W10 1703 / Server 2016 SAC 1709
    As we see now the process is broken by design, not by update sizes as abbodi86 stated.
    The Server 2016 SAC 1803 has quite similar update speed as Server 2019
    Despite the package size of 2019 is even smaller.
    I don’t expect 2016 1607 Core to finish before minute 25 as last time.
    If I am able to install a server in a time of 3 minutes the system cannot be powerless enough to patch anything within a reasonable time.
    Just for fun we could install a second 2016 server from scratch to make the sillyness of this bug obvious.
    I could literally setup 15 servers + patch them – in a timeframe where one of these 2016 1607 would be completed patching, or more depending if GUI or not.
    Showing this a complete clean installation should remove all doubts the issue is by design, and MSFT has fixed it in later code.
    Soon™ finished
    you see the new 2016 server 1607 suffers even more issues. longer update search etc. so the 02-2019 and older SSU improved it – except the installation time and wrong display of “download” phase
    ok at least there seems to be a relation of SSU and download if no older SSU was installed – interesting enough
    KB3192137 – mysterious…
    https://social.technet.microsoft.com/Forums/Azure/en-US/28b60975-c6bf-4986-8d80-7be953597a5a/what-is-update-kb3192137?forum=ws2016
    nevertheless even the new installed 2016 has the same installation speed, despite the download issue appears to be fixed.
    seems the 2016 LTSC is crashed…
    0 percent CPU makes me worried
    But I think you get the point, the new installed 1607 isnt that fast either.
    I will stop it here. not worth the time.

    Karl Wester-Ebbinghaus (@tweet_alqamar) commented  · 

    Updating 02-2019 2016 & 2019 Core comparison

    video: https://1drv.ms/v/s!ApTx3d3fhinPgpkriARDNqJrGfygWQ

    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 Wester-Ebbinghaus (@tweet_alqamar) commented  · 

    Video via Onedrive for evidence Please share video / post until fixed.
    https://1drv.ms/v/s!ApTx3d3fhinPgpkfpt3eIZ6rVJZwaw

    Setting:
    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 Wester-Ebbinghaus (@tweet_alqamar) commented  · 

    Dear Admins, suffering companions, I've tried to bump up at a very kind and helpful person at Microsoft. I cannot promise anything but I hope it does help this issue gets a checkmark before end of main support for Server 2016 LTSC, after more than a year or reporting.

    Karl Wester-Ebbinghaus (@tweet_alqamar) commented  · 

    I still encourage anyone that have active Software Assurance to take a backup when Server is shut down and use ISO / setup.exe to upgrade to Server 2019 1809. This will fix the update issue. Updates for GUi servers will take about 10 Minutes, without GUI it's done in lesser time.

    I don't see a fix coming for Server 2016, by Design, the Update packages are too big and 1607 has serious issues with TIworker process.

    Server 2016 SAC is not affected as they use newer code but this is limited choice for Software Assurance and non GUI servers.

    Karl Wester-Ebbinghaus (@tweet_alqamar) commented  · 

    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.

    Karl Wester-Ebbinghaus (@tweet_alqamar) commented  · 

    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

    Karl Wester-Ebbinghaus (@tweet_alqamar) commented  · 

    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.

    Karl Wester-Ebbinghaus (@tweet_alqamar) commented  · 

    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.

    Karl Wester-Ebbinghaus (@tweet_alqamar) commented  · 

    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

    Karl Wester-Ebbinghaus (@tweet_alqamar) commented  · 

    ^^ 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

    Karl Wester-Ebbinghaus (@tweet_alqamar) commented  · 

    I also recommend to install the most recent SSU first before installing any other CU or update.

    Karl Wester-Ebbinghaus (@tweet_alqamar) commented  · 

    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

    https://support.microsoft.com/en-ushelp/4132216

    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?

    Karl Wester-Ebbinghaus (@tweet_alqamar) commented  · 

    David, Update log is available only via Powershell. This is a change.
    Anonymous try to enable software vGPU on ESX / Hyper-V this should heal your GUI slowness and greatly improve the performance on Citrix for free.

    On the topic I am sad that Server 2016 does not offer Edge, as a substitute to IE as IE is still loading while other products are already ready.

    So my plea is: faster updates (better utiliziation and GPOs to steer dism / installer worker)
    implement Edge on Servers, please.

    Karl Wester-Ebbinghaus (@tweet_alqamar) supported this idea  · 
  12. 305 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    50 comments  ·  General Feedback » Configuration  ·  Flag idea as inappropriate…  ·  Admin →
    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 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]

    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 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.

    Karl Wester-Ebbinghaus (@tweet_alqamar) commented  · 

    Updating 02-2019 2016 & 2019 Core comparison

    video: https://1drv.ms/v/s!ApTx3d3fhinPgpkriARDNqJrGfygWQ

    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 Wester-Ebbinghaus (@tweet_alqamar) commented  · 

    I was wrong with my post from 16th Feb.

    Video via Onedrive for evidence Please share video / post until fixed.
    https://1drv.ms/v/s!ApTx3d3fhinPgpkfpt3eIZ6rVJZwaw

    Setting:
    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 Wester-Ebbinghaus (@tweet_alqamar) commented  · 

    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.

    Karl Wester-Ebbinghaus (@tweet_alqamar) commented  · 

    Dear Admins, suffering companions, I've tried to bump up at a very kind and helpful person at Microsoft. I cannot promise anything but I hope it does help this issue gets a checkmark before end of main support for Server 2016 LTSC, after more than a year of reporting.

    Karl Wester-Ebbinghaus (@tweet_alqamar) supported this idea  · 
  13. 8 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    4 comments  ·  Management Tools » Windows Admin Center  ·  Flag idea as inappropriate…  ·  Admin →
    Karl Wester-Ebbinghaus (@tweet_alqamar) commented  · 

    This not available 1809.5 to edit security of services or SNMP options

    Karl Wester-Ebbinghaus (@tweet_alqamar) supported this idea  · 
  14. 2 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  General Feedback » Licensing, SKU, & Edition  ·  Flag idea as inappropriate…  ·  Admin →
    Karl Wester-Ebbinghaus (@tweet_alqamar) shared this idea  · 
  15. 3 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  General Feedback » Shell, GUI, & Explorer  ·  Flag idea as inappropriate…  ·  Admin →
    Karl Wester-Ebbinghaus (@tweet_alqamar) supported this idea  · 
  16. 102 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    4 comments  ·  General Feedback » Applications & Add-ons  ·  Flag idea as inappropriate…  ·  Admin →
    Karl Wester-Ebbinghaus (@tweet_alqamar) supported this idea  · 
  17. 125 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    24 comments  ·  General Feedback » Licensing, SKU, & Edition  ·  Flag idea as inappropriate…  ·  Admin →
    Karl Wester-Ebbinghaus (@tweet_alqamar) supported this idea  · 
  18. 1 vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Installation and Patching » WSUS  ·  Flag idea as inappropriate…  ·  Admin →
    Karl Wester-Ebbinghaus (@tweet_alqamar) commented  · 

    still not fixed

    Karl Wester-Ebbinghaus (@tweet_alqamar) shared this idea  · 
  19. 18 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Karl Wester-Ebbinghaus (@tweet_alqamar) supported this idea  · 
  20. 38 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Karl Wester-Ebbinghaus (@tweet_alqamar) supported this idea  · 

Feedback and Knowledge Base