But what if that isn’t what actually happens? The following sections provide some troubleshooting suggestions.
If you don’t see these standard out-of-box experience (OOBE) screens, there is either something wrong with your OS image, an unexpected unattend.xml being used, or OOBE was partially completed before the computer restarted. Either start from scratch with a good image, or complete OOBE the rest of the way creating a local account, then reset the OS from the Settings app to start over.
A tip: If you are using a Hyper-V virtual machine, configure the VM to create standard (not production checkpoints). Create a checkpoint before the VM is powered on for the first time. Then start the VM and let it get to the first OOBE screen to choose a language before creating a second checkpoint. These checkpoints give you an easy way to repeatedly test the process. (The first one gives the full experience; the second just saves little time.)
Another tip (as covered in my Ignite session): You can capture the hardware hash from the machine after it gets to the language screen in OOBE. Press Shift-F10 to open a command prompt, then run PowerShell.exe. From there, you can set the execution policy to a reasonable level (RemoteSigned or Bypass) and then install and run the Get-WindowsAutoPilotInfo.ps1 script to create a CSV file with the hardware details. Copy that CSV file to a network location or USB key, then import it into the Microsoft Store for Business. The machine is still early enough in the process that it hasn’t yet checked to see if it is known to AutoPilot. Just exit out of PowerShell and the command prompt after you’ve uploaded the machine. (See https://blogs.technet.microsoft.com/mniehaus/2017/12/12/gathering-windows-autopilot-hardware-de... for more on Get-WindowsAutoPilotInfo.)
If the machine doesn’t have a wired connection and it has a wireless adapter, you should be prompted to connect to an available wireless network. If you don’t have any wired or wireless adapters, nothing is going to help – OOBE is going to short-circuit and end up creating a local account. Assuming you have an wireless adapter, you should be able to connect to a wireless network, even if it requires a captive portal – if it does, you should see a browser window open.
So what can go wrong here? Proxy servers can cause challenges if they aren’t automatically discoverable (e.g. WPAD) or if they require user authentication (there’s no user yet). Wireless networks that require certificates likely won’t work as there will not yet be any certificates. Firewalls might make Windows think that there isn’t a path to the internet.
We’re talking about basic network troubleshooting here, so you may want to use Shift-F10 to open a command prompt for further troubleshooting (IPCONFIG, NSLOOKUP, PING, etc.).
After the network connection is in place, Windows will check with the AutoPilot deployment service (in the cloud) to see if the device is known. If it is, then the customized branding can be displayed with the org name and logo. The customizations you should see are highlighted in red:
If the device isn’t configured to AutoPilot, then you get standard choices (personal vs. work/school if running Windows 10 Pro, a generic Azure AD sign-in screen with Windows 10 Enterprise, OneDrive, Cortana, privacy, etc.). What if you don’t get what you expect? There are a few possible causes:
Assuming you type in a valid username (UPN, e.g. firstname.lastname@example.org ) and password, you should continue to the next step.
Now that the credentials have been validated, the next step is to join the device into Azure AD. This is usually the easy piece, but there are some gotchas that can get in the way:
Once the Azure AD join completes, the MDM enrollment will happen. This automatic MDM enrollment is an Azure Active Directory Premium feature. If that doesn’t happen as expected, here are some things to check:
This is the easy part – I’ve never seen this fail, since the credentials have already been verified and the device is already joined using the same credentials. So there’s no reason why the third usage of those credentials shouldn’t work. After the logon, you’ll see the pulsing status screen while apps are being installed, an MDM progress display (at least once that is enabled by Intune) showing what policies still need to be applied, and finally the desktop.
At that point, the whole AutoPilot-driven provisioning process is complete. To see that the device is indeed being managed by Intune, launch the Settings app, navigate to Accounts –> Access work or school, click the “Connected to <tenant>” entry (which indicates the device is joined to Azure AD) and then click the “Info” button to see the MDM enrollment details:
This will show you information about the policies applied, server URLs, etc. You can also generate an HTML diagnostics report from here, or manually initiate a sync with Intune.
One useful link I found while going through this process: https://docs.microsoft.com/en-us/windows/client-management/mdm/azure-active-directory-integrati... has a table that is useful to look up the error codes that you might encounter (e.g. 801C0003).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.