Recently, Microsoft introduced its Windows Autopilot program. Autopilot allows a device to be associated with your tenant before the device is ever even turned on. In essence, this gives you the ability to stage all device configurations to the device before the initial Out of the Box Experience (OOBE). In plain English, it allows IT administrators to do zero-touch deployments of new devices to end-users.
1. User-Driven: This requires the user to sign in using their Azure Active Directory (Azure AD) credentials. This will then run through all configurations targeted to the device and the user (must be version 1809 or later).
2. White Glove: This allows a tech to tap the Windows key five times to initiate white-glove mode and pull any device configurations before shipping to a user. This is incredibly helpful if the user has limited/poor internet access or if application installs and configurations take a significant amount of time. The idea here is to have all applications and device configurations installed before receiving the laptop. This way, the initial login and time needed before the device is work-ready is reduced significantly from the end-user’s perspective. An ethernet connection is required. The device must also support TPM 2.0 and device attestation. Virtual machines aren’t supported (must be version 1903 or higher).
3. Self-Deploying Mode: This mode is limited because it’s only compatible with deployments that the device does not require user affinity. These types of deployments include a kiosk, digital signage device, or a shared device. In this scenario, all that’s needed by the user at the OOBE is to choose the language, locale, keyboard, and make a network connection (must be 1903 or higher).
For the intent of this blog, we will focus on User-driven mode.
Well, depending on the partner that is providing your devices, you have two options:
1. Some 3rd party vendors and Original Equipment Manufacturers (OEM’s) are willing to register the devices on your behalf. Usually, there’s an extra fee associated with this service.
2. Register the devices manually
I recently ran into this issue with a customer. We worked with a 3rd party that does three-year leases of new Surface Laptops with an option to buy out the device at the end. They don’t offer an option to import devices on the customer’s behalf, and we were never going to be able to physically get our hands on the devices before the customer received them.
However, the device serial numbers were listed on the invoice, and with some Google-fu, we found what the device model and manufacturer name would be. So, we had our tuple information.
If you want to use the last-mentioned tuple and don’t have that information, you can fire up a single device and start PowerShell.exe, run “gwmi Win32_BIOS” and “gwmi Win32_Baseboard.” This will give you the model and OEM details. Combine this information with the serial numbers provided on the invoice to complete the tuple.
Let’s start by creating the dynamic device group to apply these configurations. Autopilot devices have a unique device attribute that is only added to devices enrolled via Autopilot. We can use this attribute to build out dynamic groups that contain only the devices we wish to target. The device identifier used is [ZTDId]. A group for devices that are all autopilot enrolled would have a rule syntax similar to the below: (device.devicePhysicalIDs -any (_ -contains “[ZTDId]”))
Before these devices can be enrolled in Intune, we need to ensure that they are allowed to be enrolled. You can choose to scope this or enable all users to enroll devices into Intune. It all depends on your setup. To check this setting, login to the Azure Portal, go to Azure Active Directory, and select the Mobility (MDM and MAM) blade. From here, choose Microsoft Intune and modify the scope to your desired settings.
Something to note, if you intend on using MAM (Mobile Application Management) in your environment, it is crucial to scope this and not set to all users as it has a higher affinity then the MDM URL and could cause issues with Intune enrollment. I would recommend scoping it to a dynamic group that does not include any Windows 10 devices.
Congratulations, we now have all the pieces in place to do a user-driven autopilot deployment with autoenrollment to Intune to manage devices! We can now go ahead with Intune configuration and create policies that will push to the device at first log in at the OOBE. These configurations can include anything from application installs, security settings, and even network configurations.
Stay tuned for part two of this blog, where I show you how to deploy custom apps through Intune with Win32 App configuration deployments.
Need help understanding Intune or have additional questions? Contact a member of Withum’s Advisory Services team!