Finding stale AD computers and users without disabling something still in use

Every AD we inherit has the same ghosts. There are computer accounts for laptops recycled years ago, users who left before the last audit, and "temp" accounts that quietly became permanent. A stale-object report is one of the first things we run in a new environment, and after that we schedule it monthly. Here's the script, plus the caveats that keep you from disabling the PC the front desk still logs into every morning.

Why lastLogonTimestamp lies a little

AD has two attributes that matter here.

• lastLogon is precise but not replicated. Each domain controller keeps its own value, so you'd have to query every DC and take the newest.
• lastLogonTimestamp is replicated, so one query gives a usable answer, but it's deliberately imprecise. It only updates when the existing value is older than ms-DS-Logon-Time-Sync-Interval (14 days by default) minus a random 0 to 5 days. In practice it can lag the real last logon by roughly 9 to 14 days.

For a "not seen in 90 days" report that doesn't matter at all. For "did this user log in yesterday?" it's useless. Pick thresholds well above 14 days.

Turning the number into a date

The attribute is a Windows FILETIME (100-nanosecond intervals since 1 January 1601), and [DateTime]::FromFileTime() converts it to local time. Accounts that have never logged on have no value, and converting 0 gives you a date in 1601, so handle that explicitly. The AD module also exposes a ready-converted LastLogonDate property, which is fine to use. I convert manually so the behaviour is obvious to whoever reads the script after me.

The script

# Get-StaleADReport.ps1
Import-Module ActiveDirectory
$Days   = 90
$Cutoff = (Get-Date).AddDays(-$Days)
$Stamp  = Get-Date -Format 'yyyy-MM-dd'
$OutDir = '\\fileserver.contoso.com\IT\Reports\AD'

function Convert-LLT($value) {
    if ($value -and $value -gt 0) { [DateTime]::FromFileTime($value) } else { $null }
}

$computers = Get-ADComputer -Filter * -Properties LastLogonTimestamp, OperatingSystem, Enabled, Description |
    ForEach-Object {
        [pscustomobject]@{
            Name          = $_.Name
            Enabled       = $_.Enabled
            OS            = $_.OperatingSystem
            LastLogon     = Convert-LLT $_.LastLogonTimestamp
            Description   = $_.Description
            DN            = $_.DistinguishedName
        }
    } |
    Where-Object { -not $_.LastLogon -or $_.LastLogon -lt $Cutoff } |
    Sort-Object LastLogon

$users = Get-ADUser -Filter 'Enabled -eq $true' -Properties LastLogonTimestamp, whenCreated |
    ForEach-Object {
        [pscustomobject]@{
            SamAccountName = $_.SamAccountName
            Name           = $_.Name
            LastLogon      = Convert-LLT $_.LastLogonTimestamp
            Created        = $_.whenCreated
            DN             = $_.DistinguishedName
        }
    } |
    Where-Object { (-not $_.LastLogon -and $_.Created -lt $Cutoff) -or ($_.LastLogon -and $_.LastLogon -lt $Cutoff) } |
    Sort-Object LastLogon

$computers | Export-Csv "$OutDir\stale-computers-$Stamp.csv" -NoTypeInformation
$users     | Export-Csv "$OutDir\stale-users-$Stamp.csv"     -NoTypeInformation
"Stale (> $Days days): $($computers.Count) computers, $($users.Count) enabled users"

Look at the user filter. An account that has never logged on but was created yesterday isn't stale, so for those we compare whenCreated instead.

Getting the report to someone

We save dated CSVs to a restricted share so we can compare month to month. If you want it emailed, know that Microsoft has marked Send-MailMessage obsolete and it doesn't handle modern authentication well. For Microsoft 365 tenants we send through Graph's sendMail using an app registration with Mail.Send, scoped with an application access policy so it can only send as the reporting mailbox. A relay you control works too. Either way, attach the CSV or link to the share. Nobody wants hundreds of rows pasted into an email body.

A matching bug that made a report look clean

This one isn't about lastLogonTimestamp, but it came out of the same kind of cleanup. We were comparing a device export against a client list to find machines assigned to the wrong client. Using -like "*$client*" meant a client called "Riverton" also matched "North Riverton", so devices were silently counted under the wrong client and the report looked fine. Match names exactly, with -eq or a lookup set:

# BAD: substring / wildcard match - "Riverton" also matches "North Riverton"
$devices | Where-Object { $_.ClientName -like "*$client*" }
$devices | Where-Object { $_.ClientName -match $client }   # regex, same problem

# GOOD: exact, case-insensitive comparison
$devices | Where-Object { $_.ClientName -eq $client }

# GOOD for large lists: a HashSet with a case-insensitive comparer
$known = [System.Collections.Generic.HashSet[string]]::new(
    [string[]]$clientList.Name, [System.StringComparer]::OrdinalIgnoreCase)
$unmatched = $devices | Where-Object { -not $known.Contains($_.ClientName.Trim()) }