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

[1008covingtonlane]

Documents the Azure Local 24H2 live-migration failure "No mapping between account names and security IDs was done" (0x80070534).

Summary:

• On clusters below Azure Local 12.2605 (2026.05B), live migration of certain VMs fails, which also fails CAU / solution-update node drains.
• Cause: the VM's creating-account SID does not resolve in Active Directory. Two ways it happens: (1) the VM was created or imported under a local node administrator account; (2) it was created under an AD administrator account that has since been deleted.
• The 12.2605 fix removes the unnecessary validation of the creating account before live migration.

The article covers detection (Event 21024 / 0x80070534, the two at-risk conditions), the update resolution, and an interim quick-migration workaround (DefaultMoveType=1) that also lets the update itself complete, with a quick-vs-live comparison and a terms glossary.

Draft for review.

[AlBurns-MSFT]

Nice writeup, and the core of it holds up. I ran the read-only parts on lab hardware and checked the rest against the product behavior and Microsoft Learn. The cause (the pre-live-migration validation of the VM's creating account, which fails when that account's SID does not resolve in AD), the fix landing in 12.2605, the upgrade regression, and the version mapping (23H2 is 10.x/11.x, 24H2 is 12.x, with 11.2510 the last 23H2) all check out. On a cluster node I confirmed the cmdlets and parameters exist (including Get-ClusterResource -VMId), the three event channels exist, the detection query runs clean, and DefaultMoveType really does default to 4294967295. So the approach is sound. A few things to fix before it merges.

1. The revert block will silently do nothing for most operators. $affectedVMs is only defined in the "Apply the workaround" block. The "Disable the workaround after updating" block runs after the whole update finishes (every node has rebooted, so almost certainly a new PowerShell session, possibly on a different node), where $affectedVMs is undefined. With StrictMode off (the interactive default) foreach ($vm in $affectedVMs) just iterates zero times: no output, no error, and the VMs stay pinned to quick migration. The later "confirm by live migrating a VM" step still passes on 12.2605, so it is easy to walk away believing you reverted when you did not. Re-declare the list at the top of both the verify and revert blocks, and add a guard so a missing list stops loudly instead of silently:

   if (-not $affectedVMs) { Write-Warning "Set `$affectedVMs to your affected VM names first."; return }

   [LOW RISK] doc-only change, but worth fixing since it defeats the revert.

2. The hard-coded event IDs are not verified and at least one looks wrong. Microsoft's public "Troubleshoot live migration issues" article attributes Event 21024 to a different scenario (a VM that loses network connectivity after a successful migration) and puts the "failed at migration source" marker on Event 21502 (21501 as a variant). I could not confirm Event 1106 in the VMMS-Operational log for this signature either. The HRESULT text is right (0x80070534 is ERROR_NONE_MAPPED, "No mapping between account names and security IDs"), and since the query already matches on the message text and 80070534, that message match is the reliable signal. Suggest verifying the exact IDs on an affected 24H2 node and either correcting them or dropping the hard IDs and keeping the message match. [LOW RISK].

3. The detection query can miss the confirming event on a busy node. Get-WinEvent -LogName $log -MaxEvents 200 | Where-Object {...} pulls the newest 200 events and then filters, so on a busy VMMS-Operational log (which is where the signature event lives), or when the failure is not recent, the confirming event can sit outside that window and the query returns nothing, reading as a false "not this issue." Filtering server-side scans the whole log instead:

   Get-WinEvent -FilterHashtable @{ LogName = $log; Id = 21502, 1106 }

   (swap in whatever IDs you confirm in point 2, and add StartTime if you want to bound it). [LOW RISK].

4. Small precision fix on the DefaultMoveType note. 4294967295 is 0xFFFFFFFF, which means "use the cluster's default move type" (and that default is live migration), rather than literally the live-migration value. The reset command is correct and I confirmed 4294967295 is the real default on hardware, so this is only wording: something like "resetting to 4294967295 restores the cluster's default move type, which is live migration" reads more precisely. [LOW RISK].

5. The set and revert loops skip a bad VM silently. There is no error handling around the state-changing Set-ClusterParameter, and Get-ClusterGroup $vm assumes the cluster group name matches the VM name. A mistyped, renamed, or offline VM cascades to $null | Set-ClusterParameter, which is a non-terminating error, so the loop keeps going and prints an empty value line that is easy to miss, leaving that VM unset and still failing the drain. Wrapping the per-VM body in try/catch, null-checking the VM and resource, and printing an explicit "not set" summary at the end would make a skip visible. [LOW RISK].

None of these are blockers to the approach, quick migration is the right workaround. One caveat on validation: I could not reproduce the actual 0x80070534 failure, since it needs a 24H2 build below 12.2605 plus a VM whose owner SID does not resolve, and the lab hardware available was 23H2. So the behavioral claims (the failure itself, and that quick migration then succeeds) are backed by the source and the code path rather than a live repro.

[1008covingtonlane]

@AlBurns-MSFT thanks, this was a great review. All five are addressed in bb6062b:

1. Revert block silently doing nothing. Fixed. I re-declared $affectedVMs at the top of both the Verify and the Disable blocks (which usually run in a new session after the update, where the Apply-block variable is gone), and added a guard so a missing list stops loudly instead of iterating zero times.

2. Event IDs. I kept 21024 (Admin, the "failed at migration source" marker) and 1106 (Operational, the "No mapping" / bare 80070534 signature), because both were validated during a live reproduction of this exact failure on a pre-12.2605 24H2 cluster, and I now say that explicitly in the TSG. On the discrepancy with the public "Troubleshoot live migration" article: I believe 21024 is a generic "failed at migration source" event that is reused across scenarios (the network-loss case that article describes, and this SID case), disambiguated by the message text, so both your doc read and the repro are correct. That is exactly why I also kept the message-text match as the reliable signal; if a different build logs it under 21502 or another ID, the message match still catches it.

3. Busy-log miss. Fixed. The query now scans server-side by time with Get-WinEvent -FilterHashtable @{ LogName = $log; StartTime = $since } instead of pulling the newest 200 and filtering, so the confirming event cannot sit outside the window on a busy Operational log.

4. DefaultMoveType wording. Fixed: "4294967295 (0xFFFFFFFF) means 'use the cluster's default move type', which is live migration."

5. Silent per-VM skips. Fixed. Each per-VM body in the set and revert loops is now wrapped in try/catch with null-checked cmdlets, and prints an explicit "NOT set" / "NOT reset" summary at the end, so a mistyped, renamed, or offline VM is visible instead of leaving an empty line.

On validation: the failure itself and the quick-migration workaround were reproduced live on a pre-12.2605 24H2 cluster (with the fix's KIR toggled off then on for the A/B), which is where the 21024/1106 IDs and the bare 80070534 render came from. Thanks again for the careful pass.

[Copilot]

Pull request overview

Adds a new Azure Local Troubleshooting Guide (TSG) documenting a 24H2 live-migration failure (0x80070534) that can also block CAU/solution-update node drains, and links it from the Update TSG index.

Changes:

• Added a new TSG describing symptoms, validation steps, root cause, and resolution via updating to 12.2605+.
• Documented an interim quick-migration workaround using DefaultMoveType=1 to allow drains/updates to complete before applying the permanent fix.
• Updated TSG/Update/README.md to include the new guide.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
TSG/Update/README.md	Adds the new TSG link to the Update documentation index.
TSG/Update/Live-migration-fails-with-No-mapping-between-account-names-and-security-IDs.md	New troubleshooting article covering detection, cause, update-based fix, and workaround.