If you’ve gone poking around in the available device configuration policies in Intune, you might have seen this one in the “Device Restrictions” category for “Windows 10 and later” devices, in the “General” section:

But what does that “Require users to connect to network during device setup” actually do? The intent is simple: Don’t let the user choose to skip making a network connection (since most machines are Wi-fi connected, they aren’t connected by default) and therefore skipping the process of making it a corporate-joined (Azure AD or AD) and managed (Intune) device.  (See the CSP documentation for the documentation for the behind-the-scenes MDM policy.)  But the implementation of this is more complicated.  In addition to this setting, you also need a second one, which is available in the Windows Autopilot profile:

This “Hide change account options” setting keeps the user from saying “I’ll create a local account instead.”  (You might notice that the setting is disabled in this screenshot.  It shouldn’t be, we’ll fix that.  So right now, you can specify the setting when you create a new Autopilot profile, but you can’t change the value after the profile is created.)

So these two settings work together:  One requires that the device connect to the network, which then makes sure the Autopilot profile is downloaded; the Autopilot profile setting then keeps the user from “skipping out” of the process.  But these settings in practice are rather hard to implement:

• You can’t get the “Require users to connect to network during OOBE” setting to the device before it is connected to a network, joined to AAD/AD, and enrolled in Intune – it’s a device restriction policy delivered by Intune.  (If you get a device that is configured in S Mode, this setting is in place by default.  But due to compliance issues, this can’t be enabled for non-S Mode installs.)
• You can’t get the “Hide change account options” setting to apply if there’s no network connection that can download the Autopilot profile.

So, what good does it do?  There are two scenarios that work well:

• White glove.  If you have a technician pre-provision the device before it is delivered to the user, these settings can be applied and enforced so the user can’t skip out.
• Reset/reimage.  The “Require users to connect to network during OOBE” setting persists across Windows 10 installations.

If you are paying attention, that second point should get your interest.  How does a policy setting get persisted across Windows 10 installations?  Simple, a UEFI variable is set to indicate that a network connection is required, and Windows 10 1809 and above always check that UEFI variable when going through OOBE.  (If you need yet another reason to use UEFI, here it is.)  And if your thoughts are jumping ahead to “why can’t the OEM set this variable before they ship us the devices” (even when not using white glove) the answer is that they can – something we’re looking into.

There is an interesting side effect of this as well:  If that UEFI variable is set and you try to apply a Windows 10 image using an unattend.xml, the device can get “stuck” in OOBE because it thinks you are trying to skip the network connection (and technically you are, using the unattend.xml to do it).  So be careful with that if you are planning to do “old-style” reimaging of the device using MDT, ConfigMgr, etc.