You prepare and sequence; the tech exports, disables and deletes. Apply the Write Guardrails
base skill — never invent data; when in doubt about BitLocker preservation or a device's live
state, do nothing and escalate.
1. Inventory on activity. The tech exports Entra devices with approximate last sign-in, join
type, management state and registration date, dated. Threshold from the client's standard
(knowledge base or their documentation — Connector Degradation base skill if off), else 90
days minimum, Microsoft's floor; 180 days is conservative for deletes (verify guidance). Intune and Entra device state differ — join both
views first: cleaning the Entra object of an actively managed device breaks it. Apply
Sweep Honesty — "at least N", and what you couldn't check.
2. Build the EXCLUSION list before the candidate list:
- Autopilot-registered devices. Deleting the Entra object breaks redeployment; deregister
from Autopilot first if the hardware is retired (autopilot-deployment).
- Seasonal, spare and loaner devices — carts, field spares, seasonal staff — are offline
by design. Ask which exist.
- Recently imaged or in-transit: a young registration with no activity is a device in a
box, not a stale one.
- Hybrid-joined devices. The on-prem AD object is the source: deleting only the Entra
object gets it re-created by sync. Clean these in AD through the client's change process
and let them age out — a separate workstream.
3. Preserve BitLocker keys FIRST. Before disabling or deleting anything, the tech exports
every candidate's recovery keys to the client's secure store: deleting the device object
deletes its stored keys, and that disk is then unrecoverable. No deletion,
ever, without preservation confirmed for the batch. Record where they went — a location
reference, never the keys.
4. Disable first, delete later. Disable the candidates (blocking authentication) and wait an
agreed window, 30 days by default: a live device fails loudly and reversibly, a deleted
one does not. Straight to delete only for never-activated duplicate
records, and the note must say why. Delete after the window with no breakage reports, and
schedule the pass so the window is real.
5. Approval gate before the disable pass: sign-off from the client's documented authority on
threshold, candidate count, exclusions, BitLocker preservation confirmed, the
disable-wait-delete schedule, and rollback — re-enable during the window; post-delete
recovery is re-enrollment, and hybrid devices may need on-prem cleanup and re-sync.
6. Note it (PSA Note Discipline base skill: plain text, no markdown): threshold, dated
counts (candidates, excluded, disabled, deleted), key-preservation reference, approver,
schedule, cadence. Re-pull the export if over two weeks pass between approval and
execution.
Magic Library