I work in consulting and quite often get asked to review an existing Autopilot deployment that was either built in-house or by a team of Highly Paid Consultants [A Typical HPC]. Unfortunately, I see the same mistakes made over and over again by different organisations.
Too many apps pushed as required apps during the enrollment
Apps that force a reboot during enrollment
Basic UI elements like a business start menu not being set
Lots of PowerShell scripts added to Intune that use dirty hacks to clean-up parts of the build
The net result is a lack of quality, low standard of polish and unreliable enrollments. Unfortunately those kinds of low-grade builds have given Windows 10 Autopilot a bad name.
All Windows client deployment methods are hard. Whether it is MDT, OSD, Autopilot or another method; Developing and maintaining a reliable deployment is very hard. OSD has a deep base of community solutions and some great published books. Windows 10 Autopilot has not reached that level of maturity (yet!). Some great work is being done but very little is being published to the community.
One of the reasons that I started blogging was to spread knowledge and widen the installed base of successful solutions. I will go into detail on the how in future articles but I would like to demonstrate what good looks like with this article.
Strategy
The strategy for a successful Autopilot enrollment is simple. I use these principles on my deployments.
Minimize the number of required apps
Do not deploy Microsoft Office during enrollment
Use a tight set of device configuration policies
Use a deployment package to set UI elements and perform key OOBE setup tasks
Deploy any complex applications (applications with dependencies or requiring reboots) with a post-installation routine
The aim is getting past enrollment and to the desktop as quickly as possible. Enrollments that reach the desktop are much easier for the support teams to troubleshoot . Any enrollment that times out or errors on the Enrollment Status Page will generate support tickets and give a bad impression to end users.
Application Do and Do Not
In an ideal deployment the only applications that should be pushed as required apps during enrolment are.
Internet Browsers (I.E. Edge and Chrome)
The deployment package
Required security software (I.E. Proxy agents, Anti-Virus)
I prefer not to deploy required security software during enrollment because quite often the security software installation is badly behaved. A number of security products will force a reboot regardless of what installation options you set. Proxy products also have a tendency to block access to Internet sites required by other parts of the enrollment.
Installing Microsoft Office during enrollment is a leading cause of installation failures. The way that the Microsoft Office Click to Run installation behaves means that the Enrollment Status Page cannot always tell that the installation is still in progress. Two common issues occur, 1) the installation fails because a reboot occurs midway through the installation, 2) the Office installation causes enrollment to time out on a slow Internet connection.
If the device reboots between the Click to Run service being installed and the completion of the Office setup then the installation will be unrecoverable without admin intervention.
Deployment Package
Using a deployment package is critical to a successful deployment. I will cover deployment packages in future articles but I would recommend using the Michael Niehaus Autopilot Branding package [LINK] for your initial attempts. As you progress then I would recommend that you develop your own deployment package.
Post Installation
After installation you can adopt two strategies to complete the application installations and device setup.
Provide instructions to end users on installing optional apps from the Company Portal
Automate using script or a Co-Management task sequence
Getting end-users to act as meat robots is surprisingly successful. You can use enrollment reporting to determine whether the users followed the instructions.
In an ideal world every deployment would have a fully automated post-enrollment routine but developing those kinds of solutions are hard to build and harder to maintain. Sometimes a set of instructions are more effective than automation.
End Result
I recorded a video to show what a good enrollment looks like. The video was recorded on a virtual machine so the video was edited to cut the long pauses in reboots. No errors were removed from the video.
No shortcuts were taken. The applied configuration is a highly secure configuration that would pass a security review. And the build is fully functional as a daily use device.
On the virtual machine the enrollment including post-enrollment activities the enrollment took just over 50 minutes. On a physical device the same enrollment takes about 30 minutes.
Note - A post enrollment script performs a number of post-install setup actions including the installation of Office. You will see that in the appearance of the start menu immediately after enrollment and after the Office installation.
The video link can be found here [Autopilot Demonstration February 2021]
You have a policy causing a reboot from Computer to User setup. Re assign certain policies to the USER and you should be ok.