I had the pleasure to implement Windows Autopatch at a customer of mine and I want to share my notes from the field. This customer uses around 250 laptop laptops and they wanted to deploy autopatch to have less management overhead on updates for their Windows-based laptops. I really like this customer because there are really progressive and always want to implement new features.

We implemented this a couple of weeks ago and I’m sharing the first result with you.

Onboarding Windows Autopatch

Firstly, we needed to onboard the devices to Windows Autopatch. This was fairly easy. When you enable Windows Autopatch from this page:

A number of groups, configuration profiles, update rings, and feature update rings are created by the Windows Autopatch service.

Groups:

The configuration profiles:

Update rings:

Feature update rings:

After that, we needed to onboard our devices to Windows Autopilot. I added the dynamic device groups from the Windows Autopilot profiles:

As a result, almost all devices were ready to be onboarded:

I also had a couple of devices that were not ready:

This device particular was not active. You need to keep an eye on this section to make sure all devices are onboarded. Only 7 out of 250-ish devices were not ready. A good score I believe.

I also had a couple of devices that were not able to register. This was because these devices are part of my autopilot groups with their “Azure AD Serial Number account”. That is created when you upload the hardware hash of a device. This is expected behavior since these devices are not enrolled in Intune.

Furthermore, this is the reason that the device is not onboarded:

After the onboarding process, a release schedule option becomes available in the Intune portal:

This release schedule displays all update release information for all groups. In addition, if something goes wrong in your update deployment. You can choose to pause the updates from here.

Windows Autopatch – Quality Updates Reports

Let’s go to the reporting section. This is configured automatically by Windows Autopatch. Firstly, we look at the Windows Quality updates reporting. After that, we take a look at the feature updates.

When you go to the reporting section within Intune you see that the Windows Autopatch/Windows Quality updates are available. You get this nice summary about the updates status of your devices. Mine has 217 devices enrolled and it shows whether it is up to date.

After that, you can drill down into these reports. You have these available:

– All devices report
– Eligible devices report – historical
– All devices report – historical
– Ineligible devices report – historical

I’ll go through them 1 by 1.

Firstly, the “all devices” report:

It shows the ring, update status, update sub status, os version and os revision. This gives an overview of your patching status:

You can also see why a device is not up to date with these 2 examples:

Next is the eligible devices report. This report shows the devices that meet the prerequisites. This shows that Windows Autopatch has updated 96.84% of my devices. Nice right?

Next the all devices report – historical. This shows that only 56.28% of my devices are up to date. What’s up with that? To discover that, we need to take a look at the ineligible devices in the next report.

This is the ineligible devices report:

44% of these devices have this status because of “insufficient usage”. I thought that was odd. They had:

– Enough storage available
– The last check-in was “yesterday”
– are compliant

Weird right?
After that, I looked at the eligible requirements (source) from Windows Autopatch. I suspect that these devices are not fulfilling the first requirement. (This is a guess, so don’t take me up on it)

I wouldn’t call it insufficient usage but would name it insufficient activity but that is my personal opinion.

Windows Autopatch – Feature Update Reports

Next up are the Feature Update reports. This is not available through a separate button like the quality updates. It’s available through the reporting section of Intune.

This shows the summary, but it doesn’t state Windows Feature updates specifically. That is be a bit confusing.

These are the reports available:

For all the reports I will show the broad ring because that ring has the most devices in it and therefore the most information.

Windows Feature Update report:

Windows feature update compatibility risks report (Preview):

In this report, you can scan for compatibility risks for a specific OS version. I had 1 medium risk:

We don’t use this feature. So, I don’t have reporting available:

Lastly the Windows Feature update device readiness report:

End-user experience

So, what did the users notice about the Windows Autopatch implementation?

They got a notification about diagnostics because more information about the device is needed to fill the reports. Logically but we got some questions via the ServiceDesk about that.

Users mentioned that they would get updates more frequently and that they had to restart their device more frequently. I think that is a good thing but in time we will know if they think that also.

Also, for the dutch readers. The translation for the notifications could use some work:

Lastly, I asked the ServiceDesk if they got more calls and ticket about Windows Updates and that was not the case.

Summarization

Would I use Windows Autopatch again? It only has been a couple of weeks but I think I would use it again. The main reason is that it is really easy to set up. All the update rings and telemetry is set up automatically and it really gives much more insight than the log analytics solution with update rings.

Again, not only patching is automatically set up but reporting also. And, I think that is really important. You need to know which patch levels exist in your organization to do something about it. These windows endpoints are often the first point of entry for a hacker/malware. Therefore, they need to be as up-to-date as possible.

I am missing some features though. I would like to have a group that is always excluded from the test/first ring. Now, I have to check whether C-level people are in the first ring. I need to check this frequently because I don’t want to have them in the first ring when they redeploy their device. Of course, we can check this via a script and change this accordingly but that is not what Windows Autopatch is about for me. This must be available by default.

There should be a naming convention also for the Windows Autopatch groups. We use a naming convention and this completely screws this up.

The insufficient usage is also not really clear to me. Do these users really need to be active for 6 hours and for 2 hours continuously? How do you expect frontline workers to be active for that amount of time? Their primary task is not sitting behind a desk.

There were a couple of policies in conflict with one another:

Firstly, I created filters to apply these policies to the correct devices. After that, there still was a conflict because multiple settings were specified in multiple policies:

I decided to remove the telemetry policies altogether and the information was still available in the reporting section.

Lastly, I hope that you have found my blog about Windows Autopatch and my notes from the field insightful. If you have any questions about my deployment. Don’t hesitate to ask!

References

Other posts:
Use Winget with Intune – NielsKok.Tech
View All API Permissions Microsoft Graph – NielsKok.Tech