Recently, I supported a client facing a peculiar issue with Autopilot (v1) that I had not encountered before. Although the resolution was quite simple, it required me to revisit some dated knowledge about Autopilot, as well as the prerequisites and requirements. This organization had successfully utilized Autopilot for several years until it unexpectedly failed to provision both existing and new devices.
The Problem
The problem manifested identically across all affected devices. While everything seemed fine on the Intune side, the devices were not engaging with Autopilot during the OOBE. They appeared correctly assigned with a profile in Autopilot:
Initial troubleshooting yielded expected results — serial numbers remained unchanged, and attempts to re-register the devices with Autopilot indicated they were already registered:
Examining the Autopilot registry values revealed no profile or awareness, though the devices were capable of proceeding through OOBE, resulting in a successful Entra join and Intune enrollment.
It quickly became evident that the device was failing to retrieve the Autopilot profile. Completely removing the device from Autopilot and re-registering yielded identical results. Quick tests on a remote virtual machine were successful, suggesting this issue was particular to the affected machines or their network.
Further troubleshooting on the impacted devices indicated they were attempting to verify their Autopilot assignment but were unable to download the Autopilot profile:
Quick Review of Autopilot Requirements & Process
Before diving into the solution, let’s briefly review the high-level requirements and procedures for an Autopilot v1 device to pinpoint where issues may arise. We know the device can be Entra Joined and Intune enrolled, and it can communicate with the Graph API for Autopilot registration. However, it is unable to download the profile, and internet access has already been confirmed.
Looking at the requirements for Autopilot, we can verify key factors like OS version and licensing to ensure compliance. Networking requires some attention as there are multiple URLs necessary for Autopilot throughout its lifecycle. Specifically, for user-driven Autopilot v1, the following URLs must be accessible:
- https://ztd.dds.microsoft.com
- https://cs.dds.microsoft.com
- https://login.live.com
The most critical URL for Autopilot functionality is ztd.ssd.microsoft.com, from which the Autopilot profile is delivered to the device during OOBE. Without access to this URL, the profile will fail to download, and Autopilot won’t initiate. Essentially, ztd.ssd.microsoft.com must be accessible when Windows begins the OOBE experience, before other URLs listed here are required. When devices are initially registered with Autopilot, they also need access to https://graph.microsoft.com and https://login.microsoftonline.com for authentication. If registration occurs through an OEM or Partner Center, the https://cs.dds.microsoft.com URL is utilized.
Thus, when a user-driven Autopilot device undergoes OOBE, it uploads its hardware hash to the ztd.ssd.microsoft.com endpoint to check for a match with its tenant. Upon finding a match and if a profile is assigned, the Autopilot profile is delivered via that endpoint. Following this, branding is downloaded, and the user is prompted to authenticate with their work or school credentials. After successful authentication, the Autopilot process commences.
Identifying the Issue and Resolution
Having reviewed the previous section, you may have already deduced the issue at hand. A connectivity test to the required endpoints indicated a failure when trying to connect to ztd.dds.microsoft.com.
If you’re encountering connectivity problems with any of the endpoints, it’s quite possible that your internet traffic is being proxied or filtered. By examining detailed information from the connectivity test, you can see more about the connectivity status, including the next hop IP address, likely indicating your firewall.
If you have access to the firewall and are familiar with its settings, you might be able to check whether the endpoint is being blocked, as shown in the snippet below:
Unfortunately, there isn’t a list of IP addresses linked to ztd.dds.microsoft.com, so it’s ideal for the firewall to allow exclusions by FQDN. If that’s not feasible, consider setting up a separate VLAN with more lenient traffic filtering rules for Autopilot use. Once unobstructed access to the ztd.dds.microsoft.com endpoint is established, the profile can be successfully retrieved, and Autopilot will function as intended.
