Autopilot and Intune Faults

“When sorrows come, they come not single spies, but in battalions.” We are deploying thousands of devices with Autopilot and Intune, and the service faults come in battalions.

We have been tracking these faults for a while. There are two types:

  1. Microsoft identifies a fault with a service announcement
  2. We raise a ticket, there is no cause found for the fault. No service announcement.

In mid-May, account setup failed to complete on pre-provisioned devices. The setup just hung. No cause found.

There was a service incident at the same time (now rolled over in the logs). Users unable to use Autopilot. Different problem, but possibly related.

Application failed to unzip after downloading. No cause found.

Application failed to download from Intune, with “endpoint failed to respond.” No cause found.

Late June, Autopilot failed at the beginning, before entering ESP. Error is 80072ee2. DNS query failed for “”. Network timeout trying to register the device at DRS. No cause found.

From 21 June to 7 July, incident IT396955 “Users’ devices may have incorrectly appeared as non-compliant after Autopilot pre-provisioning in Microsoft Intune”. We don’t allow non-compliant devices to connect, so this caused a complete failure. Root cause: “A recent fix for an unrelated issue.” Although the incident dates from 21 June, it was only identified as an incident on 4 July.

On 21 July, incident IT402961 “Users and admins may have been unable to access the Microsoft Intune service or see limited functionality.” Root cause: “a network gateway outage.”

The facts show that the Autopilot service, with Intune, is fundamentally unreliable. If it were Intune alone, users would experience a failure of policy updates, or application deployments. But, during Autopilot, the result is a failed deployment.

At present, I recommend not using Autopilot to deploy devices, for the next year or so. It is too unreliable. My guess is that an internal service agreement has the wrong incentives.

Microsoft Graph and PowerShell

This is a post about using PowerShell and Microsoft Graph to access data in Azure AD, Intune and Office 365. The GUI management of these Microsoft 365 technologies is constantly evolving, but there will always be things that can’t be done that way. Microsoft Graph approaches the problem from the other direction. It provides an endpoint and API to access the entire dataset. You can then write your own scripts or applications, using the object model of the whole of the Microsoft 365 suite of products.

Continue reading

WDAC FilePath Rules and Drivers

The new File Path rules in Windows Defender Application Control (WDAC) allow EXE and DLL files in the path, but not SYS, or MSI or script files. This is curious and, as far as I know, undocumented. And it means that we cannot simply allow all files in C:\Windows. If we do that, the system will not boot because the drivers will still be blocked. We will need to use another method to add drivers to a WDAC policy.

Continue reading


The Application Control feature in Windows 10 was originally called Device Guard Code Integrity. This was brought under the Defender umbrella of security technologies as Windows Defender Application Control (WDAC). Microsoft earlier this year announced that Windows Defender would become cross-platform (with a version of Defender antivirus for macOS) and be renamed Microsoft Defender.

In my blog posts I originally called it Microsoft Defender Application Control (MDAC). You can see in the screenshot below that all the Defender technologies for Windows 10 Endpoint Protection, in Intune, are now Microsoft Defender.

Intune Endpoint Protection Policies

However, Microsoft now seems to have standardised on WDAC, so I have reverted to that (2021).