Everything you wanted to know about Windows Autopilot Deployment Program (Part 3)
Scenarios for Windows Autopilot – User-driven, Reset, Self-deploying modesIf you would like to read the other parts in this article series please go to:
Autopilot is a name for modern way of Windows deployment that you will surely enjoy. If you are new to this technology, please check our articles with the overview and pre-requisites for Autopilot. Windows deployment has many faces and therefore there exist many scenarios, where Autopilot can play its role. Grab some popcorn and make yourself comfortable, we’re starting.
The first scenario that was in Autopilot from the start is the user-driven deployment. Microsoft initially supported only joining the device into Azure Active Directory and enrolling it into Intune, with Intune then pushing the configurations down to the machine, so the users could set up the device themselves. We will go through the whole process of deployment for you to see how it looks like in practice.
Imagine, a user opened up a new OEM device like a Surface Book, for example. There is a generic Windows installation directly from the OEM loaded on the device. When it boots up it will ask a few things like the language of the OS, the region and the keyboard layout.
After network connection the machine gets its instructions – it “talks” to the Autopilot deployment service and downloads a profile of settings, which states exactly what organization the machine belongs to and its further “behavior”. The next step will be to act on that – the downloaded settings are used to customize the rest of the user experience. If those settings include a naming pattern (which is available for Windows 10 1809), the device will rename itself and reboot (so don’t worry, it is part of the process). After rebooting it will have the naming convention that you specified, and the user can get back on to the network and then type in an e-mail address and password on the logon page.
The logon page can be customized for your organization or even for the user. If you preconfigure the user, this device belongs to, you can give him/her a nice out-of-the-box experience – users won’t even have to type their e-mail address, only the password will be required and the configuration will be finished in a short time.
During deployment, Autopilot will join the device into AAD. It will trigger the MDM enrollment and once that is over, the machine will start receiving policies. To track the progress of that the enrollment status page (ESP) is quite handy. If you want to set up ESP, take a look “at this article“https://o365hq.com/blog/everything-you-wanted-to-know-about-windows-autopilot-deployment-program-part-1 .
It’s preferable to keep the user at this point until the configurations are completed. You don’t want your user to end up on the desktop while stuff is still happening, as the user is not going to really know what is going on. On the other hand, if all installations are done while the enrollment status page is being displayed, the user gets into a more favorable situation when the device is configured and ready for productive work.
The amount of time enrollment takes can vary greatly depending on how much stuff you’re pushing down to the device, its technical capabilities, and network bandwidth. If you have a lot of software and settings, that could take anywhere from five minutes at the minimum up through potentially a couple of hours. If you don’t want a user to wait that long, you can configure which apps installation will block the desktop and which apps won’t.
When you change from All to Selected, you can choose what apps will be in the block list, so the user will have to stay on ESP before these are installed.
There might be some issues, when tracking Office ProPlus installment, so to avoid these, check out this information .
In Intune you can target policies to the machine, and they get processed during the Device setup phase of the process; also, you can target them to users, and they get processed during the Account setup phase. For example, if you have 1 app targeting All devices and 2 apps targeting a User group, you will see the corresponding information on ESP (0 of 1 in Device setup and 0 of 2 in Account setup). More information here .
Setting up a profile for this mode was discussed here .
р3ю Windows Autopilot reset
The basic concept behind an Autopilot reset is getting rid of any “garbage” that might have piled up on the machine, like extra apps, extra tweaks or whatever. There are two options – reset locally and remotely, but the end result is the same in both of those cases:
- all apps, settings and personal files are wiped clean;
- AAD join and MDM enrollment are preserved so the device is still managed, you won’t get orphaned objects in AAD or Intune, you will continue to use the same ones;
- any provisioning packages that were preinstalled with the OS are preserved;
- the options picked during OOBE, like language and keyboard and some of the details around the network connections are preserved (if you wish to keep these).
Reset will take 20-30 minutes and you will end up at a log-on screen and the machine is then ready to be used by the next person.
In Windows 10 version 1709 you can initiate the reset locally via a keystroke – Windows-Control-R from a lock screen. After this, it comes to an authentication prompt and you should type in an admin account to approve the reset of the device. Obviously, you don’t want that enabled for every device in your organization, so there exists a policy that needs to be configured first to enable local reset. If you try the reset keystroke and nothing happens, you probably haven’t enabled that policy.
The remote piece is new for Windows 1809 and it offers a remote action inside of Intune, where you select the device in question, then click on Autopilot reset, and it sends the reset command down to the device.
Initially, reset option was intended for schools – the machines after the end of semester might get to a point where they need to start over, but there are certainly enterprise scenarios for doing this as well, like when employee is being promoted or leaves the company and his/her computer is prepared for a different purpose.
This mode is not associated with the user. It could be just a shared device, used by people at a help desk, call center or in a school or some place, where anyone can walk up, put in credentials and use the device. It can also be a locked down kiosk or digital signage (like a flight status board at an airport). The user-driven mode doesn’t fit quite right for either of those scenarios, as during the deployment process almost all user interaction is eliminated. On the contrary, with this mode preconfigured on the device, as soon as it is plugged in, turned on and connected to a network, hands off – the deployment is completely zero touch from that point. All you can do is watch the progress of set up.
Setting up self-deploying mode involves the same three steps (as user-driven one): registering your device, assigning a self-deploying profile via Intune, connecting to a network and just booting the machine.
As far as Internet connection is concerned, one thing needs to be pointed out – if the machine is connected to the Internet via Ethernet, the machine will just boot itself. If you don’t have Ethernet or network at boot, you’ll have to interact with this machine just a little bit setting up the Wi-Fi connection.
When you hit next, the device, connected to the Internet (as any other Autopilot machine, starting in 1703 with the July update) is going to reach out to Autopilot service and send up its harbor hash. The Autopilot will send down a self-deploying profile, and if in that profile you have included a device rename, the machine will go down applying the device rename. When the machine comes back up, you’ll see company branded welcome page, and in about 5-10 seconds, you’ll get automatically transitioned over to the enrollment status page.
On this page, you’ll see three different steps – device preparation, device setup, and account setup. Device preparation section, typically, tracks the state of the device as its joining to Azure Active Directory, but how will it happen without a user authentication? A new mechanism was invented to do this, and it requires TPM 2.0 chip for the device to authenticate into AAD on your behalf. Not sure, your devices have the luxury of possessing that? Most modern devices have TPM, or a Trusted Platform Module, which is a dedicated microcontroller designed to secure hardware through integrated cryptographic keys. Make sure it is a physical TPM 2.0 chip, devices with virtual TPMs (like Hyper-V VMs) or with earlier versions of chips (like TPM 1.2) won’t work with this mode.
Next, all the Intune configurations will come down to the device and set up this machine to be a kiosk, for example, launching into directly the kiosk web browser, a new app released recently, to allow you to enable some of the kiosk type scenarios.
Licensing requirements are the same for this mode as for the previous one, the only difference is that it requires a TPM 2.0 chip (because authentication on your behalf happens using that chip) and Windows 10 1809 (or later). If you don’t have it, you’ll see an error in the Device preparation section of the ESP, because it won’t be able to join AAD without user credentials.
Setting up a profile for self-deploying scenario
Under Device enrollment in Intune select Windows enrollment and Deployment profiles. Choose +Create profile, give it a Name and in Deployment mode dropdown select Self-deploying.
When it comes to configuring the OOBE, unlike in user-driven mode, there is nobody, who can configure language, region, keyboard, internet connectivity and then authenticate. All these settings should be automated, so when you are creating Autopilot profile, you’ll see that some new options show up, allowing you to preselect the language/region and the keyboard on the user’s behalf.
All other settings are the same as for the user-driven mode. Hit Save, wait for the profile to assign, and boot your machine – it will deploy itself with zero touches. So, self-deploying mode is ideal for user-less scenarios or shared devices as you may see now.
Autopilot can be used in many ways, this time we discussed how the users can deploy the new devices on their own, how a machine can be reset locally and remotely, and how it can deploy itself without any interaction from the user. More is coming – in the next article, we will focus on how to use Autopilot deployment for existing devices, how to migrate from Windows 7 to Windows 10 with Autopilot, and how to join a device to your on-prem AD during OOBE (in other words called hybrid AAD join scenario).
Download our PDF Zero Touch Deployment.pdf