While I will never be a fan of proxy servers, there is one case where it is useful to use one:  When you want to see all the network traffic and the actual URLs that are being visited.  I took the opportunity to capture a side-by-side video showing a Windows Autopilot user-driven scenario, joining a device to Azure AD and enrolling it in Intune.

Watching that video could be interesting, as you would ideally have side-by-side 1080p monitors to watch it on, but if you want to check it out, you can find it here:

This is a completely unedited video, showing the client device (a VM) on the left, and the network traffic on the right.  This is leveraging the free version of WinGate, which supports up to 10 concurrent users.  I typically only have 2-3 (and then only when I’m actively testing something), so this works well for me, and it’s trivial to install and configure.

For those that don’t want to watch the whole video, or who don’t have good enough eyes to pick up on what’s going on real-time, here are some timings showing what’s going on through the process:

• 00:10 : First signs of life.  This is a VM with a virtual Ethernet connected, so as soon as we get past the language, locale, and keyboard screens, the traffic starts.  Initially, you see the device connect to login.live.com, which is needed by Windows Autopilot to get a unique ID for the device (where Autopilot sent the hardware hash).  You can also see an HTTP (unencrypted) conversation starting with oscp.digicert.com, which is used to verify that a certificate is still valid.  (You’ll see lots more of these requests, basically for every SSL cert being used.)
• 00:12 : Download of the Autopilot profile.  This is one of those “blink and you’ll miss it” operations.  Given the unique ID, the device downloads the Autopilot profile from ztd.dds.microsoft.com.
• 00:18 : Communication with licensing.mp.microsoft.com.  This is part of the Windows activation process.  You can also see fe2cr.update.microsoft.com, which makes sense as the device is checking for both critical Windows OOBE fixes (OOBE-ZDP) and Autopilot updates (although we haven’t released any of those yet).
• 00:45 : The device rebooted.  This is a good indication that the Windows Autopilot profile was downloaded and the device is rebooting to complete the device rename process.
• 01:02 : Some usage events were sent to v20.events.data.microsoft.com and v10.events.data.microsoft.com.
• 01:20 : Some initial traffic to Delivery Optimization via fe3cr.delivery.mp.microsoft.com.
• 01:28 : A flurry of activity to Azure AD via aadcdn.msauth.net, login.microsoftonline.com, and other URls as it prepares to present the Azure AD sign-in page.
• 01:44 : User sign-in and MFA traffic still using the Azure AD URLs.
• 01:56 : There’s some traffic to wdcp.microsoft.com, which is used for Windows Defender.  You can also see some traffic for the Azure AD terms of use page, through the longest and most explicit URL I’ve ever seen, tokenprovider.termsofuse.identitygovernance.azure.com.
• 02:00 : First signs of Microsoft Intune, with traffic to portal.manage.microsoft.com. 
• 02:01 : The Intune enrollment process begins with traffic to enterpriseregistration.windows.net.
• 02:10 : Plenty of additional traffic to additional Intune URLs via *.manage.microsoft.com.  (You can actually tell where my Intune tenant is hosted from one of those URLs, containing MSUA01.)
• 02:16 : ESP shows up, but still shows “Preparing your device for mobile device management.”  (See this blog for more on that.)
• 02:56 : Another flurry of activity, this time showing that the Office 365 ProPlus installation is starting with the download of the Office setup.exe (yes, even before ESP knows what to track).  You’ll continue to see a lot of this traffic as the process continues, as the Office download will take a while.  The Intune Management Extensions are also downloading during this time, but that’s harder to see as it’s being done through one of the *.manage.microsoft.com URLs.
• 03:22 : Some traffic to Windows Notification Services URLs (that’s how you get app notifications, how Intune signals to a machine to perform remote actions, etc.).  Even some traffic to skype.com and officeapps.live.com for Office “stuff.”
• 03:51 : More random Office traffic, including mobile.pipe.aria.microsoft.com, which Office says is related to OneDrive for Business. That’s a good sign that an MSI package that I pushed to the device is doing a per-machine install of OneDrive.  Any other single-file MSIs will be installed around this time as well (again, with traffic to the *.manage.microsoft.com URLs).
• 03:51 : The “Preparing your device for mobile management” process completed.  That’s a good sign that Intune Management Extensions (IME) MSI finished installing and it provided a list of apps for ESP to track.
• 04:06 : Delivery Optimization checks again to cp601-prod.do.dsp.mp.microsoft.com.  This is a good sign that Intune Management Extensions (which uses DO) has started downloading an app.
• 04:41 : ESP finally displayed what needs to be configured.  Notice that two apps are already done (the two MSIs that I deployed, one for OneDrive and Intune management Extensions itself).  If I would have had more MSIs, the “done” count for apps could have been even higher.  The apps that remain at this point are Win32 apps being installed using Intune Management Extensions.
• 04:45 : First signs of traffic to config.teams.microsoft.com, a good sign the Office installation process is making progress.  Teams is about the last thing it installs, as it’s kind of “bolted on” to the Office 365 ProPlus installation process.
• 05:10 : More DO traffic, so IME is still doing its thing.
• 06:54 : Still working on apps.  You might notice a bunch of “CONNECT” sessions to various URLs.  That’s a proxy/HTTPS optimization; it keeps the connections alive just in case there’s more communication needed, as that’s a lot faster than going back through the SSL negotiation.
• 08:05 : List of completed apps went up to 3.  As there’s no more Office traffic, I would guess that it was Office.  That leaves only IME-delivered Win32 apps.
• 10;01 : IME finished installing an app (taking us to 4 of 8).
• 11:22 : IME finished another one (taking us to 5 of 8).
• 11:39 : Windows Update is downloading an updated list of trusted root certs.
• 11:51 : Another app finished (6 of 8).
• 12:29 : Another app finished (7 of 8).
• 16:19 : The last app finished, and device ESP completed.  The Azure AD user then automatically logged on.  You might notice one other interesting URL here, downloading GoogleUpdateSetup.exe.  One of the Win32 apps I installed was Google Chrome (don’t judge me, I just needed some free and freely-available apps to deploy), and it’s already kicking off its auto-update process.
• 16:45 : Even while the first sign-in animation (FSIA) page is displayed, policies are already being applied, apps are starting up, etc.  See the traffic to kailani.one.microsoft.com?  That’s related to Teams.
• 17:13 : User ESP appears.  It’s still waiting to figure out what it needs to track.
• 17:28 : See some traffic to www.bing.com?  That’s probably a live tile update.
• 17:54 : More traffic to Google, as well as to maps.windows.com (also probably a live tile update).
• 19:05 : User ESP finally determined (from Intune and IME) what user-targeted policies needed to be applied.  Basically, there were none, so user ESP completed and the desktop appeared.
• 20:13 : Some more traffic to Teams as it auto-launches.

That’s pretty much it – the end-to-end provisioning process took about 20 minutes, installed 8 apps (7 real ones, plus IME), applied an unknown number of policies (the “1 of 1” security policy thing doesn’t tell the whole story, see this blog), installed no certs or network profiles (Wi-Fi, VPN), and completed successfully.