AutoPilot vs ConfigMgr OS Deployment

This is, in effect, the holy grail and the final link in the chain for me to move all things EUD related away from ConfigMgr, and into Intune. However, so far I’m not overly impressed with how AutoPilot works compared to how ConfigMgr’s OS Deployment, and indeed even MDT, works

The ConfigMgr way

With a Task Sequence, I can manipulate the OS to a greater extend during build, than I can with AutoPilot

A big one for me is the Default User profile – I regularly inject customised settings into it so that global apps have the necessary settings they need, without a ton of post-deployment legwork.

I have a customised Start Menu that strips out a lot of the un-necessarily pin apps – leaving it with functional tools like Edge, Software Center, Settings, Control Panel and the Snipping tool on one line and then Office apps on the second – and allows the user to then pin their own apps, or re-arrange if needed.

I try not use Group Policies for these as they can be too restrictive in allowing end users to do that.

The AutoPilot way

When I tried to do that with AutoPilot I found I had 2 options – Post deployment via a script or a modified WIM file – both of which work but both have issues

Scripting it

Lets take the script approach – This is by far the weakest option. It doesn’t apply immediately after build, like all Intune scripts and apps, you need to wait for the device to sync into Intune – and this can be either relatively quick, or several minutes depending on how it processes.
The other issues is that if, for any reason that script fails, it then will not rerun leaving a broken build. “But that’s what remediation scripts are for” I hear you cry – well yes – and no – the problem there is that it has a tendency to redeploy and wipe any changes the end user has made

The WIM way

The other option, of injecting it into the WIM file, is more reliable and available out of the box – but is time consuming, and if you change the version of Windows, or even just a start menu item, then you need to go through the whole process again of Mounting an ISO, extracting the WIM then mounting it, transferring the data, then unmounting the WIM and rebuilding the ISO again.

To, Autopilot feels like a massive step back to the old days of Norton Ghost and RIS/WDS where you had t build a reference PC, install all your software and customise it as you see fit, then capture that into an image.

Granted, AutoPilot allows for apps to be deployed during the build, but even this I’ve had issues with and had to do some apps post build – or even manually!

In summary

Despite all that, I can see the benefit of AutoPilot – especially for those who have remote workers where they can rebuild a laptop without them needing to come back to their nearest office to have it done.

But then again, I feel that this shouldn’t be the responsibility of an End User – that is for the IT staff to do.

Maybe I’m just set in my ways with this, but if you have ConfigMgr, or MDT already in place, then I feel Autopilot is a massive step back to the old days

Even app deployment isn’t as easy as it is with ConfigMgr – especially when doing first builds – if it fails, it can take an age to get a device to try again. Scripts are even worse if you don’t use remediation scripts. I tend to think of scripts of being very much the UDP of the Intune world – It’ll do it once, but doesn’t care if it fails or not.

Share

2 thoughts on “AutoPilot vs ConfigMgr OS Deployment

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.