Patches Microsoft

0 views

Skip to first unread message

Theo Pontbriand

unread,

Aug 3, 2024, 6:08:34 PM8/3/24

to avciribil

Every Microsoft product has a lifecycle. The lifecycle begins when a product is released and ends when it's no longer supported. Knowing key dates in this lifecycle helps you make informed decisions about when to upgrade or make other changes to your software. This product is governed by Microsoft's Modern Lifecycle Policy.

Customers can choose Long Term Support (LTS) releases or Standard Term Support (STS) releases. The quality of all releases is the same. The only difference is the length of support. LTS releases get free support and patches for 3 years. STS releases get free support and patches for 18 months.

A new major release of .NET is published every year in November, enabling developers, the community, and businesses to plan their roadmaps. Even numbered releases are LTS releases that get free support and patches for three years.

Customers choosing LTS need the latest patch update installed to qualify for support. If a system is running 6.0 and 6.0.x has been released, 6.0.x needs to be installed as a first step. Once a patch update has been installed, applications begin using the update by default. LTS releases are supported for three years after general availability.

Customers choosing STS need the latest patch update installed to qualify for support. If a system is running 7.0 and 7.0.x has been released, 7.0.x needs to be installed as a first step. Once a patch update has been installed, applications begin using the update by default. STS releases are supported for 18 months after general availability.

Updates are cumulative and released as patches, with each update built upon all of the updates that preceded it. A device needs to install the latest update to remain supported. Updates may include new features, fixes (security and/or non-security), or a combination of both.

Updates are released on the Microsoft "Patch Tuesday" (second Tuesday of each month), however there is no guarantee that there will be a .NET release on any given Patch Tuesday. Patches are announced on the .NET blog. A digest of monthly releases is published to dotnet/announcements. For more details about .NET servicing and patching, see the .NET releases, patches, and support article.

As the end of life nears for a given .NET version, we recommend that you move to a newer .NET version, and reduce/remove your use of the given .NET version. After support ends, we recommend that you uninstall a given .NET version if you are no longer using it, or install the latest patch, and accelerate your plans to remove your use of that .NET version. Your use of out-of-support .NET versions may put your applications, application data, and computing environment at risk. You are strongly recommended to not use out-of-support software.

Starting with .NET Core 3.1, end of life dates align with Microsoft Patch Tuesday (second Tuesday of each month). For example, .NET 6 was originally released on November 8, 2021 and is supported for three years. But the actual end of support day is the closest Patch Tuesday starting that date, which is November 12, 2024.

Support for ASP.NET Core 2.1 on .NET Framework matches the ASP.NET Support policy for other package-based ASP.NET frameworks. The complete list of packages covered by this policy can be seen in ASP.NET Core 2.1 Supported Packages.

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

I've read through a dozen questions and the scores of answers to those questions, and I'm finding a mix of outdated information, bad information or just unrelated options... I suspect this is going to send down a rabbit hole, so I'll try to compartmentalize based on my testing. I never progressed far enough to get close to a resolution.

So, the end-goal -- I have some systems that we want to have extremely limited Internet access: Chrome updates, Microsoft updates, a single specific website (not pertinent to this conversation). I haven't looked at Chrome updates yet. But I've spent a considerable amount of time looking at Microsoft.

The issue likes in the fact that MS needs several domains open, some with wildcards, to access MS Updates. That removes a simple FQDN object (in the destination field) as an option. I tried suggestions for Custom URL Category objects. I tried this (for testing):

I then put that in a policy that BLOCKS my computer from being able to ping that custom url object (ie placing the custom url object in the Service/URL Category tab config). Commit and ... pings still work (allowed by the next policy). I never see it hit this test policy, so something isn't matching. BTW, www.microsoft.com resolves to an akamai address (that never changed during my testing). I then tried to add that akamai FQDN to the custom url object and ... still able to ping.

I did play around with creating a dedicated profile .. allowing the microsoft urls and blocking everything else. That works, but then I lose the ability to use this same definition to track systems going to ms update. It's also odd to have both an allow and a deny in the same policy (ie explicitly allow access to ms update while explicitly denying access to all other websites).

Another thing that crossed my mind - a simple rule that allows any internal to any external with application ms-update. EXCEPT ms-update requires ssl, so because the policies are "ands" in the application field, I've just opened up any https website.

URL categories will never work for limiting ICMP requests. That simply isn't how ICMP functions and there would be no way for your firewall to know that you're attempting to send ICMP requests to "microsoft.com" because your machine will just send the request to the resolved IP address. The only way to accomplish that specific task would be FQDN objects and hoping that the firewall and the client actually keep the resolved address in check.

You can then setup a policy that uses that category and allows app-ids [ ms-update ssl ocsp web-browsing ] with the category applied. This would allow updates to function, but it should prevent normal browsing access.

Then I created a policy allowing the target sources access to that Custom URL Category (with app's ssl, web-browsing, ms-update and ocsp). It appeared to work, but then when I inspected the logs more closely, I saw someone hitting bs.yandex.ru via that new policy. Clearly that is not correct so I reverted.

I'd be interested in seeing the detailed log information that you were seeing in this instance. The firewall will need to allow enough traffic to read the URL, but as soon as it's identified the connection should be reset if the policy is setup properly.

The Windows SDK (10.0.26100) for Windows 11 provides the latest headers, libraries, metadata, and tools for building Windows applications. Use this SDK to build Universal Windows Platform (UWP) and Win32 applications for Windows 11, version 24H2 preview and previous Windows releases.

Windows App SDK
The Windows App SDK provides a unified set of APIs and tools that are decoupled from the OS and released to developers via NuGet packages. These APIs and tools can be used in a consistent way by any desktop app on Windows 11 and downlevel to Windows 10, version 1809.

Installation on Windows 8.1 and earlier operating systems requires an Update for Universal C Runtime in Windows. To install through Windows Update, make sure you install the latest recommended updates and patches from Microsoft Update before you install the Windows SDK.

Windows app samples are now available through GitHub. You can browse the code on GitHub, clone a personal copy of the repository from Git, or download a zipped archive of all the samples. We welcome feedback, so feel free to open an issue within the repository if you have a problem or question. These samples are designed to run on desktop, mobile, and future devices that support the Universal Windows Platform (UWP).

When you use new APIs, consider writing your app to be adaptive so that it runs correctly on the widest array of Windows devices. An adaptive app "lights up" with new features wherever the devices and Windows version supports them, but otherwise offers only the functionality available on the detected platform version. For implementation details, see the Version adaptive code article.

The Windows 10 WinRT API Pack lets you add the latest Windows Runtime APIs support to your .NET Framework 4.5+ and .NET Core 3.0+ libraries and apps. To access the Windows 10 WinRT API Pack, see the Microsoft.Windows.SDK.Contracts nuget package.

The printf family of functions now conforms with the IEEE 754 rounding rules when printing exactly representable floating-point numbers and will honor the rounding mode requested via calls to fesetround. Legacy behavior is available when linking with legacy_stdio_float_rounding.obj.

Windows App Certification Kit. Several new APIs were added to the Supported APIs list in the App Certification Kit and Windows Store. If there are APIs in the supported list that appear greyed out or disabled in Visual Studio, you can make a small change to your source file, to access them. For more details, see this known issue. Find more updates to tests.