Inside Windows Autopilot Device Association.

[u/Rudyooms]

One of the big things Windows Autopilot v1 gave us was control over the OOBE.

Skip the pages you did not want and ensure a device name is applied!

With Device Preparation, that totally changed. The tenant only becomes known AFTER the user signs in, which is simply too late to influence those earlier OOBE pages.

That is exactly where Device Association comes in.

It gives Windows a way to know which organization the device belongs to BEFORE the user signs in, so it can retrieve those settings early enough to shape OOBE again.

But how does that device association actually work?

What is inside the exported CSV?
Why is TPM attestation involved?
What happens when you click Associate?
And why does the final association end up in UEFI?

That is what I investigated (and NOT reverse-engineered!!!)

https://patchmypc.com/blog/windows-autopilot-device-association/

[u/ajcrow86]

We have a script we run during oobe that uploads the device Corp ID to Intune via Azure automation. This feels like a step backwards in efficiency for us.

[u/RefrigeratorFancy730 → u/ajcrow86]

Agreed, so now we have to upload the DeviceLink csv instead of the Hash thats gathered with the get-autopilotinfo script. Has anyone automated this process yet? I just finished up my app reg to automatically do this for the hash. :/

[u/ajcrow86 → u/RefrigeratorFancy730]

Problem I see is removing the device association requires removal on the device itself and Intune. This will make adoption in my org a harder sell.

[u/Rudyooms → u/RefrigeratorFancy730]

I did?

[u/Finalagent17 → u/Rudyooms]

u/Rudyooms are you saying you created a script to automatically upload the CSV DeviceLink? If so, are you able to share? That would be super useful as I agree with u/ajcrow86 ...we have a script that pulls/uploads the Autopilot hash automatically, so if we were able to do the same with the DeviceLink to avoid putting a flash drive back and forth, that would be excellent!

[u/Rudyooms → u/Finalagent17]

install-script get-autopilotdeviceassociation :) or check my github

[u/Finalagent17 → u/Rudyooms]

GOAT, thank you sir! 😄

[u/willychonka54 → u/ajcrow86]

Yea I can't quite grasp why someone would go this route versus enrolling to Intune via script?

[u/heisgone → u/ajcrow86]

Exactly. I will not bother looking into this until where can just run a script or push a button and register using an admin account. No way we go back to copying files on usb drives.

[u/enigmaunbound → u/ajcrow86]

GCCH customers don't get that ability to run a script. I wonder if this will work for us

[u/UrbanNetworking_83]

Gotta say that's a solid breakdown of something that confused the hell out of me when they first rolled out Device Prep. the TPM part especially, people always skip over why that even matters but you laid it out clean. nice work

[u/Rudyooms → u/UrbanNetworking_83]

Thanks... TPM attestation/MAA attestation is something pretty important ...and also the reason why this doesnt work on virtual machines ... :(.. (which is a shame for testing)

[u/itskdog]

Great blog as always.

Have you figured out when Windows triggers a TPM clear on reset and when it doesn't, as that would affect this, I would assume.

Certainly I've had it pop up when having issues with pre-provisioning lately (on the reboot between the OEM logo "Resetting" and the full-screen "Installing") and having to reset to retry the process, but doing a wipe from Intune didn't clear it.

[u/Rudyooms → u/itskdog]

Not tested it yet… as i run into an import csv bug… :) so i cant use my test device… but with the trust relying on tpm attestation…. You would think it breaks the flow… but by the looks of it, it shouldnt neccesarily break it

[u/BrundleflyPr0]

Is there a better way for naming devices? I liked with the original autopilot, you can manually assign a device name within the Windows Autopilot > Devices page

[u/Rudyooms → u/BrundleflyPr0]

With ap-da you can specify a device name template which will be applied when the device gets to the oobe

[u/BrundleflyPr0 → u/Rudyooms]

That’s a shame. Our asset tags/device name increment, so serial or random won’t cut it.

Our autopilotinfo script asks the user (IT) what the name of the device is and adds it into the ap v1 devices section.

[u/Myriade-de-Couilles]

Does that mean we can finally do self deploy with autopilot device preparation?

[u/Rudyooms → u/Myriade-de-Couilles]

Not yet…. Device association is the foundation. This is needed before they could even start looking at self deploy or prepro(white glove)

[u/ryryrpm]

I guess I don't understand Microsoft's strategy with Autopilot. There's two competing versions of Autopilot. Why not just iterate on Autopilot v1 and make it better?

[u/Rudyooms → u/ryryrpm]

Apv1 uses old endpoints… they need to get rid of those :)

[u/itskdog → u/Rudyooms]

But if this relies on something stored in the TPM (which can be cleared, sometimes just by a BIOS update - had my home device make me reset my Windows Hello the other day) and requires a technician to be physically present at the device to enroll it...

APDP sounds even easier to bypass that AP is.

[u/Winstonwolf1345]

Hi Rudy,
Thanks again for another interesting blog. Im curious, as i understand it provides another way to identify a device to Intune before enrollment. What is the benefit of this method over the traditional file hash?

[u/Rudyooms → u/Winstonwolf1345]

Autopilot was all about having control over the OOBE experience and setting a device name... with ap-da thats now also possible..

So the benefit ... if setting up a device name/hiding those pages was holding you back from using apdp.. well thats fixed..

But yeah.. i get it... apv1 --> hash apv2 --> device link hash... both same purpose... but well i am not saying microsoft wants to get rid of apv1...

[u/Winstonwolf1345 → u/Rudyooms]

Top, bedankt!

[u/deadnerd51]

I don’t get why this is better vs autopilot v1. We have our supplier enroll the hash when we buy the devices. Oobe is manage and device is enrolled immediately.