Helpdesk: "Since we added the two new hosts last week, moving VMs to them fails. Hyper-V Manager says the migration operation failed at migration source, and the cluster logged Event 21502. One VM moves fine, three don't, and one we moved last month won't go back to the old host either. A forum post says to turn on processor compatibility for every VM, switch every host to CredSSP, allow live migration on any network, and turn off the firewall on the new hosts. Can we do that?"
Not yet. "Hyper-V live migration failed" is almost never one setting. Event 21502 is the summary Hyper-V logs when a live migration fails (you'll see it most on clustered hosts), and the reason is in the message text under it: a virtual switch name that doesn't exist on the destination, processor features the destination can't offer, a configuration version it doesn't support, migration settings that don't match, an authentication path that can't delegate, a connection to TCP 6600 that never opens, or a destination that can't hold the VM (memory, storage path, ISO, owners). Microsoft says it directly: "live migration can fail due to a wide array of factors", and its troubleshooting page lists about twenty different messages under the single heading Event ID 21502. Turning on processor compatibility for every VM hides CPU features from workloads that didn't need it (and needs each VM shut down), switching to CredSSP trades a delegation problem for a sign-in problem (and stops working on Windows Server 2025 with Credential Guard), any-network migration sends unencrypted VM memory over networks you didn't choose, and turning off the host firewall proves nothing about why the listener on 6600 isn't answering. Work through it as a chain: which VM, which hosts, which inner message → what does the full error say on both hosts? → what does Compare-VM report? → do the virtual switches, adapters, and attached media exist on the destination? → can the destination offer the VM's processor features? → does the destination support the VM's configuration version? → are migration settings and networks the same on both sides? → can the source authenticate to the destination? → does TCP 6600 connect? → can the destination hold the VM? Get-WinEvent on the Hyper-V logs of both hosts, Compare-VM, Get-VMNetworkAdapter, Get-VMSwitch, Get-VMProcessor, Get-VM, Get-VMHostSupportedVersion, Get-VMHost, Get-VMMigrationNetwork, Get-ADComputer, Test-NetConnection, and the failover cluster cmdlets are the sources for that chain. Change processor compatibility, authentication, and networks at once and you'll never know which one was broken.
If the inner message is "The target principal name is incorrect", The Target Principal Name Is Incorrect covers the Kerberos side of that error. If the VM won't move because a checkpoint or its AVHDX chain is broken, Hyper-V Checkpoint Operation Failed covers that side. This post covers "a running Hyper-V VM won't live migrate between Windows Server hosts, clustered or not: Event 21502 in the cluster, 'failed at migration source' or 'failed at migration destination' in Hyper-V Manager, a processor or hardware compatibility error, a failed-to-authenticate or no-credentials error, a failed-to-establish-a-connection error, or a failure that happens one way only, and you need a read-first path before you change processor compatibility, authentication, migration networks, or firewall rules."
TL;DR
- Event 21502 is the envelope, not the letter. Read the inner message and its hex code on both hosts before you change anything (Step 2). Microsoft's first check is a compatibility report: run
Compare-VMagainst the destination (Step 3). - Switch names must match exactly. Microsoft: "The virtual switch must have the same name on all nodes." (Step 4).
- Processor compatibility is per VM, needs the VM off, and has limits. "Even when processor compatibility is enabled, you can't move VMs between hosts with different processor manufacturers." (Step 5).
- One way only usually means version. A VM upgraded on a newer host can't go back: "This action can't be rolled back." (Step 6).
- Authentication is a choice with consequences. "Kerberos lets you avoid signing in to the server, but requires you to set up constrained delegation." CredSSP needs a sign-in on the source and breaks with Credential Guard on Windows Server 2025 (Step 8).
- Read the listener before the firewall. Microsoft's checklist: "Check whether the TCP Port 6600 and 3343 (for clustering) are listening on both sides." (Step 9).
Where in the chain did it break?
| Step | What should be true | Typical symptom when it breaks |
|---|---|---|
| 1. Symptom captured | Which VM, which source and destination, clustered or not, started from where, the full message, since when | "Live migration is broken" with no VM, host pair, or time written down |
| 2. Full error read | The inner message and hex code are known, on both the source and the destination | Event 21502 quoted alone; the actual reason never read |
| 3. Compatibility report | Compare-VM from the source against the destination returns no incompatibilities | The report names a missing switch, a processor, or a version the destination can't take |
| 4. Switches and media | Every switch the VM uses exists with the same name on the destination; attached ISOs are reachable there | Fails at less than 10%; a switch that "doesn't exist on the destination node"; an ISO or virtual disk provider error |
| 5. Processor | The destination offers the processor features the running VM was started with | "processor-specific features not supported"; "hardware on the destination computer isn't compatible" |
| 6. Configuration version | The destination supports the VM's configuration version | Moves one way, fails the other; Event 10698 with 21502 |
| 7. Settings and networks | Migration enabled, same authentication protocol, a reachable migration network on both sides, limits not hit | Event 21501 (limit reached); traffic on the wrong network; 0x000013AB in a cluster |
| 8. Authentication | CredSSP with a sign-in on the source, or Kerberos with constrained delegation both ways | 0x8009030E "No credentials are available"; 0x8009030D; 0x80090322 |
| 9. Connection | The destination's listener on TCP 6600 answers the source (and 3343 between cluster nodes) | 0x8007274D refused; 0x8007274C timed out; 0x8007271D access forbidden; listener disabled |
| 10. Destination capacity | Enough memory, a writable storage path, the right possible owners, no leftover state | 0x800705AA or 0x8007000E memory; Event 20413 path; 0x80071398 owner; folder errors |
| 11. Change | Only after Steps 1-10 agree: one link, one change | Every VM in compatibility mode, every host on CredSSP, same failure |
Step 1: Capture the symptom (read-only)
Write these on the ticket first:
| Fact | Why it matters |
|---|---|
| Which VM, and how many | One VM, every VM to one host, or every VM everywhere. One VM points at its own settings (Steps 4-6); one destination points at that host (Steps 4, 7, 9, 10) |
| Source and destination host | Exact names, Windows Server version and build of each, CPU vendor and generation of each. Different versions point at Step 6; different CPUs at Step 5 |
| Clustered or not | A clustered VM moved in Failover Cluster Manager, a standalone move in Hyper-V Manager, a Move-VM, or System Center Virtual Machine Manager. The settings that apply differ (Step 7) |
| Started from where | Signed in on the source host, on the destination, or from a management server or jump box. With CredSSP it matters a lot (Step 8) |
| Full message and percentage | The inner lines, the hex code, and roughly how far it got. Microsoft ties "fails at < 10%" to a missing switch and "90%~100%" to a path problem (Steps 4 and 10) |
| Since when, and what changed | New hosts, a Windows Server upgrade, BIOS or firmware updates, a VM configuration upgrade, a new switch, a GPO or security baseline, an AD delegation change |
| Time of one failing attempt | So you can match it to events on both hosts and in the cluster log (Step 2) |
Then branch on what you see:
| What you see | What it usually means (our reading unless noted) | Start at |
|---|---|---|
| a virtual switch that "doesn't exist on the destination node", or failure under 10% | The switch name differs on the destination (Microsoft's 21502 entry) | Step 4 |
| "processor-specific features not supported" or "hardware on the destination computer isn't compatible" | CPU features, BIOS settings, or microcode differ between hosts | Step 5 |
| Works one way, fails coming back | The VM's configuration version was upgraded on the newer host | Step 6 |
| "please wait for completion of an ongoing migration operation" (Event 21501) | Too many simultaneous migrations for the current limit | Step 7 |
| 0x8009030E "No credentials are available in the security package" | CredSSP without a sign-in on the source, or Kerberos delegation missing or blocked | Step 8 |
| 0x80090322 "The target principal name is incorrect" | Kerberos reached the wrong host or name; Microsoft's example is a cross-cluster move on the wrong network | Steps 7 and 8 |
| 0x8007274D, 0x8007274C, 0x80072746, or 0x8007271D | The connection to TCP 6600: refused, timed out, reset, or blocked | Step 9 |
| "disabled the listener for Virtual Machine migration connections" | Group Policy processing on the destination failed | Step 9 |
| 0x800705AA, 0x8007000E, 0x80071398, Event 20413, or a folder error | The destination can't hold the VM, can't own it, or can't reach its path | Step 10 |
Step 2: Read the full error on both hosts (read-only)
Event 21502 is a summary. The reason is in the lines under it, and often in a second event on the other host. Microsoft's own list for Event ID 21502 runs from a missing virtual switch to processor features, Kerberos errors, memory, ISO files, and storage oplocks, and in Failover Cluster Manager it points you to the VM's Information details > Show details for the full text.
Find the Hyper-V and clustering logs that have events on each host, then pull the migration events around the failed attempt from both the source and the destination:
# On the source and on the destination: which Hyper-V and cluster logs have events here Get-WinEvent -ListLog '*Hyper-V*', '*FailoverClustering*' -ErrorAction SilentlyContinue | Where-Object { $_.RecordCount -gt 0 } | Sort-Object LogName | Format-Table LogName, RecordCount -AutoSize # The migration events from the last hour, oldest first, with the full message text $logs = (Get-WinEvent -ListLog '*Hyper-V*' -ErrorAction SilentlyContinue | Where-Object { $_.RecordCount -gt 0 }).LogName Get-WinEvent -FilterHashtable @{ LogName = $logs Id = 21502, 21501, 21125, 21024, 20413, 20417, 10698 StartTime = (Get-Date).AddHours(-1) } -ErrorAction SilentlyContinue | Sort-Object TimeCreated | Format-List TimeCreated, MachineName, LogName, Id, Message The event IDs in that filter are the ones Microsoft's live migration troubleshooting pages describe: 21502 (the failure itself), 21501 (migration limit), 21125 (configuration setup failed on the destination), 21024 (lost network after migration), 20413 (configuration registration failed on the destination), 20417 (long blackout time), and 10698 (listed with 21502 for configuration version problems). Widen the time window or drop the Id filter if nothing comes back; the inner error is often logged under a different ID on the other host. Microsoft's data collection list also names the worker log ("Microsoft-Windows-Hyper-V-Worker-Admin") and, for clusters, Get-ClusterLog -UseLocalTime -Destination <Path>:
# Clustered hosts only: write the cluster log for every node, in local time, to one folder Get-ClusterLog -UseLocalTime -Destination C:\Temp\ClusterLogs Read the hex code first. Microsoft's 21502 entries map them like this:
| Code or text in the message | Microsoft's meaning | Start at |
|---|---|---|
| "a virtual switch used by the VM doesn't exist on the destination node" | Switch name missing or different on the destination | Step 4 |
| 0xC03A0014 "A virtual disk support provider for the specified file was not found." | An attached ISO the destination can't open | Step 4 |
| "processor-specific features not supported on host" | CPU features differ | Step 5 |
| "The hardware on the destination computer isn't compatible with the hardware requirements of this virtual machine" | Processor compatibility off, or microcode differs | Step 5 |
| "please wait for completion of an ongoing migration operation" (Event 21501) | Simultaneous migration limit | Step 7 |
| 0x000013AB "A cluster Network isn't available for this operation." | No usable cluster network for the move | Step 7 |
| 0x8009030E "No credentials are available in the security package" | No credentials to delegate | Step 8 |
| 0x8009030D "The credentials supplied to the package were not recognized" | Source can't authenticate to the destination | Step 8 |
| 0x80090322 "The target principal name is incorrect." | Wrong host or network for Kerberos; cross-cluster network order | Steps 7 and 8 |
| 0x8007274D, 0x80072746, 0x8007274C | Connection refused, reset, or timed out | Step 9 |
| 0x8007271D "An attempt was made to access a socket in a way forbidden by its access permissions." | Firewall or antivirus | Step 9 |
| "The Virtual Machine Management Service disabled the listener for Virtual Machine migration connections." | Group Policy failure on the host | Step 9 |
| 0x800705AA, 0x8007000E | Not enough memory on the destination | Step 10 |
| 0x80071398 "the specified cluster node isn't the owner of the group, or the node isn't a possible owner of the group" | Possible owners don't include the destination | Step 10 |
| 0x80070569 "Logon failure: the user has not been granted the requested logon type at this computer." | User rights for the virtual machine accounts | Step 10 |
Step 3: What does Compare-VM report? (read-only)
Microsoft's basic checklist says to "Check compatibilities issues by running a Compare-VM command." The cmdlet doesn't move anything: "The Compare-VM cmdlet compares a virtual machine and a virtual machine host for compatibility, returning a compatibility report." Run it on the source host, against the destination, for the VM that failed:
# On the source host: compare the running VM with the destination host $report = Compare-VM -Name APP01 -DestinationHost HV02 # Each incompatibility has a message, an ID, and the object it came from $report.Incompatibilities | Format-Table Message, MessageId, Source -AutoSize -Wrap # If the move includes storage, compare that move instead $report = Compare-VM -Name APP01 -DestinationHost HV02 -IncludeStorage -DestinationStoragePath D:\VMs\APP01 $report.Incompatibilities | Format-Table Message, MessageId, Source -AutoSize -Wrap Message, MessageId, and Source are the columns Microsoft's own Compare-VM example shows, where the report says "Could not find Ethernet switch 'Production'." for a VM whose adapter used a switch the host didn't have. An empty Incompatibilities list means the destination can take the VM's configuration, so look at Steps 7-10 (settings, authentication, connection, capacity). A non-empty list usually tells you which of Steps 4-6 to read next (our reading). If Compare-VM itself fails with a credentials or connection error, that's the same problem the migration has: go to Steps 8 and 9.
Step 4: Do the switches, adapters, and attached media exist on the destination? (read-only)
The first entry under Event ID 21502 on Microsoft's live migration page is a switch: "Live migration of VM failed. VM failed to live migrate because a virtual switch used by the VM doesn't exist on the destination node". The action is short: "The virtual switch must have the same name on all nodes." Microsoft also notes "If a virtual machine is connected to a virtual switch that doesn't exist on the destination node, then live migration fails at < 10%."
# On the source: which switch each of the VM's adapters uses Get-VMNetworkAdapter -VMName APP01 | Format-Table VMName, Name, SwitchName -AutoSize # On both hosts: the switches that exist, by exact name and type Get-VMSwitch | Sort-Object Name | Format-Table Name, SwitchType -AutoSize Get-VMSwitch -ComputerName HV02 | Sort-Object Name | Format-Table Name, SwitchType -AutoSize # On the source: anything attached to the VM's DVD drives Get-VMDvdDrive -VMName APP01 | Format-Table VMName, ControllerType, ControllerNumber, Path -AutoSize What to look for:
| Finding | What it means (our reading unless noted) |
|---|---|
A SwitchName on the source that isn't in the destination's list | The cause Microsoft lists first; names must match exactly |
Same name, different SwitchType | The name matches but it's Internal or Private on one side and External on the other; the VM loses its network or the cluster check fails |
| Adapter on an Internal or Private switch, VM clustered | Microsoft: "You can't live migrate a VM across nodes in a cluster if that VM is connected to an internal or private virtual switch." The message says "the destination has disconnected VM switch(s)" |
A Path to an ISO on a local disk or a share the destination can't read | Microsoft's 0xC03A0014 entry: an ISO the destination can't open fails the move; the fix is to set the DVD drive to None |
| Event 21125 "Configuration setup for live migration failed on the destination node." | The same switch problem seen from the destination; Microsoft's action is to make the virtual network names match and refresh the VM configuration in Failover Cluster Manager |
| Event 21024 after a successful move | The move worked but the VM lost its network: different subnets or VLANs on the destination switch, not a migration failure |
In a cluster, after you rename or create a switch, Microsoft's steps end with Failover Cluster Manager > the VM role > More Actions > Refresh virtual machine configuration before you retry. That refresh is a change (Step 11), not a check.
Microsoft's broader checklist adds team consistency: "Validate network teaming (SET or LBFO) consistency." A switch with the right name bound to a team with a different configuration is worth a second look (our reading).
Step 5: Can the destination offer the VM's processor features? (read-only)
A running VM sees the features of the host it started on. Microsoft explains why that blocks a move: "If software in the VM detects and starts using a particular processor capability, and then the VM is moved to a new virtualization host without that capability, the software can fail." So "Hyper-V performs initial checks whenever a VM live migration or save/restore operation is initiated", and "If these feature sets don't match, the migration or restore operation is canceled."
# On the source: is processor compatibility turned on for this VM, and in which mode Get-VMProcessor -VMName APP01 | Format-List VMName, Count, CompatibilityFor* # Same check for every VM on the host Get-VM | Get-VMProcessor | Format-Table VMName, Count, CompatibilityForMigrationEnabled -AutoSize # Does the VM have checkpoints (Microsoft ties this to the hardware-not-compatible error) Get-VMSnapshot -VMName APP01 | Format-Table VMName, Name, SnapshotType -AutoSize Read the result against the messages:
| Finding | What it means |
|---|---|
CompatibilityForMigrationEnabled False, hosts with different CPU generations | Expected failure. Microsoft: "If a virtual machine doesn't have processor compatibility turned on and has one or more snapshots, the move fails if the hosts have different processor versions." |
| Compatibility True, still "processor-specific features not supported" | Microsoft's checks: "Make sure the BIOS of the host has the same settings." and "Run the Get-SpeculationControlSettings cmdlet and check the results. It should be the same on all nodes." |
| Intel source, AMD destination (or the reverse) | No setting fixes it: "Even when processor compatibility is enabled, you can't move VMs between hosts with different processor manufacturers." Shut down and move, or rebuild on the other platform |
| New hosts got a microcode or firmware update the old ones didn't | Microsoft's guidance for side channel mitigations: "the best option is to live migrate VMs only from old to new microcode (uCode) revisions" |
Windows Server 2025 cluster, CompatibilityForMigrationMode shown | Dynamic processor compatibility (CommonClusterFeatureSet) needs configuration version 10.0 or later; MinimumFeatureSet is the standard mode Microsoft says to use toward older processors outside the cluster |
Two rules from Microsoft keep this from turning into a fleet-wide change. First, "You don't need to enable processor compatibility mode if you plan to stop and restart the VMs", because the guest reads the new host's features at boot. Second, "Processor compatibility mode can't be enabled or disabled while the VM is running." So for a running VM that has to move now, the choice is a short shutdown either way; the guide's tip is "Always start VMs for the first time on the oldest (least capable) CPU host." The CompatibilityFor* wildcard is our form; it shows CompatibilityForMigrationMode only where the host's Hyper-V module has it.
Step 6: Does the destination support the VM's configuration version? (read-only)
Microsoft's troubleshooting guide describes the pattern exactly: "Migration works one way but not in reverse (especially after moving to a newer OS)." with Event IDs 10698 and 21502. The VM's configuration version decides which hosts can run it:
# On the source: configuration version of every VM (Microsoft's form) Get-VM * | Format-Table Name, Version # On the destination: which configuration versions it can run, and its default Get-VMHostSupportedVersion -ComputerName HV02 Get-VMHostSupportedVersion -ComputerName HV02 -Default # On the source: integration services that report a version mismatch Get-VMIntegrationService -VMName APP01 | Format-Table VMName, Name, SecondaryOperationalStatus -AutoSize | Finding | What it means |
|---|---|
The VM's Version isn't in the destination's Get-VMHostSupportedVersion list | The destination is an older Windows Server than the version needs. You can't fix this from the VM side; move it to a host that supports it |
| Same version on both lists, moves one way only | Look at Steps 5 and 7-9 instead; the version isn't the blocker (our reading) |
SecondaryOperationalStatus ProtocolMismatch | Out-of-date integration services; Microsoft's checklist says to "Confirm VM integration services are up-to-date." |
Don't upgrade a VM's configuration version to make a mixed-version move work. Microsoft's guidance is not to upgrade until "You upgrade your Hyper-V hosts to the latest version of Windows or Windows Server.", "You upgrade the cluster functional level.", and "You're sure that you won't need to move the virtual machine back to a Hyper-V host that runs a previous version of Windows or Windows Server." The troubleshooting guide adds: "This action can't be rolled back. VMs with the upgraded version can't be migrated back to older hosts." During a rolling upgrade, keep VMs at the version the oldest host supports until the last old host is gone (our reading).
Step 7: Are migration settings and networks the same on both sides? (read-only)
Microsoft's basic checklist has two lines for this: "Check whether the migration is authorized on each side." and "Check whether the protocol used is identical on each side." Read the host settings on both hosts, then the networks each one accepts migrations on:
# On both hosts: every live migration setting (the wildcard is our form) Get-VMHost | Format-List Name, *Migration* Get-VMHost -ComputerName HV02 | Format-List Name, *Migration* # Networks each host accepts incoming live migration on Get-VMMigrationNetwork Get-VMMigrationNetwork -ComputerName HV02 # Clustered hosts: cluster networks and their role, the cluster-wide limit, # and which networks the Virtual Machine resource type excludes from migration Get-ClusterNetwork | Format-Table Name, Role, Address -AutoSize (Get-Cluster).MaximumParallelMigrations Get-ClusterResourceType -Name "Virtual Machine" | Get-ClusterParameter -Name MigrationExcludeNetworks What the settings mean, from Microsoft's Set-VMHost reference:
| Setting | What to compare |
|---|---|
VirtualMachineMigrationAuthenticationType | "The acceptable values for this parameter are: Kerberos and CredSSP." Both hosts should use the same one (Step 8) |
UseAnyNetworkForMigration | "If set to $False, incoming live migration traffic is transmitted only on the networks specified in the MigrationNetworks property of the host." The destination must list a network the source can reach |
MaximumVirtualMachineMigrations | The per-host limit. In a cluster, the cluster property wins: Microsoft says to check it with (Get-Cluster).MaximumParallelMigrations |
VirtualMachineMigrationPerformanceOption | TCP/IP, Compression, or SMB. "Compression is the default setting." SMB moves memory over SMB 3.0 instead of a plain TCP stream |
Read the result:
| Finding | What it means (our reading unless noted) |
|---|---|
| Migration not enabled on the destination | Microsoft's setup step is Hyper-V Settings > Live Migrations > Enable incoming and outgoing live migrations, on each host |
| Kerberos on one host, CredSSP on the other | The source can't authenticate the way the destination expects; pick one (Step 8) |
UseAnyNetworkForMigration False and no shared subnet in Get-VMMigrationNetwork | The destination only accepts migrations on a network the source isn't on; the connection fails (Step 9) |
| Event 21501, "please wait for completion of an ongoing migration operation" | The limit was hit. Microsoft: "Wait to finish other live migrations or increase the number of simultaneous live migrations." |
| Cluster, 0x000013AB | Microsoft: "Make sure the cluster network is configured and Allow cluster network communication on this network is selected." A Role of 0 means "Do not allow cluster network communication" |
MigrationExcludeNetworks lists the only network both nodes share | The cluster has nothing left to migrate over |
| Cross-cluster move, 0x80090322 | Microsoft: "Migration was cross-cluster but as per Live Migration Network order, the private Network was selected." |
| Event 20417, "unexpectedly long blackout time" | The move worked but slowly. Microsoft: "Make sure there's enough bandwidth available for the live migration." |
Microsoft's cluster network guidance sets the rule for every host involved: "All Hyper-V hosts that can initiate or receive a live migration must have connectivity to a network that is configured to allow live migrations." It also explains why "allow any network" is not a free fix: "live migration traffic isn't encrypted when sent over the network", so isolate it "onto trusted, private networks". In a cluster, "By default, live migration traffic uses the cluster network topology to discover available networks and to establish priority." The order and exclusions you set in Failover Cluster Manager (right-click Networks > Live Migration Settings) are what MigrationExcludeNetworks shows.
Step 8: Can the source authenticate to the destination? (read-only)
The source host opens the migration connection to the destination, so it needs credentials it can present there. Microsoft's setup page gives the two options and their cost: "Kerberos lets you avoid signing in to the server, but requires you to set up constrained delegation." and "CredSSP lets you avoid setting up constrained delegation, but requires you to sign in to the source server." When neither works you get this, from the same page:
Virtual machine migration operation failed at migration Source. Failed to establish a connection with host computer name: No credentials are available in the security package 0x8009030E. Read which protocol each host uses, what each host may delegate to in AD, and what the account starting the move allows:
# Which protocol each host uses for live migration Get-VMHost -ComputerName HV01, HV02 | Format-Table Name, VirtualMachineMigrationAuthenticationType -AutoSize # Kerberos: what each host may delegate to (Microsoft's blog form; run for both hosts) Get-ADComputer -Identity HV01 -Properties msDS-AllowedToDelegateTo | Select-Object -ExpandProperty msDS-AllowedToDelegateTo Get-ADComputer -Identity HV02 -Properties msDS-AllowedToDelegateTo | Select-Object -ExpandProperty msDS-AllowedToDelegateTo # Protocol transition ("Use any authentication protocol") on each host's account Get-ADComputer -Identity HV01 -Properties TrustedToAuthForDelegation | Format-Table Name, TrustedToAuthForDelegation -AutoSize # The admin account that starts the move: marked sensitive, or in Protected Users? Get-ADUser -Identity jsmith-adm -Properties AccountNotDelegated | Format-Table Name, AccountNotDelegated -AutoSize Get-ADGroupMember -Identity "Protected Users" | Format-Table NameSource：https://dev.to/adminpackstudio/hyper-v-live-migration-failed-event-21502-a-read-first-switch-processor-version-and-kerberos-181fRelated posts
The latest AI news we announced in October 2026
Google Cloud Spend Caps Reach General Availability With an API and Live Costs
I built a Tinder-style Website for finding coding project ideas
GSAP ScrollTrigger image sequence in WordPress without code: when DIY isn't worth it
Surviving AWS Spot Interruptions With Real Checkpointing
