Get patch-ed with Windows Autopatch – Part 2

Today, in this part-2 of the 2-post blog on Windows Autopatch, I will take you through the operations and other miscellaneous information of Windows Autopatch that you need to know if you want to start a Pilot batch in your tenant.

If you have not read part-1 of this post yet, make sure, I would advise you to check it out first before continuing with this.

Windows Autopatch Operations

Windows Autopatch working is based on the same Ring deployment concept that we have already seen and are familiar with for modern managing Windows devices with Intune and Windows Update for Business.

For the purpose, Windows Autopatch creates 4 new WUfB deployment rings in your tenant, namely,

• Modern Workplace Update Policy [Broad]-[Windows Autopatch]
• Modern Workplace Update Policy [Fast]-[Windows Autopatch]
• Modern Workplace Update Policy [First]-[Windows Autopatch]
• Modern Workplace Update Policy [Test]-[Windows Autopatch]

Windows Autopatch will not automatically add devices to the [Test] ring and you as an IT admin will need to manually add devices into that ring.

For the rest of the 3 production rings, Windows Autopatch automates the assignment of devices into the deployment ring groups and other groups required for software updates management.

For example, once you add devices to the Windows Autopatch registration group, the first set of devices to send data back to Windows Autopatch is assigned the [First] ring which has a 1% device capacity threshold for the tenant. Once the threshold is reached, Windows Autopatch will assign the [Fast] ring to the next set of devices till the 9% device capacity threshold for that ring is reached. Going forward, all other devices will be assigned the [Broad] ring which has the 90% device capacity threshold for the tenant.

However, you can choose to manually move devices between Rings if you wish to if there is any need for the same.

To do that, you again would need to navigate to the Windows Autopatch admin section in the MEM portal.

• Go to Devices > Windows Autopatch > Devices and from there,
• Select a device from under the Ready tab, for which you want to change the ring assignment.
• From under Device actions, click on the Assign device group.

Multiple devices can be selected for bulk action.

The Assign group blade will give a drop-down of 5 options to choose which Ring you want the device to be moved to.

The Automatic option is to let Windows Autopatch continue to decide the ring assignment for the device. As such, if you want to change the Ring assignment of the device from the one that Windows Autopatch already chose for the device, choose from the other 4 options which correlate to the actual Rings created for Autopatch.

Windows Autopatch Release Management

The Release management blade shows what updates are being pushed through the environment via Windows Autopatch.

Just like how you can control Windows Update rings deployment in Intune, in the same way, you get the Pause/Resume functionality with Windows Autopatch also. This can come in handy if in case you need to pause an update being pushed by Windows Autopatch as per the release management, for any particular reason.

The below snap shows an example where I paused the quality update via Autopatch for the tenant and you can see the status reflecting as Customer Pause.

Now if I have to Resume the same, this is the UI that gets presented.

See the checkboxes against the 4 Autopatch rings. [A nice addition IMHO👍]

You get the choice to Resume all the Paused rings or can choose to Resume selective Rings only and let the other rings stay paused.

Deregister device from Windows Autopatch

If you need to de-register a device from the Windows Autopatch service, that is simple as well. To do that, you again would need to navigate to the Windows Autopatch admin section in the MEM portal.

• Go to Devices > Windows Autopatch > Devices and from there,
• Select a device from under the Ready tab, for which you want to change the ring assignment.
• From under Device actions, click on Deregister device.

Multiple devices can be selected for bulk action.

Device de-registration only deletes the Windows Autopatch device record. The device continues to be managed with Intune as-is and it is expected that you will put the device back to any of the Windows Update rings that you have created and control in the tenant for the device to continue being serviced with Windows Update.

The de-registration command doesn’t trigger device membership removal of the device from the Windows Autopatch Device Registration AAD group. However, the device gets flagged as “excluded” so Windows Autopatch doesn’t try to re-register the device into the service again.

Removing devices from the Windows Autopatch Device Registration Azure AD group doesn’t deregister devices from the Windows Autopatch service.

As Microsoft mentions in their document,

If you want to reregister a device that was previously deregistered from Windows Autopatch, you must submit a support request with the Windows Autopatch Service Engineering Team to request the removal of the “excluded” flag set during the deregistration process. After the Windows Autopatch Service Engineering Team removes the flag, you can reregister a device or a group of devices.

What happens if the device undergoes hardware changes?

Registering devices in Windows Autopatch does the following:

• Makes a record of devices in the service.
• Assign devices into the deployment ring groups and other groups required for software update management.

Regarding the 1st one about device record in Windows Autopatch service, much like how it is for Windows Update for Business – Deployment Services (WUfB-DS), the Azure AD device ID acts as the anchor.

As such, if the Azure AD device ID for the device changes for any reason whatsoever, you will need to re-register the device back to the Windows Autopatch service.

Now, what can cause the Azure AD device ID of a device to change? When a device undergoes major hardware changes, such as:

• SMBIOS UUID (motherboard)
• MAC address (non-removable NICs)
• OS hard drive’s serial, model, manufacturer information

It results in a new hardware ID (hardware hash for an analogy to Windows Autopilot) that makes the device unrecognizable to the service. [We touched upon this here in one of the previous blog post, though it was in the context of Windows Autopilot 😅]

In these cases, when such a device presents itself to Azure AD, typically the user gets prompted with a Work or School account error and the subsequent join state remediation results in Azure AD creating a new Azure AD device ID for the device, even though it is technically the same device. The old Azure AD device ID gets abandoned and continues to remain as a stale entry.

How does Microsoft gain access to your tenant for Windows Autopatch?

Want to know how Windows Autopatch service (or Microsoft or the Windows Autopatch Service Engineering Team) can gain access to the tenant for the purpose of Windows Autopatch management?

Microsoft mentions that

Windows Autopatch creates and uses guest accounts leveraging just-in-time access functionality when signing into a customer tenant to manage the Windows Autopatch service.

You can read more about it here from the Tenant access documentation.

Like the Windows Autopilot service, Windows Autopatch also stores its data in the Azure data centers in the United States.

Further, Windows Autopatch relies on data from multiple Microsoft products and services to provide its service to enterprise customers, including Windows, Microsoft Intune, Azure Active Directory, and Office. And before you ask, the Windows Autopatch service follows General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA) privacy regulations. More can be read from the Privacy documentation.

Get help for Windows Autopatch

Facing any issues with Windows Autopatch or want to request update compliance report for the month? You need to reach out to Microsoft for help as anyways this is a Microsoft-managed service at the end of the day.

All you need to do is, in the MEM admin portal,

• Navigate to Tenant administration > Windows Autopatch > Support requests
• Click on New Support Request to create one.

There are two categories (with their own sub-categories to relate to all aspects of the service that you can have a problem with or may come up with a request for) to choose from when creating a support request under the Windows Autopatch realm and they are as below.

• Devices
  • Device registration and deregistration
  • Tenant Offboarding

• Updates
  • Office Updates
  • Reporting
  • Windows Feature Update
  • Windows Quality Update

Go ahead and create a support request that best matches your requirement and the Windows Autopatch Service Engineering Team will reach out to the Admin contacts specified for the tenant to help with the service request.

At the time of writing this, the Windows Autopatch Service Engineering Team is located in the United States, India, and Romania. [Check here]

The End

In the 2-post blog series, I tried my best to give you pretty comprehensive information about Windows Autopatch and if you are still reading this, then hopefully you have got the information that you were looking for related to your quest.

If we look at the evolution of Windows servicing in the enterprise landscape, I believe Microsoft’s vision for Windows Autopatch is a move in the right direction.