Logging from admin scripts: logger and systemd-cat on Linux, Write-EventLog/New-WinEvent and Start-Transcript on Windows

Goal

Send an admin script's progress and result to a durable, queryable log location appropriate to the platform, without ever writing a credential, token or password into that log.

Prerequisites

On Linux, logger (util-linux) or systemd-cat on a systemd host; on Windows, an existing custom Event Log source (registered once, in advance, with an elevated session) for Write-EventLog, which exists only in Windows PowerShell 5.1 and was removed in PowerShell 6+, or New-WinEvent (5.1 and 7.x) against a registered provider manifest.

Steps

1. On Linux, tag every message so it can be filtered later: logger -t my-admin-script "starting cleanup of /var/tmp". logger(1) describes the utility as making entries in the system log, readable afterwards with journalctl -t my-admin-script or from /var/log/syslog, depending on the system's logging setup.
2. When the whole script's stdout/stderr should go to the journal without adding logger calls everywhere, run it under systemd-cat -t my-admin-script ./script.sh; systemd-cat is described as connecting "the standard input and" output of a process, or filtering a pipeline, to the journal — useful for wrapping an existing script without modifying it.
3. On Windows PowerShell 5.1, if a registered Event Log source already exists for the script, use Write-EventLog -LogName Application -Source MyAdminScript -EventId 1000 -Message "..." for structured entries a monitoring tool can alert on; Write-EventLog requires the source to be created in advance (New-EventLog, run once, elevated) — do not create the source inside the script's normal unattended run path. Under PowerShell 7, use New-WinEvent or [System.Diagnostics.EventLog]::WriteEntry(...) instead.
4. For newer event-based logging tied to an ETW provider and manifest, use New-WinEvent -ProviderName <name> -Id <id> -Payload <values>, which writes a structured event through the registered provider rather than a source-based classic log entry.
5. For a full, unfiltered transcript of everything a script's PowerShell session printed (useful for after-the-fact debugging of an unattended run), wrap it in Start-Transcript -Path $logPath; ...; Stop-Transcript. Because a transcript captures literally everything printed to the host, treat its output file with the same access control as the script's other logs. Transcription and script block logging can also be switched on machine-wide by Group Policy, so a secret written as a literal in the script or echoed to the host can land in a transcript or event log even without Start-Transcript.
6. Before logging any value, check it against a short deny-list of variable names your script uses for secrets (password, token, key, connectionstring); redact those to a fixed placeholder before the log call, never rely on remembering to omit them ad hoc.

Expected result

A script's run is reconstructable afterwards from journalctl/Event Viewer without re-running it, and a review of the log for any run shows no plaintext credential regardless of what the script handled.

Limits and test basis

logger's exact destination (syslog daemon, journal, or both) depends on the host's logging configuration, not on logger itself. Write-EventLog fails if the source was never registered or was registered under a different log name; check with Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='MyAdminScript'} -MaxEvents 1 after a run, not just for a return value from the write call. Start-Transcript does not redact anything — a command that echoes a secret during a transcribed session still appears in the transcript file.