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.

I love Group Tags in the Autopilot device enrollment process and see many uses for them. One thing I'd like to see if the ability to use multiple Group Tags. I'm more suggesting along the lines of adding to Group Tags (i.e. not doing it as part of a CSV import), perhaps adding a common delimiter 2nd, 3rd, 4th etc Group Tag to a device. An example for this - we are using Group Tags for a customer to define the location of the device (e.g. Brisbane) so they can be dynamically added to the "Brisbane Devices" Azure AD group. It would then be nice to be able to add e.g. "ADMIN" as a second Group Tag, so that it dynamically adds into the Azure AD group that assigns an administrator Autopilot profile.

I have about a dozen autopilot profiles set up and assigned to specific groups (we have multiple locations and each one has a different naming convention, hence the multiple profiles)

When moving one workstation from a group to another, the autopilot profile either updates 24-48 hours later or not at all. It is seriosuly easier and substantially faster to manually wipe the device, manually delete AzureAD, Intune and AutoPilot record and recapture new hardware hash, reimport, reassign and reprovision.

If I move a device to a new AutoPilot assigned group, and I click SYNC, I expect the devices and profiles to be updated. That, or give me the button in the AutoPilot Devices Screen to manually assign or reassign a profile.

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,

I cannot express how utterly frustrating it is to import dozens of machines. Then as needed add them to the group they need for deployment and then sit and wait for a random and undetermined amount of time to see the status change from "Not Assigned" to "Updating" to "Assigned"

If I add a device to a group, confirm it is in the group, then click sync, why on earth is it not assigning the profile? Why does it take me adding/removing/re-adding the device to the group assigned to the autopilot profile multiple times to get it to assign.

I could let it sit for a few hours, and sometimes they're still not assigned!!

24-36 hours later, it finally gets assigned. Sometimes it takes 10 minutes, the longest I have waited was over 24 hours. This is not acceptable....

The closest workaround I have found is to completely delete the imported device from AzureAD & AutoPilot, re-import it after re-running and grabbing a "new" hardware hash despite the workstation not being touched, then add to the group and many times it will assign more quickly. If we import a dozen and let them sit on Not Assigned, it takes almost two days for the status to change,

There MUST be some manual method Administrators could use to force an immediate sync and apply the profile.

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.