Autopilot - Looking to have a device added to Entra Group after Autopilot completes

Question

Autopilot - Looking to have a device added to Entra Group after Autopilot completes

M T 55

Hello everyone, I’m looking for a way to populate a dynamic group with devices that have completed Autopilot. The challenge we’re facing is that we want applications and policies to deploy only after a device has finished Autopilot and a user has logged in. We do not want to assign all apps and policies directly to users.

I’ve been experimenting with a script (deploying through Win32App during autopilot) that uses the device ID during Autopilot to update a device extension attribute, but it doesn’t seem to work when using Connect-MgGraph -Identity.

Currently we have a dynamic group with devices that are tagged. But would like to have another dynamic group populate once the device completed autopilot.

Rahul Jindal 11,606 Reputation points

2026-02-19T21:54:33.2366667+00:00

Here is a simple way. Assign the apps and policies to a user based group, and skip the account setup part of the ESP. This way apps and policies will get skipped during Autopilot provisioning and will only apply when a user logs in and Intune has re-evaluated the policies based on default check-in schedules.
M T 55 Reputation points

2026-02-20T14:26:40.99+00:00

Hello Rahul, I want to stay away from user‑based app assignments. While this approach technically works, we don’t want to apply these apps to users because our device‑based dynamic groups require no manual intervention. With user assignments, we’d end up creating a group for Autopilot users and then manually adding each person afterward, which defeats the purpose. We also can’t use All Users, since we need to keep Autopilot app deployments separate from standard device management.

1 answer

Your answer

Rahul Jindal 11,606 Reputation points

2026-02-19T21:54:33.2366667+00:00

Here is a simple way. Assign the apps and policies to a user based group, and skip the account setup part of the ESP. This way apps and policies will get skipped during Autopilot provisioning and will only apply when a user logs in and Intune has re-evaluated the policies based on default check-in schedules.
M T 55 Reputation points

2026-02-20T14:26:40.99+00:00

Hello Rahul, I want to stay away from user‑based app assignments. While this approach technically works, we don’t want to apply these apps to users because our device‑based dynamic groups require no manual intervention. With user assignments, we’d end up creating a group for Autopilot users and then manually adding each person afterward, which defeats the purpose. We also can’t use All Users, since we need to keep Autopilot app deployments separate from standard device management.

Answer 1

Marcin Policht 82,360 MVP Volunteer Moderator

AFAIK, there isn’t a native Entra ID or Intune attribute that flips to “Autopilot completed” in a way dynamic device groups can evaluate, so you'd need t okey off something that only exists after ESP completion and first user sign-in. The two signals you might consider are device ownership becoming “Company” with a primary user assigned, or a custom attribute written after enrollment using a mechanism that runs in the user context after ESP finishes. Unfortunately, trying to update extension attributes during ESP with Connect-MgGraph -Identity will likely fail because the device context does not have Graph permissions and the managed identity flow is not available in that stage of Autopilot.

One approach without scripting Graph is to leverage the primary user assignment because that only exists once a user has logged in successfully. You can create a dynamic device group that evaluates the existence of a registered or primary user. For example, you can try using a rule similar to the following, which only captures devices after a user association exists:

(device.deviceOwnership -eq "Company") and (device.registeredOwners -any (_ -ne null))

Depending on your tenant schema you may instead rely on:

(device.devicePhysicalIDs -any (_ -contains "[ZTDId]")) and (device.managementType -eq "MDM") and (device.enrollmentProfileName -ne null)

combined with requiring a primary user through an Intune filter or assignment filter, since primary user assignment happens post-login. Another approach might be deploying a remediation script or scheduled task assigned to “All Devices” but configured to run in user context after enrollment, which writes a local registry value. You then use a Proactive Remediation or custom compliance policy that marks the device compliant only after that value exists, and you target apps and policies to a dynamic device group filtered on compliance state:

(device.isCompliant -eq true) and (device.devicePhysicalIDs -any (_ -contains "[ZTDId]"))

If you want to stamp an Entra extension attribute, you might try calling Graph using an app registration with certificate or secret and grant Device.ReadWrite.All, then run the script as a user-context PowerShell script assigned after ESP rather than as a Win32 app during Autopilot. Example structure:

Connect-MgGraph -TenantId "<tenant>" -ClientId "<appId>" -CertificateThumbprint "<thumbprint>"
Update-MgDevice -DeviceId $env:AZUREADDEVICEID -ExtensionAttributes @{extensionAttribute1="AutopilotComplete"}

Your dynamic device group would then simply evaluate:

(device.extensionAttribute1 -eq "AutopilotComplete")

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

M T 55 Reputation points

2026-02-17T01:39:37.1033333+00:00

Thank you for all the detail. I ended up using a Runbook with a webhook that accepts the device ID through a proactive remediation script, which then writes to deviceExtensionAttribute1. I chose this approach because I didn’t want to rely on an App Registration and have to manage a secret, especially within a script.

I’m still working out the best method for the proactive script, whether it should check the registry key for the ZTDID or wait until the user has logged on. The goal is to ensure the dynamic group adds the device to the proper groups without interfering with application deployments during ESP/Autopilot, so essentially after completion. Any thoughts?
Marcin Policht 82,360 Reputation points MVP Volunteer Moderator

2026-02-17T02:57:41.9266667+00:00
Your runbook and webhook approach seems to be a solid design choice, especially since it avoids embedding app registration credentials in client-side scripts. Using Azure Automation with managed identity to update deviceExtensionAttribute1 is cleaner from a security and lifecycle perspective.

The next design decision would be choosing the correct trigger so you mark the device only after Autopilot and ESP are finished and a user session exists. Checking for the ZTDID registry key alone would not be sufficient because that value exists very early in the process and does not indicate ESP completion or successful user sign-in. It would cause devices to be stamped too soon and defeat your goal of post-Autopilot targeting.

If your objective is “after first successful user logon,” consider using client-side signal to indicate the presence of an interactive user profile. A method in a proactive remediation detection script is to check whether a non-system user profile exists under:

HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

and ensure you exclude well-known SIDs such as S-1-5-18, S-1-5-19, and S-1-5-20. Alternatively, you can validate that a primary user has been assigned by querying WMI:

Get-CimInstance -Namespace root\cimv2\mdm\dmmap -ClassName MDM_DevDetail_Ext01

or checking that $env:USERNAME is not SYSTEM and that whoami returns a standard user SID. If you scope the proactive remediation to run in user context and set it to run only when a user is logged on, that becomes an implicit guarantee that ESP has completed enough for user desktop access.

Another clean signal is to check the ESP completion registry key:

HKLM:\SOFTWARE\Microsoft\Windows\Autopilot\EnrollmentStatusTracking\Device

and confirm that DevicePreparationCategory.Status and DeviceSetupCategory.Status are set to 3 (success). That should ensure that ESP phases have completed before your remediation fires. Combining that with confirmation of a real user profile shoudl make it deterministic.

You can also consider letting the detection script evaluate both ESP completion and the presence of at least one non-system profile. If both are true and the extension attribute is not yet stamped, the remediation script calls your webhook and then writes a local marker registry value such as:

HKLM:\Software\Company\PostAutopilotComplete = 1

The detection script should also check for that local marker so it does not repeatedly trigger the webhook.

From a timing perspective, proactive remediations should execute after the device is fully enrolled and the IME is running, which already places you safely beyond ESP in most cases. Running it in user context and requiring a logged-on user is usually enough. The additional ESP registry validation simply removes ambiguity.

Your dynamic group rule then remains simple and deterministic:

(device.extensionAttribute1 -eq "AutopilotComplete")

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin
M T 55 Reputation points

2026-02-20T20:21:31.48+00:00

Thank you, Marcin. I ended up going with user profiles and excluding the built‑in accounts. I also found that it’s not always reliable to use DevicePreparationCategory.Status or DeviceSetupCategory.Status, since those keys aren’t present on every device. Instead, I used EnrollmentStatusTracking and checked whether the Device, DevicePreparation, and Setup registry keys existed.

I also leveraged MDM_DevDetails, and once all of those checks passed, I created a marker file. With that in place, my remediation script now runs correctly and updates the device’s extensionAttribute without any issues.

One remaining concern, which may not be a technical issue but more of a support‑process consideration, is that when a device completes Autopilot and is later wiped, the attribute remains in Entra. A wipe, reset, or refresh doesn’t clear that attribute. Unless you know of a way this can be automatically removed, this might be a step support needs to handle manually.
Marcin Policht 82,360 Reputation points MVP Volunteer Moderator

2026-02-21T00:44:11.3566667+00:00
Glad to assist. AFAIK, you are correct. A wipe, reset, or Autopilot reset does not clear Entra device attributes because the Entra device object itself is not deleted. As long as the same device object persists, extensionAttribute1 will remain set.

If you want this handled automatically, you would need logic that evaluates “has completed Autopilot in its current enrollment cycle” rather than “has ever completed Autopilot.” One way to do that is to make your proactive remediation idempotent and state-driven instead of one-time stamping.

You can potentially have the detection script verify both that a valid user profile exists and that your local marker file exists. If the marker is missing but extensionAttribute1 is still set, the remediation can call your runbook to clear it:

Update-MgDevice -DeviceId $DeviceId -ExtensionAttributes @{ extensionAttribute1 = $null }

After a wipe, the marker file will be gone, so the next time the remediation runs during the fresh enrollment cycle, it can first clear the attribute (if present), then later restamp it once your completion checks pass again.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin
M T 55 Reputation points

2026-02-21T13:51:09.64+00:00

Hello, I really like this thought process. Can you help me understand how this can be incorporated into my current scripts? Based on what you’re describing, it sounds like my proactive script should check whether the ESP log file exists on the local C: drive and, if it’s missing, clear the attribute. Is that the correct interpretation?

I’m also wondering about the best approach for handling attribute removal. Would you recommend using a separate runbook specifically for clearing the attribute, or should that logic remain within the existing remediation workflow?
Marcin Policht 82,360 Reputation points MVP Volunteer Moderator

2026-02-21T14:26:50.5166667+00:00
Yep - that’s the correct interpretation. Your proactive remediation script can first check for the presence of your ESP/log marker file or user-profile signals. If they’re missing, it means the device is either wiped or hasn’t completed Autopilot, so the script should clear extensionAttribute1. If the signals exist, the script continues as before to stamp the attribute. This keeps the logic idempotent and cycle-aware.

You don’t need a separate runbook for clearing the attribute. Incorporating the clearing logic into the same proactive remediation workflow would be simpler and ensure one authoritative process handles both setting and removal. For example:

if (-Not (Test-Path "C:\Path\To\MarkerFile")) { Update-MgDevice -DeviceId $DeviceId -ExtensionAttributes @{ extensionAttribute1 = $null } } elseif (-Not $markerAlreadySet) { Update-MgDevice -DeviceId $DeviceId -ExtensionAttributes @{ extensionAttribute1 = "AutopilotComplete" } }

This way, the same workflow handles both new enrollments and post-wipe cleanup automatically.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin
M T 55 Reputation points

2026-02-24T16:34:04.76+00:00
I’ve tested this process, but it’s still not working as expected. During ESP, the proactive remediation script never triggers, and the attribute is never removed. I monitored the workflow using Shift + F10 and never saw any of the files deploy that are supposed to clear the attribute.

The local flag files that should be created and checked never appear during ESP. Once the device completes ESP and the user signs in, the process finally runs after check-in to Intune, but at that point it’s too late. The device is already being added to the Autopatch group, which leads to a much longer build process.

# --------------------------------------------------------- # LOCAL FLAG FILES # --------------------------------------------------------- $ESPCompleteFile = "C:\ProgramData\AutopilotESPComplete.log" $WebhookDoneFile = "C:\ProgramData\AutopilotAttributeSet.txt" $ClearFlagFile = "C:\ProgramData\AutopilotAttributeCleared.txt"
Marcin Policht 82,360 Reputation points MVP Volunteer Moderator

2026-02-24T17:24:56.82+00:00

I believe this is expected behavior. Proactive Remediations run through the Intune Management Extension, and IME does not reliably execute during ESP device phase. It typically starts evaluating assignments only after ESP completes and the device performs its first post-enrollment check-in. That would explain why none of your flag files appear during Shift+F10 and why the attribute isn’t cleared in time.

Because of that timing, you shouldn't use PR to influence anything that happens during ESP. It would be “too late” for controlling group membership that affects required app deployment during Autopilot.

If you need to control Autopatch assignment before post-ESP app processing begins, the control point should be earlier than PR. That means either scoping Autopatch with an Intune assignment filter that requires a primary user or compliance state, or restructuring so Autopatch targets users instead of devices and relies on primary user assignment, which only happens after first sign-in.

If you stay device-targeted, you might consider excluding all Autopilot devices (for example via [ZTDId]) from Autopatch and only include them once your attribute is stamped. That means Autopatch should not be broadly assigned but rather should target your dynamic “AutopilotComplete” group.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin
M T 55 Reputation points

2026-02-25T11:30:36.35+00:00

Yes, you’re correct that’s exactly the issue. When you mention “Autopatch with an Intune assignment filter that requires a primary user or compliance state,” can you clarify how to configure an assignment scope that specifically requires a primary user? I’d like to understand what that setup looks like.

I also would rather stay with a device‑based approach. When you say to exclude ZTID devices from Autopatch, how would that work if the device already has a group tag assigned? I’m trying to understand how the exclusion logic would apply in that scenario. Thank you again for you assistance and sticking with me here.
Marcin Policht 82,360 Reputation points MVP Volunteer Moderator

2026-02-25T12:13:22.12+00:00
AFAIK, there isn’t a native dynamic rule that directly evaluates “primary user exists” in Entra device groups. However, in Intune assignment filters you can target managed devices and require properties that only exist after user association. Use compliance state or a custom device property that only evaluates true after first user logon. For example, assign Autopatch to a device group but apply an assignment filter such as:

device.isCompliant -eq true

Since compliance evaluation typically happens after ESP and user sign-in, this delays effective targeting without scripting during ESP.

If you want to stay fully device-based and avoid timing races, use a structural exclusion. Create a dynamic device group that captures all Autopilot devices:

(device.devicePhysicalIDs -any (_ -contains "[ZTDId]"))

Exclude that group from Autopatch assignments. Then include only your stamped group:

(device.extensionAttribute1 -eq "AutopilotComplete")

Group tags do not conflict with this. A device can have a group tag and still match the [ZTDId] rule. The exclusion simply ensures that no Autopilot device is eligible for Autopatch until your extension attribute is written. Once your remediation stamps the attribute, the device becomes included through the positive assignment group rather than ever relying on removal timing during ESP.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin
M T 55 Reputation points

2026-03-03T13:43:19.92+00:00

I ended up taking this in a completely different direction. I created proactive and remediation scripts that run hourly and evaluate the conditions we discussed. I also built a Logic App that monitors the device group, checks for the device ID, and triggers when the device’s display name becomes NULL. So far, this approach is working as expected, and I believe we can consider this resolved. Thank you for all your time and help.
Marcin Policht 82,360 Reputation points MVP Volunteer Moderator

2026-03-03T14:16:08.84+00:00

You're welcome

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Share via

Autopilot - Looking to have a device added to Entra Group after Autopilot completes

1 answer

Your answer