The last time, I talked about the device registration process – preparing for deploying a device using Windows Autopilot.  This time, I want to switch to the device itself and explore what happens when a Windows Autopilot-registered device starts up into the out-of-box experience (OOBE) and is connected to a network.

Using a trusty network monitor app (I prefer Wireshark, and miss the Microsoft Network Monitor – the Microsoft Message Analyzer replacement for it is just too hard to use), you can follow the network traffic to see what’s up.  But since I suspect you don’t live to do that sort of thing, here’s my high-level interpretation:

• The device gets a DHCP address.
• The device checks for proxy settings using WPAD.
• The device verifies that it has internet connectivity by trying to access http://www.msftconnecttest.com/connecttest.txt, so that needs to be accessible.  (See the docs for that.)
• The device gets updated root certs and certificate revocation lists.  (See a different part of the same page for that.)
• The device sends its hardware hash and then receives a Windows Autopilot profile from *.dds.microsoft.com (for Windows 1903 and above; previous releases used the Windows activation services).  (See the Windows Autopilot requirements doc for the specific URLs.)
• Windows 10 is activated.  (See this article for more on that.)
• The device checks for Windows updates:
  • It will automatically download and install any critical updates (typically those that would keep the device from being able to work correctly).  These are typically small updates, although some larger drivers might be published as critical updates and be picked up during this process.
  • It will automatically download and install a Windows Autopilot-specific update (with Windows 1903 and above only), to get the latest functionality and fixes that we have made available.  (So far, we haven’t published one of these.)

This isn’t a comprehensive list of what happens – there is additional traffic going on too, but that’s not relevant for this particular subject.  If you want to see more, install Wireshark and watch yourself.  (Personally, I’m interested in two specific packets in the trace, but I’ll follow up on those later…)

That takes us up to the point where the device would act on what it received in the Windows Autopilot profile – that specific behavior varies based on the scenario that you’ve chosen in the Windows Autopilot profile.  We’ll talk more about each one of those in the future.  For right now, let’s explore a little more about what this profile contains.  The easiest way is to look at one.  Conveniently, with Windows 10 1903 and above it will put the profile contents into a file:

To make that file easier to read, I formatted it using Visual Studio (Visual Studio Code would work too), which mainly just put one property on each line:

{
   “AutopilotServiceCorrelationId”: “b6acc3e6-b849-4389-b81f-0ea82d7a0735”,
   “ZtdRegistrationId”: “edfdc1d9-e3c2-4c74-a51f-92573397fb5c”,
   “AadDeviceId”: “2825d8c5-a413-4a89-9e7c-f368405aa06f”,
   “CloudAssignedOobeConfig”: 28,
   “CloudAssignedDomainJoinMethod”: 0,
   “CloudAssignedForcedEnrollment”: 1,
   “CloudAssignedTenantDomain”: “contosocm.onmicrosoft.com”,
   “CloudAssignedTenantId”: “e3d700d7-0b42-4373-9501-3eec6d574149”,
   “CloudAssignedMdmId”: “9cb77803-d937-493e-9a3b-4b49de3f5a74”,
   “CloudAssignedDeviceName”: “AAD-%RAND:8%”,
   “DeploymentProfileName”: “User Driven AAD Admin”,
   “IsExplicitProfileAssignment”: true,
   “PolicyDownloadDate”: “2019-07-08T20:35:53Z”,
   “PolicyDownloadCorrelationVector”: “9O+Ykpua6k2Bt9dE.0.0”
}

That file by itself tells me a lot.  The device is registered with Windows Autopilot, it is to be joined to Azure AD (CloudAssignedDomainJoinMethod = 1), I can see my tenant details and device naming template, and more.  (If you’ve looked at Windows Autopilot for existing devices, you might see some similarities between this JSON file and the one that is used for that scenario.  That’s to be expected, as that AutopilotConfigurationFile.json takes the place of the downloaded profile – if the device isn’t registered, it will use the AutopilotConfigurationFile.json instead.)  A couple of random comments:

• The “CloudAssignedOobeConfig” value is a bitmap, where each bit corresponds to a specific setting.  See the Windows Autopilot for existing devices documentation for more details on that.
• Notice that there’s no value that corresponds to the “Allow white glove” setting.  That’s because it’s not a setting enforced on the client side.  Instead, Intune checks that setting at enrollment time and will reject a white glove-driven enrollment if it’s not set.  (The device will try multiple times before failing with a timeout error.)

What if the device isn’t registered with Windows Autopilot and boots into OOBE?  In that case, the exact same process happens, but you get what is effectively a “not a Windows Autopilot device” profile returned.  Here’s what that looks like:

Not surprisingly, there’s not much there – just a confirmation that the Autopilot deployment service was contacted and successfully returned this information.  So unless there’s an AutopilotConfigurationFile.json file in place (Windows Autopilot for existing devices), the device will not behave as an Autopilot-registered device.  You’ll see additional pages in OOBE, it will ask for work vs. home, you’ll need to accept the EULA, etc.