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.

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

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!

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.

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?

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?

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

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.

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?

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.

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.

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.

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

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.

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.

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?

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.

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