My take on Windows Autopatch

Windows patching is incredibly important to the well-being of an organization’s network and the endpoints themselves. And it is also undeniably the most stressed monthly activity in the life of an IT pro.

It has been many years since Microsoft moved away from its Fixed Lifecycle policy for its Windows OS to what it now follows as the Modern Lifecycle policy starting with Windows 10. As the result, we saw the Windows patching shifting from the old on-premise way of selective patching via WSUS to the new cloud-powered ring-based patching approach with WUfB.

However, from my experience of working in T&T projects, I still see organizations hesitant to make the final leap to a cloud-only world, sticking with co-management just to have the assurance of the ability to continue leveraging their WSUS infrastructure with SCCM to continue the Windows patching activity.

The reasons can be varied – from the fear of losing control of patching activity to struggling to cope with the ring-based approach to reporting concerns and so on.

The apparent outcome of this is why we still get to see that critical Windows updates take much longer than usual time to propagate through an environment, leaving the organization vulnerable to security exploits.

And I think this is where Microsoft aims to give a push with their latest service offering – the Windows Autopatch.

Getting to know Windows Autopatch

With the Windows Autopatch service, Microsoft aims to take over the patching activity from the organization IT (as on-behalf of the organization) and implement the best practice in an automated way (that is managed by Microsoft in the backend) to simplify the end-to-end process of deploying patches to the managed Windows endpoints of the environment.

As the official MS doc states, the service helps to free up IT Pros by taking over several areas of management as below.

Management area	Service level objective
Windows quality updates	Windows Autopatch aims to keep at least 95% of eligible devices on the latest Windows quality update 21 days after release.
Windows feature updates	Windows Autopatch aims to keep at least 99% of eligible devices on a supported version of Windows so that they can continue receiving Windows feature updates.
Microsoft 365 Apps for enterprise	Windows Autopatch aims to keep at least 90% of eligible devices on a supported version of the Monthly Enterprise Channel (MEC).

The General Availability channel is the source for Windows updates through Windows Autopatch. It should also be noted Windows Autopatch will also specifically patch drivers and firmware that are only published to Windows Update as automatic. For Microsoft 365 Apps for enterprise, it uses the Monthly Enterprise channel to balance stability and feature availability.

Further, Windows Autopatch progressive deployment is not used for either Teams or Edge updates, nor do the pause or rollback actions apply to either application. This is because these products do not make use of the ring-based deployment approach and instead, follow a different cadence for update rollout.

It is to be kept in mind that not every tenant is eligible for Windows Autopatch service as it comes at a premium and there are some pre-requisites that the tenant must meet to make use of this new service.

Windows Autopatch pre-requisites

The official MS doc for Windows Autopatch outlines the requirements that must be met to assure success with the Windows Autopatch service, of which I am highlighting the important and notable ones below.

Windows Autopatch Licensing requirements:

The following licenses entitle you to use the Windows Autopatch service

• Windows 10/11 Enterprise E3 [For EMS E3/E5 customers]
• Windows 10/11 Enterprise E5 [For EMS E3/E5 customers]
• Windows 10/11 Enterprise VDA.

Thus if you are an M365 E3/E5 customer, you are already covered. But EMS E3/E5 customers will need to get either of the above as per the requirement to use the Windows Autopatch service.

Further, for customers with Intune standalone licensing (no EMS subscription), it is required to get the Azure AD premium license along with Windows 10/11 Enterprise E3/E5 license to make use of the service.

Windows Autopatch supported Operating Systems:

• Windows 10/11 Pro
• Windows 10/11 Enterprise
• Windows 10/11 Pro for Workstations

Note that only 64-bit versions of the above OS SKUs are supported.

Windows Autopatch supported Device management scenarios:

• Devices must be corporate-owned – Windows Autopatch doesn’t support BYOD devices.
• Devices must be managed by either Intune or Configuration Manager Co-management.
• Devices must be in communication with Microsoft Intune in the last 28 days.
• Devices must be connected to the Internet.
• Devices must have a Serial number, Model, and Manufacturer.

It is to be noted that devices managed purely with SCCM are not supported.

You will need to have co-management configured with the following workloads set to Pilot Intune or Intune.

• Windows Update workload
• Device configuration workload
• Office Click-to-Run apps workload

Windows Autopatch – How it is different from the Intune – WUfB combination?

Well, as the matter of fact, Windows Autopatch makes use of already existing services like the WUfB, WUfB-DS, and Microsoft Intune (obvious for the management of the endpoints and the Windows Update ring creation and all other policy creation stuff) for its working.

Sprinkle some automation on top of it in the sense of management (group creation and management, policy creation and management, and so on), and the end result that you get is what Windows Autopatch is.

Citing example using my tenant, you will see that once you enroll your tenant with the Autopatch service, some automation from the backend will happen to create the below things in your tenant.

You will have four deployment rings created as shown in the below snap which the Autopatch service will be utilizing for its patching activity and the device ratio between these four rings will be maintained at 90% for Broad, 9% for Fast, 1% for First with only a small number of devices for the Test ring.

The listed ratios will be managed automatically. However, you can choose to move devices manually if you so choose.

Similarly, you will see five Feature updates for Windows 10 and later policies being created for use by the Windows Autopatch service.

And for assignment purposes, you will see a bunch of groups being created in Azure AD to support Windows Autopatch activity.

But then, in the ideal case, you don’t need to manually add devices to these groups. All you need to do is register the device to the Windows Autopatch service by adding it to a single group. If everything is good, the Windows Autopatch service will take care of placing the device in the applicable Ring based on the automation logic as programmed in the backend.

So what’s the difference then between patching with Windows Autopatch vis-a-vis patching utilizing WUfB (or WUfB-DS for the instance?

To answer that, let’s see what Microsoft says about it.

What Microsoft is stating is that you can either

• have your IT continue using the tools and processes that you’re accustomed to (can be on-prem via WSUS or cloud-driven via WUfB and WUfB-DS) for managing and deploying updates to the managed Windows endpoints of the environment, or

• sit back and relax, free your IT from the chores of update management activities and let Microsoft do it for your organization on-behalf via the Windows Autopatch service.

Which in simple terms relates to a Customer managed vis-a-vis a Microsoft-managed approach.

If you are an existing EMS customer, should you upgrade to M365 licensing just to take benefit of Windows Autopatch?

This section expresses my take and initial impression of working through the Windows Autopatch.

To patch managed Windows devices of the environment in an Intune-controlled world, all that was required from the IT end was to (a) plan and create the Windows Update deployment rings, (b) prepare the assignment groups, and finally (c) add the identified devices to their respective assignment groups to start receiving updates from WUfB.

Having problems with a particular update that is getting currently being deployed through a ring. You can (a) Pause the ring and even do (b) Rollbacks if supported by your ring configuration. Once the issue has been mitigated, you can (c) Resume the ring.

Need to expedite a feature update (for example, move a few devices to Windows 11) or an out-of-band quality update to your managed endpoints?

Microsoft introduced the WUfB-DS for this exact purpose and to make use of it, all that is required from IT is to create the corresponding Feature update or Quality update policy and target it to the required assignment group. And yes, there are other pre-requisite configuration items that are required to be met at the device level for the above to work.

Windows Autopatch basically takes over all such activities via automation, that was otherwise expected to be performed by IT. And that is what the whole story is about!

As such,

• if you have not moved to the modern way of patching Windows 10/11 endpoints with Intune in your environment, or
• if you are already using Intune and Windows update rings for patching Windows 10/11 endpoints but struggling to cope up, and
• if you meet the pre-requisites to make use of this new service from Microsoft,

You will definitely find this new service from Microsoft a lifesaver for your IT.

But if you are one of those unlucky ones without the Windows 10/11 E3/E5 licensing, should you care to invest to get hands-on with this service only?

For me, there isn’t anything extra that the Windows Autopatch service will be doing that cannot be achieved manually otherwise. But does it makes the life of IT pros like us easy, definitely yes!

That’s all for today.