Diving under the hood of Windows Autopatch
It's been some time since I've written any blog content so let's see how this goes...
Windows Autopatch is now GA after going through a public preview period, and bringing with it the functionality for a (sufficiently licensed - E3/E5 only, no BusPrem, A or F SKU's) customer to completely offload ongoing maintenance of Windows, Office 365 Apps, Teams and Edge to Microsoft. But what's really happening when you enable it within your tenant and you start to onboard devices?
Initial Configuration:-
After enabling the service via Tenant administration>Windows Autopatch and waiting a few minutes while it presumably spins up the required back-end bits, you get access to a new section of the Devices tab where you can take various actions and view devices that are in a "Ready" state. When Autopatch is initially configured, it creates an AAD group called Windows Autopatch Device Registration which devices must be manually added into (or via nested groups, which is handy), to become visible to the service on a sync:
For these Ready devices, you can then configure which deployment ring they're attached to manually (useful if you've got certain devices you want to be first, such as IT, or devices you want to definitely keep in broad deployment, such as C-Levels)
Updates are all controlled via the above group assignments, which relate to 4 Update Rings also created by the Autopatch onboarding, with broadly the same settings, just with differing deferral periods. Note that there's no deferral on Feature Updates, so be mindful of devices not up to date or being held back for technical reasons
You can also view "Not Ready" devices, and while it's nice to see there are devices that somehow failed the prerequisite checks, in my opinion, having a better status field with some instantly available information or required actions rather than having to dig into each device to find the reason would provide a better management experience.
I could go over all the other things it creates, such as custom OMA-URI Intune policies for things that should really be Settings Catalog (though this is apparently changing soon), or the concerns around the highly-privileged Managed Identities you have to exclude from MFA, but I'll save all that for a different blog, because this is where my deep-dive started to get more interesting...
Hidden Secrets:-
As someone who loves poking about in the Graph API, I fired up my dev tools out of curiosity, and I noticed that when making a change to the service, such as assigning a device group, it wasn't hitting the v1.0 or even the Beta Graph endpoints. Remember the Microsoft Managed Desktop, the 2018 product that was certainly an interesting concept of "Desktop as a Service", but hasn't had much airtime or traction with customers, certainly from my experience...
There's a number of undocumented API's across O365, some people have even gone as far as writing custom PS modules to do stuff (Configuring Office 365 settings using PowerShell - The non-supported way - Evotec), but this is the first time I've seen an API being repurposed in this way and not lining up with the documented schema Microsoft Managed Desktop API Schema | Devices.
There was a recent service outage, MO402741 that affected many parts of O365, but I found one of the impacted services particularly interesting: "Autopatches within Microsoft Managed Desktop". Hmm.
One thing that is a potential problem here is that API endpoint has an access-control-allow-origin so only the MEM portal can interact with it. With so many MEM admins looking to automate things via the Graph, it's perhaps somewhat short-sighted locking out any way of custom automation that admins with a large amount of endpoints might want to do, especially given the current limitations of the GUI.
>Are there Autopatch specific APIs or PowerShell scripts available?
Programmatic access to Autopatch isn't currently available.
Windows Autopatch FAQ - Microsoft Docs
Dissecting further:-
I didn't notice it at first, but one of the many things created by Autopatch is a PowerShell script:
If this was a Win32 app, you'd be out of luck without the encryption key, but PowerShell scripts can be easily extracted via Graph (Get back your Intune PowerShell Scripts – Modern IT – Cloud – Workplace (oliverkieselbach.com)).
So I grabbed the script to take a look, and you can too:
262588213843476
Nothing too strange, but my eye was instantly drawn to the $SystemScript variable, and the 22.6k character Base64 encoded string. After running through a decoder, look, another script!
262588213843476This one is more interesting, and clear from the synopsis that we're dealing with the Autopatch onboarding installing the Managed Desktop Client Library and Cloud Managed Desktop Extension. Digging into the referenced .cab file sheds a little more light, but between the CMD Extension and the MMD Broker (which includes the MMD Action Engine to run Elevated Actions to fix end user issues dated August 2019), it all seems very system agnostic.
I can only imagine the back-end services are doing some matching on the serialNumber and aadDeviceID values reported back to the MMDLS API, but I'm not too bothered trying to dig further.
It is nice to see that there's various certificate checks along the way to combat potential MITM attacks though.
Summarise yourself, already!:-
Now, Microsoft creating stuff for their internal services and then repurposing them (sometimes at cost) isn't new. From the early days of O365 (What's next for Office 365? CRM Online and Windows Intune | ZDNet) all the way back in 2011, to the release of the Xbox One in 2013 (Xbox One & Azure cloud computing: A match made in heaven | VentureBeat), MS have been utilising and repurposing tooling and telemetry data across internal, consumer and enterprise services to improve the security and reliability of other services. Heck, the AAD Security Defaults came about because of data collected from consumer MSA services (Introducing security defaults - Microsoft Tech Community)!
With that in mind, am I really that surprised that they're using an existing toolset developed for their their Managed Desktop product to try and ease the burden of updating devices by making it available to all customers (with M365 E3/E5 licensing...)? Not really.
Am I surprised they're not charging extra? Perhaps... (Premium add-ons for Microsoft Intune - Microsoft Intune)
Microsoft are aware that the Autopatch reporting is pretty bare-bones, so in my mind, implementing Update Compliance still feels like something every company should do. As far as Autopatch as a product, I'm still relatively underwhelmed, especially given the limitations that would still fall on the customer to resolve:
Personally, I'd much rather be implementing appropriate policies in Intune, Servicing Profiles via config.office.com, and the Update Compliance solution for reporting, which can still provide incredibly light-touch management, and the flexibility of something like PowerApps/PowerAutomate or Azure Monitor from the Log Analytics to flag any issues, but I'll be keeping an eye on the service as it develops, maybe it'll change my mind.
