Purpose

This article documents how the Vestis QL image refresh system actually works under the hood - the PowerShell script, the Ninja task that runs it, and the Ninja tasks that distribute new content each month. For the monthly update process (what L1/L2 does when a ticket comes in), see the SOP article instead.

System overview

Two independent pieces work together:

1. Distribution (Ninja, manual) - pushes new content from Spindle out to plant servers' staging folders
2. Processing (Ninja, automatic/nightly) - runs process-vestis-images.ps1 on each plant server, which reads whatever landed in staging and applies it to the live display folders

Neither piece needs to know about QL/CL or English/French directly - that distinction is handled entirely by which Ninja distribution task is run against which target group, and which language file is attached to it. The script itself only ever looks at filenames.

Folder structure (per plant server)

The PowerShell script: process-vestis-images.ps1

Runs nightly on every plant server. Logic, in order:

1. Ensures required folders exist (staging, work, skipped, Random, Monthly, Archive) - creates them if missing, so it works even on a server that's never had this structure before.
2. Clears stale work folders left over from any previous run that didn't finish cleanly.
3. Scans staging for input files - both .zip files and raw image files (.jpg, .jpeg, .png, .gif, .bmp, .webp).
4. Routes each file by filename:
   • A number found anywhere in the filename -> destination is Monthly\<that number>
   • No number in the filename -> destination is Random
   • Zips are extracted into a temp work folder first; images are copied into one (no extraction needed).
   • Language words (English/French) anywhere in the name are ignored for routing purposes.
5. Resolves conflicts per destination - if two different source files in the same run both resolve to the same destination (e.g. two files that both look like month 8), the more recently modified one wins. The loser is moved to \Skipped for manual review rather than silently dropped.
6. Swaps in the new content for each winning destination:
   • Archives whatever currently exists at that destination into a timestamped folder under Archive\...
   • Moves the new content into place as the destination folder
7. Deletes the source file from staging once it's been successfully applied. If something errors partway through, the source file is left in staging (not deleted) so it can be retried or investigated - it does not silently disappear on failure.
8. Runs retention cleanup - deletes archive subfolders older than 365 days (configurable via $RetentionDays near the top of the script).
9. Logs every step with a timestamp to process-log.txt.

The script is intentionally idempotent-safe: running it on a night with nothing new in staging just logs "nothing to do" and exits - there's no harm in it running every single night regardless of whether content actually changed.

Ninja task: nightly processing

• Schedule: Daily, 12:01 AM
• Action: runs process-vestis-images.ps1
• Targets: all plants, including QL
• Maintenance: none required under normal operation. This task should not need to be touched month to month - only the distribution tasks (below) get updated routinely.

Ninja tasks: distribution

Two separate tasks, split by language/plant group:

• Schedule type: Run Once Immediately - this fires once automatically when the task is first saved/assigned to a device. Resaving the task does not reliably re-trigger delivery to devices that have already successfully received a prior push - Ninja appears to track per-device completion for this trigger type.

• Monthly update mechanism (reliable method): use the bulk device-run action rather than resaving the distribution task:

  1. Go to Devices in NinjaOne
  2. Filter to the target group (QL for French, All US and CL except QL for English)
  3. Select all matching devices via the checkboxes
  4. Use the Run menu at the top of the filtered list -> Automation -> Script
  5. Pick the relevant distribution script and run it against all selected devices at once

  Do this for both groups each month (English and French), even if only one language's content changed.

Legacy system (retired)

Two older scheduled tasks previously handled this via an installer-driven EXE:

• Run Vestis EXE from SpindleMessagesAdmin (ran monthly, executed a Vestis installer EXE)
• Archive Vestis EXEs (ran monthly, archived old EXE files)

Both are disabled (not deleted) on migrated plants - kept in place for reference/rollback rather than removed outright.

Where to make changes

• Script logic changes (new file types, new routing rules, retention period): edit process-vestis-images.ps1 directly. Test on one plant before rolling out broadly.
• Monthly content changes: never require script changes - only the Ninja distribution task's attached files and the bulk device-run action.
• New plant onboarding: no plant-specific configuration needed in the script itself; just ensure the new plant is targeted by the correct distribution task(s) (English or French) and the nightly processing task.