Windows - Maintenance Tasks - Get Device User Profiles

What the Windows user profile inventory Worklet does

This Automox Worklet™ walks every local user profile on a Windows endpoint and returns three data points per profile: the username, the on-disk size of the profile directory, and the number of days since that user last logged on. The output is rendered as a fixed-width table and written to the Automox Activity Log, so a fleet-wide profile inventory is reviewable from the console without remoting into a single endpoint.

The Worklet enumerates profiles through Get-CimInstance -ClassName Win32_UserProfile, which is the supported CIM-backed view of the registry hive at HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList. Each ProfileList subkey is named for a SID and exposes the ProfileImagePath value that anchors the profile on disk; the Worklet derives the human-readable username from the leaf of that path and resolves the days-since-logon value from the LastUseTime property surfaced by Win32_UserProfile.

A custom Get-DirectorySize function recurses the entire ProfileImagePath tree and sums file lengths, which is more accurate than the rough size attributes on the profile object. ConvertTo-LowestDenomination then scales the byte total into KB, MB, GB, or TB for readable output. Profiles without a recorded LastUseTime (typical for the Default and system service accounts) report as zero days since last logon and are clearly visible as a baseline row.

Why audit user profiles across a Windows fleet

Stale Windows user profiles are the quiet tax on a managed fleet. A shared workstation that has hosted twelve interns over two years carries twelve full profiles in C:\Users, each with browser caches, OneDrive sync state, and Teams downloads. The disk fills, Windows Update fails for lack of working space, and the help desk ticket lands months after the user the profile belongs to has left the company. Knowing the username, the disk footprint, and the days-since-logon for every profile on every endpoint is the precondition to any orphan profile cleanup policy, any storage reclamation initiative, and any user access review evidence package. Without that data, the cleanup is guesswork and the audit is anecdotal.

Orphaned user profiles in C:\Users consume disk space, slow logon times, and expand the attack surface around stale Windows credentials, but identifying them by hand means RDP into each endpoint and parsing the Win32_UserProfile output one host at a time. This Worklet returns a consistent, parseable Win32_UserProfile table from every Windows endpoint under management so the orphan profile decision is made once, in the console, against fleet-wide data rather than guessed at per host.

How the user profile audit works

1. Evaluation phase: The evaluation script exits 0, which marks every targeted endpoint as non-compliant and routes it to remediation. This pattern is intentional for inventory Worklets: there is no compliant state to assert against, only fresh data to collect. Schedule the policy at the cadence the inventory needs to be refreshed, and every run produces a new snapshot.

2. Remediation phase: The remediation script writes a BEGIN marker that includes $env:ComputerName, then pipes Get-CimInstance -ClassName Win32_UserProfile through ForEach-Object. For each profile it derives the username from Split-Path -Leaf on LocalPath, computes the LastUseTime delta against [DateTime]::Now, calls Get-DirectorySize against LocalPath to sum the recursive file lengths, and runs ConvertTo-LowestDenomination to scale the byte total. Rows are accumulated in an ArrayList, written out with Format-Table -AutoSize, and bracketed by a matching END marker. The script exits 0.

User profile inventory requirements

• Windows 10, Windows 11, or Windows Server 2012 R2 and later (workstation and server SKUs are both supported by the Win32_UserProfile class)

• Administrator context for the Automox agent so Get-CimInstance can read every entry under HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList and the recursive directory walk can read every profile under C:\Users

• WMI and CIM available on the endpoint (default on every supported Windows build; the script will fail closed if the Winmgmt service is disabled)

• PowerShell 5.1 or later; no module imports beyond the in-box CimCmdlets and Microsoft.PowerShell.Management modules

• FixNow eligible: run this Worklet ad hoc from the device page or a policy page when an inventory snapshot is needed immediately, without waiting for the next scheduled evaluation

Expected output and orphan-cleanup readiness

The Activity Log entry for each endpoint opens with a BEGIN USER PROFILE OUTPUT FOR <computername> banner, followed by a three-column table: Username, Profile Size, and Days Since Last Logon. Sizes are rendered in the largest unit that yields a value of one or greater (so a 2.4 GB profile prints as 2.4GB, not 2400MB). A matching END USER PROFILE OUTPUT banner closes the run, which makes parsing the log with a regex such as BEGIN USER PROFILE OUTPUT FOR (.+?) =============(.+?)END USER PROFILE OUTPUT straightforward when assembling fleet-wide reports.

Use the output to drive the next action. Profiles with hundreds of days since last logon are orphan candidates for the Remove Old User Profiles Worklet. Profiles with disproportionate size relative to their logon recency are candidates for targeted cache cleanup. To resolve a username back to its SID (for example, when staging a delprof2 or Remove-CimInstance -Query "SELECT * FROM Win32_UserProfile WHERE SID='S-1-5-21…'" command), cross-reference the HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList subkey whose ProfileImagePath ends in the listed username. Capture the Activity Log output alongside the policy run identifier for audit evidence, then schedule a recurring cadence (monthly is typical for workstations, weekly for shared servers) so the inventory stays current as profiles are created and abandoned.