Currently, Azure AD Hybrid Domain Join (In Preview) does not allow the use of variables such as %SERIAL% or %RAND% but only allows the use of a simple prefix such as WIN10- for the computer name. This is an important feature that does currently exist for standard Azure Domain join but not Hybrid where customers need to ensure the device enrolls in Autopilot in Intune, but also in the local network AD domain.

I wrote a blog post about this issue in more details here.

https://www.moderndeployment.com/intune-hybrid-domain-join-error-80180005/

Most customers use a standard Computer naming convention with the serial number OR asset tag from the BIOS on the hardware device.

Example: L-%SERIAL% for laptops or D-%SERIAL% for desktops. Win10 SCCM task sequences allow the use of variables (%SERIALNUMBER%) for this requirement.

Autopilot standard Azure AD profile allows %SERIAL% but again, not Azure HYBRID Azure Domain join currently which is in PREVIEW.

Thanks
Nathan

From the requirements here:
https://docs.microsoft.com/en-us/intune/windows-autopilot-hybrid
"Have access to your Active Directory (VPN connection not supported)."

This requirement breaks the concept of having a device that could be shipped anywhere directly to a user. Large enterprises still have, and will continue to have applications that rely on domain connectivity for authentication. Many of these enterprises build their devices onsite and ship to users that never see the corporate network. Autopilot could never work in this scenario without users disclosing their credentials.

The feature we would like is a secure means of establishing an AAO VPN tunnel during enrollment that would allow enterprise users with domain applications to enroll their devices.

When importing Autopilot devices in Intune, we would like (for us and the OEM) to be able to assign machine names against each device that is imported.

Sadly %Rand% or %Serial% is not sufficient for a lot of our use cases (e.g. IT labs). We use location identifiers in the device name for our fixed device estate (7000 devices) - this allows us to create dynamic device groups based on location, room, lab, etc. which in turn is used for policy/app control (e.g. licensing, etc.).

In the file used to import the device it would be good to have an additional tag option, e.g.:
Device Serial Number,Windows Product ID,Hardware Hash, Order ID, Device Name,

Currently, to register a device for Autopilot, it's hardware hash needs to be uploaded to the portal via

A) the vendor (partner portal)
B) Manually - the device needs to be progressed past the OOBE and the script needs to be run to extract the hardware hash, the device is then reset.

Whilst A) is great for large volume orders coming from the manufacturer / reseller, what about ad-hoc rapid purchases required immediately. B) is a larger administration overhead which multiplies by the number of ad-hoc devices required.

What if;
During OOBE on a non-registered device, at the page, "Sign in using a Microsoft Account or create a local account" you could actually sign in using your name@company.com and based on the @company.com are redirected to your corporation sign in page and then Autopilot continues from there.

There would be security concerns (compromised email could lead to the ability to create corporate network accessible device or at very least corporate image), but additional security layers could be added for email registered devices which would limit the risk from this attack vector, you could restrict ad hoc deployments via portal approval required, admin approval, etc etc. Whilst Hardware Hashed registered devices are auto-approved.

We have multiple deployments where devices have been enrolled with a Device Enrolment Manager account and then issued to users.

Using a DEM account has allowed us to manage the enrolment of devices and configure any steps not yet supported by Intune before issuing to users. This isn't something that would be appropriate to change with AutoPilot.

These same deployments are relying on the ability to use the devices Compliance state as telemetry within a Conditional Access policy. Unfortunately we have seen mixed results where devices do not consistently report as compliant nor do they consistently report the reason for their non compliance.

Through working with support I have been provided with this article where it is stated this is an unsupported scenario -

We need this added as a supported scenario.

It's not appropriate for everyone to use AutoPilot or to rely on user led enrolment or to issue one device to a user or for devices to not be ever shared without needing re-enrolment.

This is proving a major blocker to adoption of Intune and Conditional Access.

If you need anymore information or scenarios at all please let me know.