One of the biggest challenges that we run into with customers who want to adopt Windows Autopilot for deploying new devices is the variety of network setups.  This can be broken down into a few high-level categories:

• Challenges for devices that need to make an initial connection to the corporate network, due to network security mechanisms such as 802.1x, which often leverages either computer or user certificates to grant access.  Sometimes these mechanisms only apply to Wi-Fi networks (meaning wired connections are fine), but it could also apply to wired network connections as well.
• Challenges for devices that need connectivity to the internet, which may require access through a proxy server or a firewall.  This can be especially problematic in cases where user authentication is needed (whether using AD/AAD credentials, certs, or other mechanisms), but there are also discovery issues (i.e. how does the client discover that it needs to use a proxy server).
• Challenges for devices that need connectivity from the internet, which may require access via VPN, typically needed for Active Directory-based scenarios (e.g. Hybrid Azure AD Join).

Generally, these can all be considered “bootstrapping” problems.  In the past, when customers used traditional image-based deployment mechanisms, they built mechanisms to work around these, often solving the issues before the device was ever delivered to the end user.  When shifting to Windows Autopilot, those mechanisms may no longer work (depending on the specifics).

Our general guidance for Windows Autopilot networking focuses on outbound connections, i.e. what internet-based services does the device need to talk to in order to complete the Windows Autopilot provisioning process.  But it doesn’t really talk about the items I mentioned above.

There are some general solutions that can be applied to the challenges above.  It’s useful to talk about those before getting into the scenarios that benefit the most from those.  Here’s a list:

• WPAD.  This is a mechanism that allows a device to discover what proxy server script (PAC) that should be used to communicate to the internet.  (Note that many network teams don’t like WPAD because it is considered a security risk – devices in public spaces could be directed to a proxy server that monitors network traffic without the user’s knowledge.  Also, proxy servers that perform SSL inspection are evil and will likely break Windows Autopilot and other services that validate the SSL server certs.)
• Whitelisting.  This is a mechanism that is used in multiple situations:
• With a firewall, to allow access through the firewall for a list of internet addresses (IP or DNS names).
• With a firewall, to allow certain machines to connect to a list of internet addresses through a pre-authorization process (e.g. registering their MAC addresses in advance).
• With a proxy, to allow access through the proxy server for a list of internet addresses (IP or DNS names), without any user or device authentication.
• Guest network.  Devices can connect to a limited network (e.g. allowing only internet access, perhaps with a captive portal to authenticate users).
• Certificate enrollment.  To access the corporate network (i.e. using 802.1x), the
  device or user may need a cert.  Deploying from a different network (guest or directly on the internet) may be able to get those certificates enrolled so that the device can later access the corporate network.  Intune uses SCEP to talk to a certificate enrollment service (e.g. an Active Directory Certificate Services NDES server) to issue needed certs.
• VPN.  If the device can’t directly access the corporate network, but can access the internet or a separate guest network, it may be able to then make a VPN connection.  (If the VPN connection needs a cert, then certificate enrollment may still apply.)
• Temporary bypass.  The user can be given a mechanism to connect to the corporate network without certificates for a period of times (hours).  That could be the normal Wi-Fi network, or a separate restricted network.  Generally this would require a helpdesk call.
• Pre-provisioning.  Technicians can set up devices on a separate network (OEM, partner, or customer network) to get device configuration in place before the device is given to the user. 
• Custom imaging.  The OEM can load a custom image that has the needed device configuration pre-loaded in the image.  (To keep the customer out of the imaging business, one of the main Windows Autopilot goals, it would be best to just provide the “tweaks” to the OEM and let them make those tweaks in the image.)

Now, let’s talk about the different Windows Autopilot scenarios.

User-driven Azure AD Join

The best thing about Azure AD Join is that it just requires internet access.  Let’s see how the solutions above may apply:

• WPAD.  This can be effective to allow devices to discover the proxy server that they use.  If WPAD is not supported and a proxy must be used, there is presently no simple way to specify the proxy settings.  (You can find some workarounds in other blogs that directly poke the proxy server URL into the system using a Shift-F10 command prompt, but that’s not at all user friendly.)
• Whitelisting.  This is very effective in allowing devices to access the needed internet URLs (e.g. for Windows Autopilot, Azure AD, Intune, and more).
• Guest network.  This is very effective too – typically guest networks don’t use proxy servers, so they avoid problems related to that (configuring, whitelisting).  Intune can then deploy the needed configuration (e.g. certs, proxy settings, WI-fi connections) so that the device can later use the corporate network.
• Certificate enrollment.  After the device has an internet connection, it can get certs so that it can later access secured networks (e.g. 802.1x).
• VPN.  This should never be necessary with Azure AD Join.
• Temporary bypass.  This could be used if the corporate network is otherwise too restrictive or requires a proxy that can’t be pre-configured.
• Pre-provisioning.  This will be discussed later, as that’s really a technician-driven white glove scenario.
• Custom imaging.  This can certainly solve issues related to proxy server configuration (can be pre-configured in the image) and machine cert-related (for 802.1x machine authentication).  It can’t do anything with user certs (which can also be used with 802.1x) because the user needs to sign on first (chicken-and-egg problem).

So what do I recommend?  It’s a sort of flow chart:

• If your corporate network behaves like an open internet connection (can resolve DNS names and access all HTTP and HTTPS hosts, without authentication, certs, or proxies), you’re all set.
• If you have a proxy, can you bypass it by whitelisting URLs that can go directly through the firewall, bypassing the proxy?  If so, you’re all set.
• If you use 802.1x with Wi-Fi but not wired networks, can you provision devices using Ethernet?
• If you use 802.1x with both Wi-Fi and wired networks, and can authenticate using machine certs, can you have the OEM embed a cert in the device image?
• If you use 802.1x with both Wi-Fi and wired networks, and can authenticate using only user certs, you’ll need to use a guest network (ideally one with open, unauthenticated internet access, although a captive portal will work fine).
• If all else fails, users can provision devices on a different network (home, coffeeshop, etc.).

User-driven Hybrid Azure AD Join

Hybrid Azure AD Join has the same requirements as Azure AD Join, but with one additional one:  It needs connectivity to an Active Directory domain controller, so the device needs to be on the corporate network.  Again, looking at the above list of solutions:

• WPAD.  This is effective to help devices discover the proxy server they need to use to access the internet.
• Whitelisting.  This is also effective to help devices access the needed internet URLs.
• Guest network.  This typically isn’t effective, as you would need to still “poke holes” into your normal corporate network in order to access an Active Directory domain controller.  Most security people would frown on this.
• Certificate enrollment.  If the device can’t enroll in Intune and join AD, it won’t be able to enroll any certificates.
• VPN.  This is not presently supported with Windows Autopilot Hybrid Azure AD Join.  It’s something we’re looking at for a future release.
• Temporary bypass.  This could be used to allow access to both the corporate network and the internet.
• Pre-provisioning.  As with Azure AD Join, this will be discussed later as part of the white glove discussion.
• Custom imaging.  This can help with machine certs and proxy configuration, but not user certs (same as Azure AD Join).

Again, recommendations:

• Devices must be connected to the corporate network and have internet access.
• If using a proxy server, it either needs to be discoverable or pre-configured, or bypassed.
• If you use 802.1x with Wi-Fi but not wired networks, provision devices using Ethernet.
• If you use 802.1x with both Wi-Fi and wired networks, and can authenticate using machine certs, the OEM can embed a cert into the image.
• If you use 802.1x with both Wi-Fi and wired networks, and can authenticate using only user certs, you’ve got a problem – see the white glove solution below for a potential solution.

User-driven Azure AD Join with white glove pre-provisioning

As discussed on my Tech Community blog post, Windows Autopilot white glove pre-provisioning splits the device provisioning process into two pieces, a technician phase and a user phase.  The nice thing about the technician phase is that it can be done on any network (yours, a partners, an OEM or distributor’s, etc.) and can therefore provision any needed proxy settings or machine certs, before the user even gets the device.

The one thing it can’t do:  pre-provision user certs.  To do that requires the user to actually sign in (creating the user profile).  So if you are using 802.1x with user certs, this won’t help get the machine on the corporate network.  The same suggestions in the user-driven Azure AD Join section above still apply for the user portion of the process.

User-driven Hybrid Azure AD Join with white glove pre-provisioning

The requirements for doing a Hybrid Azure AD Join using white glove pre-provisioning are actually different than a normal Windows Autopilot user-driven Hybrid Azure AD Join deployment.  Specifically, there is no requirement for the technician phase of the process to be done on the corporate network – it can be done on any network as it does not need to directly talk to an Active Directory domain controller.  So it too can be done on any network (yours, a partners, an OEM or distributor’s, etc.)  This would join the device to Active Directory via the offline domain join process (using the Intune Connector for Active Directory, a.k.a. the ODJ Connector), and provision any needed proxy settings or machine certs, before the user even gets the device.

As with white glove pre-provisioning for Azure AD Join, this too has the same limitation when it comes to user certs – still no way to get those on the device without the user signing in, which must be done on the corporate network because it has to be validated by an Active Directory domain controller.  So see the Hybrid Azure AD Join requirements and suggestions above for that part of the process (keeping in mind the configuration that can be done by the technician process).

Self-deploying Azure AD Join

Windows Autopilot self-deploying mode only supports Azure AD Join.  So it too has the same requirements as the user-driven Azure AD Join section above.  There are some additional networking requirements though, as some devices do not ship with the needed EK cert on the TPM and need to be able to get that cert over the internet “just in time” for it to be used by the TPM attestation process.  The exact URLs that are needed for this can vary by TPM manufacturer.  (See my previous blog on TPM attestation for more details here.)

Wrapping Up

We are looking at ways that we can improve Windows Autopilot to take into account the complexities of existing corporate networks.  Some things that we are considering include:

• Support for the complete Hybrid Azure AD Join process over VPN (as mentioned before, a work-in-progress for a future Windows 10 release).
• Support for configuring proxy settings, either manually (e.g. type them in during OOBE) or via Autopilot (e.g. part of the Autopilot profile).  (If you think manual would be acceptable, let me know – some think this wouldn’t be user-friendly, although other platforms already provide this.)
• Support for getting a complete list of MAC addresses from all of your Windows Autopilot-registered devices, so that you can use that information for whitelisting the devices (e.g. using that instead of 802.1x).
• Support for pre-provisioning user certificates and user profiles.  (This is particularly challenging, so this may prove to be impossible.)

If any of these are of interest to you, please let me know (via e-mail or Twitter, or submit suggestions via https://microsoftintune.uservoice.com).

You can also consider changing your network too.  Zero trust networks are growing in popularity, moving the security boundary to a different place (instead of trying to protect every part of the network).  Or you can consider using a transparent proxy on your network (no need to configure individual machines for that).