| Previous | Next |
| SL_E_IA_ID_MISMATCH | SL_E_TAMPER_RECOVERY_REQUIRES_ACTIVATION |
SL_E_IA_MACHINE_NOT_BOUND
What the licensing code means
Interpret SL_E_IA_MACHINE_NOT_BOUND inside Automatic Virtual Machine Activation, not as a generic activation failure. Windows has reached AVMA activation of a Windows Server guest through an eligible, activated Windows Server Datacenter Hyper-V host; in this case, the guest did not establish or retain the expected AVMA binding to its Hyper-V host.
This result is HRESULT 0xC004FD04. Pair it with the selected product/Activation ID and operation name so later logs do not attribute an add-on, edition, or volume-license result to the base Windows product.
Data that identifies the actual cause
Record VM generation/identity, host migration or restore events, host activation state, guest Activation ID, and AVMA events on both sides. Before changing the system, add the following context:
- Product identity: request rate and previous AVMA attempts.
- Activation context: hypervisor vendor and Hyper-V integration state.
- State at failure: host edition and activation status.
- Correlation evidence: guest edition/build and installed AVMA key family.
- Change history: host/guest licensing event timestamps.
Work from state to cause
- Begin with the operation that emitted this result and its target Activation ID.
- Inventory guest edition, AVMA key, Hyper-V platform, host edition and activation state, host/guest channel and request throttling; this establishes whether the request was aimed at the intended product and activation channel.
- Use events and tool output to demonstrate: record VM generation/identity, host migration or restore events, host activation state, guest Activation ID, and AVMA events on both sides.
- Rule out the adjacent case: this is a machine-binding failure, not merely key installation or platform detection.
The surrounding licensing model prevents two common misdiagnoses. The host must be an eligible activated Windows Server Datacenter system, and the guest AVMA key must match a supported Windows Server guest edition. AVMA depends on the virtualization platform and the licensing state of the Hyper-V host; it is not a network call to a conventional KMS host.
Actions that usually make this harder to diagnose
- Avoid using an AVMA key on an unsupported hypervisor or mismatched guest edition.
- Avoid troubleshooting AVMA as an Internet connectivity failure.
How this differs from adjacent licensing codes
| Result | Different condition |
|---|---|
SL_E_IA_ID_MISMATCH | Different condition: the AVMA identity presented by the host cannot activate the Windows Server edition installed in the guest. |
SL_E_IA_PARENT_PARTITION_NOT_ACTIVATED | Different condition: the Hyper-V parent/host is not activated, so it cannot provide AVMA proof of entitlement to the guest. |
SL_E_IA_INVALID_VIRTUALIZATION_PLATFORM | Different condition: the guest is not running on the supported Microsoft Hyper-V platform required by AVMA. |
Corrective direction
Use the targeted fix: stabilize the supported host/guest configuration and trigger a fresh AVMA activation after any identity or migration issue is resolved. Avoid simultaneous key changes, store resets, service restarts, and network changes because they make it impossible to identify which precondition mattered.
Representative failure: A cloned or restored guest carries stale activation-binding state after moving between hosts.
Verification after the change
Technical references
- Automatic Virtual Machine Activation — diagnostic and operational context.
- Slmgr.vbs activation options — supported tools and state fields used to verify the resulting state.
- SoftwareLicensingProduct WMI class — Microsoft guidance for the activation mechanism represented by this HRESULT.
Looking for a different code? Search another status or error code.