R.I.P. Express Updates - November 13, 2018. Placed on life support to be turned off at the end of support for 1803.

TL;DR: You won’t be seeing express updates or delta updates for 1809. Celebrate and rejoice.

The release of 1809 Microsoft has brought a change to how they package and deploy the monthly quality updates (cumulative updates) for Windows 10 (versions 1809 and later only). This change will reduce the file size of the current cumulative update process significantly saving you a bunch of network bandwidth. It also does away with the need for the Express update system - which was a way for a system to only download the items that it needed to patch itself rather than the whole kit and caboodle that were the cumulative updates.

Great in theory. AWFUL in practice.

For those of you who didn’t enable Express updates or didn’t read any of the experiences of those who did - here’s a brief rundown:

Seriously though - the concept was great. Reduction in bandwidth makes any network engineer happy - especially when that data is traversing the magical WAN. The client would only download the changes that it needed from the package rather than downloading the whole cumulative update. However, what you gain back in bandwidth you lose in storage. Cumulative updates (the ones that contain all the files necessary to get you from RTM to Current regardless of which CU you currently have installed) tend to be in the 1 - 1.5GB range depending on how long the OS has been supported and how many quality updates have been required for the OS. That’s pretty large in and of itself. But then you have these Baseless PSF files that come with EACH Express update… 4-5GB. Absolute unit.

You can imagine some storage engineers were not very happy with the ConfigMgr/WSUS admins when that switch got enabled. So everyone was told “disable express updates unless you’ve got a ton of storage space” and then everyone proceeded to not care about Express updates.

Except Microsoft.

Death To Express Updates

Here’s the snoozer of a white paper. Feel free to try and read it if you want - but I am going to try to the best of my ability dissect it in this post. Here’s the shortened version:

Get current version of file to be updated. Take any locally stored reverse differential (VCurrent -> VRTM). Apply the reverse differential and the forward differential (VRTM -> VTarget) in a single transaction (to make sure that the file doesn’t get stuck as the older version). Store the new reverse differential (VTarget -> VRTM) on the machine. Cleanup any reverse differentials before VCurrent.

Here we go with the extended explanation.

We’ll ignore the “delta” updates for now and focus on the full cumulative updates and the express updates before exploring the new cumulative updates. Delta updates are going away starting in February for all branches so if you use them currently, be prepared.

Full Cumulative Updates (or LCU Update)

These updates contain all of the binaries that have changed since this feature update (e.g. 1803) was released. So the September cumulative update also contains all of the binary changes for the August update. You can envision it as something like this:

Obviously many more files and more months (1803 has been out for quite some time now), but that is essentially the idea. Each of the binaries is compressed to save space, but eventually these updates hover at around 1.2 GB each. Not the most efficient use of space but it gets the job done with one update to rule them all.

Express Updates

Express updates have a super small CAB file (like less than 20MB). This is what is transferred up front to the workstation to deploy the update. From there the workstation does some back and forth negotiation with the update server (WSUS or Windows Update) to determine which parts of the updates are required. The update server sends the appropriate differential data to the workstation and updates the files. This ends up transferring about 100-200 MB of data to the workstation.

On the update server side there is a rather large file (typically 5-7 GB in size) that contains differentials for up to five previous update revisions and the RTM version of the file. I described this earlier in the post, but this is the reason for the bloat - lots of forward binary differentials. Another downside being that these express updates could only be applied to N-5 or RTM (so if you’re more then 5 months behind on your updates, no express updates for you).

The New Cumulative Updates

The new hotness.

Seriously - Microsoft is estimating that these updates will be just slightly larger than the express update data transfer. So they should be around 100-300 MB each. And they’re cumulative. You might be asking yourself - “How in the hell can they fit ALL of that update in such a tiny package?” I was confused too - here’s how it works.

Each cumulative update contains the data to take you from RTM to the Target version of the update. The cumulative update ALSO contains the reverse differentials to take you from Target version of the update back to RTM. So there are only TWO differentials for all files changed since RTM stored in the update (hence the significant space savings). In the case that a new file is created, a compressed version of it is stored as a “null differential” (meaning that there is no previous version of the file to be merged with).

“But wait!” you say, “If the update only contains the forward and reverse differentials for that release - how can it be cumulative?”

Sales guy from above lied to you. Super surprising that someone in sales would lie to you, right?

As part of the update process, Microsoft is borrowing some additional storage space from your machine. Those reverse differentials that are included with the update are stored on your machine in the WinSxS store. So the trick is, your machine ALWAYS knows how to get back to RTM from the currently installed version. It might be easier to see this in a flowchart.

So we look to the workstation to get us back to RTM but at the same time combine that with the data from the update to get us from RTM to the target version. In the case a new file is created (i.e. it did not exist when RTM was released) we just hydrate the compressed version of that file that is stored in the update package.

At the end of the process the second to last applied cumulative update’s reverse differentials are removed from the machine (so if you are updating monthly and you are applying January’s cumulative update, November’s reverse differentials will be removed). This means that you can uninstall January’s cumulative update if there are issues and it will revert you back to December’s cumulative update - but you can’t go back to November.

“But wait!” you say again as the most keen observer, “If we don’t have a full copy of the file anywhere in this process (except with the null differentials of course) what happens when I have a corrupt copy of a file?”

We’re going back to the Baseless PSF from earlier. Only this time it’s stored on Windows Update.

When corruption is detected it adds the file to a list of corrupted files and the update goes as far as it can before exiting out with a failure. The machine then goes to work trying to repair the files that are corrupted by getting them from the PSF file stored in Windows Updates and then presto chango, the next time the update is applied it should succeed.

The biggest concern I have with this is organizations that have blocked Windows Update as a source -I’ve requested more information from Microsoft on how these environments may be affected.

UPDATE: For those users who have blocked Windows Update as a source in their environment, your option is to configure a Windows Repair Source as detailed in this Microsoft Docs article here.

What do I need to know?

To summarize - you don’t really need to know anything other than the updates are going to be much smaller going forward. Don’t look for express updates or delta updates for 1809 - they don’t exist.

I’ll update this post as soon as I get more information about the potential issues with blocking Windows Update in an environment.

Update: See above for the solution for environments without access to Windows Update. I’ll create a post in the future on how to set this up.

I think that about wraps this up though - if you have any questions please don’t hesitate to post a comment below or hit me up via the contact link above. Happy Admining!