AzLocal.UpdateManagement

0.9.1

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

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

Install-PSResource -Name AzLocal.UpdateManagement -Version 0.9.1

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 Get-AzLocalExcludedSubscription Set-AzLocalExcludedSubscription

PSEditions

Desktop Core

Dependencies

This module has no dependencies.

Release Notes

## Version 0.9.1 - Five changes in this release. (1) READINESS ALLOW-LIST OVERRIDE: `Get-AzLocalClusterUpdateReadiness` / `Export-AzLocalClusterUpdateReadinessReport` gain an opt-in `-SchedulePath` (apply-updates schedule, schema v2) and direct `-AllowedUpdateVersions` parameter. When a constraint is supplied and a cluster is NOT pinned to the `Latest` sentinel, readiness is recomputed using ONLY the allow-listed updates: a cluster whose Ready updates all fall outside its allow-list is reported `UpdateState = UpToDate` / `ReadyForUpdate = $false` (no action under the schedule), while the raw Azure update-summary state is preserved in a new `AzureUpdateState` column alongside `AllowedUpdateVersions` and `AllowListSource` (`None`/`Latest`/`Explicit`/`TopLevel`/`RowOverride`). Per-ring overrides beat the top-level fleet default via the new private resolver `Resolve-AzLocalClusterAllowList` (a `***` rings cell is the all-rings wildcard; an untagged cluster falls back to the top-level default). The default code path (neither parameter supplied) is unchanged. The assess-update-readiness GitHub Actions + Azure DevOps examples opt in automatically when a `./config/apply-updates-schedule.yml` file is present. (2) TRANSIENT LOGIN RETRY: every read-only/idempotent task across the GitHub Actions and Azure DevOps pipeline examples now retries the transient `azure/login` / `az` OIDC token-exchange failure ("Error: JSON is invalid: Expecting value...") once - GitHub workflows pair a `continue-on-error` primary login (`id: azure_login`) with an `if: steps.azure_login.outcome == 'failure'` retry step (12 guards across 10 workflows); Azure DevOps tasks use the native `retryCountOnTaskFailure: 2` (14 across 10 pipelines). Mutating tasks (Apply Updates, Retry Failed Updates, Raise ITSM tickets) are deliberately excluded to avoid duplicate-apply / duplicate-ticket risk. (3) BUG FIX: dry-run (`-WhatIf`) pipeline runs now render their step summary + outputs. When a pipeline step ran in WhatIf / dry-run mode (e.g. "Config: 2 - Manage UpdateRing Tags" with dry-run = true), `$WhatIfPreference` cascaded from the workload cmdlet into the reporting helpers and silently suppressed their `Out-File` writes (`Out-File` itself supports ShouldProcess), so the run produced ZERO step summary and ZERO step outputs - operators had to dig through the raw runner log to see what WOULD change. The pipeline reporting/artifact writes (`Add-AzLocalPipelineStepSummary`, `Set-AzLocalPipelineOutput`, and `Set-AzLocalClusterUpdateRingTagFromCsv`'s artifact-directory + JSON sidecar) now pass `-WhatIf:$false`, so a dry run always emits its full preview - the "Dry Run | True" settings row, the per-cluster "would change" detail, and the "This was a dry run. No changes were applied." footer - straight to the run Summary, while the actual Azure tag PATCH remains correctly suppressed by ShouldProcess. Additive + bug-fix - the actual Azure tag PATCH remains correctly suppressed by ShouldProcess. (4) OPTIONAL SUBSCRIPTION-EXCLUSION LIST: a new opt-in CSV lets operators exclude entire subscriptions from EVERY AzLocal.UpdateManagement Azure Resource Graph query without editing the individual KQL. Point `AZLOCAL_EXCLUDED_SUBSCRIPTIONS_PATH` (pipeline/env variable) at a repo-relative CSV (columns `Subscription IDs,Subscription Name,Comment / Notes`; only the first read, each value GUID-validated, invalid rows skipped with a warning) and every query centrally appends `| where id !startswith '/subscriptions/<id>/'` via new private helpers injected once in `Invoke-AzResourceGraphQuery`. Two new public cmdlets `Get-AzLocalExcludedSubscription` / `Set-AzLocalExcludedSubscription` (`-Path`/`-SubscriptionId`/`-Clear`) inspect/override the list; a header-only CSV warns and excludes nothing; the default (unset, no explicit call) is a no-op. All 20 pipeline examples declare the variable and Copy/Update drop an inert header-only `config/Excluded-Subscription-Ids.csv` skeleton (never overwriting). (5) AZURE DEVOPS SHARED-SETTINGS VARIABLE GROUP: all 10 ADO example pipelines now source their shared non-secret settings (exclusion path, schedule path, monitor-delay, failed-retry toggle, full `SIDELOAD_*` family) from one `- group: AzureLocal-Pipeline-Settings` reference - the ADO equivalent of GitHub repo Variables, set once per project (7 map-form `variables:` blocks converted to list form; no member redefined inline). Azure auth stays on the WIF service connection; the group is a one-time `az pipelines variable-group create` prerequisite. Export count 64 -> 66; otherwise additive. `GENERATED_AGAINST_MODULE_VERSION` bumped to `'0.9.1'`.

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

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.10 64 6/26/2026
0.9.1 (current version) 11 6/26/2026
0.9.0 51 6/25/2026
0.8.99 5 6/25/2026
0.8.98 4 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