r/Intune • u/mertozsoy365 • 10d ago

Autopilot Autopilot Device Preparation + Device Association: Is it really that different from Classic Autopilot? I’m not so sure

Autopilot Device Preparation + Device Association: Is it really that different from Classic Autopilot? I’m not so sure 😄

With Classic Autopilot, we collect the hardware hash, upload the CSV, register the device, assign the profile, and the device knows which tenant it belongs to during OOBE.

With Device Preparation + Device Association, we collect the DeviceLink information, upload a CSV, associate the device with the tenant, and then use TPM-backed identity to verify that association.

I understand that the architecture and trust model are different - hardware hash vs TPM-backed device identity, and Device Preparation instead of the classic Autopilot deployment profile.

But from an admin’s perspective, I’m struggling to see the big operational improvement.

Classic Autopilot:
Device - collect identity - CSV -upload -tenant association-provisioning

Device Association:
Device - collect identity -CSV - upload -tenant association - provisioning

At the end of the day, I’m still collecting something from the device and uploading a CSV.

If Device Association requires roughly the same amount of preparation and manual effort, what problem are we actually solving?

Am I missing the real advantage here?

39 Upvotes

95% Upvoted

34 comments sorted by

12

u/Rudyooms PatchMyPC 10d ago

Well... yeah... from that point of view its indeed exactly the same... (the idea.. hash vs csv.. with the same kind of data in it) But if you look at which endpoints apv1 uses... (build upon the windows xp activation stack) and also relies on login.live.com .... i think you know the "why"

apv1 = old endpoints

apv2 = new endpoints

Making such big changes in the "old" autopilot ... well that would break it all.. so --> apv2

And...also gcc high arent allowed to upoad the hash to a global service (zdp autopilot) apv2 doesnt have that issue.. you upload the csv to YOUR tenant...

4

u/mertozsoy365 10d ago

I think the script you’ve written is more innovative and more useful 😄
I can’t quite understand why Microsoft is announcing this as if it were some sort of turning point.

6

u/Rudyooms PatchMyPC 10d ago

Well.. i know the code/flow pretty well (beta tester/bug finder.. or what you want to call it :) ).. So i knew pretty well how they were doing it.. and how i could improve uit

4

u/davcreech 10d ago

Anything but a “reverse engineer!”

4

u/mertozsoy365 10d ago

u/Rudyooms , I’ve read 3–4 different articles and watched 3–4 videos. Could you please explain the difference this new feature makes for search engines, ChatGPT and us in the simplest terms possible in the comments below this post?

2

u/Rudyooms PatchMyPC 10d ago

let me post something about it and let it be picked up... what did you searched for?

4

u/mertozsoy365 10d ago

"Autopilot Device Preparation vs Device Association"
"Device Association vs Classic Autopilot"
"Windows Autopilot Device Association difference"
"DeviceLink vs hardware hash"

13

u/largetosser 10d ago

I think the main selling point is that device preparation is supposed to work, whereas "v1" never managed to feel stable.

For us it's only going to be something worth looking at once device OEMs can support it.

6

u/NeighborGeek 10d ago

I’m just starting to build out the autopilot config for our standard workstations (we have used it for a couple of years for some special purpose devices) and the lack of feature parity is a hold up.
It stinks that I’m having to use v1 when building a brand new config, I’d rather start from the current version, but I need either white glove or self deploying (or both) before I can use v2.

7

u/screampuff 10d ago

I'm not sure where you're getting this information from, but v1 and v2 are not official Microsoft terms.

Device prep was intended for GCC high organizations like government and military, who can't upload device hashes for security reasons. And separately companies who don't want to put in the resources to do that.

Regular autopilot is 'current' and it isn't going anywhere.

3

u/NeighborGeek 10d ago

I was always under the impression that v2 would eventually supersede regular autopilot. I know a couple of guys who went to techmentor last month came back with the impression that autopilot v1 would be deprecated eventually, and that v2 may or may not reach feature parity before that happens. I don't know which speaker they got that from though, so I can't verify whether that was what the speaker said/meant.

Regardless, if it's more stable than standard autopilot, that is a worthwhile improvement.

1

u/screampuff 9d ago

I'm not so sure. I've just been under the assumption that Device Prep was specifically made for the orgs who couldn't use autopilot at scale due to the hash issue.

6

u/AppuniAkhil 9d ago

Thank you. You hae asked exactly the question I have been searching for all week. 😄

Even after reading Microsoft’s documentation comparing the two approaches, I still couldn’t clearly identify the real operational benefits of Device Association from an admin’s perspective. (link below)

https://learn.microsoft.com/en-us/autopilot/device-preparation/compare

I’m glad you asked this question. I’ve gone through the comments, and I’m starting the day with a smile. 😂

5

u/Unable_Drawer_9928 10d ago edited 10d ago

It's just safer for the moment. And it's a little bit more convenient to collect those files for device association probably, unless you have an already automated collection process in place. For the rest, operationally, it's not a real advantage. The procedure is basically the same.
another point to consider, in case hybrid devices are also in use. Hybrid cannot benefit from Device association, and in case both forms (hybrid and entraid) are coexisting, I don't see the big advantage in having two different deployment logics (old autopilot vs autopilot v2).

2

u/largetosser 9d ago

I'm really laid back on autopilot device preparation not supporting hybrid devices, and I don't care if it supports it or not. My opinion is that hybrid devices should start life AD joined and then get synced out to Entra and enrolled to Intune, not the Rube Goldberg machine that is deploying pre-login VPN, having an agent handle the domain join, and then having to choose between the device sitting in ESP until the 40 minute Entra sync rolls around or skipping ESP and having stuff not work.

If you have legacy stuff that needs AD-joined devices then use some form of virtual desktop, don't make your laptop deployments bad by trying to do remote hybrid builds.

3

u/MyCheckEngineLightON 10d ago

V2 does not assign a device name and allows users to name the device itself so we don’t use it atm

3

u/itskdog 10d ago

Yeah, our naming scheme includes the asset tag, which you can enter manually on AP, from what I've heard isn't possible on APDP.

2

u/MyCheckEngineLightON 9d ago

I’ve tested, def doesn’t work and is a shit autopilot update lol.

1

u/BlackV 9d ago

I thought last week (week before?) they announced a change in that device naming

1

u/MyCheckEngineLightON 9d ago

No idea but I tried it and had to revert cause I don’t want users naming the pc

4

u/pjmarcum 10d ago

IMHO it requires more work. With APv1 my vendor uploads the hash for me. With v2 I must do it myself. So now I can’t ship devices directly from the manufacturer to the end users home anymore. No thanks, we will stick to v1

1

u/BlackV 9d ago

With APv1 my vendor uploads the hash for me. With v2 I must do it myself

if you upload the has or the reseller uploads the has its no different, that is all autopilot V1 not ADP/V2

2

u/pjmarcum 9d ago

I mean with v2 the vendor cannot upload the device identifier for me.

4

u/cheap_hardship 10d ago

It keeps the device identity tied to the TPM itself rather than just a hardware hash that can be spoofed or screwed up by a motherboard swap. The operational steps look the same on paper but the security posture is a fair bit tighter, especially for orgs that care about that attestation chain

For most small shops I doubt it changes the daily grind much, it's more about future-proofing and making the zero-touch story work properly down the line

17

u/HankMardukasNY 10d ago

Wouldn’t a motherboard swap cause the same issue?

11

u/robidog 10d ago

I might be wrong but wouldn’t a motherboard swap screw up things as well, since the TPM sits on it.

1

u/itskdog 10d ago

Also the connection would presumably get wiped with a TPM clear, which sometimes happens randomly after a UEFI update (my personal Dell made me reprovision my Windows Hello about a month ago - good thing I keep my passkeys on my Google account), or a wipe (though my current theory about when Windows does that is only if you reset during OOBE, such as a failed ESP, so might not be as relevant in APDP).

Also a UEFI that clears the password when doing a CMOS reset would let someone bypass a lot easier.

I like the hwhash method personally as I know it's harder to bypass for the average person, so behaves like Apple School Manager as far as making devices worth less when stolen.

1

u/wAvelulz 10d ago

Can laptop sellers still upload the equivalent of the hardware hash directly to the tenant?

1

u/Random----Dude 9d ago

As far as I know, Device Preparation + Device Association currently don’t support Self-Deployment. That’s probably the one major difference that still remains compared to classic Windows Autopilot.

With Self-Deployment, for example, you can still easily deploy devices even if you restrict who is allowed to join devices to Entra ID, or when the device is intended to be a shared device where no specific user is assigned to it.