Category: Cloud

Bulk deployment of end-user computing (EUC) devices is a fact of corporate life, and has been for at least 20 years. The vendors and products change, but the task remains essentially the same: how to distribute devices to staff with the desired applications and configurations.

This blog is about deploying Windows devices, and for the managers of the process rather than the technicians. Windows deployment is a mainstream topic with some excellent technical commentary from Michael Niehaus, Peter van der Woude, Rudy Ooms and others. There is rather less about the pros and cons of different methods.

Autopilot v1.0 provides a cloud service for Windows deployments, to replace on-premises re-imaging. But it can be unreliable, and is a slower experience for the end user unless you prepare (pre-provision) the device in advance.
Autopilot v2.0 (called Autopilot Device Preparation) is significantly simplified and so should be more reliable. Currently, it lacks a pre-provisioning mode, which restricts it to the slow experience. But this is mitigated by a new feature that allows you to select which apps are installed as a priority before the user reaches a working desktop. The more standard apps you have, the more of an advantage this is.
It may be unfashionable, in the age of cloud services, but an on-premises re-imaging service combined with Autopilot v2.0 will probably provide the most efficient result overall.

Deployment

The aim of deployment has been remarkably consistent. I can’t see that it has changed at all: take a device from the manufacturer, and convert it to one that is ready for work as efficiently as possible.

Image –>

Re-image –>

Identity –>

Applications –>

Configurations

1. Image
   • The OS image deployed to the original equipment by the manufacturer (OEM)
   • Because manufacturers generally compete in consumer as well as business sectors, the OEM image tends to contain a variety of other applications: freeware, trialware and vendor utilities.
2. Re-image
   • A custom image deployed in place of the OEM one
   • Either simply to remove all the vendor-added software
   • Or to do that as well as add corporate software, in order to speed up the overall process of delivering a fully ready device
   • Done by a wide variety of imaging tools: historically, Ghost; then Altiris, Windows Deployment Services (WDS), Microsoft Deployment Toolkit (MDT), FOG and many others.
3. Identity
   • Enrolment in an identity management system, so that the device is recognised as a corporate device, and the user logging on is recognised as a corporate user
   • Either on-premises Active Directory, or cloud Entra ID, or a hybrid of both.
4. Applications
   • The installation of corporate applications by an agent on the device
   • The agent can go on to patch and replace applications during the life of the image
5. Configurations
   • The configuration of different settings on the device
   • Everything from BitLocker to certificate authorities to Kerberos to application configurations (if the application is designed to store settings in the registry)
   • Ultimately these are done by settings in the registry, or by running a script or executable
   • The available settings are defined either in XML-formatted templates (ADMX) or Configuration Service Providers (CSPs)
   • Different device management tools generally provide an interface to set these configurations.

So the aim is to get from 1 to 5 as efficiently as possible. What are the obstacles?

Step 2 is an expensive step. The OEM device has to be unboxed, re-imaged, and re-boxed for delivery. If you re-image with a “thin” image (no applications), then there has to be time to install all the applications later. If you re-image with a “fat” image (all the applications) then by the time it gets to the end user there is a good chance that some of them need to be updated. If you re-image well in advance, the device will need Windows updates and possibly even a full feature update e.g. from Windows 11 23H2 to 24H2.

Step 3 is a complicated dance that has to be carefully controlled. The process has to ensure that only the devices you want to enrol can enrol (e.g. not personal devices); and that all the devices you want to enrol are enrolled (i.e. not bypassed).

Steps 4 and 5 are really about timings. You don’t want to deliver a device to a member of staff until it is ready to use; but you also don’t want them sitting idle watching a progress bar.

Up until perhaps 2018-2020, this process was performed with on-premises infrastructure, SCCM being perhaps the most common but with many alternatives.

Autopilot

Windows Autopilot, introduced in 2017, changed this model in a really quite radical way. What it did was to make every single new Windows desktop OS in the entire world check in first with the Autopilot cloud service to see whether it is a corporate device. It is worth having a look at the Autopilot flowchart. If we simplify it a little, we have two flows:

1. Start, and connect to the Internet; get the unique hardware ID of the device; then check with the cloud Autopilot registration service whether the device is registered; if it is, get an Autopilot profile for setting up the device.
2. Follow the Autopilot profile to enrol the device in Entra ID and in Intune; then use Intune apps and device configuration profiles to set up the device.

Autopilot also has a secondary flow, to set the device up in a technician phase first; and then, if the device is assigned to a user and not used as a kiosk-type device, perform a second phase depending on the user account. This technician phase is equivalent to the re-imaging phase in Step 2 above.

Autopilot changes the way devices are deployed because, using the first workflow (“user-driven mode”), you can send the OEM-supplied device direct to the end-user. The device will always check first whether it is registered in Autopilot, and then set itself up accordingly. Or, using the secondary workflow, you can part set it up, then deliver it to the end user to complete. Being a cloud service, it also appealed to organisations that wanted to reduce their on-premises services.

There were two main problem with this. The first is that the process has been (in my experience) unreliable. The second is that, unless you insert the additional step of pre-provisioning the device, the setup is inherently a slow experience for the end user.

For unreliable, see my previous blog: Autopilot and Intune faults. Just to be absolutely clear, these are not configuration errors. They are backend faults in the service causing unpredictable and unsolvable failures in the status monitored by the Enrollment Status Page (ESP). It is hard to put a number on this, but I would say it was perhaps 2-5% of all deployments. That might not sound a lot, but lets take two scenarios:

• The device is sent to a member of staff working from home; it fails to build correctly; they are stuck at “setup failed”. What happens now? They are at home. The support staff can’t see the screen.
• You are helping a group of people migrate to their replacement device, in a large migration. One or two fail at Account Setup. The staff can’t leave, because the device doesn’t work. Do you try a reset and start again? Do you give them another device and start again? Do you try to fix it?

For slow, a user-driven deployment might take perhaps 20-30 minutes on an excellent network, depending mainly on the number of applications to install and uninstall. If you are on a poor network, say at home, then it might be a lot longer. For the end user, this is time spent simply waiting. If they go away to do something else, they will not come back and find it done, because it will be waiting at a logon prompt before starting the Account Setup phase.

In contrast, I would say that an on-premises deployment should be 99.9% successful and fast. The device is almost fully built by a technician, before being handed over. I really cannot remember any significant level of faults, once the deployment is fully tested and piloted, so the user phase is short and reliable. Of course, it requires double handling, as in Step 2. But the double-handling is the same in the case of pre-provisioning.

Autopilot Device Preparation

Autopilot v2.0 was introduced this year, 2024. It is a radical rethink of the original version. There are four main changes in the architecture. The question is: will they make the process more reliable, and faster?

1. There is no pre-registration of the device hardware ID
2. There is, as yet, no pre-provisioning or unassigned-user mode (called “self-deploying”)
3. The ESP is, by default, replaced by an extension of the Out of Box Experience (OOBE)
4. A list of priority apps and scripts is used instead of a list of blocking apps.

No pre-registration

Instead of using a global registration service, it works as follows:

• The end-user account is added to a security group
• When the account signs in on any unmanaged device, that device is automatically enrolled in Entra ID and Intune
• Intune assigns a Device Preparation profile to members of the user group
• The profile adds the device to a device group
• That device group is used to install applications and configure the device.

This is a big change in architecture. The hardware ID used for device registration is a bit like the boot configuration used to prevent Windows licence fraud. It is explained in this blog: Autopilot hardware hash. Registration ensures that only a registered device can enrol, and that all registered devices are enrolled.

Registration was not difficult, for a large organisation. Either the vendor registered all new devices, or a script could be run to extract them from all existing devices. It is another step, but not a big one. I think removal of this step is more of an advantage for small organisations, where extracting the hash could be quite difficult.

If the step was not needed, why was it there, and what are the consequences of removing it? It seems to be a balance of risk. Autopilot v2.0 now allows an option of providing a simpler corporate device identifier. This could be used to prevent enrolment of unauthorised devices. But, for Windows, the identifier still has to be pre-loaded as a CSV of the device manufacturer, model and serial number. It is just slightly easier, since it does not require access to the device to obtain it.

No pre-provisioning

Autopilot v2.0 currently only supports the primary, user-driven, workflow. Microsoft says in the FAQs that: “The pre-provisioning mode and self-deploying mode scenarios will be supported in the future, but aren’t part of the initial release.”

Pre-provisioning is a fundamentally different workflow from user-driven.

• At this stage, we usually don’t know what user will receive the device. It is a bulk preparation process, similar to re-imaging
• Because there is no user account, and so no authentication or authorization, it uses a different process to validate the identity of the device
• This process requires the “attestation”, or proving the identity of, the Trusted Platform Module (TPM), the unique hardware component incorporated in the device by the vendor. This proves that the device is the one registered in Autopilot, and not an imposter.

Since there is no pre-registration in Autopilot v2.0, it will not be possible to attest that the device is the one registered. We will have to wait and see how Microsoft solves this. But, without it, we lose the ability to cut the end-user wait time in half. An alternative is to re-image the device with standard applications installed, before handing over the device for a deployment with Autopilot v2.0.

No Enrollment Status Page

The ESP controls the flow of Autopilot v1.0. A failure at any step causes Autopilot to end with an error. Depending on the profile, the user can then either reset the device and start again, or continue anyway to a part-completed desktop.

As I have described elsewhere, the failures are sometimes caused by faults in configuration, but often by unknowable back end failures in the cloud services. Microsoft even recommended at one stage to not use the ESP to track progress.

In Autopilot v2.0, the ESP is optionally replaced by a simple progress indicator during the OOBE dialogue. I think this is easier for a user to understand. The percentage progress, however, is not the actual progress through the work. It is the percentage of the total time allowed before the process times out, default 60 minutes.

The ESP itself is not the cause of failures. However, other failures in the process cause it to terminate Autopilot, even if those failures are not fatal to the deployment.

List of reference apps

The change with the biggest impact on the end-user experience is the list of “reference apps”. It is an ambiguous term. It means the apps to install during deployment. All other apps are installed after the setup is complete.

Autopilot v1.0 has the concept of “blocking apps” in the ESP. These hold the deployment until they are installed, and raise an error if they fail. The choice is none, selected apps, or all. If you configure All, then the deployment will take longer than if you configure Selected (although, if you pre-provision, this time does not matter). However, if you configure Selected, other apps are not installed. Instead, they will wait perhaps an hour for the next sync cycle. This may or may not be acceptable. In my experience it is not.

Autopilot v2.0 replaces this with “apps you want to reference with this deployment”. These apps are installed during the deployment. Unlike v1.0, all other apps continue to install without a pause, but without holding the setup. This gives a better user experience than v1.0, because it might only be another 5 -10 minutes before all the required apps are installed. With this design, I think it is reasonable to finish setup with a subset of apps, for example Office 365, Company Portal and a VPN or zero-trust network client, and perhaps any configuring “apps” (scripted configurations deployed as custom win32 apps). There is always more to do in the minutes immediately after setup is complete, and while the other apps are installing.

You might say this is making the best of a bad job, because with no pre-provisioning the only alternative is to hold the setup until all the apps are installed. But I think it is actually a realistic alternative to pre-provisioning. It really depends on whether you can package everything up to deliver an acceptable desktop in an acceptable amount of time.

The list of reference apps also cuts out a minute or more spent enumerating apps in Autopilot v1.0. Instead, Autopilot v2.0 only installs apps from the single device group specified in the profile. Microsoft calls this Enrollment Time Grouping.

Summary

I am optimistic that Autopilot Device Preparation (Autopilot v2.0) will be more reliable than v1.0, because the process has been simplified: in particular with no ESP and so fewer reasons for failure.

It is not faster. You might expect it to be, and Microsoft claims it to be (because of Enrollment Time Grouping). But my tests do not bear this out. It takes a given amount of time to download and install apps, and this does not change. It is possible there is less time spent enumerating the apps to install, but this does not translate into a shorter time overall.

However, the new ability to specify the must-have apps, and for installation of other apps to continue outside of the setup window, gives an opportunity to cut the waiting time for an end user.

The lack of a pre-provisioning mode means that you cannot take the theoretically fastest route (barring failures) of preparing the device with all apps before giving it to the end user. It might be unfashionable, but this means there is a rationale for re-imaging the device with a conventional on-premises technology before shipping it to the end user to complete with Autopilot v2.0.