AzLocal.UpdateManagement

0.9.20

PowerShell module to manage Azure Local (formerly Azure Stack HCI) cluster updates using Azure Update Manager APIs. Provides functions to start updates, check update status, list available updates, and monitor update runs.

Minimum PowerShell version

5.1

Installation Options

Copy and Paste the following command to install this package using PowerShellGet More Info

Install-Module -Name AzLocal.UpdateManagement

Copy and Paste the following command to install this package using Microsoft.PowerShell.PSResourceGet More Info

Install-PSResource -Name AzLocal.UpdateManagement

You can deploy this package directly to Azure Automation. Note that deploying packages with dependencies will deploy all the dependencies to Azure Automation. Learn More

Manually download the .nupkg file to your system's default download location. Note that the file won't be unpacked, and won't include any dependencies. Learn More

Owners

Copyright

(c) Microsoft. All rights reserved.

Package Details

Author(s)

  • Neil Bird Microsoft

Tags

Azure AzureLocal AzureStackHCI Updates UpdateManager HCI Automation CICD Pipeline ServiceNow ITSM Incident

Functions

Connect-AzLocalServicePrincipal Start-AzLocalClusterUpdate Invoke-AzLocalFailedUpdateRetry Get-AzLocalClusterUpdateReadiness Get-AzLocalClusterInventory Get-AzLocalClusterInfo Get-AzLocalUpdateSummary Get-AzLocalAvailableUpdates Get-AzLocalUpdateRuns Set-AzLocalClusterUpdateRingTag Invoke-AzLocalFleetOperation Get-AzLocalFleetProgress Test-AzLocalFleetHealthGate Export-AzLocalFleetState Resume-AzLocalFleetUpdate Stop-AzLocalFleetUpdate Test-AzLocalClusterHealth Get-AzLocalFleetStatusData New-AzLocalFleetStatusHtmlReport Test-AzLocalUpdateScheduleAllowed Reset-AzLocalSideloadedTag Get-AzLocalItsmConfig Test-AzLocalItsmConnection New-AzLocalIncident Copy-AzLocalPipelineExample Update-AzLocalPipelineExample Copy-AzLocalItsmSample Get-AzLocalFleetHealthFailures Test-AzLocalApplyUpdatesScheduleCoverage Get-AzLocalUpdateRunFailures Get-AzLocalApplyUpdatesScheduleConfig Resolve-AzLocalCurrentUpdateRing Get-AzLocalApplyUpdatesScheduleNextFirings New-AzLocalApplyUpdatesScheduleConfig Update-AzLocalApplyUpdatesScheduleConfig Get-AzLocalApplyUpdatesScheduleCycleCalendar Get-AzLocalFleetHealthOverview Get-AzLocalLatestSolutionVersion Sync-AzLocalClusterUpdateSummary Get-AzLocalFleetConnectivityStatus New-AzLocalFleetConnectivityStatusSummary Add-AzLocalPipelineVersionBanner Add-AzLocalPipelineSupportFooter Assert-AzLocalAzureSubscriptionAccess Assert-AzLocalPipelineReport Export-AzLocalAuthValidationReport Invoke-AzLocalClusterInventory Set-AzLocalClusterUpdateRingTagFromCsv Export-AzLocalUpdateRunMonitorReport Export-AzLocalFleetUpdateStatusReport Export-AzLocalClusterUpdateReadinessReport Export-AzLocalFleetConnectivityStatusReport Export-AzLocalApplyUpdatesScheduleAudit Export-AzLocalFleetHealthStatusReport Resolve-AzLocalPipelineUpdateRing Export-AzLocalClusterReadinessGateReport Invoke-AzLocalReadinessGatedClusterUpdate Invoke-AzLocalReadinessGatedFailedUpdateRetry Add-AzLocalFailedUpdateRetryHintSummary Add-AzLocalApplyUpdatesStepSummary Add-AzLocalNoReadyClustersStepSummary Invoke-AzLocalItsmTicketingFromArtifact Update-AzLocalSideloadCatalog Resolve-AzLocalSideloadPlan Invoke-AzLocalSideloadUpdate Export-AzLocalSideloadStatusReport Add-AzLocalSideloadStepSummary Get-AzLocalExcludedSubscription Set-AzLocalExcludedSubscription

PSEditions

Desktop Core

Dependencies

This module has no dependencies.

Release Notes

## Version 0.9.20 - Monitor: 3 - Fleet Update Status: the "Fleet - SBE Version(s) Distribution" table is reworked to group by hardware OEM provider and read the correct YYMM. Solution Builder Extension (SBE) packages are vendor-specific, so the table now leads with an "OEM Provider" first column and groups clusters PRIMARILY by hardware OEM (Dell / HPE / Lenovo / Microsoft / ...) then by SBE YYMM. The OEM is resolved from each cluster's reported node manufacturer (properties.reportedProperties.nodes[].manufacturer) via the new private helper Resolve-AzLocalHardwareOem; a new readiness-row field SbeOemProvider carries it (also in readiness-status.csv). SBE YYMM is now read from the THIRD version octet (<major>.<minor>.<YYMM>.<build>, e.g. 5.0.2605.1000 -> 2605, 5.0.2603.1522 -> 2603); v0.9.19 incorrectly used the second octet. Clusters with no vendor SBE (the base placeholders 2.0.0.0 / 2.1.0.0 and any cluster with no SBE package) now show "N/A - No SBE Installed" for YYMM (genuinely not present, not "unknown") while still grouping under their hardware OEM. Export count unchanged at 69 (Resolve-AzLocalHardwareOem is private). Renders identically on GitHub Actions and Azure DevOps. `GENERATED_AGAINST_MODULE_VERSION` bumped to `'0.9.20'`.

## Version 0.9.19 - Update: 1 - Assess Update Readiness fixes an SBE-prerequisite mis-classification, surfaces which updates the allowedUpdateVersions allow-list is filtering out, and Monitor: 3 - Fleet Update Status gains two new tables. FIX: a cluster with a genuinely-Ready update is no longer mislabelled "SBE Prerequisite / Not-Ready" just because it also carries a HasPrerequisite SBE update - the shared classifier Get-AzLocalClusterReadinessStatus (Update: 1 / Apply-Updates readiness gate / Monitor: 3) tested SbeBlocked before ReadyForUpdate; it is now gated on there being no Ready update, so a cluster with a Ready feature update AND a HasPrerequisite SBE classifies as ReadyForUpdate (only a cluster whose sole available update is the prereq item stays SbeBlocked). Assess Update Readiness adds an "Updates filtered out by the allow-list" table: when the allow-list removes updates Azure reports as Ready, this fleet-wide aggregate (not per cluster) lists each filtered-out update, whether the rule is Global (top-level) or Per-Ring (row override), the affected ring(s), and a distinct cluster count - so operators can see which update names to add to apply-updates-schedule.yml (new step output allowlist_filtered_updates + PassThru AllowListFilteredUpdateCount). Assess Update Readiness also adds a "Status checked (UTC)" column (the updateSummary lastChecked - when Azure last scanned the cluster for updates) to the Not-Ready + detail tables (new row field StatusLastChecked); a stale value explains why a portal-visible update is not yet Ready, with a note to refresh via Sync-AzLocalClusterUpdateSummary before re-running. Monitor: 3 - Fleet Update Status adds (1) a "Fleet - SBE Version(s) Distribution" table pivoting each cluster's installed SBE version (vendor.YYMM.x.x); base placeholders 2.0.0.0 / 2.1.0.0 and clusters with no SBE content show as "No SBE Installed" (YYMM column kept, no Support column - SBE has no Microsoft support window); and (2) an "Updates - Recent Successful Updates" table listing runs that reached Succeeded in the last 48h with Cluster + Update portal deep-links. Headers renamed: "Fleet Version Distribution" -> "Fleet - Solution Update(s) Version Distribution"; "Update Run History and Error Details" -> "Updates - Recent Failed Update Attempts". Supporting: Get-AzLocalUpdateRuns rows carry a raw EndTimeUtc [datetime]; Step 4c collects the full run set (no -Latest). New step outputs sbe_version_dist_count, recently_completed_48h. Export count unchanged at 69. `GENERATED_AGAINST_MODULE_VERSION` bumped to `'0.9.19'`.

## Version 0.9.18 - Follow-up strict-mode hardening after v0.9.17. A live re-run of Update: 3 - Apply Updates showed the failed-update single-retry STILL crashed on one cluster with "The property 'steps' cannot be found on this object". v0.9.17 guarded only the TOP-LEVEL progress.steps read in Format-AzLocalUpdateRun; the recursive step-tree walkers it calls (Get-DeepestActiveStep, Get-CurrentStepPath, Get-DeepestErrorMessage, Find-DeepestError) still read $step.steps/status/name/errorMessage BARE and threw under Set-StrictMode -Version Latest on a LEAF step omitting `steps`. All walker reads are now guarded; a broader strict-mode audit hardened more optional-field bare reads across Get-AzLocalUpdateSummary, Get-AzLocalAvailableUpdates, Get-AzLocalClusterUpdateReadiness, Get-AzLocalFleetStatusData, Get-AzLocalUpdateRunHealthEvidence and Get-AzLocalFleetHealthFailures. Also new: a Support disclaimer footer (new exported helper Add-AzLocalPipelineSupportFooter, wired as a final if:always() step in all 20 templates) renders at the bottom of every pipeline run summary, plus a caveat line on the install-step version banner. Export count 68 -> 69. `GENERATED_AGAINST_MODULE_VERSION` bumped to `'0.9.18'`.

## Version 0.9.17 - PSGallery install-step retry hardened to survive a PROLONGED search-index outage. After a customer hit a PSGallery blip that outlasted the v0.9.16 5-attempt / ~2.5-min window (all 5 attempts failed with "No match was found ... 'AzLocal.UpdateManagement'"), the shared install step in all 20 GitHub Actions + Azure DevOps templates (26 install blocks) now retries up to 25 attempts (~25 min) with the same capped exponential backoff + jitter (10s, 20s, 40s, then a 60s cap). This is ONE uniform mechanism on BOTH platforms - a single long-retry run - deliberately chosen over a self-re-queue so GitHub Actions and Azure DevOps behave identically and no extra permissions (GH 'actions: write' / ADO Queue-builds) are required. ~25 min stays under the ADO 60-min hosted-agent job cap; GitHub-hosted runners have a 6-hour cap. Normal-path behaviour is unchanged (a healthy install returns on the first attempt) and the latest module version is still installed. ALSO in this release: the Update: 3 - Apply Updates step summaries (readiness gate + apply) now open, on scheduled/cron runs, with a banner making it explicit that the targeted UpdateRing(s) are derived from the operator's own apply-updates-schedule.yml (path + current cycle day + matched rings), with the Apply banner recommending Config: 3 - Apply-Updates Schedule Coverage Audit for the full per-day cycle (new Private helper Get-AzLocalApplyScheduleSourceBanner; renders nothing on manual runs); the Apply-Updates "Cluster Readiness" table gains an UpdateRing column after Cluster (plus a matching UpdateRing field on every readiness row / readiness-report.csv); and a Set-StrictMode -Version Latest crash retrying a failed update whose ARM run omits `location` or `progress.steps` (Format-AzLocalUpdateRun, also hardened in Get-AzLocalFleetStatusData + Get-LastUpdateRunErrorSummary) is fixed with PSObject.Properties guards. No public function or export-count change (still 68). `GENERATED_AGAINST_MODULE_VERSION` bumped to `'0.9.17'`.

## Version 0.9.16 - Pipeline bootstrap hardening (Update: 3 - Apply Updates and every other template). The shared "Install AzLocal.UpdateManagement from PSGallery" step in all 20 GitHub Actions + Azure DevOps templates (26 install blocks) now retries a transient PSGallery search-index blip ("No match was found ... 'AzLocal.UpdateManagement'") up to 5 attempts (was 3) with a CAPPED exponential backoff plus jitter (~10s, 20s, 40s, 60s + 0-4s random) so fanned-out fleet jobs no longer retry in lockstep and a >30s index blip is ridden out. A customer and the internal fleet both hit a run where the module installed cleanly in one job but a sibling job failed all 3 old attempts seconds later (~30s window was too short). The benign "No Clusters Ready" reporting job in apply-updates (GH job no-clusters-ready / ADO stage NoClustersReady) is now non-fatal (continue-on-error / continueOnError): a persistent install blip on a nothing-to-apply run no longer turns a healthy no-op red. Jobs that genuinely need the module still fail hard after the hardened retry. No public function, parameter or export-count change (still 68). `GENERATED_AGAINST_MODULE_VERSION` bumped to `'0.9.16'`.

## Version 0.9.15 - Update: 1 - Assess Update Readiness surfaces two operator-guidance improvements: (1) clusters that are 'Up to Date' ONLY because the allowedUpdateVersions allow-list held back every Ready update get their own visible "Up to date - Ready update held by allow-list" table + a labelled sub-count (new PassThru AllowListHeldCount); (2) SBE-prerequisite Not-Ready clusters carry a manual-action knowledge note (review the Hardware OEM docs + sideload the SBE). Fixed: Update: 2 - FORCE (break-glass) runs now HONOUR the allow-list (Resolve-AzLocalPipelineUpdateRing gains -ForceImmediateUpdate + Resolve-AzLocalForceAllowList; FORCE bypasses only the schedule WINDOW, never the version allow-list). No public function or export-count change (still 68). `GENERATED_AGAINST_MODULE_VERSION` bumped to `'0.9.15'`.

## Version 0.9.14 - Surface allow-list-suppressed Ready updates in Update: 1 - Assess Update Readiness (new `Available Ready updates` column + `Up to Date *` marker/footnote), a per-cluster allow-list-mismatch warning, and a 3-attempt PSGallery install-step retry across all 20 templates. No public function, parameter or export-count change (still 68). `GENERATED_AGAINST_MODULE_VERSION` bumped to `'0.9.14'`.

## Version 0.9.13 - Bug fix: Monitor: 3 - Fleet Update Status no longer crashes on a failed update run that carries a short deepest-error message.

For full release notes see:
https://github.com/NeilBird/Azure-Local/blob/main/AzLocal.UpdateManagement/CHANGELOG.md

FileList

Version History

Version Downloads Last updated
0.9.20 (current version) 128 7/8/2026
0.9.19 11 7/8/2026
0.9.18 69 7/7/2026
0.9.17 16 7/7/2026
0.9.16 51 7/6/2026
0.9.15 170 7/2/2026
0.9.14 19 7/2/2026
0.9.13 18 7/2/2026
0.9.12 58 7/1/2026
0.9.11 89 6/29/2026
0.9.10 105 6/26/2026
0.9.1 13 6/26/2026
0.9.0 52 6/25/2026
0.8.99 6 6/25/2026
0.8.98 5 6/25/2026
0.8.97 35 6/24/2026
0.8.96 34 6/23/2026
0.8.95 10 6/23/2026
0.8.94 107 6/19/2026
0.8.93 25 6/18/2026
0.8.92 10 6/18/2026
0.8.91 13 6/18/2026
0.8.90 5 6/18/2026
0.8.89 7 6/18/2026
0.8.88 41 6/17/2026
0.8.87 37 6/16/2026
0.8.86 17 6/16/2026
0.8.85 6 6/16/2026
0.8.84 34 6/15/2026
Show more