What’s next for Windows 10 and Windows Server quality updates
Published Aug 16 2018 10:45 AM 86K Views
Microsoft

Today I’m excited to share that we’ll be bringing a new design for quality updates to the next major versions of Windows 10 and Windows Server, coming later this year. This design creates a compact update package for easier and faster deployment.

Windows 10 quality updates are cumulative, containing all previously released fixes to ensure consistency and simplicity, and are released monthly. As Mike Benson noted in his post last month on “Windows 10 quality updates explained & the end of delta updates,” we are continuing to work to reduce the impact of cumulative update sizes and reduce complexity for IT administrators. That is why, beginning February 12, 2019, Microsoft will end its practice of creating delta updates for all versions of Windows 10.

For down-level supported versions of Windows 10, Microsoft will continue to provide express updates in addition to a full update (also referred to as a latest cumulative update, or LCU) each month. Starting with the next major version of Windows 10 and Windows Server; however, there will be only one quality update type—and it will be smaller in size, redistributable, and simpler to manage. This new, single update approach offers benefits over the three existing update types (full, delta, and express):

  • Organizations that get full updates from Windows Server Update Services (WSUS) or from the Microsoft Update Catalog will seamlessly save network bandwidth thanks to the smaller size of the update.
  • Organizations that have been using delta updates to manage the size of quality updates will no longer have to monitor the update status and history of their devices to determine which devices are eligible for delta updates.
  • Since this new quality update package will be redistributable, organizations that utilize express updates via WSUS, System Center Configuration Manager (SCCM), or a third-party management solution that supports express updates will experience enormous savings in network bandwidth and cache size on their distribution points or update servers. In addition, devices with the next major version of Windows 10 will be 40% more efficient* while updating since there will be no behind-the-scenes computing of the optimal differentials required to download express updates.

*40% improvement in device memory utilization as compared to Express updates (Reference set measurement)

whats-next-for-quality-updates_01.png

whats-next-for-quality-updates_02.png

**Express update size as depicted is the best-case scenario with the assumption that the device stays up-to-date each month.

Quality updates packaged using this new design will be distributed over Windows Update (WU) and WSUS in a cabinet (.cab) file and available as downloadable Update Standalone Installer (.msu) files from the Microsoft Update Catalog. Devices managed by Microsoft Intune, and third-party mobile device management (MDM) solutions, as well as on-premises management solutions that get updates from WSUS or the Microsoft Update Catalog, will all have access to this new quality update design.

Microsoft will use the same update package design to deliver quality updates to devices connected directly to Windows Update. Today, if these devices are running a currently supported version of Windows 10, they receive applicable quality updates as full updates (LCU) with feature updates and successive monthly quality updates using express updates. Devices connected directly to Windows Update that are running the next major version of Windows 10 (and future versions) will benefit from the new small update size whether they are installing applicable quality updates with a feature update or installing a monthly quality update at any time.

This change in approach applies to all monthly quality update releases, i.e. “B” releases, out-of-band releases, and “C” and “D” releases. If you want to learn more about monthly quality update releases, see John Wilcox’s post on the Windows 10 update servicing cadence.

For more information on optimizing update bandwidth, see Optimize Windows 10 update delivery. To learn more about Windows as a service, visit the Windows as a service page on the Windows IT Pro Center.

 

31 Comments
Steel Contributor

Nice, thank you for reduce the updating size, and the overview information. :smiling_face_with_smiling_eyes:

Will this impact the need for servicing stack updates?

Copper Contributor

With this new Monthly Quality Update, will it be cumulative like the full update was? Or will it become a monthly non-cumulative update?

Copper Contributor

Can we also expect for the updates to install faster?

Copper Contributor

Could you please provide some details about the inner workings of the new updates?

Copper Contributor

This has been a major issue for many of my customers not to adopt Windows 10, as they have poor network connectivity and slow networks. Let us hope that Microsoft really decreases the size of those updates to a level my clients won't have this excuse anymore. 

 

I'd also love to see only ONE version of Windows, no Home, no Enterprise, no Professional, or any other flavors  Just one Windows version! 

Microsoft

I'll try to consolidate my answers in one reply here.

 

Susan,

Servicing stack updates will still be needed when there are servicing stack issues that need to be fixed.

 

Jeremy, 

It will continue to be cumulative

 

Devin,
Express took a lot of CPU time, and this new format will take much less.  So it should install faster, but it will heavily depend on the speed of your machine (slower machines will benefit more)

 

Klaus,

What inner workings would you like to know about?

 

Anoni,

Yes, we believe this will be a lot better for many customers due to the reduced size.  Especially enterprise customers or small and medium business that have multiple branch offices.

thanks,

Mike Benson

Could you go into the details of how you are compressing the file in order to get these updates smaller and why it can't be backported to prior versions?

Copper Contributor

Could I confirm that the latest cumulative update for Windows 10 is still mixed with security patches + non security patches ?

 

Could you help share the mechanism behind for how it reduces the size of package while all updates are still included ? 

Microsoft

Yes, the LCU (latest cumulative update) is still cumulative and contains both security and non-security updates.  There are no changes in the update payload within the cumulative update.  Only change was to how it is stored.

 

I'll try my best to explain how the new system works.  In my explanation I'll refer to 3 update types - Full Update, Express Update, and now the new Smaller Update.  Each of these updates types are just different formats, but the end result on your system would be the same thing - a fully cumulative update that gives you all the security and non-security patches for the Windows OS in one package.

 

Full Update - contains compressed version (similar to ZIP style compression) of every component and binary that has changed in the OS since RTM

 

Express Update - The server contains compressed deltas from multiple baselines for every component and binary that has changed since RTM.  Your machine chats back and forth with the server (the server could be Windows Update itself, or it could be a local WSUS server) to identify which byte ranges it needs and then downloads those ranges.  Your device then hydrates those byte ranges back into complete files on your device and then does an installation. By multiple baselines, I mean that it includes deltas from specific points in time.  Generally we use last months LCU (N), the month before (N-1) all the way back N-5 months, and RTM.  So the server express file could be 6-7GB while the end device only downloads 150-200mb.

 

Small Update - The package contains the compressed delta from RTM for each file (Forward Delta), and the delta back to RTM (Reverse Delta).  Essentially this means instead of containing multiple baselines, it only has 1 baseline (RTM).  As an example, if your device were on the September LCU and then you installed October, your machine would apply the September reverse delta to go back to RTM and then the October forward delta to go to October (10B).  It does this in a transaction so there is no possibility of your device being stuck in the middle somewhere - either the full update succeeds or does not.  Since all the content is in the package itself, no server negotiation is needed.   Because it only has a single baseline (from RTM) it will sometimes be larger than an express update for someone that was on the previous months patch.  But the size difference should be minimal, and without the server negotiation and on device analysis it uses less CPU during download and install.  

What is really great about the new smaller package format is that same file is available from Windows Update, WSUS, and Catalog.  So even if you download from HTTPS (Catalog) and double click to install you get the smaller experience.  Unlike express that only worked via Windows update or WSUS (or 3rd parties solutions that support the express protocol).

 

To make this change, there were modifications needed in both the package format itself, and in the update stack on the client.  Making those types of changes to older versions of the OS would be risky (the update stack is absolutely critical).  With a new version of the OS we have many months of both internal testing as well as Windows Insider previews that we can use to validate the changes at scale and reduce risk.

 

Mike

Copper Contributor

Hi Mike,

Thank you for that detailed explanation. Certainly answers a lot of questions.

In your Small Update example, you indicate the update would first apply the back delta from September to RTM, then apply the forward delta from RTM to October. Are there cleanup mechanisms built in that will automatically cleanup the accumulation of delta information? Or would this data be cleaned up through use of Disk Cleanup? Or by nature of the design will there be no accumulation aside from the last installed LCU?

Copper Contributor

Thanks Mike,

That's what I wanted to know about the "inner workings" of the new "small updates".
The back and forth patching sounds crazy - great solution if that works reliable and fast.

Cheers

  Klaus

Copper Contributor

Thanks for the detailed explanation !!~

Copper Contributor

Will this new "Quality Update" require:

-WSUS server to be 2016 or will 2012r2 WSUS servers be supported?

-"Express Updates" enabled on the downstream WSUS servers (DISA provides DOD upstream and they don't enable that feature)?

 

Thank you!

Deleted
Not applicable

Hello,
Why is WSUS not operating as a multi-threaded process all the time?


Task Manager graphs sugests that the dispatcher is switching between cores, but they are not all active at the same time.
Overall utilization is below 20% most of the time during the update. Why is that and what are they waiting on?


Machine is an 8th Gen i7, 16G, SSD and a 100Mbps Fi0 conection.

 

Thanks in advance. Regards,

EQ

Copper Contributor
Hello Mike, Just for a clarification purpose and for my understanding. From next version of Windows 10; there will no express update type and other update type? Many of my customers interested to adopt to Windows Express Updates but why there are so many changes in Update Delivery Type Mechanism and so quickly.. My customers running on SCCM + WSUS to patch their devices monthly. Does these changes applies to SCCM + WSUS as well? In this case; how the supportability and integration with SCCM. Again any changes to SCCM Client Agent Settings or Site Servers required.? Currently from SCCM CB 1806 there are improvements in place to initiate Software Update Maintenance from SCCM and that takes care of cleaning up the DP space and WSUS content directory. If it next major version release; which is the next version of release we are talking 1809? Do Microsoft have a roadmap of offering single Update Delivery Type Mechanism instead of multiple types and changes happens quickly to adopt for Enterprise customers..
Microsoft

Hello everyone, here are some answers to the most recent questions.

 

Mat Calvin - WSUS from Server 2012r2 is supported by the new smaller cumulative updates

 

Esteban - Unfortunately I'm not enough of a WSUS expert to know the answer to that question.  I'd recommend either reaching out to your account manager, or going to a technet forum dedicated to WSUS.

 

Rajkumar - 
Correct - for Windows 10 1809 there will just be the new smaller cumulative update.  Much less confusing than having Full updates, delta updates and express updates :).  The new smaller cumulative update will work with WSUS and SCCM.  SCCM CB 1806 will work with the new smaller update.  

 

thanks,

Mike

Copper Contributor

Hi Mike/Maliha -

 

Hoping you can shed a little more light on how Microsoft is achieving the space savings in the "small" updates. I understand that you're only including the forward differentials for RTM -> Target version (rather than forward differentials for 5 versions + RTM), but you're also including the reverse differentials for each version of the file back to RTM - and those have to be non-zero sized as well, right? The system still has to know how to convert what it has to RTM and then to target for hydration, or am I misunderstanding a fundamental concept here?

 

Thanks!

Copper Contributor

Also @Mike Benson / @Maliha Qureshi

 

The whitepaper that describes this new update process (https://docs.microsoft.com/en-us/windows/deployment/update/psfxwhitepaper) describes the automatic repair process being potentially reliant on Windows Update - is this true? Will this automatic repair process be affected by any group policies blocking access to Windows Update as a source?

 

When corruption is detected during update operations, automatic corruption repair will start as usual and use the Baseless Patch Storage File published to Windows Update for each update to fix corrupted manifests, binary differentials, or hydrated or full files.

Brass Contributor

I have the first of these small updates last Wednesday. 123 MB instead of 1 GB! It felt good. :smiling_face_with_smiling_eyes:

Bronze Contributor

Hi @Nathan Ziehnert,

 

If I understand your first question correctly, you are wondering how what Mike calls the "Smaller Update" could be smaller than the "Express Update". As far as the size of the content delivered to each client goes, I don't believe that Microsoft is claiming these updates to be smaller. In fact, if you look at the "Update size" graph, the bar for the new Quality Update is slightly taller than the bar for the Express Update. It sounds like the real benefits comes from the greatly reduced amount of data that needs to be transferred to and stored on the update servers, and the reduction in processing on the client.

 

As far as whether blocking access to Windows Update with a GPO would affect automatic corruption repair, I'd be interested to hear the answer to that as well.

Copper Contributor

Thanks @Ryan Steele - I agree that they are slightly larger than the expected data transfer of express updates, but this is inclusive of everything (one 150-300MB update being cumulative for all revisions of an OS) which is significantly smaller than the all in storage cost of express updates (5-6GB on the WSUS server). Fundamentally something is very different between how they were packaged in Express vs how they are now being packaged.

Bronze Contributor

@Nathan Ziehnert, I think I see your misunderstanding. You may be under the impression that the Smaller Updates contain the reverse differentials for the previous months' quality updates, but this is not the case. Each update contains only two sets of deltas: the ones to get from RTM to that update, and the ones to get from that update back to RTM. 

 

Let's say you installed Windows 10 1809 in September, then you installed the 2018-10 Cumulative Update in October. That update contains the deltas to get from RTM to 2018-10, as well as the deltas to get from 2018-10 back to RTM. Then you installed the 2018-11 Cumulative Update in November. It contains the deltas to get from RTM to 2018-11 and the deltas to get from 2018-11 back to RTM. Windows uses the deltas it already has from the previous update to get from 2018-10 to RTM, the it uses the new deltas it just downloaded to get from RTM to 2018-11. 

Copper Contributor

@Ryan Steele- (facepalm) thank you. I guess I wasn't assuming that the updates were relying on data stored locally but that process makes much more sense now.

Microsoft

@Nathan Ziehnert, @Ryan Steele

Corruption repair requires access to Windows Update or a Windows Repair Source. For an environment with blocked access to Windows Update, you can configure a Windows Repair Source to use within your network.

Copper Contributor
Will this be available for all versions of Server 2016?
Bronze Contributor

@djello, Mike Benson made a post earlier in this thread saying:

 

To make this change, there were modifications needed in both the package format itself, and in the update stack on the client.  Making those types of changes to older versions of the OS would be risky (the update stack is absolutely critical).  With a new version of the OS we have many months of both internal testing as well as Windows Insider previews that we can use to validate the changes at scale and reduce risk.

So no, it doesn't sound like it will be coming to Server 2016, only Server 2019.

 

Copper Contributor

Great job, rethinking the update package format and logic.

 

While reading Mike's lines about the inner working, I wonder about the need to place reverse deltas into the small updates.

 

I'd think it might be more efficient to calculate the reverse on the fly while applying a forward delta. If local disk space is not a concern (is it nowadays?), but processor and memory use is, "calculating" the reverse might be as easy as just saving (or keeping) the original file in the component store.

 

However, if the compression algorithm in the update packages does use some XOR-logic or similar, so that reverse + forward deltas do not take much more space than forward deltas only, you have done a really great job. Are there any details about that?

Brass Contributor

I can no longer tell if Server SKU and Desktop SKU Latest Cumulative Updates are still Server and Desktop, or if they are identical packages?

 

catalog.update.microsoft.com 2019-04 1709 LCU for Server and Desktop are the same URL.

http://download.windowsupdate.com/d/msdownload/update/software/updt/2019/03/windows10.0-kb4489890-x6...
http://download.windowsupdate.com/d/msdownload/update/software/updt/2019/03/windows10.0-kb4489890-x6...

 

catalog.update.microsoft.com 2019-05 1903 LCU for Server and Desktop are the same also.

https://www.catalog.update.microsoft.com/Search.aspx?q=2019-05%20x64%201903

 

http://download.windowsupdate.com/c/msdownload/update/software/secu/2019/05/windows10.0-kb4497936-x6...

 

LCU-Same.jpg

 

So are they the same now?

Microsoft

Hello Neo,

Server and Client updates have always been in the same package.  They share a lot of components, so it's easier for admins if we ship them together as one update.

 

thanks,

Mike

Brass Contributor

@Mike Benson 

Ok thanks.

 

Previously - packages downloaded from the update catalog marked as 'Server' weren't able to be installed to a 'Desktop' image using ADK DandISetEnv, and vice-versa. 1703 is when I was building and the packages were still seperate.

 

I just wanted to ask, while I'm here, the latest 1903 SSU KB4500109 has an internal WSUSSCAN.cab - however the manifest is checking signatures from 2004... is this correct? I'm asking because the LCU KB4497936 and KB4505057 are failing to be applied to the Recovery image 'Winre.wim' - I've posted details about it here: https://techcommunity.microsoft.com/t5/WinHEC-Online/ADK-18362-1-DISM-Fails-Offline-Install-for-kb44...

 

The most concerning error message is about Vista, which happens if the Add-Package command is run a second time, after it has failed the first time, with the 80070002 Error.:

E:\WinROG\windows10.0-kb4497936-x64_4ac9328bb1376d2cadb09f56ba95ac9b08b88fba.msu: An error occurred applying the Unattend.xml file from the .msu package.
For more information, review the log file.
 Error: 0x80070002

PS E:\WinROG> DISM /Image:E:\WinROG\mount\RE /Add-Package /PackagePath:"E:\WinROG\windows10.0-kb4497936-x64_4ac9328bb1376d2cadb09f56ba95ac9b08b88fba.msu" Deployment Image Servicing and Management tool Version: 10.0.18362.1
Error 50.
DISM does not support servicing a Windows Vista RTM or earlier operating system. If the operating system is supported check that SSShim.DLL is present.

 

Version history
Last update:
‎Aug 16 2018 10:45 AM
Updated by: