Defining the Problem and the Script's Shape
A good automation script starts by defining a narrow, testable job — for example, 'archive log files older than 30 days from a folder and email a summary' — rather than one script that tries to do everything. Sketch the inputs as parameters (a -Path, a -RetentionDays, a -Recipient), decide what success and failure look like, and only then start writing the body; scripts designed backward from their parameters are far easier to schedule, test, and hand off than ones grown organically from a quick one-liner.
Cricket analogy: It is like a bowling coach designing a single specific drill — 'hit a yorker length six times in a row' — rather than a vague 'get better at bowling' session, because a narrow, measurable goal is actually trainable.
Building the Core Logic
With the shape defined, write the core loop using Get-ChildItem -Path $Path -Recurse -File to enumerate candidates, filter with Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-$RetentionDays) }, and act on each with Move-Item or Compress-Archive inside a ForEach-Object. Support -WhatIf and -Confirm by adding [CmdletBinding(SupportsShouldProcess)] and wrapping the mutating call in if ($PSCmdlet.ShouldProcess($file.FullName, 'Archive')) { ... }, so anyone running the script for the first time can preview exactly what it would do before it touches a single file.
Cricket analogy: It is like a captain setting a defensive field only after mentally rehearsing where the batsman is likely to hit, rather than placing fielders randomly and hoping for the best.
function Invoke-LogArchive {
[CmdletBinding(SupportsShouldProcess)]
param(
[Parameter(Mandatory)][string]$Path,
[int]$RetentionDays = 30,
[string]$ArchivePath = "$Path\Archive"
)
if (-not (Test-Path $ArchivePath)) {
New-Item -Path $ArchivePath -ItemType Directory | Out-Null
}
$cutoff = (Get-Date).AddDays(-$RetentionDays)
$stale = Get-ChildItem -Path $Path -Filter '*.log' -File |
Where-Object { $_.LastWriteTime -lt $cutoff }
foreach ($file in $stale) {
$dest = Join-Path $ArchivePath "$($file.BaseName)_$($file.LastWriteTime.ToString('yyyyMMdd')).zip"
if ($PSCmdlet.ShouldProcess($file.FullName, "Archive to $dest")) {
Compress-Archive -Path $file.FullName -DestinationPath $dest
Remove-Item -Path $file.FullName
}
}
}Wiring Up Notifications and Exit Codes
A script meant to run unattended should report what happened without a human watching: build a summary object as you go, send it with Send-MailMessage (or a Graph API call if SMTP AUTH is disabled on your tenant), and set an explicit exit code with exit 1 on failure so a scheduler or CI pipeline can detect trouble without parsing log text. Wrap the whole body in a top-level try/catch so an unhandled exception still produces a clean failure notification instead of the script simply vanishing mid-run with no trace.
Cricket analogy: It is like a scorer sending the final result to the league office the moment the match ends, win, loss, or abandoned, so no one has to guess what happened from silence.
Scheduling and Hardening for Unattended Runs
Register the finished script as a Scheduled Task with Register-ScheduledTask, running under a dedicated service account with least-privilege access rather than a personal admin login, and use -Trigger (New-ScheduledTaskTrigger -Daily -At 2am) so it runs consistently outside business hours. Store any credentials needed with a secrets manager or the SecretManagement module rather than a plaintext password in the script, and log to a rotating file (or a central sink like a SIEM) so that six months later, when someone asks 'did this run last Tuesday,' the answer doesn't depend on anyone's memory.
Cricket analogy: It is like a franchise scheduling net practice at a fixed 6am slot every day regardless of who shows up to supervise, using the ground staff's access badge rather than a star player's personal key.
Test every automation script manually with -WhatIf first, then run it once interactively end to end, before registering it as a Scheduled Task. Catching a logic bug while you're watching is far cheaper than discovering it three weeks into unattended nightly runs.
Never hard-code passwords, API keys, or connection strings directly in a script that will be scheduled or checked into source control. Use the SecretManagement/SecretStore modules, Azure Key Vault, or a managed identity — a plaintext credential in a .ps1 file is one accidental git push away from a security incident.
- Scope automation scripts narrowly around one well-defined job with clear inputs and success criteria.
- Design parameters first, then build the core logic, so the script is testable and schedulable from the start.
- Add [CmdletBinding(SupportsShouldProcess)] and $PSCmdlet.ShouldProcess() to support -WhatIf previews before mutating anything.
- Wrap the whole script body in try/catch and set explicit exit codes so schedulers and CI can detect failure reliably.
- Send a completion notification (email, Slack, Teams) so unattended runs are observable without checking logs manually.
- Run scheduled scripts under a dedicated least-privilege service account, never a personal admin login.
- Store credentials in a secrets manager (SecretManagement, Key Vault) — never hard-code them in the script.
Practice what you learned
1. What does [CmdletBinding(SupportsShouldProcess)] combined with $PSCmdlet.ShouldProcess() enable?
2. Why should a scheduled automation script set an explicit exit code on failure?
3. What is the recommended way to store credentials used by a scheduled PowerShell script?
4. Why should a Scheduled Task run under a dedicated service account rather than a personal login?
5. What is the benefit of wrapping an entire automation script's body in a single top-level try/catch?
Was this page helpful?
You May Also Like
PowerShell Best Practices
Practical conventions for writing PowerShell scripts and functions that stay readable, safe, and maintainable as they grow.
PowerShell Quick Reference
A condensed reference of the PowerShell syntax, operators, and cmdlets you reach for most often day to day.
PowerShell vs Bash
How PowerShell's object pipeline compares to Bash's text pipeline, and when to reach for each shell.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics