Write a Script to Check For a File and Export All Results to a CSV File

Alexander

Updated: July 30, 2026 03:14

Automox does not have a built-in inventory query for arbitrary files, so the way to answer "which devices have this file, and what version" is to run a Worklet that reports the answer as text, then export those results.

The pattern has three parts: a remediation that prints a consistent, parseable line for every device, a schedule so it runs across the fleet, and an export of the resulting log.

1. Write output you can actually filter later

The single most important choice is making the output uniform. Every device should emit one line in the same shape, including devices where the file is absent, so the export can be sorted and filtered rather than read by eye.

$targetPath = "C:\Program Files\Example\app.exe"
$hostname   = $env:COMPUTERNAME

if (Test-Path -Path $targetPath) {
    $version = (Get-Item $targetPath).VersionInfo.FileVersion
    Write-Output "RESULT|$hostname|FOUND|$version"
} else {
    Write-Output "RESULT|$hostname|NOTFOUND|"
}

exit 0

A few deliberate choices in that example:

A stable prefix such as RESULT| makes the line easy to locate in an export that also contains other log text.
A delimiter means the exported column can be split into fields in a spreadsheet.
Both branches print. If only the "found" case emits output, absent devices are indistinguishable from devices that did not run.
exit 0 because the check itself succeeded. A missing file is a finding, not a failed run, and exiting non-zero here makes the report look like a fleet of errors.
Write-Output, not Write-Host. Write-Host targets the information stream and is less reliable for this purpose.

2. Checking paths inside user profiles

Worklets run as the SYSTEM account, so there is no "current user" and variables such as $env:USERPROFILE resolve to the SYSTEM profile rather than a signed-in user. A path like C:\Users\$currentUser\Downloads\file.txt will not resolve.

Enumerate the profiles instead, and report which user each result belongs to:

$hostname = $env:COMPUTERNAME

foreach ($profile in Get-ChildItem "C:\Users" -Directory) {
    $candidate = Join-Path $profile.FullName "Downloads\example.txt"
    if (Test-Path -Path $candidate) {
        Write-Output "RESULT|$hostname|$($profile.Name)|FOUND"
    }
}

exit 0

3. If the check needs 64-bit PowerShell

Worklets run in a 32-bit PowerShell session, so C:\Program Files is redirected to C:\Program Files (x86) and HKLM:\SOFTWARE to WOW6432Node. A 64-bit file or registry check therefore needs the 64-bit PowerShell:

$scriptBlock = {
    $app = Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*" |
           Where-Object { $_.DisplayName -like "Microsoft Update Health Tools" }
    if ($app) {
        Write-Output "RESULT|$env:COMPUTERNAME|FOUND|$($app.DisplayVersion)"
    } else {
        Write-Output "RESULT|$env:COMPUTERNAME|NOTFOUND|"
    }
}

$result = & "$env:SystemRoot\sysnative\WindowsPowerShell\v1.0\powershell.exe" `
    -ExecutionPolicy Bypass -NoProfile -NonInteractive -Command $scriptBlock
$code = $LASTEXITCODE

Write-Output $result
exit $code

Capture $LASTEXITCODE immediately, before any other command overwrites it, and write the captured output explicitly. Assigning the invocation to a variable without printing it swallows the result, which is a common reason a reporting Worklet produces an empty log. See PowerShell Script Works Locally but Can't Find Filepath in a Worklet.

4. Evaluation code for a reporting Worklet

A reporting Worklet is meant to run every time it is scheduled rather than only when a device is non-compliant, so the evaluation always reports that remediation is required:

Write-Output "Reporting Worklet, remediation always required."
exit 2

Two consequences to expect rather than treat as faults:

The devices will permanently show as Pending Update, because the evaluation never returns compliant. That is inherent to this pattern.
Use exit 2 rather than exit 1. An exit 1 from Worklet script content frequently surfaces as Exit Code 124, COMMAND TIMED OUT, which looks like a failure even though the script completed.

Evaluation code also runs on every device scan regardless of schedule, so keep it to the two lines above rather than performing the check twice.

5. Exporting the results

Once the Worklet has run across the target devices, export the log from the console. The Activity Log can be filtered by policy type and policy name to isolate this Worklet's runs, expanded to show the per-device detail, and exported to CSV.

Per-device output is also available in the Policy Results device table for a given run. If you see summary text but no output, confirm the Details column is enabled in that table's column settings, since it can be turned off.

Open the CSV in a spreadsheet and split the output column on your delimiter to get one row per device with clean fields. Because every device emitted a line in the same shape, a count of FOUND versus NOTFOUND is then a filter rather than a manual review.

Why not the API

The API exposes device inventory that Automox collects natively, but arbitrary file checks and some security state are not part of that inventory. Where the data is not collected natively, a Worklet that prints its findings plus an export of those results is the available route, which is why the output format matters so much.

Community examples

Community Worklets are contributed examples rather than Automox features, so review and test them before use.

Was this article helpful?

0 out of 0 found this helpful