Recently I have been having conversations with clients about Microsoft Autopilot. When I am having these conversations I always start by telling those on the call or in the room what Autopilot isn’t. This may sound like a strange way to open a discussion but there is a very good reason to open this way in particular when it comes to Autopilot.
The reasons that clients are asking about Autopilot and how to adopt it are many. They may have seen it mentioned by Microsoft on social media or blog posts. One of the guys on the team may have heard about it and tried to set it up, or their current build process is getting a bit long in the tooth and it may be time to look at its replacement.
A big driver for companies now may also be the migration away from Window 10 to the adoption of Windows 11. If the client is deploying brand new hardware which is being ordered with Windows 11 Pro or above, they are good to go. If they have fairly new hardware in the field, then a rebuild will be required and Autopilot will not be able to help.
This is where the title for the blog came to mind. Clients are asking about Autopilot mainly to replace their build process. The current process could be based on a 3rd party delivery system or may be based on System Centre/Microsoft Configuration Manager (SCCM) Task Sequences. The conversation normally starts with the client saying they want to replace their build process and use Autopilot as they are getting rid of SCCM on-premises and going “Cloud Only”.
My response to the client at this point is that you need to understand that Windows Autopilot is not a tool for producing or distributing builds across endpoints. So again back to the title of this post, Autopilot, what it isn’t.
So what is it then…
Autopilot is the first step to adopting cloud management.
At its most basic Autopilot will tie hardware to your 365 tenant and let you reset the device remotely to its Out Of Box Experience (OOBE). You have a couple of options available to you to select in an Autopilot “Profile” such as accepting the EULA, is the user a local admin or not and setting a naming template. But that is about all you can do with Autopilot.
After resetting a machine that has been registered to Autopilot it will pretty much return to the way it was when it was taken out of the box with a computer name based on the template you decided. And most importantly it will have the manufacturer tested firmware and drivers.
What you will not have after doing this is:
- Any Settings or configuration
- Desktop Wallpaper
- Registry Settings
- Encryption
- Applications
- Company Specific Configurations
- Updates – Microsoft or 3rd party
So at this point the owner of that computer isn’t going to be very productive. No applications, no Onedrive, nothing.
But the old build process had all this stuff already there and the user would be fully productive within x mins, so what gives???
When it comes to Autopilot it is only a single step of a multistep process to give a fully configured endpoint to a user. To deliver a fully configured and secured endpoint to a user and for that user to be productive the conversation needs to pivot to discuss Microsoft Intune.
The Solution
Using Autopilot to have the device registered to the 365 tenant and an Autopilot profile assigned and the device auto-enrolled in Intune is the first step. Within Intune the following will need to be configured to closely emulate the legacy build process:
- Applications
- Device Configurations
- Endpoint Security Settings – Encryption, Antivirus, Firewall etc
- Updates – Rings or Autopatch
Each of the above points may well be a full project in itself and should be discussed in full with clients. Normally around this point the realisation sets in that Autopilot isn’t what they thought it was and they may be considering sticking with the Microsoft Deployment Toolkit Task Sequences they already have.
That is now the point that the conversation needs to cover the benefits of moving device management to Intune and the fact that there is no longer a requirement to build machines “in the office”. Another modern driver for adopting cloud managed endpoints may well be that clients may be looking to remove offices and go full remote, IT is no longer a blocker in this process. Devices can be sent direct to users wherever they are as long as they have an internet connection, they are good to go.
Conclusion
So when we have meetings come in that clients want to talk about Autopilot we already have the meeting agenda ready to discuss Intune.
It is likely that the “heritage” build process can be replicated to utilise Autopilot with Intune and achieve pretty much the same results. There may be the odd thing that need to be taken care of with the use of Powershell scripts but these will likely be very client specific.
Once the policies and settings have been agreed with the client to closely emulate their existing position it is then time to move the discussion on to how to best automate as much as possible, I will cover that in a future post.