Windows
View all Worklets
WindowsWindows

Windows - Maintenance Tasks - Remove Old User Profiles

Remove stale Windows user profiles past a configurable age threshold to reclaim disk space and enforce a clean baseline

Worklet Details

What the stale profile cleanup Worklet does

This Automox Worklet™ removes Windows user profiles that have exceeded a configurable inactivity threshold, with a default of 30 days. The Worklet enumerates every local profile through the Win32_UserProfile WMI class, calculates how long each account has been idle, and deletes profiles whose LastUseTime is older than the configured ageLimit.

Built-in accounts are protected automatically. The hardcoded exclusion list covers defaultuser0, NetworkService, LocalService, and systemprofile, and the Worklet honors a whitelistedUsers parameter so you can pin specific accounts (service accounts, kiosk users, on-call admins) in place. After remediation, the Worklet reports the total profiles removed and the disk space reclaimed in human-readable units, so the activity log doubles as a storage-recovery metric.

The script reads two policy parameters: ageLimit (integer days; default 30) and whitelistedUsers (string array of SAM account names). The remediation also registers a per-user scheduled task named LogonEventHook_<username> that writes a logon_event.txt file at each interactive logon. When that file is present, the Worklet uses its LastWriteTime as a more reliable idle-time signal than the WMI LastUseTime, which can stall on some Windows builds.

Why purge inactive Windows profiles at fleet scale

Stale user profiles accumulate quietly on shared workstations, VDI and RDS hosts, training-lab endpoints, and conference-room PCs. Every drive-by login leaves behind a profile directory under C:\Users and a hive entry under HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList. Months later, the C: drive crosses 80% full, the next Windows feature update fails the free-space precheck, and the cleanup tickets start landing on the IT operations queue. Dormant profiles also carry cached credentials, browser data, and historical files that fall outside data-retention policy and surface as findings during CIS, HIPAA, and SOC 2 audits.

Profile bloat compounds fastest on shared workstations, classroom labs, and Citrix-style multi-user hosts where dozens of accounts may sign in over a quarter. This Worklet enforces the retention baseline on every evaluation, so the next policy run catches stale accounts before they show up as a free-space alert or an audit finding for orphaned credentials. A single ageLimit value applied through one Automox policy reaches every workstation, every RDS host, and every shared lab machine at once, instead of waiting for a help-desk ticket about a full system drive.

How stale profile cleanup works

  1. Evaluation phase: The Worklet calls Get-CimInstance -ClassName Win32_UserProfile to enumerate every local profile and reads LastUseTime from each CIM instance, substituting 1/1/1990 when LastUseTime is null so the profile is flagged for review. If the LogonEventHook scheduled task is present and a logon_event.txt file exists under the profile root, the Worklet uses that file's LastWriteTime instead. It then iterates C:\Users directly through Check-NTUserDat, which inspects the LastWriteTime of NTUSER.DAT in each subfolder as a secondary signal. Profiles whose username appears in whitelistedUsers, or matches the built-in exclusion list (defaultuser0, NetworkService, LocalService, systemprofile), are skipped. The endpoint exits with code 2 when one or more profiles exceed the ageLimit.

  2. Remediation phase: For each flagged profile from the Win32_UserProfile pass, the Worklet measures the directory size via a recursive Get-DirectorySize helper and then calls Remove-CimInstance on the Win32_UserProfile object, which removes both the on-disk directory under C:\Users and the matching subkey under HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList. Profiles flagged only by the NTUSER.DAT fallback are deleted with Remove-Item -Recurse -Force, which clears the directory only. The script accumulates a per-run total of profiles removed and bytes reclaimed, formats the byte count into KB, MB, GB, or TB, and writes the summary to stdout for the Automox activity log.

Stale profile cleanup requirements

  • Windows 10, Windows 11, or Windows Server 2016 and later with PowerShell 5.1 or 7 (Get-CimInstance and Remove-CimInstance available)

  • Administrative privileges on the endpoint; the Automox agent runs as SYSTEM by default, which already satisfies this

  • ageLimit parameter: integer days of inactivity before a profile qualifies for removal (default 30; common values 14, 30, 60, 90)

  • whitelistedUsers parameter (optional): SAM account names to exempt, for example svc_backup, kiosk01, oncall_admin

  • Roaming profile users should be managed through Group Policy or FSLogix; this Worklet operates on local profiles only

  • Permission to register a per-user scheduled task (LogonEventHook_<username>) used to capture interactive logon timestamps

Expected endpoint state after profile cleanup

After remediation, every local profile remaining on the endpoint has been used within the ageLimit window. The C:\Users directory contains only active accounts plus any whitelist exemptions, and free space on the system drive has increased by the cumulative size reported in the activity log. Profiles deleted through the Win32_UserProfile path also have their matching SID subkeys removed from HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList.

Validate the result with Get-CimInstance -ClassName Win32_UserProfile | Where-Object { -not $_.Special } | Select-Object LocalPath, LastUseTime, SID, then sort by LastUseTime to confirm no entry predates the threshold. Cross-check the ProfileList registry hive with Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList' to confirm that no orphaned SID subkeys remain. On the next scheduled run, the evaluation phase should exit 0 with the message All user profiles on this device are compliant, which is the steady-state signal in the Automox activity log.

View in app
evalutation image
remediation image

Consider Worklets your easy button

What's a Worklet?

A Worklet is an automation script, written in Bash or PowerShell, designed for seamless execution on endpoints – at scale – within the Automox platform. Worklets deploy named-CVE mitigations within hours of disclosure, perform configuration, remediation, and install or remove applications and settings across Windows, macOS, and Linux.

do more with worklets