Azure Local Updates Are Changing: What 2610 and Patch Tuesday Security Updates Mean for Your Update Runbook

If you’ve been around Azure Local (formerly Azure Stack HCI) for any length of time, you know updates are where a lot of the real-world pain lives. The October 2026 release of Azure Local (2610, solution version 12.2610.1004.41) and the changes landing in November move the update story forward in some meaningful ways, so I wanted to pull them together in one place along with how I’d adjust an update runbook.

What changed (the short version)

Straight from the What’s new in Azure Local page:

• Security updates on Patch Tuesday (starting November 2026). OS latest cumulative update (LCU) and .NET updates are released the same week as Patch Tuesday instead of waiting for the next feature/cumulative release.
  • If you’re already on the latest Azure Local release, these act as security-only updates.
  • If you’re on an applicable older release, installing the security update also brings along the required Azure Local security updates to get you to the target security release version.
  • They can only be applied through supported update paths.
• Combined OS and SBE CAU updates. OS updates and OEM firmware/drivers (the Solution Builder Extension, or SBE) can now be applied in a single coordinated Cluster-Aware Updating run. Fewer reboot cycles, less time with workloads bouncing around the cluster.
• New Get-SolutionHealthSummary command. Gives you a concise summary of the most recent solution health check results, calling out critical and important issues you should fix first.
• Composed ISO on a semiannual cadence, aligned with OEM validation and release cycles.

And a couple from the last few months that matter for the same conversation:

• 2608 introduced the prepare updates workflow (prepare now, install later) and a new update state, Pending OEM Validation, for feature updates that are awaiting OEM validation.
• 2607 added the ability to download update packages directly from the Azure portal for limited-connectivity and offline scenarios.

Why this matters

The Patch Tuesday change is the big one. Previously, many teams treated Azure Local updates as a “once a month, whenever the release drops” event. Now there are effectively two motions to plan for:

1. Security updates that track Patch Tuesday.
2. Feature/solution updates (the monthly 26xx releases), which for OEM-validated systems may sit in Pending OEM Validation until your hardware vendor signs off.

From working with OEM-validated systems, I can tell you the second point is the one people get tripped up by. You may see an update in the portal and wonder why you can’t install it yet. Now there’s an explicit state that tells you why.

A practical pre-update runbook

Here’s how I’d structure the pre-flight on a cluster node. All of the -SolutionUpdate cmdlets below are documented in Update Azure Local via PowerShell. Get-SolutionHealthSummary requires 2610 or later.

1. Check where you are

# Current solution version and update environment state
Get-SolutionUpdateEnvironment |
    Select-Object State, CurrentVersion, CurrentSbeVersion, HealthState

If HealthState isn’t healthy, stop here. Don’t start an update on a cluster that’s already unhappy.

2. Get the health summary (2610+)

# Concise summary of the most recent solution health check results
Get-SolutionHealthSummary

Before this command existed, digging through health check output to find what actually blocks an update took a lot of scrolling. Fix anything flagged critical before going any further. Important items deserve a look too, since they tend to show up again as failed update steps.

Tip: If you need to send logs to support, 2610 also adds a SANDiagnostics role for filtering logs on SAN-based deployments, and since 2601 you can collect diagnostic logs directly from the Azure portal.

3. See what’s available

Get-SolutionUpdate |
    Select-Object DisplayName, Version, State, PackageType |
    Format-Table -AutoSize

Keep an eye on the State column. With the 2608 changes you may see updates waiting for OEM validation. On OEM-validated hardware, that’s expected, not something you need to troubleshoot.

4. Kick it off (or prepare it for later)

# Start a specific update by its resource ID
$Update = Get-SolutionUpdate | Where-Object { $_.State -eq 'Ready' } |
    Sort-Object Version -Descending | Select-Object -First 1
if ($null -ne $Update) {
    Write-Host "Starting update: $($Update.DisplayName) ($($Update.Version))"
    $Update | Start-SolutionUpdate
} else {
    Write-Host "No update in a 'Ready' state - nothing to do."
}

If you’d rather separate download/staging from install so your actual maintenance window is shorter, look at the prepare updates workflow added in 2608. Check the current documentation for the exact steps before scripting it.

5. Monitor progress

$Stopwatch = [System.Diagnostics.Stopwatch]::StartNew()
:MonitorUpdate while ($true) {
    $Run = Get-SolutionUpdate | Where-Object { $_.State -like '*Installing*' -or $_.State -eq 'Installed' -or $_.State -like '*Failed*' } |
        Select-Object -First 1
    switch -Wildcard ($Run.State) {
        'Installed'  { Write-Host "Update installed."; break MonitorUpdate }
        '*Failed*'   { throw "Update failed - state: $($Run.State)" }
        default      { Write-Host "Update state: $($Run.State) (sleeping 5 minutes)"; Start-Sleep -Seconds 300 }
    }
    if ($Stopwatch.Elapsed.TotalHours -gt 12) { throw "Timeout Exceeded" }
}

Note: Validate the exact state strings returned in your environment before relying on the wildcards above. They’re a starting point, not gospel.

Of course, you can watch all of this from the Azure portal or Azure Update Manager as well. The portal’s update experience has gotten much richer over the past year (see 2602).

What I’d change in your process today

1. Add a monthly “Patch Tuesday + a few days” slot for Azure Local security updates, separate from your feature update cadence.
2. Stay on a supported update path. Security updates only apply through supported paths. Clusters that drift too far behind make every month harder.
3. Talk to your OEM about SBE timing. With combined OS + SBE CAU runs, the firmware/driver payload matters more than ever, and Pending OEM Validation is now visible in the update state.
4. Make Get-SolutionHealthSummary a gate in any automation (Jenkins, Azure DevOps, GitHub Actions, whatever you use). If it reports critical issues, fail the pipeline before Start-SolutionUpdate ever runs.
5. Plan for limited connectivity. If you have sites with constrained bandwidth, the portal download option (2607) plus import/discover of update packages is worth testing now, not during an outage.

Wrapping up

The direction is clear: Azure Local updates are becoming more frequent, more predictable, and more transparent about why something can or can’t install yet. Get your runbook ready for the November Patch Tuesday release and you’ll be ahead of most.

If you’ve already run 2610 in your lab, I’d love to hear how Get-SolutionHealthSummary and the combined CAU runs went for you. Leave a comment below or find me on the Microsoft Tech Community.

References

• What’s new in Azure Local
• About updates for Azure Local
• Update Azure Local via PowerShell
• Use Azure Update Manager to update Azure Local
• Azure Local release information