Track Last User Login on Windows for Session Audits

What the LastLogin file writer does

This Automox Worklet™ enumerates currently logged-in users on a Windows endpoint and writes a LastLogin.txt file into each of their profile directories. The file contains the current timestamp in ISO 8601 format, the username, the endpoint hostname, and the policy run identifier. After the policy run completes, every active user profile on the endpoint has a fresh, file-system-resident record of when the session was observed.

The Worklet uses Get-WmiObject Win32_LoggedOnUser (or its CIM equivalent Get-CimInstance Win32_LoggedOnUser) to identify all interactive sessions, then resolves each user to a profile directory via the ProfileImagePath value under HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList. The script writes the LastLogin.txt file with Set-Content, overwriting any previous version so the file always reflects the most recent observation.

Because the evaluation phase reads the current logged-in user list without changing anything, the Worklet is safe to run on a tight recurring schedule (every 30 minutes is a common choice). Each run refreshes the LastLogin file for every active user. Inactive profiles are left alone, which means the timestamp on a profile's LastLogin.txt reflects the last time the user was actually logged in when a policy run hit the endpoint.

Why track Windows user sessions at the file system level

Windows already records login events in the Security event log, but the event log is volatile, retention is short by default, and reading it from another tool requires elevation and event log subscription plumbing. A simple LastLogin.txt file in each user's profile sidesteps all of that. Any downstream tool that can read a file can answer the question "who was logged in on this endpoint recently and when." Shared workstations, kiosk endpoints, lab machines, and call-center desktops all benefit from this kind of lightweight session signal.

Querying logon history through the Security event log requires Get-WinEvent against event ID 4624 on every endpoint, parsing through noise from service accounts and Kerberos tickets, and an admin context that the audit team usually does not have. Schedule this Worklet on the daily session-audit policy so the current interactive user, logon timestamp, and SID are written to a documented file path under C:\ProgramData on every Windows workstation and server in scope. A session-audit query can be answered by reading a single file on each endpoint instead of parsing Event Viewer, and the telemetry file stays current for the next compliance audit, incident review, or access-validation request.

How the LastLogin file write works

1. Evaluation phase: The Worklet queries Win32_LoggedOnUser via Get-CimInstance to retrieve the list of interactive sessions on the endpoint. For each session, it parses the Antecedent string to extract the domain and username, then looks up the matching ProfileImagePath under HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList to resolve the user's profile directory. If at least one valid profile is found, the endpoint is flagged for remediation. Endpoints with no interactive sessions are reported compliant and skipped.

2. Remediation phase: The remediation script iterates the resolved profile list and writes %ProfileDir%\LastLogin.txt for each one using Set-Content. The file content includes the ISO 8601 timestamp, the username, the endpoint hostname from $env:COMPUTERNAME, and the Automox policy run identifier supplied by the agent. Exit 0 on success or non-zero with the offending profile path in stderr if a write was blocked by NTFS permissions or a roaming profile mount issue.

LastLogin tracking requirements

• Windows 10, Windows 11, or Windows Server 2016 and later with PowerShell 5.1 or PowerShell 7 available

• Local administrator or SYSTEM privileges for the Automox agent so the script can write into other users' profile directories

• Roaming profile sync configured to include LastLogin.txt if the downstream tool reads the file from the network share rather than the local profile

• Awareness from operations that the Worklet writes a small file (under 1 KB) into each active profile on every policy run; the file is overwritten in place rather than appended, so it does not grow

• An end user notification or runbook entry explaining the file's purpose if your users routinely browse their profile directory and might flag the file as suspicious

Expected LastLogin file state after the policy runs

After remediation, every currently logged-in user's profile directory contains a LastLogin.txt file with the policy run's timestamp. A downstream tool reading C:\Users\<username>\LastLogin.txt sees a small text file with the ISO 8601 timestamp, the username, the endpoint hostname, and the policy run identifier. Subsequent policy runs overwrite the file with a newer timestamp, so the freshness of the file reflects the last time the user was logged in when the Worklet ran.

Validate by running the Worklet on a single shared workstation with two known active sessions, then confirming both profiles contain a LastLogin.txt with the expected content. For audit evidence, capture the file paths and contents into a SIEM via a file integrity monitor or a separate collector Worklet. A regression where one profile stops getting an updated file usually means the profile is loaded read-only, the user has been switched fast, or a roaming profile has lost its sync token; investigate those before assuming the Worklet itself has failed.