AMA: Enrolling modern devices with Windows Autopilot

Hi Daniel, the “block device use until required apps are installed..” setting can be set to ALL if you are doing pre-provisioning and want all apps to be tracked in ESP. The challenge with doing this is that the whole process will fail if an app that’s targeted fails but is not necessarily crucial to deployment. We are working on improving this experience for more flexibility in the pre-provisioning phase in the near term.

If your users accounts are hybrid, give pure Azure AD Joined devices a try. Very few things require Device authentication and hybrid-User authentication just works -- for most things. The only place we struggle is Windows will first try to authenticate the user with their modern auth token, when things like our RADIUS server and old web applications require username and password authentication.

Hi Michael, after you've added a Win32 app to Intune, you can use Intune to create one or more supersedence relationships between apps. In general, supersedence is where you update or replace something. In Intune, supersedence enables you to update and replace existing Win32 apps with newer versions of the same app or an entirely different Win32 app. Here is a doc to help further: https://docs.microsoft.com/en-us/mem/intune/apps/apps-win32-supersedence

In our environment new devices coming with bloatfree OS directly from Lenovo & Dell (extra costs). This doesn‘t work when buying from the store near buy. To get a fresh OS I recommend OSDcloud from David S. It downloads/installs official business version of Win10 or 11 directly from MS source and injects drivers from Dell,Lenovo,HP,Microsoft,VMware from vendor sources based on hardware. You just need 8GB USB pendrive and the custom script is even possible stored in Azure storage account …

Thanks for the live reply on this one. Regarding to the bloatware side, it would be nice to have a clean image install possibility, I would say during pre provisioning or maybe even during user provisioning. I believe vendor tooling should be secured by deploying them through Intune. That I would like to manage as an IT department.

We're investigating installing OS updates during the Autopilot flow (i.e., moving the OS forward to a desired version). Moving the OS back to a supported version is very hard, including inventorying OS images, drivers, firmware, etc. With respect to bloatware, we did have an idea of offering an option to reset the device with the option to remove bloatware during the Autopilot process. We've never ranked it too high, since that's a horribly long process to do a reset, and would be a bad experience for the end user. If you have other ideas or thoughts, we're open to them, too.

There is a myriad of reason for this that all stem from this not being our recommend or preferred path for provisioning new Windows endpoints. Is there a specific reason that you must have a device object in your on-prem AD? Keep in mind that authentication to on-prem resources does not require this in the vast majority of cases; see https://docs.microsoft.com/en-us/azure/active-directory/devices/azuread-join-sso for reference.

The feature was designed with a CMG in mind as a general core assumption of Autopilot is that connectivity to the on-prem environment may or may not exist. Ultimately, as long as the ConfigMgr client can communicate with the site, there's no reason it shouldn't work. Providing that connectivity would be tricky during Autopilot though (I can't actually think of a way to make it happen) as there is no VPN client deployed or connected at this point in Autopilot and IBCM wouldn't be sufficient either as the device hasn't had a client auth cert deployed to it yet.

That depends. Today, there is no explicit coordination or orchestration between the different deployment methods and so it's possible that conflicts occur because of this. These conflicts are generally unpredictable and thus terribly difficult to discover or troubleshoot. Thus yes, we ultimately recommend that folks avoid mixing the multiple types of app deployment during Autopilot. Packaging your MSI-based apps as a Win32 app is a fairly straight-forward and quick process so avoiding these conflicts is also straight-forward.

Hi Anthony, LAPS isn't directly related to Autopilot so whether or not you use LAPS and whether it supports hybrid Azure AD joined Windows endpoints are two distinct capabilities for you to choose, As for when will an Azure-based LAPS solution be available from Microsoft, as has been revealed recently in a recent Windows Insider's release blog post, we are currently working on this but have nothing specific to share about timelines for release and integration with MEM at this time other than yes, this is something we are working on. However, keep in mind that our strongly recommended path for new Windows endpoint provisioning is Azure AD join -- hybrid Azure AD join is meant for existing devices only and shouldn't in general be considered for new device provisioning. See aka.ms/cloudnativeenedpoints for a lot more details on this.