DeviceLifecycle

Problem

Inactive Windows devices rarely disappear from every management platform at the same time. A computer may still exist in Active Directory after its Intune managed-device record is gone, may retain an old Entra ID object, or may never have been managed by one of the cloud sources at all.

That makes it unsafe to treat cleanup as a simple name comparison or as a rule that requires a matching object in every platform. A legitimate absence in Entra ID or Intune does not, by itself, mean the identity is inconsistent.

DeviceLifecycle was built around a stricter question: what evidence actually exists for this device, and is that evidence sufficient to permit a change safely?

Solution

DeviceLifecycle is a PowerShell automation that treats Active Directory as the authoritative on-premises source, correlates Entra ID and Intune records when they exist, and moves eligible devices through a controlled lifecycle.

The workflow provides three modes:

• ReportOnly inventories and classifies devices without administrative changes;
• Quarantine performs reversible containment and preserves the context required for recovery;
• Enforce includes quarantine and allows final removal only after configured retention and cleanup periods.

The current decision model explicitly distinguishes a missing record from an inconsistent record.

Evidence-aware correlation

The identity chain still relies on stable platform identifiers:

1. the AD computer SID is matched against Entra ID onPremisesSecurityIdentifier;
2. when exactly one valid Entra record exists, its deviceId can be correlated with Intune azureADDeviceId;
3. every source that actually exists contributes its own activity timestamp.

The policy now works as follows:

• AD always participates in lifecycle evaluation;
• Entra ID participates only when a unique, valid match exists;
• Intune participates only when a unique, valid match exists;
• a missing Entra ID or Intune record means unavailable evidence, not ManualReview;
• duplicate matches, identity inconsistency, or a missing timestamp on an existing source still block automation;
• a Microsoft Graph query failure remains fail-closed and is not treated as a successful query returning zero records.

In practice, an old AD computer with no cloud record can continue through the lifecycle normally. Conversely, if a valid cloud record shows recent activity, that evidence prevents the device from being incorrectly classified as stale.

Lifecycle

The thresholds are configurable. The project defaults are:

When a device becomes eligible, Quarantine or Enforce may disable the AD computer account, move it to the quarantine OU, and issue an Intune Retire only when a managed-device record actually exists.

The local state.json file preserves context across runs. This matters because Retire itself may remove the Intune record before the rest of the lifecycle has completed.

Two scheduled tasks with different responsibilities

Scheduled execution is split into two tasks:

{OrganizationName} - Device Lifecycle

This is the primary lifecycle task. It runs daily and uses the configured operational mode, including Enforce once production approval has been completed.

{OrganizationName} - Device Lifecycle Snapshot

This is an observability task. It runs periodically — every 30 minutes by default — and always forces ReportOnly.

This separation keeps DeviceLifecycle-Latest.csv current for inventory, API consumers, dashboards, and audit workflows without turning each snapshot refresh into an administrative lifecycle run.

Safety and recovery

The project is designed to bound the impact of an incorrect decision:

• ReportOnly remains the initial deployment mode;
• MaximumActionsPerRun caps how many devices can be changed in a run;
• -WhatIf allows the Enforce path to be simulated before a real change;
• ambiguous or inconsistent identities remain in manual review;
• missing timestamps on existing sources remain in manual review;
• final deletion happens only after the quarantine window;
• residual cloud cleanup happens only after the AD object has been removed;
• quarantined devices have an explicit recovery workflow.

Recovery is deliberately administrative. The restore script can re-enable the AD account, return the object to the production OU, clear lifecycle state, and support device revalidation.

Production validation

On August 28, 2026, the updated correlation policy was validated in a real environment in four stages:

1. a ReportOnly run to review the new classifications;
2. confirmation that devices without Entra ID or Intune records were no longer sent to manual review solely because those records were absent;
3. an Enforce -WhatIf run to verify the exact proposed actions;
4. a controlled first Enforce execution under the configured per-run action limit.

The batch completed as expected, allowing the primary task to be promoted to persistent Enforce while the snapshot task remained permanently isolated in ReportOnly.

Environment-specific device counts, hostnames, and identifiers are intentionally excluded from the public project.

Operational capabilities

• environment initialization and prerequisite validation;
• AD/Entra/Intune correlation with optional cloud sources;
• scheduled execution as SYSTEM;
• frequent non-destructive ReportOnly snapshots;
• staged quarantine and enforcement;
• configurable activity, retention, and per-run action limits;
• CSV reports, execution logs, and persistent JSON state;
• PowerShell -WhatIf support;
• recovery and uninstall procedures;
• optional read-only integration through DeviceLifecycle-API.

What it demonstrates

DeviceLifecycle demonstrates production-oriented infrastructure automation where the primary engineering challenge is not issuing administrative commands, but correctly modeling the quality of evidence before acting.

The evolution of its correlation policy reinforces that principle: missing information should not automatically be treated as inconsistency, while every piece of information that does exist must pass strict validation before it can contribute to a destructive decision.