Thank you everyone, and for responding to my question in the AMA recording, it is much appreciated 🙂

In addition to Maggie's comment below, she also covered this question during the live AMA around 42:44.

Take a look at this: https://learn.microsoft.com/en-us/intune/intune-service/enrollment/windows-enrollment-status?source=recommendations#block-access-to-a-device-until-a-specific-application-is-installed. The behavior defers based on the mode and type of app. Hope this helps!

Thanks for your participation in today's AMA. The panelists covered this topic around 44:13.

We previously used QuickCreate HyperV wizard with offline JSON provisioning (the JSON file injected into the Windows folder inside the VMDK). Today, we cannot offer this service any longer, because this offline JSON provisioning is no longer supported.  We were told to use Corporate Identifiers, but it requires device intervention as  YesaitRavanty said, because you need to pass the Corporate Device Identifier to the Intune Admin so that he/she adds it to Intune.

YesaitRavanty : there is no recommended approach as of today, as Device Prep seems still in early days : no device renaming (MS : yes, we understood that labeling on device name is bad. It is however useful when talking to your IT colleagues about A-devices, T-devices and C-devices, for Admins/Teachers/Classmates for example), no GroupTag (means there is no persistent variable, that is kept across new Windows OS reinstallations, like for example creating rings of devices using EntraID groups), no OOBE customization to bypass the privacy questions, and no much ability to recognize some basic company branding when device boots for first time so that you feel welcome.

We appreciate your participation in today's AMA. This question was covered around 36:08.

I'm referring to using Microsoft Graph and sorting out Autopilot object ID/Intune object ID/ Azure object ID. 

Thanks for participating in today's AMA! This question was answered at 33:00.

This question was covered in today's AMA around 29:12. For more information, go to aka.ms/CloudNativeEndpoints 

The device actually is renamed to %serial% before MDM enrollment, but unfortunately is overwritten later when the device is hybrid-joined.  This is a known pain point that's on our backlog.

A few years back, Jon Callahan posted this blog that walks through recommendations for what apps to push in Autopilot, Selecting Required Apps for your Enrollment Status Page | Microsoft Community Hub In terms of troubleshooting, check out https://learn.microsoft.com/en-us/autopilot/troubleshooting-faq 

Could you clarify the flow you're thinking of?  It's not clear what "pre-boot" PIN here means.

The panelists covered this topic around 22:27. They also encouraged you to go to aka.ms/AutopilotDocs for more information. 

You can have successive self-deploying (or pre-provisioning) deployments on devices from certain OEMs by selecting the device on the Autopilot Devices page and clicking Unblock between deployments.  Hope this helps.

Thank you everyone, and for responding to my question in the AMA recording, it is much appreciated 🙂

This question was covered at 24:48 during the AMA. 

Thank you. We do set most of our apps to AVAILABLE however some mandatory security or app updates we cannot leave to/rely on the users to self-serve from Company Portal (because they won't do it...). Maggie - I read in a few places that the Autopilot "Block list" still lets other REQUIRED apps install during Autopilot, which is why we haven't implemented this method. Is there any truth to this?

There's a slew of logs captured today, and it'd be surprising you won't be able to use them.  :)  Configurability of auto-logs collection logs paths is on the backlog.