| Previous | Next |
| SL_E_TKA_INVALID_CERT_CHAIN | SL_E_TKA_CERT_NOT_FOUND |
SL_E_TKA_GRANT_NOT_FOUND
What Windows has already determined
Interpret SL_E_TKA_GRANT_NOT_FOUND inside token-based activation, not as a generic activation failure. Windows has reached certificate-backed token activation for approved volume-licensing scenarios in isolated or high-security environments; in this case, the token issuance material does not contain the grant required for the target activation operation.
The stored HRESULT is 0xC004F304. Keep that value, the symbolic name, and the target Activation ID together; converting it to a generic “Windows is not activated” status discards the stage that selected the next diagnostic step.
How to test the failing boundary
- Select the exact licensing product or Activation ID that returned this result; do not rely only on the first line of
slmgr /dlv. - confirm the mechanism in use: certificate-backed token activation for approved volume-licensing scenarios in isolated or high-security environments.
- prove the code-specific condition by collecting: record issuance-license identity, target SKU/Activation ID, grant identifiers, installation history, and file signature.
- apply the distinction “a missing grant is different from a grant present but malformed or mismatched” before choosing a key, network, certificate, firmware, time, or entitlement repair.
- change one decisive precondition, rerun one activation/evaluation operation, and verify the resulting LicenseStatus and LicenseStatusReason.
The surrounding licensing model prevents two common misdiagnoses. for this HRESULT: Certificate discovery, chain validation, challenge matching, grant parsing, and policy matching are distinct stages, so a generic certificate reinstall can conceal the failing boundary. for this HRESULT: Token-based activation is a specialized volume activation method; the issuance license describes certificate criteria and is not interchangeable with a KMS host key or MAK.
What to collect from the affected system
The decisive record is to record issuance-license identity, target SKU/Activation ID, grant identifiers, installation history, and file signature. Before changing the system for this HRESULT, add the following context:
- Product identity for this HRESULT: certificate thumbprint, subject, issuer and validity interval.
- Activation context for this HRESULT: private-key provider and exportability flag.
- State at failure for this HRESULT: challenge/grant correlation and relevant licensing event IDs.
- Correlation evidence for this HRESULT: target Activation ID and SKU.
- Change history for this HRESULT: installed token issuance license identity.
When investigating this result, protect secrets while collecting evidence. Full product keys, complete IID/CID values, private keys, PINs, challenge blobs, account credentials, and unredacted certificate material for this HRESULT do not belong in public tickets. Partial keys, hashes, thumbprints, IDs, timestamps, and state transitions are normally enough to correlate the failure.
The diagnostic fork is precise: a missing grant is different from a grant present but malformed or mismatched. A broad instruction for this HRESULT to “try another key” or “check the Internet” would discard what this HRESULT already established.
What a safe fix looks like
Resolve this code at its producing layer: install the correct token issuance license supplied for the target product and organization. A successful command is not enough by itself; verify the stored licensing state and any renewal, validity, or binding data affected by the operation.
Representative failure: A token license for one product family is installed on a system attempting to activate another.
How this differs from adjacent licensing codes
| Result | Different boundary |
|---|---|
SL_E_TKA_CERT_NOT_FOUND | Relative to this result: no certificate matching the token-activation lookup could be found in the stores visible to the licensing process. |
SL_E_TKA_INVALID_CERT_CHAIN | Relative to this result: the activation certificate chain cannot be built to an accepted trust anchor or fails chain validation. |
SL_E_TKA_INVALID_SKU_ID | Relative to it: the target Windows edition or Activation ID is not enabled for token-based activation. |
Choosing remediation by the symbolic code prevents an entitlement problem from being treated as transport failure, or a state-transition result from being treated as a bad product key.
Actions that usually make this harder to diagnose
- While diagnosing it, avoid exporting or replacing private keys before preserving certificate and provider evidence. That action changes evidence for this HRESULT without correcting the established boundary.
- avoid switching to a weaker certificate merely to bypass issuance-license criteria. The result already narrows the problem more precisely.
- do not delete licensing stores, edit signed license files, alter firmware markers, bypass certificate checks, or use unofficial activation tools. During investigation, those actions can create a second integrity problem and destroy the evidence needed to repair the legitimate license.
Verification after the change
A useful it test records the before/after values for the exact Activation ID. It should prove that the correction removes “the token issuance material does not contain the grant required for the target activation operation” without replacing it with a different key, KMS, certificate, OEM, Store, or validity failure.
Technical references
- Plan for volume activation — diagnostic and operational context for this HRESULT.
- Slmgr.vbs token-activation options — supported tools and state fields used to verify it.
- Microsoft token-activation event guidance — Microsoft guidance for the activation mechanism represented by it.
- SoftwareLicensingProduct WMI class — platform behavior relevant to it.
Looking for a different code? Search another status or error code.