Why Your Self-Healing Scripts Fail (and How Azure Identities + AlertMonitor Close the Loop)

If you are managing Microsoft 365 or Azure infrastructure, you’ve likely dabbled in Azure Automation. You write a PowerShell runbook to clear a stuck queue, automate a user offboarding task, or cycle a misbehaving service. It feels like a win—until you realize the script ran three hours after the incident started, or worse, it ran on the wrong server because your monitoring tool and your automation platform don't actually talk to each other.

A recent discussion on user-assigned managed identities highlights a critical evolution in how we handle authentication for these scripts. Unlike system-assigned identities, which die with the automation account, user-assigned identities exist as standalone Azure resources. They allow you to share a single identity across Logic Apps, Function Apps, and multiple automation accounts. This is a technical leap forward for security and portability, but it exposes a deeper operational gap: having a portable identity doesn't fix a fragmented workflow.

The Problem: Identity Sprawl Meets Tool Sprawl

Technically, the article gets it right. Using user-assigned identities is the superior way to handle M365 automation when workloads span subscriptions. You create the identity in the portal, grab the client ID, grant permissions via the object ID, and you’re authenticating without storing credentials in scripts.

But here is the reality for the sysadmin or MSP technician:

You have the RMM tool sending alerts about disk space. You have the separate Azure Automation account running scripts. You have the helpdesk system tracking user complaints. These are three different silos.

1. The RMM Detects: Your RMM flags that C: drive on EXCH-01 is at 90%.
2. The Human is Paged: You get the alert at 2:00 AM. You wake up, VPN in, and investigate.
3. The Manual Fix: You remember you have a script for this, but it’s in a different repository. You run it manually.

The identity was there. The script was there. But the bridge between the detection and the resolution was missing. The alert didn't trigger the runbook; it just triggered a pager. This is the hidden cost of tool sprawl. You have invested in automation that requires human intervention to execute, defeating the purpose of proactive IT.

How AlertMonitor Solves This

AlertMonitor doesn’t just monitor infrastructure; it closes the loop between detection and resolution. We understand that having a user-assigned managed identity is only useful if a platform can leverage it the moment an issue arises.

Instead of treating your Azure runbooks as a separate library of scripts, AlertMonitor treats them as actionable extensions of our alerting engine.

The workflow changes dramatically:

• Step 1: AlertMonitor detects the anomaly (e.g., Exchange transport logs filling the disk).
• Step 2: The policy engine instantly matches this alert to a specific remediation runbook.
• Step 3: AlertMonitor triggers the Azure Automation runbook, utilizing your pre-configured user-assigned identity for secure, passwordless execution.
• Step 4: The script clears the logs, frees up space, and returns a success code.
• Step 5: AlertMonitor auto-resolves the ticket.

No pager. No VPN. No 3:00 AM scramble. The user-assigned identity handles the security; AlertMonitor handles the orchestration. Furthermore, our Canary Deployment monitoring ensures that if you write a new script to patch a fleet of Windows servers, it rolls out to a test group first. This prevents the "accidental fleet-wide disruption" scenario that keeps every IT Director awake at night.

Practical Steps: Implementing Proactive Remediation

To move from reactive patching to self-healing, you need to leverage your identities within a unified trigger system. Here is how you can structure a standard remediation task—clearing temporary log files on a Windows Server—using PowerShell, ready to be triggered by an AlertMonitor policy.

1. Define the Logic (PowerShell)

This script checks a specific path for files older than 7 days and deletes them. In production, this would run under the context of your User-Assigned Managed Identity.

param(
    [Parameter(Mandatory=$true)]
    [string]$TargetPath,
    
    [Parameter(Mandatory=$false)]
    [int]$DaysToKeep = 7
)

try {
    $CutoffDate = (Get-Date).AddDays(-$DaysToKeep)
    $DeletedFiles = Get-ChildItem -Path $TargetPath -Recurse -File -ErrorAction SilentlyContinue |
                    Where-Object { $_.LastWriteTime -lt $CutoffDate }

    if ($DeletedFiles) {
        $DeletedFiles | Remove-Item -Force -ErrorAction Stop
        Write-Output "SUCCESS: Removed $($DeletedFiles.Count) files older than $DaysToKeep days from $TargetPath."
    } else {
        Write-Output "INFO: No files found older than $DaysToKeep days."
    }
}
catch {
    Write-Error "FAILED: Error cleaning up path $TargetPath. Error: $_"
    exit 1
}

2. Configure the AlertMonitor Trigger

In AlertMonitor, create a policy for "Windows Server Disk Space":

• Condition: If C: drive usage > 85%.
• Action: Execute Azure Runbook (Script: Log-Cleanup).
• Safety Net: If runbook fails > 3 times, escalate to Level 2 Engineer.

By attaching the runbook directly to the alert condition, you transform a static script into a proactive defense mechanism. You stop managing outages and start managing automation.

Related Resources

AlertMonitor Self-Healing & Proactive IT AlertMonitor Platform Overview Book a Demo Self-Healing & Proactive IT Resources