AzLocal.UpdateManagement

0.9.0

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 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.9.0 - Managed repo README auto-drop. `Copy-AzLocalPipelineExample` and `Update-AzLocalPipelineExample` now also drop a lightweight, link-first `README.md` into the customer REPO ROOT (alongside the workflow folder, `config`, and the turnkey updater script), so a freshly set-up pipelines repo explains itself: what it is, how to refresh after a module release (`.\Update-Module-And-Pipelines.ps1`), and where the docs live (links to https://aka.ms/AzLocal.UpdateManagement and its CI/CD runbook). Operator content is never destroyed: the README is written only when the repo has NO usable README - missing, whitespace-only, or a GitHub "Add a README" default stub (an H1 matching the repo name plus at most a one-line description). A README already carrying the new hidden `<!-- AZLOCAL-README-VERSION: x.y.z -->` marker (invisible in rendered Markdown) is version-gate refreshed IN PLACE only when the bundled template is newer; any other non-empty README is treated as operator-owned and left untouched (remove the marker line to freeze a managed README as your own). The drop is default-on for `-Platform GitHub|AzureDevOps`, suppressed by the new `-SkipReadme` switch, and skipped for `-Platform All` (its content references the turnkey script + `config` that only exist in the single-platform layouts). The turnkey `Update-Module-And-Pipelines.ps1` template is bumped `1.1.0` -> `1.2.0` to also stage the managed README in its scoped `git add` - but ONLY when the README carries the marker, so an operator-owned README is never swept into the automated commit. Two new private helpers (`Get-AzLocalReadmeTemplateVersion`, `Test-AzLocalReadmeReplaceable`) back the drop, with full Pester coverage. Additive - no public function, parameter-removal or export-count change (still 64). `GENERATED_AGAINST_MODULE_VERSION` bumped to `'0.9.0'`.

## Version 0.8.99 - Follow-up to v0.8.98's turnkey updater: the dropped `Update-Module-And-Pipelines.ps1` now also stages ITSELF. When the module ships an improved updater template, `Update-AzLocalPipelineExample` (called inside the script) version-refreshes the dropped script IN PLACE - but in v0.8.98 the script's scoped `git add` staged only the workflow folder + `config`, so that self-refresh was left as an uncommitted working-tree change the operator had to spot and commit by hand. The template now resolves its own repo-relative path from `$PSCommandPath` (only when it actually lives inside the repo) and appends it to the staged paths, so the self-update is committed and pushed alongside the regenerated YAMLs. The bundled template's `# AZLOCAL-UPDATER-VERSION` marker is bumped `1.0.0` -> `1.1.0`, so a customer who already has the v1.0.0 script dropped gets this fix auto-applied on their next run (version-gated refresh). Bootstrap caveat: the single transition run that upgrades a v1.0.0 drop to v1.1.0 executes the OLD body, so that one refresh is not self-staged - the operator commits the refreshed script once, and every run thereafter self-stages. Template + tests only - no public function, parameter or export-count change (still 64). `GENERATED_AGAINST_MODULE_VERSION` bumped to `'0.8.99'`.

## 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'`.

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 (current version) 12 6/25/2026
0.8.99 3 6/25/2026
0.8.98 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