Updating Autopilot devices safely

Changing an Autopilot device name or Group Tag looks like a small Graph update. I would spend more time checking which device will receive it than writing the update call. The inventory match must be unambiguous, the requested change must be allowed, and somebody must deliberately enable writes.

The scheduled Azure Functions workflow in Autopilot-Device-Configuration makes those checks explicit. What I particularly like is that you can inspect a proposed change before the function makes it real.

Start in dry-run mode

The timer-triggered function defaults DRY_RUN to true. To disable dry-run, you must first provide a non-empty pilot serial allowlist. Configuration validation enforces it:

if (-not $dryRun -and $pilotSerialNumbers.Count -eq 0) {
    throw 'PILOT_SERIAL_NUMBERS must contain at least one serial number before DRY_RUN can be disabled.'
}

Leaving the pilot scope empty cannot accidentally enable writes. During a dry run, the processor records WOULD_UPDATE and does not call the Graph update operation. That gives you a chance to compare the proposed names and tags with approved inventory. Better to discuss an unexpected tag in a report than after it has changed a group assignment.

Make eligibility explicit

A matching serial number is only part of the decision. The inventory record must also opt in:

if ((Get-InventoryProperty -Record $Record -Name 'EligibleForAutomation' -Default $false) -ne $true) {
    $reasons.Add('EligibleForAutomation is not explicitly true.')
}

Excluded, legacy and conflicting records are rejected. Provisioning, lifecycle and join-type values must be approved too. If the evidence is missing, the workflow skips the record. An Autopilot identity by itself does not establish the current Entra join state, so filling in that gap with an assumption would be a poor shortcut.

Correlate exactly and avoid duplicate writes

The processor normalizes serial numbers and requires exactly one match between inventory and Autopilot. Zero matches and duplicate matches both mean skip. It then validates the requested device name and Group Tag and compares them with the current values. Already-compliant devices are logged and left alone; the next scheduled run does not need to send the same update again.

Keeping those steps separate helps when you need to explain a skip or a change later. Structured events carry a per-run correlation ID and a summary. There is no need to turn the function into a public request endpoint just to follow what a scheduled batch did.

Treat write mode as a release gate

The project uses a system-assigned Managed Identity with Graph's DeviceManagementServiceConfig.ReadWrite.All application permission for reading and updating. That permission can change Autopilot identities. Review the inventory and dry-run output, then run a narrowly scoped pilot before considering a wider rollout.

A successful Graph response does not tell you every downstream effect. Changing a Group Tag can change dynamic group membership and Intune assignments. Updating the display name does not immediately rename an already-enrolled device either; the name takes effect through a later supported enrollment flow. Check those consequences separately.

Operational checklist

• Keep dry-run enabled while validating inventory and proposed changes.
• Require a small, explicitly approved pilot list before enabling writes.
• Ensure each inventory record has an approved lifecycle, provisioning method, and join type.
• Resolve missing or duplicate serial matches rather than guessing.
• Review Group Tag impacts on dynamic groups and assignments.
• Monitor structured outcomes and retain the run correlation ID.

There is unfinished work here: this is an MVP, and join-type evidence comes from trusted inventory. The workflow does not independently resolve every device through Intune and Entra. Close that gap before trusting it with unattended production changes. Putting "temporary" in a change request does not close it, unfortunately.