v1.0.3 — Azure Local LENS Workbook

Install

Download AzureLocal-LENS-Workbook.json from the assets below and import it into the Azure portal (Monitor → Workbooks → New → Advanced Editor → paste the JSON).

---

A small post-v1.0.2 patch driven by a customer-reported gap in the 🔄 Update Progress tab's 📜 Update Run History and Error Details table, where a real failed update on an HealthCheckSucceeded progressStatus was silently filtered out by the table's Status dropdown and (after that fix) duplicated by a stale dedup key. Both fixes live exclusively in workbooks/UpdateProgress/UpdateProgress.workbook.

1. Update Progress — Status filter dropdown extended from 4 to 7 entries. Reported case: a customer's Azure Local cluster failed an update with progressStatus == 'HealthCheckSucceeded' (a platform state where the pre-update health-check phase succeeded but the actual update run was not started — typically because the cluster's update was blocked by an administrator operation such as a separate ongoing update or a recently-terminated preparation). The Update Run History and Error Details table on the 🔄 Update Progress tab uses an UpdateHistoryStatusFilter multiselect pill to let users narrow the table by progressStatus value, but in v1.0.2 the dropdown only listed four values: Success, Error, Extracted, and the default * (All) sentinel. When the user selected * (All) the workbook's value::all substitution silently expanded to the four enumerated jsonData values — rather than acting as an unscoped wildcard — so rows whose progressStatus was anything outside that set (HealthCheckSucceeded, NotStarted, Downloaded, InProgress) were dropped from the table on every filter combination. Root cause: Workbooks value::all on a multiselect pill is not a true wildcard — it expands to the comma-separated list of enumerated jsonData values (the same set the user sees in the dropdown), so any platform value not present in jsonData is filtered out even when "All" is selected. Fix: the UpdateHistoryStatusFilter jsonData block is extended from 4 to 7 entries — adds HealthCheckSucceeded (rendered as "Health Check Succeeded (run blocked / not started)"), NotStarted ("Not Started"), Downloaded ("Downloaded"), and InProgress ("In Progress"). The default value remains * (All). Distribution check on a live 60-node test workspace at the time of the fix: Error = 136, Success = 133, Extracted = 7, NotStarted = 4, HealthCheckSucceeded = 2, Downloaded = 1, InProgress = 0 — confirming this is not a theoretical bug; multiple clusters were silently missing from every customer's table.

2. Update Progress — Failed-run dedup collapsed to one row per cluster (latest unresolved failure). Follow-on to Fix 1: with the dropdown extended to surface HealthCheckSucceeded rows, a customer's cluster now showed two Failed rows — the most recent attempt on the latest Solution release and an older attempt on the previous (now superseded) Solution release — because the table previously deduped Failed runs by iff(state == 'Failed', strcat(hciClusterName, '|', updateName), id) and ordered by arg_max(lastUpdatedTime, *). That meant each (cluster, update package) pair was treated as a separate row, so a cluster that had failed on two consecutive monthly update packages would surface both — even though the older package has already been superseded by the newer one and is no longer actionable. Fix: the dedup key for Failed rows is simplified from (hciClusterName + '|' + updateName) to just hciClusterName, and the arg_max ordering is changed from lastUpdatedTime (a background platform timestamp that updates regardless of which update package the cluster is currently attempting) to timeStarted (the wall-clock time the active attempt began). Net effect: each cluster contributes at most one Failed row to the table — the latest attempted, unresolved failure — and superseded older packages are collapsed. Succeeded / InProgress / Extracted / HealthCheckSucceeded / NotStarted / Downloaded / Error runs continue to dedup by id (their normal one-row-per-run semantics are unchanged). Live-verified end-to-end via direct Azure Resource Graph REST calls against microsoft.azurestackhci/clusters/updates/updateruns: the affected cluster collapses from two rows to one (latest attempt, full error message intact and surfaced through the pack() property-grid flyout introduced in v1.0.1 Fix 10). The section's tip banner is updated to read: "For Failed runs, only the most-recently-attempted update package per cluster is shown (older / superseded failed packages are collapsed). Unresolved Failed runs are always surfaced regardless of the Time Range filter; once a later Succeeded run exists for the same cluster, the older Failed run is hidden."

No other workbook content changes. The workbook header banner bumps from v1.0.2 to v1.0.3.