Windows Autopatch Client Broker: What It Is, When to Use It, and Why It Matters
In this post, we’ll break down what it does, when you need it, and how to align it with your organization’s update strategy.
TL;DR Windows Autopatch now relies on the Client Broker for daily readiness checks and health reporting. MC1139484 (Aug 22, 2025): Microsoft is improving how the Windows Autopatch Client Broker is managed and installed. Rollout starts September 22, 2025 If you onboarded devices before this or lack “Ready/Not ready” visibility, deploy the Client Broker from Intune > Tenant administration > Windows Autopatch > Tenant Management > Manage client broker.
Ever since the change in license requirement and the fact that recent updates made it an even better feature, Windows Autopatch has evolved into a mature update service, offering features like hotpatching, improved reporting, and streamlined update ring management.
But behind the scenes, there’s a lesser known component that plays a crucial role in keeping your devices healthy and compliant: the Windows Autopatch Client Broker.
In this post, we’ll break down what it does, when you need it, and how to align it with your organization’s update strategy.
What Is the Windows Autopatch Client Broker?
Once a device is registered with Windows Autopatch, Microsoft runs post-device registration readiness checks daily.
These checks verify:
- The device is running a supported OS version.
- Windows update policies are managed via Microsoft Intune MDM and not overridden by Group Policy Objects (GPO).
- Microsoft Office update policies are also not managed via GPO. “Office updates must be managed via Intune or another supported method that downloads updates directly from the Office CDN.”
- Required network endpoints are reachable.
- The device can report its compliance and status back to the Autopatch service.
The older Microsoft Cloud Managed Desktop Extension (MCMDE) was used in the early days of Autopatch.
This has now been fully replaced by the Windows Autopatch Client Broker and will soon make the transition from powershell to Win32.
The Client Broker is the primary component responsible for running readiness checks and reporting health status to the Autopatch service.
Do You Always Need It?
The Client Broker is now a standard part of the Windows Autopatch configuration going forward.
If you’ve recently onboarded devices, the Autopatch Client Setup Script will ensure it’s installed automatically. This is set to be changed with an announched update coming in september. More on this further up.
Without the Client Broker (and without the legacy MCMDExtension): Devices can still receive Autopatch updates, but post-registration readiness data won’t be reported, so you lose the extra visibility in the Autopatch Devices blade.
With the Client Broker (current/recommended): Devices perform the daily readiness checks and send health/compliance results. If something breaks, the device shows under Not ready so you can remediate before it impacts compliance.
When to Install the Client Broker
You should ensure the Client Broker is deployed if:
- Your devices were onboarded to Autopatch before 2025 and may still be using the old MCMDExtension.
- You want full visibility into device readiness and compliance.
- Devices are showing as Not ready but the cause is unclear.
- You’re preparing for new Autopatch features (like hotpatching) where readiness checks confirm eligibility.
How the Client Broker is installed (2025 update)
MC1139484 (Aug 22, 2025): Microsoft is improving how the Windows Autopatch Client Broker is managed and installed. Rollout starts September 22, 2025.
Default method after the update (September 22, 2025)
- The Client Broker is now deployed by Win32 app (default), replacing the older PowerShell script for greater reliability.
- The broker performs ongoing post-registration readiness checks and supports automated log collection when a support ticket is created.
On-demand portal controls
- You can deploy the broker to all Autopatch devices or scope to specific Microsoft Entra ID groups directly from the portal.
Existing devices
- Devices that already received the broker via the PowerShell script will remain on that assignment.
- You can migrate those devices to the Win32 app deployment when you’re ready.
🔄 Status “In progress” is normal The broker continuously processes new devices and runs health checks, so the action typically remains in progress by design.
What to do next
- Plan the switch to the Win32 app for new deployments. Decide if/when to migrate existing script-based installs.
- Scope on-demand deployments to the right Entra ID groups for phased rollout. (Think about your scopes going towards 22 september)
- Keep your Hotpatch policy posture: new quality update policies have Hotpatch enabled by default; review and deploy to eligible devices.
The current (before 22 september, 2025) and soon old way of installing
- Open the Intune admin center.
- Go to:
Tenant administration > Windows Autopatch > Tenant Management - Select Manage client broker.
Overall you have two options. Either install the broker through the powershell script like the in the screenshot. Or to Install/Migrate to the Win32 app when your tenant is enrolled with the new upcoming update.
Tip: Ensure that the endpoint
device.autopatch.microsoft.com
is allowed in your firewall or proxy.
(Microsoft updated the Client Setup Script between February–March 2025 to require this. It is definitely worth checking your allowlists.)
Best Practices
- Check “Not ready” devices regularly – Use the Autopatch reports which can be found in the “Reports” blade in Intune to catch issues early.
- Combine with reporting improvements – The improved Autopatch reporting (rolled out in early 2025) pairs well with readiness data for proactive patch management.
💡 Side Note — Hotpatch Updates
Windows Autopatch does not automatically configure a hotpatch policy for you. If you want devices to receive no-reboot monthly security patches (Hotpatch),
you need to create and assign a Windows quality update policy in Intune:
- Go to Devices > Windows updates > Quality updates > Create policy.
- Set When available, apply without restarting the device (“Hotpatch”) =
Allow.- Assign the policy to your Autopatch device group.
Without this policy, Autopatch falls back to standard cumulative updates.
More information about hotpatch can be found on the MSLearn page Windows Autopatch Hotpatch updates
Why This Matters for Your Update Strategy
Windows Autopatch isn’t just about pushing updates, it’s about confidence that every device as a healthy update cycle, is compliant, and ready for what’s next. If there is a situation where the device is not supported anymore, that is your signal that a replacement of the hardware is required. This way, you’ll leave no device behind! The Client Broker acts like a health monitor: essential for readiness checks, invaluable for spotting and resolving issues before they cause downtime or leave security gaps.
Closing Thoughts
If you’ve read my earlier post, What’s New in Windows Autopatch, you know Microsoft is putting more effort on automation and insight.
The Client Broker fits perfectly into this direction. Automating readiness checks so you can spend less time chasing device status and updates and can spend more time focusing on strategic IT improvements or read more Azure with Tom blogposts 😜
Next step: Review your Autopatch devices and confirm the Client Broker is installed.
It’s a small change that can make a big difference in how confidently you manage updates.
if you came this far, thank you for reading. Feel free to send me questions/feedback on linkedin.