Script to Delete Inactive Local User Accounts

Understanding Last Logon Data

To identify inactive accounts, you must query the LastLogonTimestamp property from the Win32_UserAccount WMI class. This attribute is stored as a large integer representing Coordinated Universal Time (UTC). A common pitfall is assuming this value is always present or easily convertible; in reality, new accounts or system service accounts may return null. Your script must account for these missing values to avoid casting errors that crash the execution loop.

The calculation involves comparing the current date against the converted timestamp. If the difference exceeds your threshold (e.g., 90 days), the account is flagged for removal. Note that this data is only updated when a user logs on interactively. Service accounts or users who never log in locally will retain their creation time or a default value, which might require different handling depending on your security policy.

Prerequisites and Permissions

Deleting local users modifies the SAM database, which requires elevated permissions. You cannot run this script with standard user rights. Ensure you are running the terminal or IDE as an administrator. For more details on managing execution contexts, refer to our guide on Running Scripts as an Administrator in Windows.

Additionally, verify that the target machine is not domain-joined if you intend to manage only local accounts. Domain controllers handle user lifecycle differently through Active Directory. If you are unsure about the device status, check its join state first. See Check if Device is Joined to a Domain for verification steps.

Robust Script Implementation

The following script addresses the scoping and parsing issues found in previous drafts. It explicitly defines variables within the loop scope to prevent leakage and uses safe conversion methods for dates.

$ThresholdDays = 90
$CutoffDate = (Get-Date).AddDays(-$ThresholdDays)

# Retrieve all local non-disabled accounts
$Users = Get-WmiObject -Class Win32_UserAccount -Filter "LocalAccount=True AND Disabled=False"

foreach ($User in $Users) {
    # Skip built-in accounts like Administrator or Guest
    if ($User.Name -match "^(Administrator|Guest|DefaultUser)$") {
        continue
    }

    # Safely parse LastLogonTimestamp
    $LastLogonRaw = $User.LastLogonTimestamp
    $LastLogonDate = $null

    if ($LastLogonRaw -ne $null -and $LastLogonRaw -ne "") {
        try {
            # Convert CIM datetime string to .NET DateTime object
            $LastLogonDate = [System.Management.ManagementDateTimeConverter]::ToDateTime($LastLogonRaw)
        } catch {
            Write-Warning "Failed to parse date for user: $($User.Name)"
            continue
        }
    } else {
        # If no logon exists, treat as very old (or create date)
        # Adjust logic here if you prefer to keep accounts with no history
        Write-Host "No logon data for $($User.Name). Skipping or marking based on policy."
        continue 
    }

    # Check if the account is older than the threshold
    if ($LastLogonDate -lt $CutoffDate) {
        Write-Host "Removing inactive user: $($User.Name) (Last login: $LastLogonDate)"
        
        try {
            Remove-LocalUser -Name $User.Name -ErrorAction Stop
            Write-Host "Successfully deleted $($User.Name)"
        } catch {
            Write-Error "Could not delete $($User.Name): $_"
        }
    }
}

Key Logic Corrections

• Scoping: The variable $User is defined by the foreach loop, ensuring it is fresh for each iteration. This prevents residual data from previous loops affecting the current check.
• Date Parsing: We use [System.Management.ManagementDateTimeConverter]::ToDateTime() instead of manual string manipulation. This method reliably converts the WMI format (YYYYMMDDHHMMSS.mmmmmmsUUU) into a standard DateTime object, avoiding the "Win32_DateTime" string errors.
• Null Handling: The script checks if LastLogonTimestamp is empty before attempting conversion. Accounts with no login history are skipped to prevent accidental deletion of dormant but valid service profiles.

Testing and Safety Measures

Before running this script in production, always perform a dry run. Modify the script to output the list of users that would be deleted without calling Remove-LocalUser. This allows you to verify that the date calculations align with your expectations.

Be aware that deleting a user also deletes their profile folder under C:\Users\Username unless configured otherwise. Ensure no critical data resides in those folders. If you need to move files before deletion, consider combining this logic with file management scripts. See Powershell Script to Move Files: A Comprehensive Guide for techniques on backing up user data prior to account removal.

Common Pitfalls

One frequent error occurs when the system clock is incorrect, leading to false positives. Always ensure NTP synchronization is active on the host machine. Another issue arises when trying to delete the currently logged-in user. The Remove-LocalUser cmdlet will fail if the session is active. You may need to disconnect sessions using quser and logoff commands before attempting deletion.

Finally, remember that this script only affects local accounts. If your environment uses Group Policy for password expiration, inactive accounts might already be disabled. Combining this cleanup script with regular audits ensures a clean and secure user directory.

Frequently Asked Questions

What happens to the user's profile folder when the account is deleted?

By default, Windows deletes the user's profile directory located in C:\Users during the account removal process. Any unsaved documents or application settings stored there will be permanently lost. Always backup important data before running the deletion command.

Can I use this script to delete domain users?

No, this script specifically filters for LocalAccount=True. Domain users are managed through Active Directory and require different cmdlets like Remove-ADUser. Using this script on a domain controller may result in errors or unintended local changes only.

Why does the script skip accounts with no last logon date?

Accounts with no logon history often represent newly created users or service accounts that do not interactively log in. Deleting them immediately could break applications relying on those identities. The script skips them to prevent accidental loss of functional accounts.

How can I test the script without actually deleting users?

Comment out the Remove-LocalUser line and replace it with a Write-Host command. This will print the names of accounts that meet the criteria, allowing you to verify the date logic and filter conditions safely.

Does this work on Windows Server versions?

Yes, the Win32_UserAccount WMI class and Remove-LocalUser cmdlet are available in Windows Server 2012 R2 and later. Ensure you are using a compatible version of PowerShell, ideally 5.1 or higher, for best stability.