12/09/2020: this post was updated to clarify that Client operating systems will get .NET Core updates via Automatic Updates, while Server operating systems will get .NET Core updates via WSUS and MU Catalog.

12/14/2021: this post was updated to reflect Hosting Bundle updates are also available on Microsoft Update now.

Starting in December 2020, we will be delivering .NET Core updates on Windows via Microsoft Update. We have received many requests for this, particularly from organizations that acquire and manage all of their Microsoft-related updates via Microsoft (or Windows) Update. This change will enable organizations to manage .NET Framework and .NET Core updates in the same way. If you don’t want to use Microsoft Update to update .NET on your machines, you don’t have to, and can continue using one of the existing options.

Applications using the Framework Dependent Deployment model will benefit from .NET Core updates delivered by Microsoft update. There is no change to apps that use the Self-Contained Deployment model, these apps are still responsible for keeping the runtime updated.

 

Background

When updates for the product are available on Windows Update, the job of an enterprise IT administrator tasked with ensuring security patches are installed in a timely manner is mostly fully automated.

Until now, we did not deliver .NET Core updates automatically via Microsoft Update. This was because of earlier customer feedback around potentially breaking apps. This feedback was centered around .NET Framework major/minor feature updates (for example going from 4.5 to 4.8) which installed in-place rather than side-by-side with earlier versions.

In the .NET Core case, major/minor (feature) updates always install side-by-side. Only monthly servicing updates install in-place and replace previous servicing updates. We are delivering .NET Core servicing updates monthly without issues. .NET Core servicing updates have evolved from fully side-by-side installs to patches that replace earlier versions with “runtime roll-forward”, so once an update is deployed apps can use the latest (serviced) runtime version automatically.

 

The Details

Updates on Microsoft Update (MU), not Windows Update (WU)

.NET Core is an independent product, unlike the .NET Framework which is a component of the Windows operating system.  Windows Update is reserved for updates to the OS, while Microsoft Update is for other products like .NET Core, Visual Studio, and so on. Therefore, updates to .NET Core will always be distinct from .NET Framework and will be available on Microsoft Update (MU) and not Windows Update (WU).

What if I don’t want .NET Core updates delivered by MU?

If you’ve opted in for receiving updates via Microsoft Update but you don’t want updates for .NET Core delivered automatically by Microsoft Update, at this time you can block these updates by following the guidance in the Blocking .NET Core update delivery from Microsoft Update section later in this post.

Runtime Roll-Forward

.NET Core applications by default run on the latest servicing update. That means your .NET Core applications will run on the latest servicing version of .NET Core 3.1, for example, after it has been installed on your machine by Microsoft Update. The same is true if you are not using Microsoft Update, however, you need to install that update manually.

In-place Install for Monthly Servicing Updates

Prior to .NET Core 3.0, each update for .NET Core installed side by side with previous updates. This resulted in computers having many versions of .NET Core updates installed even though only the latest one was being used (the previous section on Runtime Roll-Forward covered this), but these computers still incurred the disk footprint due to multiple installations. Starting with .NET Core 3.0, patches for the .NET Core Runtime and SDK are installed as in-place updates. That is, installing a new patch version (for example, 3.1.10) removes previous patch versions (3.1.0 through 3.1.9). Microsoft Update will only maintain one update within each SDK feature band.

Note: major/minor (feature) updates for .NET Core always install side by side with previous versions.

What will be delivered from MU?

Updates with both security and non-security fixes for all supported versions of .NET Core (currently .NET Core 2.1, .NET Core 3.1 and .NET 5.0) will be available on MU. These updates will target the .NET Core SDK, .NET Core Runtime, ASP.NET Core Runtime, and the .NET Core Desktop Runtime installers deployed either independently or as part of another application. .NET Core runtime binaries included with an application built as a self-contained deployment will not be updated by MU.

Updates for .NET Core have always included both security and non-security fixes in a single package. No changes are being made around this model.

Note: updates for the Hosting Bundle won’t be available on MU initially while we work through a couple of issues. These updates will need to be downloaded and deployed from our download website. We will update this post once the issue is corrected and we are ready to start delivering updates for the hosting bundle via MU.

The .NET Core Runtime and ASP.NET Core Runtime installers within the hosting bundle will be updatable from MU. The third component not independently serviced outside the hosting bundle – ASP.NET Core Module (ANCM) does not need frequent servicing, and we plan to enable MU updates for the hosting bundle before we need to service this.

Starting Dec 14, 2021 updates for all bundles for all supported versions of .NET Core are available on MU. This includes the hosting bundle which was not available on MU initially.

Reboots

.NET Core servicing updates replace previous updates for the same major/minor version. If files being replaced are in use, the installer bundle will signal the need for a reboot to Windows by a 3010 return code. This is a request for a reboot and can be pended/deferred if needed, though in that case the older version being updated will only be removed when the computer is rebooted.

If multiple updates are being installed from Windows Update or Microsoft Update then Windows will automatically install multiple updates at once and then reboot just once.

The .NET Core hosting bundle will restart IIS services after updating the ASP.NET Core Module (ANCM) component.

 

Enabling .NET Core Updates

When we say updates will be delivered via MU, this is an over-simplification because we’re really referring to a couple of different things. Microsoft Update has a few distinct distribution channels and the .NET Core updates will be available on all of them. Amongst these distribution channels, Automatic Updates is relevant to end users and consumers, while Windows Server Update Services (WSUS) and the MU Catalog are relevant to IT administrators.

 

For consumers/end-users and computers that connect directly to Microsoft Update

Automatic Updates

This is the experience most end users are familiar with. After you opt-in, updates are typically installed automatically, at night, with no action required.

You must opt-in to get updates from Microsoft Update by enabling “Receive updates for other Microsoft products when you update Windows” (you can find this under Settings > Update & Security > Windows Update > Advanced options).

These updates will be installed via Microsoft Update to computers with a Client operating system that have a supported major/minor version such as .NET Core 2.1, 3.1 or .NET 5.0 already installed. .NET Core updates will not be offered via Automatic Updates (AU) to unsupported versions of .NET Core, including nightly builds, or to Server operating systems. Computers with Server operating systems can receive .NET Core updates if they’re managed by Windows Server Update Services (WSUS) or System Center Configuration Manager (SCCM). See the following sections for details on how to get updates in an environment managed using WSUS or SCCM.

Alternatively, you can go to your Windows Update Settings and click on Check for updates.

If updates are available, you’ll see a list of these updates and can choose to install these immediately without waiting for automatic overnight install.

 

For IT administrators

Windows Server Update Services (WSUS)

This distribution channel is mostly relevant to IT administrators. An IT administrator can configure computers across the enterprise to connect to an internal WSUS server instead of connecting directly to MU over the internet. This is more efficient, since the payload is downloaded just once over the internet and served locally to internal computers. It also allows finer control over which updates are deployed to which computers and when.

Configuring Products for synchronization in Windows Server Update Services (WSUS)

Products – Updates for .NET Core will be published under .NET Core 2.1, .NET Core 3.1, and .NET 5.0 products in WSUS. These products are nested under the Developer Tools, Runtimes, and Redistributables top level product.

Classifications – Updates for .NET Core will be published under one of the following classifications based on the contents/payload: Security Updates, Critical Updates, or Updates.

You need to select these products and classifications for synchronizing in your WSUS configuration the first time. For more information about this, see this article on Products to Synchronize in WSUS.

.NET Core updates for both Client and Server operating systems will be available via WSUS.

Synchronizing Updates

Updates need to be synchronized with either Microsoft Update or an upstream WSUS server. Synchronization can be initiated either automatically on a pre-defined schedule, or manually. For more information about this, see this article on Synchronizing Updates in WSUS.

Approving Updates

Updates need to be approved before they’re deployed to client computers. This approval may either be manual, or rules can be configured for automatic approval for selected product and classification. For more information about this, see this article on Approving Updates.

 

Using System Center Config Manager/Endpoint Config Manager

System Center Config Manager (SCCM) and Endpoint Config Manager (MECM) help manage PCs and servers with more flexibility than is possible using WSUS. Similar to WSUS, you can set up synchronization and automatic approval of updates for deployment to target machines using SCCM or MECM. If you’re using one of these management tools to manage your environment, you should refer to this documentation on Software Update management for further details.

Blocking .NET Core update delivery from Microsoft Update

Most users we asked told us they want their computers to be kept up to date and secure automatically for them, but we realize some customers may not want this. If you prefer not to have your .NET Core installation automatically updated, there are a few different options.

For computers that get updates from WSUS, or SCCM (Managed Deployment Environment)

For computers in a managed environment that get their updates from a WSUS server or are using SCCM, you need to explicitly approve the Product entries for .NET Core 2.1, .NET Core 3.1, and .NET 5.0 before you start receiving updates.

If you’ve already approved these products for updates and have a need to block the automatic deployment of updates, do one of the following:

1. Un-approve the products you previously approved in the WSUS admin console.
2. Set one or more of these blocker registry keys to prevent the corresponding updates from being deployed.

 

.NET Core Version	Registry Key	Name	Value
Block all .NET Core updates	[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET]	“BlockMU”	dword:00000001
Block .NET 6.0 updates	[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET\6.0]	“BlockMU”	dword:00000001
Block .NET 5.0 updates	[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET\5.0]	“BlockMU”	dword:00000001
Block Core 3.1 updates	[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET\3.1]	“BlockMU”	dword:00000001
Block Core 2.1 updates	[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET\2.1]	“BlockMU”	dword:00000001

 

Setting the registry key can be achieved by adding one or more entries (this is an example for blocking 6.0 updates) in a “.reg” file and running this.

Note: the above registry keys are not exclusive to computers in a managed environment, they can be used on any computer to block the delivery of .NET Core updates by Microsoft Update.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET\6.0] "BlockMU"=dword:00000001

Alternatively, you can use Group Policy to deploy the registry key to many computers at once.

 

For computers that directly connect to MU for updates (Unmanaged Deployment Environment)

For end users and other computers that connect directly to Microsoft Update (don’t use WSUS or SCCM), we recommend you use Microsoft Update to keep your .NET Core installations up to date and secure automatically. In some cases, you may want to manage this yourself – for example, if you are an enterprise that doesn’t use WSUS or SCCM and instead directly connects its computers to Microsoft Update. In this case you can set the blocker registry key(s) described in the previous section.

Alternatively, you can download/save these files and run them (remember to save these with a .reg extension so they open using regedit):

.NET Core Version

Block all .NET Core updates delivered by MU

Block .NET 5.0 updates delivered by MU

Block .NET Core 3.1 updates delivered by MU

Block .NET Core 2.1 updates delivered by MU

 

 

In Closing

We’re excited to start delivering updates for .NET Core via Microsoft Update and look forward to your feedback on this experience. If you are an IT administrator responsible for managing deployment across your enterprise, review the above section For IT administrators so, you are ready on day one.