Implementing Automated Storage Utilization Monitoring on Windows Servers (Part 2)
After successfully deploying automated storage-utilization monitoring on our Linux-based instances, I was tasked with extending the same capability to Windows servers within our private cloud. While the objective remained the same, collect and report storage metrics automatically, the Windows implementation introduced unique challenges due to platform differences in automation and system behavior.
Understanding the Requirements
Just like the Linux solution, the Windows-based approach needed to:
Collect total storage capacity, used space, and free space
Identify each server using its unique Server ID
Post aggregated metrics to our monitoring endpoint
Run reliably and autonomously without human intervention
The logic for gathering and transmitting metrics was simple. The challenge was ensuring that the PowerShell script executed automatically and consistently.
Designing the Storage Collection Script
I built a PowerShell script that captured:
Disk size
Storage used
Available free space
Server ID (retrieved through a custom API endpoint)
The script then packaged the data and posted it to our monitoring API, mirroring the behavior of the Linux version. But unlike Linux, automating recurring execution wasn’t as straightforward.
Tackling Windows Automation Challenges
- Replacing Cron with Windows Scheduled Tasks Linux relies on cron jobs, which run indefinitely once configured. Windows uses Scheduled Tasks, so I automated the script with:
New-ScheduledTaskAction
New-ScheduledTaskTrigger
Register-ScheduledTask
Everything appeared correct during testing, until I noticed an unexpected issue.
- The Hidden Three-Day Trigger Limitation By default, Windows Scheduled Tasks without an explicit repetition duration expire after three days. After that, the trigger simply stops firing, even though the task still exists.
This behavior is very different from cron.
To fix it, I explicitly set:
-RepetitionDuration ([TimeSpan]::MaxValue)
This ensured the task ran indefinitely, just like a cron job.
Handling a More Subtle Issue: Server Restarts
After resolving the trigger-duration issue, another problem surfaced:
The task didn’t reliably restart after server reboots.
Cron automatically recovers after a restart. Windows Scheduled Tasks do not, depending on how the task is defined. I attempted multiple configurations, including delayed-start options and different trigger types, but the results were inconsistent.
Implementing a Bootstrap Mechanism
To guarantee reliability, I introduced a lightweight bootstrap script triggered at system startup. Its job was simple:
Check if the monitoring task was running
Restart the task if necessary
This ensured that no matter how often a server rebooted, storage monitoring resumed automatically.
Outcome & Impact
Despite the additional complexity, the Windows implementation ultimately delivered the same level of automation and reliability as the Linux version.
Windows servers now report real-time storage metrics automatically.
Server-specific identification allows accurate metric attribution.
The bootstrap mechanism ensures resilience across reboots.
Combined with the Linux solution, our monitoring became fully unified across the private cloud.
This enhancement has improved infrastructure visibility, enabled early detection of storage issues, and contributed significantly to operational efficiency by reducing Mean Time to Detect (MTTD).
Top comments (0)