Automating VMware Snapshot Cleanup with PowerCLI and Scheduled Tasks
Snapshot sprawl is one of those quiet problems that creeps up on even the most disciplined virtual infrastructure teams. A snapshot taken for a quarterly patching window in a Brisbane datacentre gets forgotten, another lingers after a vMotion in Sydney, and before long the datastore is gasping for space. For Australian organisations operating under the Privacy Act 1988 and the Notifiable Data Breaches scheme, those forgotten snapshots are more than a storage nuisance — they can represent unencrypted copies of customer data sitting in limbo outside the normal backup rotation.
This article walks through a practical approach to building a self-maintaining snapshot hygiene routine using PowerCLI and the Windows Task Scheduler. The goal is a lightweight, scriptable workflow that runs unattended, produces a clear audit trail, and aligns with the operational realities of local IT teams juggling hybrid workloads between city offices and regional hubs.
Why Snapshot Hygiene Matters in Australian Environments
A single snapshot rarely causes trouble, but most vSphere estates end up with dozens of them. Each one is a delta file that grows with every write to the parent VMDK, which means a week-old snapshot on a busy file server in a Parramatta office can quietly consume hundreds of gigabytes. When the underlying datastore fills, the cascade is familiar: VMs pause, HA triggers, applications time out, and the on-call engineer in Melbourne gets paged at 2am.
Regulatory pressure adds another layer. The Australian Signals Directorate's Essential Eight framework encourages regular review of system state, and the Office of the Australian Information Commissioner has been increasingly vocal about the lifecycle of personal information held in test and development copies. A snapshot of a production database that nobody is managing is, in audit terms, an unmanaged copy of personal data — exactly the kind of artefact that attracts scrutiny during a notifiable data breach investigation.
Operationally, the case is just as strong. Many local IT shops run lean teams, often with engineers splitting time between a head office in the CBD and remote sites connected by the National Broadband Network. Automating routine cleanup means those engineers spend less time on Saturday morning hygiene checks and more time on projects that actually move the business forward.
Building the PowerCLI Cleanup Script
The backbone of the solution is a PowerCLI script that connects to vCenter, enumerates snapshots, applies a sensible age threshold, and removes anything that matches the policy. Most teams settle on a 72-hour rule for general-purpose VMs and a 14-day rule for long-running change windows, though this varies by business unit.
A typical workflow starts with Connect-VIServer using a dedicated service account, then Get-VM | Get-Snapshot to gather the full inventory. From there, the script filters by .Created, by VM name pattern, and optionally by a tag applied through vSphere Tags. A safety check excludes any snapshot whose description contains a known marker string — useful for letting change managers flag windows they want preserved.
Connect-VIServer vc01.melbourne.corp.local -Credential $cred
$snapshots = Get-VM | Get-Snapshot | Where-Object {
$_.Created -lt (Get-Date).AddDays(-3) -and
$_.Description -notmatch "KEEP-CHG-\d+"
}
foreach ($snap in $snapshots) {
Remove-Snapshot -Snapshot $snap -Confirm:$false
Write-Output "Removed $($snap.Name) from $($snap.VM)"
}
For teams that want a head start rather than writing this from scratch, the free PowerCLI utilities page has a pre-built version with parameterised thresholds and CSV output that drops straight into the workflow above.
Manual vs Automated Snapshot Management
Before wiring up the scheduler, it helps to be clear about what changes when cleanup is automated. The table below compares the two approaches across the dimensions that matter most to a busy operations team.
| Aspect | Manual Cleanup | Automated Cleanup |
|---|---|---|
| Time investment | Hours per week across the team | Minutes to review logs |
| Error rate | Inconsistent, dependent on the engineer | Predictable, policy-driven |
| Audit trail | Spreadsheet notes, often after the fact | Timestamped log file per run |
| Scalability | Breaks beyond roughly 50 VMs | Scales to thousands of VMs |
| Compliance posture | Reactive, hard to evidence | Continuous, reportable |
| Out-of-hours coverage | Limited to on-call rotation | Runs regardless of public holidays |
The shift from manual to automated is less about replacing human judgement and more about removing the repetitive scanning work so engineers can focus on the exceptions that genuinely need investigation.
Configuring Windows Task Scheduler for Routine Execution
PowerCLI on its own does not run on a schedule — it needs a host. A small Windows Server, often a management VM already joined to the Active Directory domain, is the usual choice. The scheduled task wraps the PowerCLI script with the right credentials and triggers it at a sensible cadence.
A nightly run at 0100 AEST works well for most Australian environments, since this sits comfortably after business hours in Sydney, Melbourne, and Perth and well before the Auckland morning ramp for any trans-Tasman workloads. During daylight saving, the scheduler will run an hour earlier in local terms, which is fine for cleanup jobs that are not time-critical.
The task should run as a dedicated service account with the "Log on as batch job" right, not as a domain admin. The action launches powershell.exe with -ExecutionPolicy Bypass and the full path to the script. Setting "Run whether user is logged on or not" and "Run with highest privileges" covers the common edge cases. It is worth testing the task manually with the same account first, because the most common failure mode is a credential or execution policy issue that only surfaces under the scheduler context.
Logging, Monitoring, and Compliance Alignment
Automation is only valuable if the output is visible. The script should write to a rolling log file, ideally on a share that is included in the regular backup regime so the audit trail is preserved. A simple Start-Transcript at the top captures everything, and a Send-MailMessage block at the end can fire a summary to a distribution list whenever snapshots are removed.
For organisations aligning with the Essential Eight, the log entries themselves become evidence. A timestamped line such as Removed snapshot SRV-FS-01 patching from SRV-FS-01 is exactly the kind of artefact an assessor wants to see. Where the Corporations Act 2001 imposes a seven-year record-keeping obligation on certain financial data, those snapshot removal logs can be archived alongside other system journals.
Public holidays are worth a brief note. Schedules that align with ANZAC Day or Australia Day will run normally, which is usually fine, but any task that triggers downstream automation should be wrapped in a "skip if holiday" check if the receiving system is not staffed. Local teams often handle this with a small calendar file rather than complicating the script itself.
For more background on the approach used here, plus a few other scripts open-sourced over the years, take a look around the Virtxpert blog. The free tools section in particular has a couple of one-liners that pair nicely with the cleanup job for daily health reporting and capacity trending across multi-site vCenter deployments.