Autopilot enrollment via MDT

[mhilboe852]

Hi all,

Within our organization, we’re implementing Microsoft Endpoint Manager to manage devices like laptops.

The situation is as followed: laptops are currently unmanaged and we’re trying to find a user-friendly way to enroll these laptops in MEM. Options to add a ‘Work or School account’ aren’t an option as users only have a ‘user account’ without admin rights. On the other hand, we’d like to take this opportunity to enroll a new (clean install) image with configurations and software from MEM.

After installing the OS with MDT and the offline JSON profile the device boots with the expected OOBE screen, ready to enroll in MEM. After entering the credentials the device is enrolled in AAD. Based on some rules the device is added to a dynamic group that is assigned to the ESP and configurations… probably AAD detects the membership too late which returns in a half-baked configuration.

We prefer to enroll without any manual interactions such as installing a provisioning package or running a PS-script from the OOBE-screen.

Any suggestions so devices will get their ESP and configuration profiles that are assigned to the group as pre-provisioning isn’t an option with offline Autopilot profiles?

Used resources:

https://docs.microsoft.com/en-us/archive/blogs/mniehaus/speeding-up-windows-autopilot-for-existing-d...

https://docs.microsoft.com/en-us/mem/autopilot/existing-devices

Thanks in advance!

[#2]

What is the Dynamic Device Group query? Is it one like this one with the ZtdCorrelationId from the JSON file?
(device.enrollmentProfileName -eq “OfflineAutopilotprofile-7F9E6025-1E13-45F3-BF82-A3E8C5B59EAC”).

[#3]

Hi Harm, the device group query is indeed like the one in your example. The device based on this query becomes a member of this group, but Intune recognizes its membership too late..

[#4]

Dynamic groups do take time to get Intune config applied, specially for new members. I’m not surprised with this behavior. 

Moe

[#5]

+1.. Just like Moe tells... Dynamic groups can take some time before they are processed.

https://call4cloud.nl/2020/10/autopilot-the-group-membership-war/

[#6]

Perhaps you should use the moment when you have to laptop of the user at the office location to register the device in Autopilot by using the get-windowsautopilotinfo.ps1 -online command in the current Windows installation. If it's registered, you can then proceed in wiping the OEM/Previous installation for a new current version of Windows. When the user turns on his/her laptop again, the device will be in the ZTDid group and ready for deployment using Autopilot.

[#7]

Thanks for the suggestion! I'll probably go with the provisioning package after a clean installation. This is, for now with the pre-provisioning method included, the most user-friendly way.

[#8]

Thanks for your reply Rudy! Seems like I've got to deal with this situation.

[#9]

Did you manage to fix your deployment?

[#10]

Sorry for my late reply! I did go with the easy 'route': when the user brings in their device, the device will get a newly installed installation of Windows 10. In the first OOBE-window will add a provisioning package to enroll in AAD and MEM. With the 'hideOOBE'-option configured in the provisioning package, the machine can be pre-provisioned by the IT department.