These days every batch job I write follows the same habits. Here they are, with working bash and PowerShell versions.

The rules I follow now

1. Dry run by default. The script only prints what it would do unless you explicitly tell it to act.
2. Detect collisions in the plan, before anything moves.
3. Never clobber. Check the destination, and use mv -n as a backstop.
4. Log every change with old and new names, so you can undo it.
5. Make it re-runnable. Files already in the target state get skipped, so running it twice is harmless and an interrupted run can just be restarted.

Bash

#!/usr/bin/env bash
# normalize-names.sh - lowercase names and replace spaces with underscores
# Usage: ./normalize-names.sh DIR           (dry run)
#        ./normalize-names.sh DIR --apply   (actually rename)
set -euo pipefail
DIR="${1:?usage: $0 DIR [--apply]}"
APPLY=0
[[ "${2:-}" == "--apply" ]] && APPLY=1
LOG="rename-$(date +%Y%m%d-%H%M%S).log"
declare -A planned   # target -> source, needs bash 4+

while IFS= read -r -d '' src; do
    dir=$(dirname "$src"); base=$(basename "$src")
    new=$(printf '%s' "$base" | tr '[:upper:]' '[:lower:]' | tr ' ' '_')
    [[ "$base" == "$new" ]] && continue          # already done: re-runnable
    dest="$dir/$new"

    if [[ -n "${planned[$dest]:-}" ]]; then
        echo "COLLISION  $src and ${planned[$dest]} -> $dest" | tee -a "$LOG"
        continue
    fi
    planned[$dest]="$src"

    if [[ -e "$dest" ]]; then
        echo "EXISTS     $src -> $dest (skipped)" | tee -a "$LOG"
        continue
    fi

    if (( APPLY )); then
        mv -n -- "$src" "$dest"
        if [[ -e "$src" ]]; then
            echo "FAILED     $src -> $dest" | tee -a "$LOG"
        else
            echo "RENAMED    $src -> $dest" | tee -a "$LOG"
        fi
    else
        echo "WOULD      $src -> $dest" | tee -a "$LOG"
    fi
done < <(find "$DIR" -maxdepth 1 -type f -print0)

A few details in there are easy to miss:

• find -print0 with read -d '' handles spaces, quotes and even newlines in names. Never loop over $(ls).
• mv -n (no clobber) refuses to overwrite an existing file. I don't trust its exit status to tell me it skipped, because that behaviour differs between platforms and coreutils versions, so the script checks whether the source still exists afterwards.
• The -- before the filenames stops a file called -rf.txt being read as options.

PowerShell

PowerShell gives you dry runs for free. Declare SupportsShouldProcess, wrap the change in $PSCmdlet.ShouldProcess(), and -WhatIf works just like it does on built-in cmdlets.

# Normalize-Names.ps1 - run with -WhatIf first
[CmdletBinding(SupportsShouldProcess)]
param([Parameter(Mandatory)][string]$Path)

$log = "rename-{0:yyyyMMdd-HHmmss}.csv" -f (Get-Date)

$plan = Get-ChildItem -LiteralPath $Path -File | ForEach-Object {
    $new = $_.Name.ToLower() -replace '\s+', '_'
    [pscustomobject]@{ Source = $_.FullName; NewName = $new; Target = Join-Path $_.DirectoryName $new }
} | Where-Object { (Split-Path $_.Source -Leaf) -cne $_.NewName }   # skip already-normalized

# Two inputs mapping to the same output? Stop before touching anything.
$collisions = $plan | Group-Object Target | Where-Object Count -gt 1
if ($collisions) {
    foreach ($c in $collisions) { Write-Warning "Collision -> $($c.Name): $($c.Group.Source -join ', ')" }
    throw 'Resolve collisions before renaming.'
}

$results = foreach ($item in $plan) {
    if (Test-Path -LiteralPath $item.Target) {
        [pscustomobject]@{ Source = $item.Source; Target = $item.Target; Result = 'SkippedExists' }
        continue
    }
    if ($PSCmdlet.ShouldProcess($item.Source, "Rename to $($item.NewName)")) {
        try {
            Rename-Item -LiteralPath $item.Source -NewName $item.NewName -ErrorAction Stop
            $r = 'Renamed'
        } catch { $r = "Failed: $($_.Exception.Message)" }
        [pscustomobject]@{ Source = $item.Source; Target = $item.Target; Result = $r }
    }
}
if ($results) { $results | Export-Csv -LiteralPath $log -NoTypeInformation -WhatIf:$false }

Run it in two passes:

.\Normalize-Names.ps1 -Path D:\Scans\Incoming -WhatIf
.\Normalize-Names.ps1 -Path D:\Scans\Incoming

Rename-Item already refuses to overwrite an existing file, but we still test first so the skip lands in the log instead of showing up as an error. Keep Move-Item -Force out of rename scripts. -Force is exactly the overwrite you're trying to prevent.

Read the plan before you apply it

When the dry run finishes, I look for any COLLISION or warning lines first. Then any EXISTS lines, since a target that's already there usually means an earlier partial run or a genuine duplicate. Last, I check the count against what I expected. If the plan says it'll rename 4,000 files and you expected 40, stop.

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()) }

Keep a library, not a pile of one-offs

Anything you run more than once goes in the Script Manager with a clear name, a category, a description of what it changes, and a sensible default timeout. TRMM supports PowerShell, batch and Python. Ad-hoc commands from the console are fine for poking around, but if it changes state it belongs in the library, where someone else can review it and re-run it exactly the same way.

Remember it runs as SYSTEM

By default TRMM scripts run as SYSTEM. That's what you want for installing software, changing services, editing HKLM or anything else machine-wide. It also means a few things catch people out:

• HKCU is SYSTEM's hive, not the user's.
• Mapped drives and user-profile paths aren't what you expect.
• Network access goes out as the computer account.

The Run As User option runs the script in the logged-on user's session instead. It only works when somebody is actually signed in, so it's a poor fit for an overnight fleet run. For per-user settings we usually run as SYSTEM and loop through the user hives, or deploy the change somewhere that applies at sign-in.

One script with parameters beats five copies

Instead of keeping five near-identical scripts, accept parameters and pass them from the script's default arguments or at run time:

param(
    [string]$ServiceName = 'Spooler',
    [ValidateSet('Check','Restart')][string]$Mode = 'Check'
)

Arguments are typed the way you would on a command line (for example -ServiceName Spooler -Mode Restart). Never pass secrets as plain arguments, because they end up in run history. Use the RMM's custom fields or environment variables where you can, and limit who can view history.

Write it so running it twice is harmless

A fleet script will hit machines in every state you can imagine, and someone will run it twice. Check before you change anything, make a second run a no-op, and report clearly. We start every output line with a fixed status word so results can be grouped later, and we always set an exit code:

# Ensure-BitLockerRecoveryEscrow.ps1 - safe to run repeatedly
$ErrorActionPreference = 'Stop'
try {
    $vol = Get-BitLockerVolume -MountPoint $env:SystemDrive
    if ($vol.ProtectionStatus -ne 'On') {
        Write-Output "SKIP: BitLocker not enabled on $env:SystemDrive"
        exit 0
    }
    $kp = $vol.KeyProtector | Where-Object KeyProtectorType -eq 'RecoveryPassword'
    if (-not $kp) {
        Write-Output "FAIL: no recovery password protector"
        exit 1
    }
    BackupToAAD-BitLockerKeyProtector -MountPoint $env:SystemDrive -KeyProtectorId $kp[0].KeyProtectorId | Out-Null
    Write-Output "OK: escrowed $($kp[0].KeyProtectorId)"
    exit 0
}
catch {
    Write-Output "FAIL: $($_.Exception.Message)"
    exit 1
}

Don't skip the exit code. When a script is used as a check or an automated task, the RMM uses the return code to decide pass or fail. A script that catches every error and exits 0 will show green forever, and whoever's watching the dashboard has no idea machines are failing underneath it.

Roll it out in rings

Order matters here. This is the sequence we stick to:

1. Run on one test machine and read the full output.
2. Run on a small, mixed group: a desktop, a laptop, an older OS build, a machine with a non-admin user.
3. Use bulk script against a single client or site.
4. Only then target everything, or attach it to an automation policy.

Put recurring work on a policy

For anything recurring, add the script as an automated task on an automation policy instead of running it by hand every week. Policies apply at the client, site or agent level, so you can pilot on one site before widening it. Offline agents pick up their tasks when they come back, which beats chasing laptops around manually.

# results.csv exported from the bulk run: hostname, output
Import-Csv .\results.csv | ForEach-Object {
    $status = ($_.output -split ':')[0].Trim()
    [pscustomobject]@{ Host = $_.hostname; Status = $status; Detail = $_.output }
} | Group-Object Status | Select-Object Name, Count

Calling TRMM from your own scripts

Once you're comfortable, you can trigger runs from your own tooling. Authentication is an X-API-KEY header. Check field names against your version, since they've changed over time. The easiest way I've found is to watch the request the web UI sends in your browser's developer tools.

$base    = 'https://api.rmm.contoso.com'
$headers = @{ 'X-API-KEY' = (Get-Secret -Name 'TrmmApiKey' -AsPlainText) }
# Cloudflare Browser Integrity Check blocked our POSTs without this
$ua      = 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0 Safari/537.36'

# GET worked even without the User-Agent
$agents = Invoke-RestMethod -Uri "$base/agents/" -Headers $headers -UserAgent $ua

# POST returned 403 / error 1010 until -UserAgent was added
$body = @{
    script      = 42            # script ID from the library
    args        = @('-Mode', 'Check')
    output      = 'wait'
    timeout     = 120
    run_as_user = $false
} | ConvertTo-Json
$agentId = '<AgentID>'
Invoke-RestMethod -Method Post -Uri "$base/agents/$agentId/runscript/" `
    -Headers $headers -UserAgent $ua -ContentType 'application/json' -Body $body

This is the small script we start from. It lists users and Intune managed devices, follows paging properly, and keeps the secret out of the file.

Registering the app

1. In the Entra admin center, go to Applications > App registrations > New registration.
2. Give it a name the next tech will understand (we use something like svc-graph-reporting). Single tenant, no redirect URI.
3. Copy the Application (client) ID and Directory (tenant) ID from the Overview page.

Permissions, and the consent button everyone forgets

Under API permissions > Add a permission > Microsoft Graph, pick Application permissions, not Delegated. Delegated permissions are for a signed-in user and do nothing in the client credentials flow. This script needs two:

• User.Read.All
• DeviceManagementManagedDevices.Read.All

Then click Grant admin consent for <tenant>. This is the step I always forget on a new tenant. Until the status column shows a green tick, you'll still get a token, but every call comes back 403. Ask only for the read permissions you actually need. An app secret with Directory.ReadWrite.All is a tenant-wide key sitting on some server, and I don't want to be the one explaining that to a client.

Where the credential lives

Under Certificates & secrets you can upload a certificate or create a client secret. I prefer certificates, because the private key stays in the machine's certificate store and never gets pasted into a file. If you do use a secret, give it a short expiry, put the renewal date on a calendar someone actually reads, and never hard-code it. We keep ours in a SecretStore vault on the box that runs the job:

Install-Module Microsoft.PowerShell.SecretManagement, Microsoft.PowerShell.SecretStore -Scope CurrentUser
Register-SecretVault -Name LocalStore -ModuleName Microsoft.PowerShell.SecretStore -DefaultVault
Set-Secret -Name 'GraphReportApp' -Secret (Read-Host -AsSecureString 'Client secret')

Run that as the same account the scheduled task runs as, because the vault is per-user. For unattended use you'll also need to set the SecretStore's password behaviour to suit your environment (see Set-SecretStoreConfiguration).

Getting a token and following the pages

The token endpoint is https://login.microsoftonline.com/<TenantID>/oauth2/v2.0/token. With client credentials the scope is always https://graph.microsoft.com/.default, which means "whatever application permissions have been consented". The response contains access_token, which is good for roughly an hour.

Graph hands results back in pages. When there are more, the response includes an @odata.nextLink property with the full URL of the next page, and you keep following it until it's gone. If you skip this, the report quietly stops at the first page (100 users by default). Nobody notices for months, until someone asks why the licence count looks low.

The full script

# Get-GraphInventory.ps1 - list users and Intune managed devices via Microsoft Graph
# Requires: Microsoft.PowerShell.SecretManagement + a registered vault holding the secret
$TenantId = '<TenantID>'
$ClientId = '<AppClientID>'
$Secret   = Get-Secret -Name 'GraphReportApp' -AsPlainText

function Get-GraphToken {
    $body = @{
        client_id     = $ClientId
        scope         = 'https://graph.microsoft.com/.default'
        client_secret = $Secret
        grant_type    = 'client_credentials'
    }
    $tokenUri = "https://login.microsoftonline.com/$TenantId/oauth2/v2.0/token"
    (Invoke-RestMethod -Method Post -Uri $tokenUri -Body $body `
        -ContentType 'application/x-www-form-urlencoded').access_token
}

function Invoke-GraphPaged {
    param([Parameter(Mandatory)][string]$Uri, [Parameter(Mandatory)][hashtable]$Headers)
    $all = [System.Collections.Generic.List[object]]::new()
    do {
        $page = Invoke-RestMethod -Method Get -Uri $Uri -Headers $Headers
        foreach ($item in $page.value) { $all.Add($item) }
        $Uri = $page.'@odata.nextLink'
    } while ($Uri)
    $all
}

$headers = @{ Authorization = "Bearer $(Get-GraphToken)" }

# Single quotes matter: in double quotes PowerShell would try to expand $select
$users = Invoke-GraphPaged -Headers $headers `
    -Uri 'https://graph.microsoft.com/v1.0/users?$select=displayName,userPrincipalName,accountEnabled&$top=999'

$devices = Invoke-GraphPaged -Headers $headers `
    -Uri 'https://graph.microsoft.com/v1.0/deviceManagement/managedDevices?$select=deviceName,operatingSystem,osVersion,lastSyncDateTime,userPrincipalName'

"{0} users, {1} managed devices" -f $users.Count, $devices.Count
$devices | Sort-Object lastSyncDateTime |
    Select-Object deviceName, operatingSystem, osVersion, lastSyncDateTime, userPrincipalName |
    Export-Csv -Path .\managed-devices.csv -NoTypeInformation

If you'd rather use a certificate

Doing certificate auth with raw Invoke-RestMethod means building and signing a JWT client assertion yourself. It's doable but fiddly, so when we use certificates we let the Microsoft Graph PowerShell SDK do that part:

# Certificate auth with the Graph SDK - no secret on disk at all
Connect-MgGraph -TenantId '<TenantID>' -ClientId '<AppClientID>' -CertificateThumbprint '<Thumbprint>'
Get-MgDeviceManagementManagedDevice -All | Select-Object DeviceName, OperatingSystem, LastSyncDateTime

It's the same app registration with the same permissions. You just upload the public key (.cer) under Certificates & secrets.

$t = Get-GraphToken
$t.Length            # a long string, not an error
($t -split '\.')[1]  # middle segment of the JWT - decode it to check the "roles" claim