AzLocal.UpdateManagement

0.8.98

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 -RequiredVersion 0.8.98

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

Install-PSResource -Name AzLocal.UpdateManagement -Version 0.8.98

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 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

PSEditions

Desktop Core

Dependencies

This module has no dependencies.

Release Notes

## Version 0.8.98 - Turnkey "refresh after every release" updater for the customer repo. `Copy-AzLocalPipelineExample` now also drops a self-contained `Update-Module-And-Pipelines.ps1` into the customer's REPO ROOT (alongside the existing workflow + config starter files), with the chosen devops platform (`GitHub`/`AzureDevOps`) and the resolved workflow subpath baked in at drop time. After each module release the operator just runs that one script: it `Find-Module`s the latest `AzLocal.UpdateManagement`, installs it ONLY when newer (no uninstall churn), re-imports it, calls `Update-AzLocalPipelineExample` to regenerate the pipeline YAMLs, then stages ONLY the workflow folder + `config` (`git -C $RepoRoot add -A -- $gitPaths`, never a blanket `git add .`), and commits + pushes under ShouldProcess (`-WhatIf`/`-NoPush` supported). The drop is default-on for the two single-platform modes, suppressed by the new `-SkipStarterUpdater` switch, and skipped for `-Platform All`; the template is BOM-less and verified to parse. Existing repos get it too: `Update-AzLocalPipelineExample` now drops the same script at the repo root when absent (also gated by `-SkipStarterUpdater`), since pre-v0.8.98 customers upgrade via Update not Copy. The dropped script is version-stamped (`# AZLOCAL-UPDATER-VERSION: X.Y.Z`, a dedicated template semver from `1.0.0`, independent of the module version): when the module ships an improved template, both Copy and Update re-render it IN PLACE only when the existing marker is strictly older (logged `Updated`); an up-to-date or markerless operator-owned file is preserved, never clobbered. Separately, the `Test-Pipelines.ps1` helper was renamed to `Tools/Update-Module-And-Pipelines.ps1` (Tools/ is stripped from the published package, fixing a prior leak of the maintainer script into the PSGallery nupkg). Additive - no public function, parameter-removal or export-count change (still 64). `GENERATED_AGAINST_MODULE_VERSION` bumped to `'0.8.98'`.

## Version 0.8.97 - Update-readiness reporting clarity across the fleet reports, plus intelligent detection of stale "Up to Date" clusters in the Apply Updates readiness table. (1) `Get-AzLocalUpdateRunFailures` Detail view gains an `UpdateRing` column sourced from the cluster ARM `UpdateRing` tag (secondary Resource Graph query against `microsoft.azurestackhci/clusters`; blank when no ring tag). (2) Monitor: 3 (`Export-AzLocalFleetUpdateStatusReport`) Update Run History table gains an Update Ring column (after Cluster Name) and a new "Clusters - Ready for Update" table. (3) Assess Readiness (`Export-AzLocalClusterUpdateReadinessReport`) gains a "Clusters - Ready for Update" table and a separate `ready-for-update.csv` artefact (`-ReadyForUpdateCsvFileName`), and collapses the "All clusters detail" table behind an "Expand to view clusters" <details> block. (4) Monitor: 2 collapses the "Fleet Health Overview" table behind the same expander. (5) The Apply Updates "Cluster Readiness" table now flags clusters that report "Up to Date" while the public update manifest advertises a newer build (a stale cached assessment, e.g. a disconnected cluster) with an "Update Available (stale assessment)" status, and adds a "Support" column. Two new private helpers (`Get-AzLocalReadyForUpdateRows`, `Get-AzLocalReadyForUpdateTableMarkdown`) back the shared ready-for-update view. Report-only and additive - no public API, parameter, or export-count change (still 64). `GENERATED_AGAINST_MODULE_VERSION` bumped to `'0.8.97'`.

## Version 0.8.96 - Follow-up to v0.8.95: surfaces the stalled / orphaned in-flight run signal in the prominent pipeline SUMMARY OUTPUT (the JUnit test-reporter check), not just the artifact CSV. v0.8.95 detected the stall and showed it in the CSV and markdown step summary, but the per-cluster JUnit `<testcase>` classification cascade in `Export-AzLocalUpdateRunMonitorReport` never referenced `IsStalled`, so a frozen `InProgress` run (e.g. an orphaned run stuck for weeks) was reported only as a long-running step and the operator had to open the CSV to learn it was stalled. A new top-priority branch now emits `Status`/failure `Type` = `Stalled` with a `STALLED: no orchestration activity for <duration> ...` message (ARM lastUpdatedTime, current step, step/overall elapsed, progress) instead of falling through to the LongRunningStep/LongRunningOverall reasons. The bundled sample `azurelocal-itsm.yml` gains an additive `Stalled:` trigger key (raiseTicket true, severity 2, category "Update run stalled / orphaned"). The stalled output also spells out the manual remediation: because a stalled run still reports `InProgress` the failed-update single-retry job skips it, so the JUnit failure body and a new callout under the in-flight markdown table tell the operator it is NOT auto-retried and give the `Get-SolutionUpdate`/`Get-SolutionUpdateRun`/`Start-MonitoringActionplanInstanceToComplete`/`Start-SolutionUpdate` flow plus the public Troubleshoot-solution-updates doc link. The CSV and `-PassThru` shape are unchanged. Template + report + docs + tests only - no public API, parameter or export-count change (still 64). `GENERATED_AGAINST_MODULE_VERSION` bumped to `'0.8.96'`.

## Version 0.8.95 - Adds a guarded, opt-in ONE-TIME automatic retry of FAILED Azure Local cluster updates, plus the transient-error and stalled-run hardening that motivated it. New public cmdlets: `Invoke-AzLocalFailedUpdateRetry` (per-cluster primitive - re-issues the same `updates/{name}/apply` action the portal Try again button uses, only when the cluster updateSummary state is NeedsAttention/UpdateFailed/PreparationFailed; an in-progress or stalled/orphaned run is deliberately SKIPPED), `Invoke-AzLocalReadinessGatedFailedUpdateRetry` (Step.6 thin-YAML fan-out that reuses readiness-report.csv, retries each failed-state cluster once with -Confirm:$false but NOT -Force so the guard stays active, emits per-status step outputs + apply-retry-results.json + a Failed Update Single-Retry summary section), and `Add-AzLocalFailedUpdateRetryHintSummary` (discoverability notice). The one-time guard is a durable `UpdateRetryAttempted` cluster tag (a second tag alongside the generic `UpdateLastAttempt` audit pointer); a recorded attempt for the same update version returns `RetryAlreadyAttempted` so a scheduled pipeline never re-applies in a loop, and the guard auto-clears once the retried run reaches Succeeded (or a stale RetryFailed attempt ages out after 1h) via the existing post-success reconciliation. The capability is OFF by default and gated by the `FAILED_UPDATES_SINGLE_RETRY` pipeline variable in `apply-updates.yml` (GitHub + Azure DevOps); when it is off, both the Apply-Updates and Monitor In-Flight Updates pipelines print a short awareness notice (with the exact enable command + a pointer to the new "Opt-in: single-retry of failed updates" CI/CD README section). Also ships two supporting hardening changes: (1) `Export-AzLocalUpdateRunMonitorReport` gains a `-StalledNoProgressHours` parameter (default 24, 0 disables) that flags an `InProgress` run whose ARM `lastUpdatedTime` has frozen as CRITICAL with a stalled chip, an eighth `stalled` step output, a `StalledCount` PassThru field and a new "Last Activity (UTC)" column (`Format-AzLocalUpdateRun`/`Get-AzLocalUpdateRuns` now surface `LastUpdatedTime`) - motivated by an orphaned run stuck InProgress for 30+ days; and (2) `Invoke-AzResourceGraphQuery` now retries transient network failures (`ConnectionResetError(10054)`/"Connection broken"/5xx gateway/timeout), not just throttling, sharing the same `-MaxRetries` budget but NOT arming the cross-call cooldown, with new `$script:LastResourceGraphTransientNetwork`/`LastResourceGraphTransientRetryCount` diagnostics. Export count 61 -> 64. `GENERATED_AGAINST_MODULE_VERSION` bumped to `'0.8.95'`.

## Version 0.8.94 - Expands `BEGIN/END-AZLOCAL-CUSTOMIZE` marker coverage across every bundled CI/CD pipeline YAML (both GitHub Actions and Azure DevOps) so operator-owned INFRASTRUCTURE values survive `Update-AzLocalPipelineExample` - including with `-Force`, which otherwise reverts edits made outside marker regions. Three new uniquely-named region families wrap: the Azure DevOps WIF service connection name on each `AzureCLI@2`/`AzurePowerShell@5` task (`service-connection-<job>`); the hosted agent pool / GitHub `runs-on:` label that selects where a job runs (`runner-target-<job>`); and the sideload self-hosted pool/runner that the on-prem Advance job must use (`sideload-runner-<job>`). 45 marker pairs added across 20 files; region names are derived from the nearest stage/job and are unique per file. The merge engine (`Update-AzLocalPipelineExample`) and marker parser were already generic, so no function code changed - this is purely a template + docs + test release. Per-run INPUT defaults (updateRing, config paths, throttle) are deliberately NOT wrapped: they are already overridable per run and via variable groups, and wrapping them would freeze the module author's ability to improve defaults each release. No public API or export-count change (still 61). `GENERATED_AGAINST_MODULE_VERSION` bumped to `'0.8.94'`.

## Version 0.8.93 - Fixes a Bad Request in the `Update: 1 - Assess Update Readiness` pipeline. `Sync-AzLocalClusterUpdateSummary` (and the `Export-AzLocalClusterUpdateReadinessReport` stale-assessment auto-scan that calls it) POSTed the `updateSummaries/default/checkUpdates` ARM action with NO request body; the `2026-03-01-preview` API spec now requires a body, so the bodyless POST was rejected with `HttpRequestPayloadAPISpecValidationFailed` / `MissingRequiredParameter`. The cmdlet now sends an empty JSON object `{}`, validated against a live cluster. Bug-fix only - no API, parameter or export-count change (still 61). `GENERATED_AGAINST_MODULE_VERSION` bumped to `'0.8.93'`.

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.0 15 6/25/2026
0.8.99 3 6/25/2026
0.8.98 (current version) 2 6/25/2026
0.8.97 34 6/24/2026
0.8.96 33 6/23/2026
0.8.95 8 6/23/2026
0.8.94 106 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 35 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