Here you can see the enablement package on the file share for the software update deployment package.

Next, I looked for the enablement package cab file inside of the SUDP on the file share. I then had it run and pull down the enablement packages into the software update deployment package. Here is the ADR I created to download the enablement packages. Next, I created an Automatic Deployment Rule (ADR) for the enablement packages, and in turn, created a software update deployment package for the enablement packages. I did this because I already had the Product: Windows 10 enabled. I followed the directions and enabled the Classification: Upgrades in my ConfigMgr lab. There is a lot of information out there about enablement packages, so I’m not going to go into any more detail about it in this post.Ī quick read on the doc site about this particular update allowed me to know which KB I was looking for: KB5003791: Update to Windows 10, version 21H2 by using an enablement package. They are left disabled until you ENABLE them via a PACKAGE, hence, this is how enablement packages were born.

Instead, each month, features are added to Windows in the Cumulative Updates.

This is a fundamental change in how Microsoft does Windows servicing, removing the requirement to do large in-place upgrades. Once you’re on Windows 10 20H1 (2004 or Build 19041), or above, you can upgrade right to 21H2 via the enablement package. You might remember that I mentioned it in December’s Endpoint Management Recap. Recently, I was asked by Dave Stanicki how to deploy Windows 10 21H2 via the enablement package using the ConfigMgr application model.

Win 10 21h2 download