Skip to content

[WIP] [WIP] Address feedback from team discussion on fully converged design updates#264

Merged
liunick-msft merged 1 commit into
dev/nl/updateFullyConvergedDocfrom
copilot/sub-pr-249
Mar 16, 2026
Merged

[WIP] [WIP] Address feedback from team discussion on fully converged design updates#264
liunick-msft merged 1 commit into
dev/nl/updateFullyConvergedDocfrom
copilot/sub-pr-249

Conversation

Copilot AI commented Mar 16, 2026

Copy link
Copy Markdown
Contributor

Thanks for the feedback on #249. I've created this new PR, which merges into #249, to address your comment. I will work on the changes and keep this PR's description up to date as I make progress.

Original PR: #249
Triggering review: #249 (comment)

@copilot open a new pull request to apply changes based on this feedback


💬 Send tasks to Copilot coding agent from Slack and Teams to turn conversations into code. Copilot posts an update in your thread when it's finished.

@liunick-msft
liunick-msft marked this pull request as ready for review March 16, 2026 15:53
@liunick-msft
liunick-msft merged commit 10ae26b into dev/nl/updateFullyConvergedDoc Mar 16, 2026
1 of 2 checks passed
@liunick-msft
liunick-msft deleted the copilot/sub-pr-249 branch March 16, 2026 15:53
Copilot AI requested a review from liunick-msft March 16, 2026 15:53
Copilot stopped work on behalf of liunick-msft due to an error March 16, 2026 15:53
1008covingtonlane added a commit to 1008covingtonlane/AzureLocal-Supportability that referenced this pull request Jul 8, 2026
… (Operational)

Per the live L4 validation (skill PR Azure#264, 2026-07-08): Event 21024 in the
VMMS-Admin log is only the "failed at migration source" marker and does NOT
contain the SID error text; the definitive "No mapping between account names and
security IDs" signature is Event 1106 in the Hyper-V-VMMS-OPERATIONAL log, with
the HRESULT rendered as the bare code 80070534 (no 0x prefix). The old query only
searched VMMS-Admin and matched 0x80070534, so it surfaced the marker but never the
confirming signature.

- Query both VMMS-Admin and VMMS-Operational; add Id 1106; match the bare 80070534;
  select LogName so the two events are distinguishable.
- Reword the prose to attribute the marker to Event 21024 (Admin) and the definitive
  signature to Event 1106 (Operational).
- Add the VMMS-Operational log to the "collect for Microsoft Support" list.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
1008covingtonlane added a commit that referenced this pull request Jul 9, 2026
…nd security IDs (0x80070534) (#326)

* Add TSG: live migration fails with 'No mapping between account names and security IDs' (0x80070534)

24H2 clusters below Azure Local 12.2605 (2026.05B) fail to live-migrate VMs whose
creating account SID does not resolve in AD, which also fails CAU / solution
update node drains. Two causes: (1) VM created/imported under a local node
administrator; (2) created under an AD administrator account that no longer
exists. The 12.2605 fix removes the unnecessary validation of the creating
account before live migration. Documents detection (Event 21024 / 0x80070534),
the update resolution, and the interim quick-migration (DefaultMoveType=1)
workaround that also lets the update itself complete. Quick-vs-live comparison,
terms glossary, and cross-link to the distinct 22H2->23H2 dynamic-memory issue.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Address PR #326 review: fix Related link encoding, add index entry, hyphenate modifiers

- Fix the Related link to the 22H2->23H2 upgrade TSG: double-encode the literal
  %2D in the target filename as %252D so GitHub resolves it (the working repo
  convention per TSG/Upgrade/README.md), instead of the single-encoded %2D that
  404s.
- Add the TSG to TSG/Update/README.md so it is discoverable from the Update index.
- Hyphenate compound modifiers: sub-second, in-guest, time-sensitive,
  latency-sensitive.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Cite only the 12.2605 solution version; drop the internal 2026.05B release label

Azure Local customers running full Azure Local (not HCI) do not recognize the
"2026.05B" HCI-style release label and it only adds confusion. Reference the
Azure Local solution version 12.2605 alone throughout the customer-facing TSG.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Add Azure Migrate (VMware/Hyper-V) scenario and clarify 23H2 vs 24H2 versions

- Note that VMs migrated into Azure Local from VMware or Hyper-V (for example
  using Azure Migrate) can carry an owner SID that does not resolve in Active
  Directory when the migration registered the VM under a local node administrator,
  making them subject to this failure. Add it to Issue Validation and Cause.
- Clarify the affected versions: 24H2 solution versions are 12.25xx/12.26xx (fix
  in 12.2605+); 23H2 clusters (11.25xx) are not affected because the account
  validation was introduced with 24H2.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Fix Issue Validation query: the 0x80070534 signature is in Event 1106 (Operational)

Per the live L4 validation (skill PR #264, 2026-07-08): Event 21024 in the
VMMS-Admin log is only the "failed at migration source" marker and does NOT
contain the SID error text; the definitive "No mapping between account names and
security IDs" signature is Event 1106 in the Hyper-V-VMMS-OPERATIONAL log, with
the HRESULT rendered as the bare code 80070534 (no 0x prefix). The old query only
searched VMMS-Admin and matched 0x80070534, so it surfaced the marker but never the
confirming signature.

- Query both VMMS-Admin and VMMS-Operational; add Id 1106; match the bare 80070534;
  select LogName so the two events are distinguishable.
- Reword the prose to attribute the marker to Event 21024 (Admin) and the definitive
  signature to Event 1106 (Operational).
- Add the VMMS-Operational log to the "collect for Microsoft Support" list.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Address Alex Burns review: robust detection query + safe workaround scripts

- Detection query: scan the whole recent log server-side with
  Get-WinEvent -FilterHashtable @{LogName; StartTime} instead of -MaxEvents 200,
  so a busy VMMS-Operational log cannot push the confirming event out of the window.
  Keep both the validated event IDs (21024 Admin marker, 1106 Operational signature)
  and the message-text match; state that these IDs were validated during a live
  reproduction of the issue, and note the message text stays reliable if a build logs
  the failure under a different ID.
- Workaround scripts: re-declare $affectedVMs at the top of the Verify and Disable
  blocks (they usually run in a new session after the update, where the Apply-block
  variable is gone, so the revert was silently iterating zero times), add a guard that
  stops loudly on a missing list, wrap each per-VM body in try/catch with null-checked
  cmdlets, and print an explicit "NOT set / NOT reset" summary so a skipped VM is visible.
- DefaultMoveType note: 4294967295 (0xFFFFFFFF) means "use the cluster's default move
  type", which is live migration (precise wording).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants