What best practices should be followed when transitioning from an SCCM-based legacy setup to Windows Autopilot with Hybrid Azure AD Join 

During Windows Autopilot provisioning, users sometimes receive the message "You can't get there from here" due to Conditional Access or authentication requirements. Are there any planned improvements to simplify authentication during Autopilot while maintaining security?

Will Microsoft introduce more flexible device naming options in Windows Autopilot, such as using custom attributes like location, department, or serial number?

Many of us pre-stage devices in inventory before shipping to users — with Autopilot v1 we'd white-glove them so apps like Office were already installed. Device Preparation (v2) dropped that. Is pre-provisioning coming back to Device Prep, or is there a recommended way to stage warehoused devices before they reach the user?

Is there a list of all URLs required for AutoPilot to work? 
Trying to get this working from an on-prem secured network has been pretty painful - still haven't gotten it working yet. It would be great if there was a comprehensive list of all required URLs/IPs/ports, including calling out exactly what URLs don't permit TLS inspection. Also, do you think at some point there could be a troubleshooting tool similar to what O365 has that automatically determines your tenant, tests all the required URLs, etc. and gives you a report of what's working, what's not, and what configuration changes need to be made?

thx

On mobile, we have been purely iOS for the past years, but will soon be absorbing a company that is purely Android. Assume all upcoming android device as company owned. 

1. Which is better enrollment "Corporate-owned, fully managed user devices" or "Corporate-owned devices with work profile"
2. Wil it be better to factory reset the mobile devices prior to enroll, or just enroll. Note we are strict on DLP.
3. How do we ensure that once android device is enrolled that it is on our tenant "forever".

Thank you

Sometimes when we send a device for repair, they replace the motherboard with one that is already registered to a different Tenant. I assume it was not removed from its last tenant when it was offboarded and the OEM reused the motherboard. Is there any solution for this?

I'd like to proactively catch it but it usually shows up when the user tries to enroll in autopilot. At that point, the new hardware hash needs to be exported. A ticket needs to be opened with Microsoft to have the device removed from it's old tenant, and then the new hardware hash can be imported.
Any way to make this less painful?

what are the most common reasons a newly enrolled device remains stuck as not evaluated or pending for compliance. Whats the best route to determine next steps?

Autopilot Device provisioning is not completing successfully, and we are encountering an error stating “Something went wrong” (Error Code: 0x80004005). However, the issue resolves automatically after some time. What could be the reason behind this?