Registering devices with the Windows Autopatch service

This week is all about the relatively new Windows Autopatch. Windows Autopatch is a cloud service provided, by Microsoft, that automates the update process for Windows, Microsoft 365 Apps for enterprise, Microsoft Edge, and Microsoft Teams. The steps to get started with Windows Autopatch are pretty straight forward, especially with the latest adjustments of how the service interacts with the tenant. Those adjustments improve the security posture of the service, by relying on application-only authentication, and further simplifies the enrollment process of the tenant. Together that makes the enrollment pretty straight forward. That’s also why this post simply assumes that the onboarding is successfully performed. Once the tenant is enrolled to the Windows Autopatch service, the next main action is the registration of the devices with the service. This post will have a closer look at the actions to register devices with the Windows Autopatch service and the actions performed by the service.

Note: Windows Autopatch requires Windows 10/11 Enterprise E3 or higher, to be assigned to the users. Without the availability of that license, or a license that includes that license, Windows Autopatch won’t be avialable.

Windows Autopatch device registration

When looking at using Windows Autopatch, it all starts with the device registration. The device registration is required, before devices can actually be managed in Windows Autopatch. To get the devices registered, there are two different paths available depending on the device. There is a path for Windows 365 Cloud PCs and a path for basically every other Windows device.

  • For Windows 365 Cloud PCs, the registration with the Windows Autopatch service starts during the provisioning of the Cloud PC, once the Provisioning policy is configured with Windows Autopatch enabled (as shown in Figure 1).
  • For every other Windows device, the registration with the Windows Autopatch service starts once the device is added to the Windows Autopatch Device Registration Azure AD group (as shown in Figure 2).

Important: Keep in mind that whenever something happens to the device that causes the generation of a new Azure AD device ID (i.e. hardware replacement), the device must also readded to the Azure AD group.

Note: As with every Azure AD group, devices can be added by using a direct membership, by nesting other Azure AD groups (with a maximum of one level of nested groups), and by using bulk import of group members.

Windows Autopatch update ring distribution

Whichever method is used, the device registration process will get started. The Windows Autopatch service will scan the Azure AD group every hour, to discover newly added devices that must be registered with the service. That scan can also be triggered manualy by using the discover devices option. During that registration process, the Windows Autopatch service will perform a few intelligent actions, to make sure that the devices are ready and configured to receive the different updates. It starts by verifying the prerequisites. That includes checks on the existince within the service, the Intune management status, the latest activity, the platform, the SKU, and more. Once the device passes those check, it calculates the deployment ring distribution. And this is where a part of the strength of the service is and where it gets interesting. That calculation is done by taking percentages of the devices within the organization and adding those devices to different groups. That percentage depends on the size of the organization. For the different deployment rings the percentages are used as described in the table below.

SizeTestFirstFastBroad
≤ 2000%5%15%80%
> 2000%1%9%90%

Depending on the calculated update ring, the device will be added to one of the related Azure AD device groups. That group will make sure that the device will get the deployment ring configuration that belongs to that update ring. Besides that, that group will also make sure that the device will get the configuration that belongs to Microsoft Edge updates, Microsoft 365 apps for enterprise updates, and Microsoft Teams updates. That’s achieved by applying different device configuration profiles, with also a different update cadance for the different update rings. For Microsoft Edge that means the beta release for the test group and the stable release for the first, fast, and broad group. And for Microsoft 365 apps for enterprise that means a different update deadline and update deferral for every update ring. The table below provides an overview of the different groups, related to the update rings.

Device groupRingDescription
Modern Workplace Devices-Windows Autopatch-TestTestThis group is used for the deployment ring for testing update deployments of Windows updates, Microsoft Edge updates, Microsoft 365 apps for enterprise updates and Microsoft Teams updates, prior to production rollout
Modern Workplace Devices-Windows Autopatch-FirstFirstThis group is used for the first production deployment ring for early adopters of Windows updates, Microsoft Edge updates, Microsoft 365 apps for enterprise updates and Microsoft Teams updates
Modern Workplace Devices-Windows Autopatch-FastFastThis group is used for the fast deployment ring for quick rollout and adoption of Windows updates, Microsoft Edge updates, Microsoft 365 apps for enterprise updates and Microsoft Teams updates
Modern Workplace Devices-Windows Autopatch-BroadBroadThis group is used for the final deployment ring for broad rollout into the organization of Windows updates, Microsoft Edge updates, Microsoft 365 apps for enterprise updates and Microsoft Teams updates

Note: The test deployment ring only contains devices that are manually added to the group. Devices will not be automatically added to that group. So, make sure to find members within the organization for that group.

Windows Autopatch device configuration

After adding the device to the Azure AD group for the update ring configuration, the next intelligent part of the Windows Autopatch service kicks in. The devices registered with the Windows Autopatch service, will be added to different Azure AD groups that are used for applying different pieces of configurations. Those pieces of configurations are used for configuring the important details. Those details being the telemetry configuration, the update frequency and the data collection. The different Azure AD groups used and a short description are listed in the table below.

Device groupDescription
Modern Workplace Devices-AllThis group contains all devices managed by Windows Autopatch
Modern Workplace Devices Dynamic – Windows 10This group contains all devices managed by Windows Autopatch and running Windows 10
Modern Workplace Devices Dynamic – Windows 11This group contains all devices managed by Windows Autopatch and running Windows 11
Modern Workplace Devices-Virtual MachineThis group contains all virtual devices managed by Windows Autopatch

Note: The dynamic Windows 10 and Windows 11 groups are currently looking for specific Microsoft Managed Desktop  properties that are not available when only using Windows Autopatch.

Those groups, however, are not really actively used for applying configurations by using Microsoft Intune. With the exception of the Windows 10 and Windows 11 dynamic groups. Those groups, however, are not correctly filled when only using Windows Autopatch. When looking at configurations that are applied to devices that are registered with the Windows Autopatch service, there are also policies applied that are not directly update related. Policies with only settings around the update process that are used for configuring the important details. Those details being telemetry, frequency and data collection. The device policies used for applying those important details and the description of the assignments are described in the table below.

Device policyDevice groupDescription
Modern Workplace – Set MDM to Win Over GPOAll update groupsThis policy is used for configuring the MDM preference for any applied configurations
Modern Workplace – Telemetry Settings for Windows 10All update groups and an exception of the dynamic Windows 11 groupThis policy is used for configuring the telemetry settings for Windows 10 devices
Modern Workplace – Telemetry Settings for Windows 11All update groups and an exception of the dynamic Windows 10 groupThis policy is used for configuring the telemetry settings for Windows 11 devices
Modern Workplace – Window Update Detection FrequencyAll update groupsThis policy is used for configuring the Windows update detection frequency
Modern Workplace – Data CollectionAll update groupsThis policy is used for configuring the data collection and telemetry settings

Note: Keep in mind that besides the specifically mentioned policies, there are many other policies applied. Those policies, however, are all directly and clearly related to the update configurations of Windows updates, Microsoft Edge updates, Microsoft 365 apps for enterprise updates, and Microsoft Teams updates.

Windows Autopatch registered devices

Once devices successfully passed the check on the prerquisites, are added to an update ring group, and recieved the related configurations, those devices are marked as Active within the Windows Autopatch service (as shown below in Figure 3). That’s also immediately the last autmoated part of the registration process with the Windows Autopatch serice. Starting that moment the IT administrator can monitor the update status of those devices by using the specific reports that become available via the Windows Autopatch service. Besides that, the IT administrator can manage the update group membership of devices and deregister devices from the Windows Autopatch service. Only basic management capabilities, as more isn’t needed.

Note: It can take up to an hour for devices to appear as registered devices in the Windows Autopatch service.

More information

For more information about Windows Autopatch and the device registration process, refer to the following docs.

2 thoughts on “Registering devices with the Windows Autopatch service”

  1. The 2 telemetry policies conflict. As you dedcribed the groups are not correctly filled. My Win11 device ends up in both telemetry groups.

    Reply
    • Hi Rkast,
      That’s exactly one of the things that I described. The dynamic groups for filtering Windows 10 and Windows 11 devices, are currently looking for a property that doesn’t exist by default.
      Regards, Peter

      Reply

Leave a Reply to Peter van der Woude Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.