I recently assisted a client with an unusual Autopilot (v1) issue I hadn’t seen before. While the solution turned out to be straightforward, it required dusting off some old Autopilot knowledge and revisiting the prerequisites and requirements. This organization had been using Autopilot for a few years without any issues, and then, seemingly out of nowhere, it stopped working when they tried to provision existing or new devices.
The Problem
The issue was the same on all the affected devices. Everything looked good on the Intune side, but devices were not engaging Autopilot during OOBE. They showed correctly with a profile assigned in Autopilot:
Some basic troubleshooting came back as expected – the serial numbers did not magically change, and if we tried to re-register the devices with Autopilot, they identified that they were already registered:
Checking the Autopilot registry values showed no Autopilot profile or awareness, but devices could go through the OOBE, which resulted in a successful entra-join and Intune enrollment.
At this point, it was pretty obvious that the device was not pulling down the Autopilot profile. Completely deleting the device from Autopilot and re-registering it had the same result. Some quick testing on a remote virtual machine was successful, indicating something specific to those machines or the network to which those machines were connected.
Some additional troubleshooting on the affected machines revealed that they were indeed checking if they were part of an Autopilot assignment, but they were failing to download the Autopilot profile:
Quick Review of Autopilot Requirements & Process
Before going into the resolution, let’s quickly discuss the high-level requirements and sequence of an Autopilot v1 device to identify where things are failing. In this case, we know the endpoint can be Intune enrolled and Entra Joined, and we know it can communicate with the graph API to perform the Autopilot registration. However, it’s failing to download the profile, and we have already confirmed that the device has internet.
If we examine the requirements for Autopilot, we can quickly and easily identify things like OS version and licensing to confirm that those are met. Networking requires a little bit of work. There are numerous URL access requirements for Autopilot from start to finish, but if we focus strictly on the Autopilot deployment service, we need access to these URLs (these are for user-driven Autopilot v1):
- https://ztd.dds.microsoft.com
- https://cs.dds.microsoft.com
- https://login.live.com
The most important URL in this list for Autopilot to function is ztd.ssd.microsoft.com. This is the URL from which the autopilot profile is delivered to the device during the OOBE. Without access to ztd.ssd.microsoft.com, the profile will fail to download, and Autopilot will never be engaged. So, technically, access to ztd.ssd.microsoft.com is required when Windows starts the OOBE experience before the other URLs located here come into play. Initially, when devices are registered with Autopilot, they need access to https://graph.microsoft.com and https://login.microsoftonline.com to authenticate. If the devices are registered by an OEM or through Partner Center, the https://cs.dds.microsoft.com URL is used.
So, when a user-driven autopilot device goes through the OOBE, it sends its hardware hash up to the ztd.ssd.microsoft.com endpoint to see if there is a match with a tenant. If a match is made and a profile is assigned to the device, the Autopilot profile is delivered to the device via the ztd.ssd.microsoft.com endpoint. From there, branding is also pulled down, and the user is asked to authenticate with their work or school credentials. After authenticating, the Autopilot process begins.
Identifying the Issue and Resolution
After reading the previous section, you can probably guess the issue here. If we do a quick connectivity test to the required endpoints listed in the requirements for Autopilot, we can see that it fails when trying to connect to ztd.dds.microsoft.com
If you’re having connectivity issues with one of the endpoints, it’s very likely that your internet traffic is either being proxied or filtered. If we grab the detailed information, we can see additional information about the connectivity test, including the next hop IP address, which is probably your firewall.
If you have access to the firewall and are comfortable navigating it, you can check to see if the endpoint is being blocked, like it in the snip below:
There is no list of IP addresses associated with ztd.dds.microsoft.com, so hopefully your firewall can make exclusions by FQDN. If that’s not possible, another option is to create a separate VLAN with looser traffic filtering rules that can be used for Autopilot. After clearing a way to the ztd.dds.microsoft.com endpoint, the profile could be retrieved and Autopilot started working again.
