DeviceLifecycle

Problem

Inactive Windows devices rarely disappear from every management system at the same time. A single computer may leave behind an Active Directory object, a Microsoft Entra ID device, an Intune managed-device record, an Autopilot registration, and operational state stored locally.

Deleting records by computer name or by one stale timestamp is unsafe. Names can be reused, cloud records can lag behind on-premises changes, and an Intune Retire operation may remove the managed-device record before the wider lifecycle is complete.

DeviceLifecycle was created to answer a stricter question: is there enough consistent evidence to change this device identity safely?

Solution

DeviceLifecycle is a PowerShell automation that correlates records across Active Directory, Entra ID, and Intune, evaluates multiple activity signals, and moves eligible devices through a controlled lifecycle.

The workflow has three operating modes:

• ReportOnly inventories and classifies devices without making administrative changes;
• Quarantine performs reversible containment by retiring the Intune record, disabling the AD account, and moving it to a quarantine OU;
• Enforce permits final removal only after the configured retention and cloud-cleanup grace periods.

Ambiguous, duplicated, incomplete, or protected records are assigned to manual review instead of being modified automatically.

Architecture

The correlation chain uses stable platform identifiers rather than computer names alone:

1. the AD computer SID is matched to the Entra ID onPremisesSecurityIdentifier;
2. the Entra deviceId is matched to the Intune azureADDeviceId;
3. activity timestamps and lifecycle state are evaluated against configurable thresholds.

Each execution produces a current CSV report, per-run reports, execution logs, and a persistent JSON state file. The state file preserves identifiers and lifecycle timestamps even when an action removes a source record.

The automation can also trigger a Microsoft Entra Connect delta synchronization after directory changes. The quarantine OU intentionally remains within synchronization scope so that quarantine does not cause an immediate and unintended cloud deletion.

Safety and recovery

The project is designed to fail closed:

• ReportOnly is the default mode;
• servers, domain controllers, the execution host, Autopilot devices, protected objects, and configured exceptions are excluded;
• missing or ambiguous identity matches stop automated action;
• unreliable activity data produces manual review;
• MaximumActionsPerRun limits operational blast radius;
• destructive paths support PowerShell -WhatIf;
• permissions can be delegated only to the managed and quarantine OUs;
• residual Entra cleanup happens only after the AD object has been removed;
• quarantined devices have an explicit recovery workflow.

Recovery is deliberately administrative rather than automatic. The restore script can re-enable the AD account, return it to the production OU, clear lifecycle state, trigger synchronization, and support revalidation of hybrid join and Intune enrollment.

Operational capabilities

• environment initialization and prerequisite validation;
• scheduled execution as SYSTEM;
• staged reporting, quarantine, and enforcement;
• configurable inactivity and retention thresholds;
• CSV reporting and rotating execution evidence;
• persistent lifecycle state;
• manual-review classifications;
• recovery and complete uninstall procedures;
• optional read-only integration through DeviceLifecycle-API.

Current state

The repository contains the complete automation, configuration template, helper module, installer, scheduled-task registration, environment tests, recovery tooling, uninstall workflow, security policy, changelog, and bilingual architecture documentation.

The public version is sanitized for portfolio and reuse. Environment-specific tenant IDs, credentials, hostnames, certificate references, organizational names, and delegated permissions remain outside version control.

What it demonstrates

DeviceLifecycle demonstrates production-oriented automation where the primary engineering challenge is not issuing administrative commands, but defining when software has sufficient evidence to act. Its core principles are conservative identity correlation, progressive enforcement, least privilege, recoverability, bounded actions, and preserved operational evidence.