Replies

One more thing, I’ve read about complaints that “install during automatic maintenance” does not work for some Windows 10 versions but should work well for later ones.

For best compatibility disable it, as you did. Users reported at borncity that on affected OS versions the timed installation and restarts will not happen if you enable this feature.

I can confirm this to happen on 1607, including Server 2016 LTSC 1607 which disqualifies the OS for me another time / or set a overriding GPO for this OS.

Because of this I can always recommend to create one OU for each Windows Client and Server version, so you can handle existing and potential differences.

 

naming OUs like

Windows 10 LTSC 2015
Windows 10 LTSC 2016
Windows 10 LTSC 2019
Windows 10 SAC 1809
Windows Server 2012
Windows Server 2012 R2
Windows Server 2016 LTSC 1607
Windows Server 2016 SAC 1809
Windows Server 2019 LTSC 1809

etc.

This looks like much of work but ulitmately I have had a lot of reasons to do this. e.g. Citrix Workspace does not work with 2015 LTSC but with all other Windows releases etc.
WMI filters generally cost too much performance, so I rather keep them sorting, which (in addition to other tools) let me keep track about Windows OS fragmentation and possible upgrade needs due to support ends as a side effect.

seamonkey420 wrote:

Just an update after further testing/checking today. I believe the settings I have are working as they should and we no longer get the “Check for Updates” button. Even though in settings it says updates are paused, i was able to get an office 2016 update via wsus today on my machine so…. i think my settings are actually fine and working as they should on 1809. thanks everyone who chimed in!

The check for update button is intented to no longer show up as you have set “turn off access to all windows features.”

Windows Update for Business will only offer Windows Updates. This is the reason why MS has implemented Dual Scan, so orgs can use WuFB for Windows Updates where deferrals or full stops can be set via GPO, and on top telemetry help to not receive updates / upgrades to machines that have known blockers.

WuFB ultimately features a centralized a view in Azure to monitor your device health (at costs) and update status, besides WSUS for other products.

The next step if you want dump WSUS altogether, will be Azure Update management (at costs).

However Dual Scan will allow orgs to use WSUS for all other MS products just as MSI based Office, SQL etc and their updates.

WuFB is not designed to completely replace WSUS as it won’t offer all updates available for all MS products – these would come from WU instead (if the button / GPO is checked to include other products) if you have no WSUS.

If you want to use WuFB you need to take care to enable and configure distributed delivery and tune BITS GPOs so all clients will feed each other instead all of them download from MS WU / WuFB eating up your bandwith (both is no longer a problem if all are on 1809 / Server 2019 due to smaller update sizes)

With your current GPO configuration WuFB is disabled and updates deferrals should not work.

 

sorry the much editing, but the WYSIWYG editor does not like copy and paste.

anonymous wrote:

Hi seamonkey, thanks for the detail posting. I am surprised that WuFB settings works as intended so deferrals are in place if you want only to use WSUS. By documentation you are right telemetry has at least set to basic to allow WuFB to work. But it also says that WSUS will not respect ANY settings of the WuFB such as deferrals. It will not work if you disable dual scan. That’s what the both available posts about dual scan coming from MS are telling. Can you please double check that deferrals really work as intended when updates only come from WSUS. This should not be the case.

I agree. I would be surprised if this would work.

If anyone is questioning why I put so much time and passion into this

1. Server 2016 is the same crapware as Server 2008 and 2012 (without R2).

The rule that every second OS release is a better one perfectly lines up with Windows 10 AND Servers (except 1511, that was merely a hotfix to avoid waiting for 1607).

The other point is, that I want to proove that LTSC is not something you can rely on for Servers and Clients alike.

2. Getting the latest release can be reasonable at a certain time, but it seems it is no longer optional – not even for LTSC.
This is all possible with inplace upgrades this is easily done from 2008 to 2019. But you need Software Assurance to do so / or another license agreement (Providers, IaaS etc)

The famous printer control bug in LTSC 2015 1507 gives it another drift.

3. For Servers, however, there are so many dependencies – VMware Level, Citrix, Backup, etc. Microsoft cannot expect anyone to upgrade to Server 2019 just to have a performant and more reliable OS – it is NOT a Client.

4. 2016 is still in main support. PERIOD.
By Microsofts support definition it has to be patched, if there are functional issues – this is valid – except for LTSC.

It deserves a backport of whatever MSFT has incorporated in 1703 or later to solve the issue

1 user thanked author for this post.

NetDef

anonymous wrote:

Great finding. So if a manual Dism install is faster than the automated process wouldn’t this reinforce the point it’s not just the bigger size of updates but a defect in the automated process???

it does not. I put some time into this. it is faster but not as fast as it should / could be – depending the hardware – you can probably save your time to script this into PS.

Hi everyone,

I cannot agree that manual download / installation / extraction of the MSU files will speed up things (much).

I’ve had hard times <span style=”display: inline !important; float: none; background-color: #ffffff; color: #333333; font-family: Georgia,’Times New Roman’,’Bitstream Charter’,Times,serif; font-size: 16px; font-style: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;”>this morning</span> to find out in my lab. Definitely though, I defend, that the update size and OS age is not the reason for a slow patching LTSC 1607.
It is in the code.

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

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

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.

 

“Is this downloading from Microsoft, or locally from a WSUS server?

 

Actually it does not matter. The outcome is same for WSUS and WU (haven’t tried WuFB / peer2peer)

The confusing part is, as stated in the remarks, the download time appear to be much longer given the table. This is not the case.

 

The download is fast with the latest CU.
The problem is that 1607 reports to “Download” in GUI and Core while it is already installing, so most of the time it sits there installing (tiworker.exe).

Add the DL time to the installation time in the table above. my line wasn’t busy for long DL 1.5 GB.

abbodi86 wrote:

Comparing 1607 with 1809 is not reasonable

I agree the 1809 are much smaller by design (express updates), and in GUI you might even see a linear dependency of update package size and time.

we all can review the GUI based update package sizes here, at a glance: https://www.computerbase.de/downloads/betriebssysteme/windows-10-kumulatives-update/

Comparing them makes still sense for me, as neither any later Server “2016” such as Server 1709 Core or 1803 Core suffers from the same issues – whilst having the same big batches to work on and will be much faster than 1607 Core.

And neither does this apply to any of the Servers before, even though they all share cumulative updates by now.

To make it clear: you can wait for patching one Server 2016 1607, while you are patching 20 or more 2012 R2 server or even 2019 while waiting the one Server 2016 to complete. And that is not a lack of ressources in CPU and storage. It just happens.

One Patchday we started a 2016 machine at 5 pm it was finished after all others at 11 pm, installed 2 CUs during this time, and that’s what other report in uservoice and technet, too.

Freeco’s comment is interesting and it does actually match that some users say they do not see any speed issues here.

1 user thanked author for this post.

NetDef

anonymous wrote:

a stable release cycle where updates are only released after they’ve been extensively tested, and an LTSB cycle where it’s, well, LTSB. All available to everyone. All with full control over the update process. Heavenly bliss for everyone, rather than just to people who can pay to still not have the control they need.

LTSC (formerly LTSC) is not stable. It has the same issues as SAC but just with longer “support”.

And by definition MS does not patch code issues, unless they find it neccessary. also OEMs refuse to support LTSC by now because by definition new drivers are unsupported!

LTSC is spin-off of SAC in an overall freeze state – including all the errors SAC has.
Keep this in mind. The only difference is it has no apps, no store, not even Edge as a competent replacement to IE 10 (support end 2020).

This was one major in LTSC 2015, never fixed. Users cannot change default printers:

https://answers.microsoft.com/en-us/windows/forum/windows_10-hardware/devices-and-printers-window-loads-very-slow-in/98f7feaf-e321-440f-9b91-b1dd0c5b4f36

https://community.spiceworks.com/topic/1956454-windows-10-devices-and-printer-
takes-forever-to-load?page=4

Till today there is no bugfix. I’ve called MS several times and they declined to fix it on LTSC as it is not security relevant. One needs to a open a premium support case, and this MAY actually get triaged by Microsoft US.

LTSC is designed to have as less codechanges as possible, by definition they told me.

 

1 user thanked author for this post.

AlexEiffel

2019 is based on Windows 1809 and so incorporates most of the benefitical changes, including monthly updates that have only 1/10 of the size of any previous version.

it has the best settings app so far and less conflicts / clutter with old control panel

it offers the most modern Defender protection + ATP and Azure Device Health support and if needed Azure / Hello expierence.

So I recommend it over a 3 years old LTSC 2016.

 

woody wrote:

Nobody thought about the future consequences of, say, a Win10 version 2003 that’s not from 2003. The Windows teams’ (there are two now) ability to plan and brand from a user’s point of view is horrendous.

Well maybe I am too pessimistic but I have forseen this after Windows 10 BETA

Windows 10 2003 / Server (2019) 2003 will happen, and just right then all harddying XP / Server 2003 users will again ask for updates hahaha.

But Woody, I would not be surprised if they change this soon – and again. Same for Citrix by the way https://www.citrix.de/downloads/workspace-app/

 

AlexEiffel, we have to keep in mind that ultima ratio next to the 365 delay there is a GPO where it says stop updates / upgrades from DATE. so if you are not adopting the fast cycles you can use this.

ideally the update prevention time should have been the max support time so 18 months (or longer for fall releases), not 365 days.

3 users thanked author for this post.

AlexEiffel, Kirsty, woody

in my opinion this change is correct but it will break GPO designs another time. And this change, same as Dual Scan will catch many admins and SysOPs pants down, because one is not obliged to read (MSFT) blogs and twitter in their work free time.

But apparently you have, too.Besides the regular changes we have seen (CB / CBB, later SAC / SAC-T), while some of them were just namings, we have a lot of confusion here and the ADMX is NOT prepared to cover up these changes. There are literally 6-7 restart policies and some do not even apply to all OS versions and not even to all Windows 10 / Server 2016+ OS versions, too.

I’ve made my plea to Ned because his title is deprecation motivator and he is a nice and communicative worker at Microsoft and I hope they will go off the schedule and change things, if they change across all versions. Because all the redesigns leave out any LTSC branches altogether.

Not that LTSC is designed for any upgrades, it is quite the difference but I simply do not want to use WMI filters or grouping my computers in OS version OU just to get on par with MS design changes where 4 GPOs (server, client and respecting testing groups) for Windows Updates is not enough.

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

just my 2 cents as a specialist that is assigned to WU management.

MS should take care that not anyone has SCCM Configmgr finally or is fully expierienced with Azure Update management to get things right for WuFB.

 

1 user thanked author for this post.

woody