Microsoft To Split .NET Patch Rollouts from Windows
An upcoming change to Microsoft's .NET Framework patch delivery model could take effect as early as next month.
Under the new approach, which Microsoft announced this week, .NET Framework patches will arrive separately from Windows patches on "update Tuesdays" (typically the second Tuesday of each month). Currently, Microsoft releases its .NET Framework patches with Windows patches.
The patches will be "cumulative updates," meaning that they contain past updates, as well as new ones. Microsoft won't offer separate security and quality cumulative updates with the new separate .NET Framework patch scheme, although it does offer that approach with Windows 10 patches.
Microsoft didn't specify an exact date when this new update policy of separating .NET Framework patches from Windows patches would take effect, but it did indicate that it'll start when the "Windows 10 October 2018 Update" gets released. That's likely a reference to the next major feature update to Windows 10. Microsoft delivers major feature updates to Windows 10 twice per year, in the spring and in the fall, and they typically arrive on update Tuesdays, so it's likely that the new policy will kick off on Oct. 9, although Microsoft didn't specify that date.
Microsoft made this policy change to give organizations greater patching flexibility.
"This new approach will give you more flexibility on installing .NET Framework updates," the announcement indicated, adding that it can help IT pros "more selectively test line of business applications before broadly deploying."
However, the new policy won't add greater flexibility for organizations using older Windows versions. It just takes effect for organizations using the coming Windows 10 October 2018 Update (version 1809) and newer versions, as well as the coming Windows Server 2019 product.
Organizations using Windows 10 version 1803 and older will still get the same combined .NET Framework and Windows patches each month. Microsoft didn't describe what happens to older Windows Server versions, but likely the patches that arrive will be the combined ones. Windows 7 and Windows 8.1 users will still get "multiple .NET Framework updates, per Windows version," Microsoft's announcement indicated.
This approach where Windows and .NET Framework patches are separate will be mostly noticeable by organizations that use patch management systems to control when updates get installed on devices. Microsoft specifically mentioned that Windows Server Update Services users will see the separate .NET Framework patches. Windows 10 users that use the Windows Update service to install updates automatically likely won't notice the change, Microsoft's announcement indicated.
IT pros that access the Microsoft Update Catalog to download patches will be able to find these separate .NET Framework patches. They'll be listed by their Knowledge Base (KB) article numbers, Microsoft's announcement explained.
Reboots are necessary in most cases after installing .NET Framework cumulative updates. However, the announcement suggested that the new approach with separate patches wouldn't necessarily result in more system reboots for organizations, depending on IT pro actions. Here's how Microsoft expressed that point:
Windows Update will orchestrate making sure updates that ship at the same time are processed together and only require a single reboot. Guidance to WSUS/IT Admins is to continue to ensure that updates are grouped and deployed together to avoid any potential additional reboots.
The new policy change likely will be welcomed by IT pros for the reasons that Microsoft described. It's the latest change of many, adding to Microsoft's most recent explanation of its Windows 10 patching process back in August.
The separated .NET Framework patches also might help organizations when Microsoft releases flawed patches. For instance, some of Microsoft's flawed July 10 patches were Windows 10 updates, but some were specifically .NET Framework patches, which got fixed in August.
Kurt Mackie is senior news producer for the 1105 Enterprise Computing Group.