.NET Automatic Updates for Server Operating Systems

Jamshed Damkewala

We’re excited to announce that starting April 2022, we will be making monthly updates for modern .NET (.NET Core) available for server operating systems via Microsoft Update (MU) on an opt-in basis.

If you do not want to have your servers updated automatically for you no action is required. If on the other hand you do want to leverage this for your servers review continue reading below.

There is no change for client operating systems which will continue to receive updates via Automatic Updates, WSUS, and MU Catalog as earlier.

More Information

Updates for supported versions of .NET Core 3.1, .NET 5.0 and .NET 6.0 are currently offered to server operating systems via Windows Server Update Services (WSUS) and Microsoft Update Catalog but not the Automatic Updates (AU) channel. You can now get your server operating system automatically updated by opting in for this behavior.

Opting in

You can opt in for automatic updates by setting one or more of these registry keys on your server.

.NET Version Registry Key Name Value
Allow All .NET Updates [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET] “AllowAUOnServerOS” dword:00000001
Allow .NET 6.0 Updates [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET\6.0] “AllowAUOnServerOS” dword:00000001
Allow .NET 5.0 Updates [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET\5.0] “AllowAUOnServerOS” dword:00000001
Allow .NET 3.1 Updates [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET\3.1] “AllowAUOnServerOS” dword:00000001

Setting the registry key can be achieved by adding the entry (this is an example for enabling 6.0 updates) in a “.reg” file and running this.

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

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

Why are we making this change?

From the first time we started shipping updates for modern .NET via Microsoft Update we have continued to refine this delivery channel including the recent addition of updates for the Hosting Bundle. The vast majority of customers use servers in a managed environment and deployments are handled using a management tool such as Microsoft Intune, Microsoft Endpoint Manager (MEP), System Center Config Manager (SCCM) or Windows Server Update Services (WSUS) and these customers prefer their servers are not directly patched outside of this management environment so they can exercise control over scheduling potential service downtime, reboots, etc. So when we started offering updates via MU we excluded Automatic Updates (AU).

A small number of customers have told us they don’t use a deployment management tool and would like to leverage AU to update their servers similar to clients. We believe the opt in approach we’re rolling out today will allow these customers to get the benefit of AU for their server operating systems without impacting the larger set of customers that do not want this.

In Closing

We’re excited to start delivering updates for modern .NET to server operating systems via Microsoft Update on an opt-in basis and look forward to your feedback on this experience. If you do not want to have your server operating systems updated automatically for you no action is required. If on the other hand you do want to leverage this for your servers review the guidance above.

26 comments

Discussion is closed. Login to edit/delete existing comments.

  • Mystery Man 0

    Hello, Jamshed. Please inspect the table in this post. The backslashes have gone missing.

    • Jamshed DamkewalaMicrosoft employee 0

      Thanks, you’re right, the escape characters were somehow lost during publishing, I fixed it now.

      • Ben Hutchison 0

        No you didn’t. The table shows the key Microsoft.NET, but the example .reg file below it shows the key Microsoft.NET instead.

        • Jamshed DamkewalaMicrosoft employee 0

          I believe its fixed now.

      • Macray Blackhand 0

        You still have inconsistencies all over the place.

        The table shows: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NET\6.0

        The example below the table shows: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET\6.0

        The example from your reply below (4/13/22) shows: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NET\6.0

        This is a Registry change on a server, no minor thing, how in the world can you be so careless??

        This is what I’ve done, but no sign of 6.0.5 being installed. I’ve manually checked for updates as well, when do I start seeing this update?

        Snip of Registry changes made

  • Quintos 0

    Is there any predefined PolicyFiles to download , so that we can import the policy file to server and all we need to do are just edit the value.
    I think it was hard for users to manually edit the Registry key/value.

    • Jamshed DamkewalaMicrosoft employee 0

      You can simply add this to a new text file with .reg extension:

      Windows Registry Editor Version 5.00
      [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET\6.0]
      “AllowAUOnServerOS”=dword:00000001

  • Deepak Gupta 0

    Thank you for this! I manage a small number of servers and WSUS is an overkill. I would have preferred AU to be turned on by default though because as you said, the bigger customers manage them using WSUS or SCCM anyway. But this would be a huge time saver for me.

    Thanks again.

  • Jason Baginski 0

    Glad it’s opt-in. Until .NET updates are seemless like .NET Framework updates were, there’s no way our servers could be automatically updated.

    Here’s what happened yesterday on three different Server 2016 systems:
    Ran windowsdesktop-runtime-6.0.4-win-x64.exe, checked task manager, see the 5 winform apps that were running prior(but of course, they don’t show up on the task bar or system tray). End task on each one of them and started them back up. GitHub #23857
    Ran dotnet-hosting-6.0.4-win.exe, checked our one blazor site. Two of the three servers returned an error. Went into Control Panel, Programs, Uninstall a program, uninstalled the hosting bundle. Reran dotnet-hosting-6.0.4-win.exe, checked sites and everything good. GitHub #28537

    AKA, if either of those ran automatically, we’d be screwed.

  • Martin Horvath 0

    Why aren’t .NET and .NET Core updates available in MSRC when they are classified as security updates?

    • Jamshed DamkewalaMicrosoft employee 0

      Not sure what you mean by available in MSRC, can you elaborate?

      • Martin Horvath 0

        MSRC (Microsoft Security Response Center)
        https://msrc.microsoft.com/update-guide

        It’s where all Microsoft products lists their security related updates including CVE details.
        All except for .NET Core 3/5/6.
        Their API is also very much used to collect information used for example patch Tuesday.

        As an enterprise software provider with many large customers, it’s very cumbersome to handle .NET updates in “quirky special ways”.
        Please handle all the patching logic including how you publish information, in a standardized way, like the rest of Microsofts products (tip: look how OS updates are handled or even .NET framework).

        After that, then by all means, add special opt-in and opt-out features.

        • Jamshed DamkewalaMicrosoft employee 0

          Updates for .NET are listed on the MSRC site. Set the Product Family filter to Developer Tools, scroll to the bottom. In a pinch look for the CVE-2022-23267. You will see line items for .NET Core 3.1, .NET 5.0 and .NET 6.0.

  • George Stamatopoulos 0

    Hang on, hang on.
    BEFORE posting anything, can you at least check your facts????

    Firstly, WHICH registry path is it?
    Are you saying that you didn’t even REVIEW your post before posting to even notice that the \ were missing???
    Have you SEEN how many idiots on IT forums have directly pasted your initial post to their forums without the \ and not even noticing? They obviously don’t know ANYTHING about registry hives to not even notice that there were no \ to define the path.

    So what is it??? [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NET] or [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NET\6.0] ????

    I have checked 2 servers running Windows Server 2012 R2 and Windows Server 2016, and my Windows 10 desktop, and NONE of them have such a registry path!

    I CAN find [Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework] !

    So you can PLEASE actually include some FACTS with your post?
    What operating system are you talking about?
    What software needs to be installed for this to work?
    And for the sake of ALL of our sanity, what the HELL is the ACTUAL registry path?????

    I want to know so that I can create an enforced GPO to DISABLE this god awful and extremely STUPID decision from ever being implemented on any of my servers!

    Has anyone at Microsoft heard of change control? Sure, let’s configure our servers to auto update without letting anyone know what they have done, when they did it, what could POSSIBLY go wrong?
    Oh, and I suppose Microsoft is still using Solarwinds technology, because god forbid we learn anything at all about how stupid and dangerous supply chain vulnerabilities are! Let’s just let servers do whatever they want, who needs any IT involvement?

    No need to add, I am VERY disappointed in this decision, but it has helped to show who in the IT field is just a stupid copy/paste artist who doesn’t even READ what they are posting or even notice that it doesn’t make ANY sense at all.
    sorry for the rant… can’t believe anyone at Microsoft could post something like this and think it’s a brilliant idea…
    Why don’t you go talk to the Microsoft Exchange development team who found out weeks later that Microsoft forced a .net framework update that immediately broke all of Exchange’s powershell commands… Looking forward to the next surprises created by one arm of a vendor’s company that has a critical impact on another arm of the same vendor’s company.

    • Jason Baginski 0

      I’m not sure how you read this post, but I read it as “if you wanted to receive .NET automatic updates, set or create these registry entries”. The default is to not serve using AU, so no change necessary if you want things to operate as they have(“opt-in”).

      • Jamshed DamkewalaMicrosoft employee 0

        Correct. If you want everything to remain as-is (like it was before April 2022), no further action is required.

    • Jorge Morales Vidal 0

      Please read again, this post is about an opt-in feature, through Window Registry keys, to enable automatic updates for .NET Core 3.1, .NET 5 and .NET 6. It is not turned on by default because, as the section “Why are we making this change?” says, most business users don’t use Automatic Updates (AU), as they rely on other means to deliver updates to their servers. If you don’t do anything, the updates in your servers will continue to be delivered as they are today.

      • Jamshed DamkewalaMicrosoft employee 0

        Correct.

    • Jamshed DamkewalaMicrosoft employee 0

      Like I said in the post if you do not want your servers updated automatically no action needs to be taken, that is the default state. You can set the reg keys only if you want to opt-in to this new behavior.

  • Colin Groothius 0

    Thanks for the article. I’m left with a doubt. Are these security updates or are they functional improvements to the frameworks or both? I would auto approve security updates but would require a controlled rollout of any functional changes.

    Thanks
    Colin

  • Chance Rollins 0

    At the time of this post, there is still a discrepancy between the table and the registry file. To clarify for everyone, there is a separate sub key under Microsoft called “.NET”. The sub key Microsoft.NET is incorrect.

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NET]
    “AllowAUOnServerOS”=dword:00000001

    • Jamshed DamkewalaMicrosoft employee 0

      This is fixed now.

  • Dean Jackson 0

    Thank you for this feature, I deliver .NET apps to small companies who have in-house Windows Server without anything like WSUS, and this will help.
    Not directly related, but a question on something similar:
    for the .Net framework cumulative updates, they frequently get released as “Preview” (and they’re listed as Preview in Windows updates for Windows 10/11), and yet Windows Update auto-installs them. If it’s truly a preview and a there will be a later update coming that’s the real version, Windows Update should not auto-install it. If it’s the real version and no later one is coming, I don’t think it should be called a Preview.
    Can you please explain this?

  • Trendy Owner 0

    On Febrary 2022, I updated a cumulative update for .net framework for windows 10,
    then restart the windows, it stops at the Lenovo logo page. Very helpless.
    And luckily, I can perform a restore. Thanks for Microsoft update provide a restore point by its ownself
    automatically.
    From then on, every month, when the cumulative update for .net framework for windows 10 is available and
    pending to install, I am very afraid that my system may not perform the update successfully again and
    then staying on the Lenovo logo loading screen.
    I am not sure whether my hardwares are compatible or imcomatible with the new update.

Feedback usabilla icon