“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:
- Microsoft identifies a fault with a service announcement
- 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 “enterpriseregistration.microsoft.com”. 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.