"Something didn't go as planned. Undoing changes." That's the cryptic message your end users are seeing when they boot up their Windows 11 machines this week. Microsoft's May security update is failing to install on devices with insufficient space on the EFI System Partition (ESP) — typically those with 10MB or less free. The installation progresses through initial phases but crashes at 35-36% during reboot, leaving systems unprotected against dozens of critical security patches.
The Real Cost of Silent Update Failures
If you're running a helpdesk today, you know exactly what happens next. Your phone starts ringing. Users complain their laptops are "acting weird" or "slow." Ticket queues swell with vague descriptions like "PC stuck at startup." Technicians spend hours investigating each device individually, only to discover it's the same update failure repeated across dozens — or hundreds — of endpoints.
The pain is compounded by tool sprawl. Your RMM platform shows the device as "online." Your separate monitoring tool reports everything green because the server itself is running. Your standalone helpdesk has tickets labeled "PC slow" with zero context about what's actually happening. Meanwhile, critical security vulnerabilities remain unpatched because the update mechanism itself is broken.
This isn't just annoying — it's dangerous. Microsoft's advisory suggests either modifying the Windows registry to force the update (risky for remote devices) or rolling back and waiting for a future fix. Neither option protects your users today.
Why Your Current Tool Stack Is Failing Your Users
The disconnect between monitoring, patching, and support isn't just inefficient — it's exposing your organization to risk. Here's what typically happens in a fragmented environment:
-
The RMM platform shows patching failures as logs buried deep in device details, visible only if a technician proactively checks.
-
The monitoring tool doesn't detect the issue because the device is technically online and functioning normally.
-
The helpdesk gets reactive tickets from frustrated users who've already experienced the problem.
-
The patch management system retries silently, creating a loop of failures without escalating to human oversight.
This architectural gap exists because most IT tools were built as point solutions. RMM vendors focused on remote control. Monitoring vendors focused on uptime metrics. Helpdesk vendors focused on ticket workflows. None of them talk to each other out of the box, so your technicians end up with 12 tabs open across 5 different consoles just to support one client.
The real impact? Your average response time for this specific issue might be 4-6 hours — because you're waiting for users to report problems you could have detected automatically. Your SLA compliance takes a hit. Your technicians burn out answering the same tickets for the same issue across dozens of devices. And your security posture weakens with each failed patch attempt.
How AlertMonitor Turns This Chaos Into Proactive Support
AlertMonitor's integrated helpdesk doesn't just manage tickets — it connects the dots between monitoring alerts, RMM data, and end-user support in a single unified workflow. Here's how it changes the game for this specific Windows update failure:
Automated Detection and Ticket Creation: When AlertMonitor detects the specific failure pattern associated with the Microsoft May update (the boot failure during the 35-36% reboot phase), it doesn't just log it. It automatically creates a support ticket populated with full context: the device name, user affected, specific error codes, and relevant system health data. This happens before the user even finishes their morning coffee.
Intelligent Assignment and Escalation: AlertMonitor routes that ticket to the right technician based on device type, client, and alert severity. If the ESP partition size is below 10MB (the known threshold for this issue), the ticket is flagged as critical with a suggested remediation path. Your helpdesk team sees high-value tickets with actionable intelligence instead of generic "PC not working" descriptions.
One-Click Remote Resolution: Each ticket includes one-click remote access to the affected device. Technicians don't need to launch a separate RMM console, authenticate again, or search for the device. They're connected immediately, with the full alert history visible side-by-side with the ticket. The technician can immediately verify the ESP partition size, apply the registry workaround if appropriate, or schedule a follow-up when Microsoft releases a fixed update.
Real-Time SLA Tracking: IT managers get accurate SLA data without spreadsheet gymnastics. Because monitoring and helpdesk live in the same system, AlertMonitor knows exactly when the issue occurred (alert timestamp) and when it was resolved (ticket closure). No more guessing or manual reconciliation between disconnected systems.
Practical Steps: Detecting and Managing ESP Partition Issues
Here's how you can put AlertMonitor's unified approach into practice right now to manage the Microsoft May update issue — and prevent similar problems in the future:
Step 1: Deploy a Monitoring Script for ESP Partition Size
Run this PowerShell script across your Windows endpoints to identify devices at risk for update failures:
# Check EFI System Partition (ESP) size and free space
$espPartition = Get-Partition | Where-Object { $_.Type -eq 'EFI' -and $_.IsBoot -eq $true }
if ($espPartition) {
$volume = Get-Volume -Partition $espPartition
$freeSpaceMB = [math]::Round(($volume.SizeRemaining / 1MB), 2)
$totalSpaceMB = [math]::Round(($volume.Size / 1MB), 2)
$result = [PSCustomObject]@{
ComputerName = $env:COMPUTERNAME
ESPDriveLetter = if ($volume.DriveLetter) { $volume.DriveLetter } else { "Hidden" }
ESPFreeSpaceMB = $freeSpaceMB
ESPTotalSpaceMB = $totalSpaceMB
AtRisk = if ($freeSpaceMB -lt 10) { "YES" } else { "NO" }
Timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
}
$result | Format-Table -AutoSize
# In AlertMonitor, this would automatically trigger an alert if AtRisk is YES
# and create a ticket with this data attached
}
else {
Write-Host "EFI System Partition not found on this system."
}
Step 2: Create an Alert-to-Ticket Workflow in AlertMonitor
Configure AlertMonitor to automatically generate tickets when:
- ESP partition free space drops below 15MB (giving you a buffer before the 10MB threshold)
- Windows Update logs contain failure codes related to the May update
- Reboot failures are detected during the typical patching window
These tickets should automatically include:
- Full system inventory (make, model, OS version)
- Related alert history for the past 30 days
- One-click remote access to the device
- Known documentation for this specific issue
Step 3: Implement a Remediation Runbook
For affected devices, your technicians can use this automated remediation script via AlertMonitor's remote execution:
# Backup registry before making changes
$backupPath = "C:\Temp\RegistryBackup_$(Get-Date -Format 'yyyyMMdd_HHmmss').reg"
reg export HKLM\SYSTEM $backupPath
Write-Host "Registry backed up to $backupPath"
# Apply workaround to force the update to use a different temp location
# NOTE: This is a temporary workaround until Microsoft releases a fixed update
$regPath = "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\OSUpgrade"
if (!(Test-Path $regPath)) {
New-Item -Path $regPath -Force
}
# Set flag to allow using OS temp drive for update operations
Set-ItemProperty -Path $regPath -Name "AllowOSUpgrade" -Value 1 -Type DWord
Set-ItemProperty -Path $regPath -Name "ReserveManager" -Value 1 -Type DWord
Write-Host "Registry workaround applied. Attempting update retry..."
# Trigger Windows Update to retry
$autoUpdate = New-Object -ComObject Microsoft.Update.AutoUpdate
$autoUpdate.DetectNow()
Write-Host "Windows Update has been triggered to retry the installation."
Write-Host "Monitor the status via AlertMonitor's integrated ticket view."
Step 4: Close the Feedback Loop
Once resolved, AlertMonitor automatically:
- Updates the ticket with resolution details
- Links the ticket to the device history for future reference
- Updates SLA metrics in real-time
- Creates a knowledge base article that can be reused for similar issues
The Bottom Line
When your monitoring, RMM, and helpdesk work in isolation, your IT team is constantly fighting uphill battles against problems that should have been caught automatically. The Microsoft May update issue is just one example of how fragmented tools leave your end users vulnerable and your team reactive.
With AlertMonitor's unified platform, your helpdesk transforms from a reactive complaint department into a proactive support engine. Issues are detected before users report them. Technicians work with context-rich tickets instead of starting from zero. SLAs become measurable realities instead of spreadsheet guesses.
The question isn't whether these update issues will happen — they will. The question is whether your helpdesk will learn about them from your monitoring platform or from frustrated end users. With AlertMonitor, the answer is clear.
Related Resources
AlertMonitor Helpdesk & End-User Support AlertMonitor Platform Overview Book a Demo Helpdesk & End-User Support Resources
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.