| Previous | Next |
| SL_REMAPPING_SP_PUB_KM_CACHE_POLICY_CHANGED | SL_I_OOT_GRACE_PERIOD |
SL_I_OOB_GRACE_PERIOD
Where this licensing result is produced
The actionable meaning of SL_I_OOB_GRACE_PERIOD is tied to license state, grace and validity. At the Software Protection Platform state machine that evaluates whether a license is active, in a grace or validity interval, out of tolerance, expired, non-genuine, or in notification, Windows determined that the product is operating in its initial out-of-box grace period before activation is required.
The stored HRESULT is 0x4004F00C. 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.
This result should be read against these rules: for it: Informational licensing HRESULTs can describe a valid grace or time-based state even though the value is not S_OK; callers should inspect severity and state rather than treating every nonzero code as failure. for it: Grace expiration, validity expiration, hardware out-of-tolerance, non-genuine state, and notification mode have different causes and transitions even when the user sees a similar activation banner.
Checks in the order that matters
- Begin with the operation that emitted this result and its target Activation ID.
- inventory Activation ID, LicenseStatus, LicenseStatusReason, GracePeriodRemaining, EvaluationEndDate, GenuineStatus, trusted time and hardware binding; this establishes whether the request was aimed at the intended product and activation channel.
- use events and tool output to demonstrate: record LicenseStatus, GracePeriodRemaining, installation time, Activation ID, key channel and the planned activation method.
- rule out the adjacent case: this is a valid temporary state, not evidence that activation already completed.
- After the narrow correction for it, verify both the immediate HRESULT and the persistent licensing state after service restart or reboot when relevant.
Evidence to preserve before changing anything
The decisive record is to record LicenseStatus, GracePeriodRemaining, installation time, Activation ID, key channel and the planned activation method. Before changing the system for it, add the following context:
- Product identity for it: trusted time and recent time-service events.
- Activation context for it: hardware or firmware changes affecting binding.
- State at failure for it: activation channel, partial product key and last successful activation/renewal.
- Correlation evidence for it: LicenseStatus and LicenseStatusReason for the exact Activation ID.
- Change history for it: GracePeriodRemaining and EvaluationEndDate.
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 it do not belong in public tickets. Partial keys, hashes, thumbprints, IDs, timestamps, and state transitions are normally enough to correlate the failure.
Choose recovery by the producing stage
| Result | Different boundary |
|---|---|
SL_I_OOT_GRACE_PERIOD | Relative to this result: the license has entered an out-of-tolerance grace interval after hardware or binding change exceeded the normal tolerance. |
SL_I_NONGENUINE_GRACE_PERIOD | Relative to it: genuine validation placed the installation in the first valid non-genuine grace state before enforcement or notification transition. |
SL_I_NONGENUINE_GRACE_PERIOD_2 | Relative to it: the installation is in the second defined non-genuine grace category used by the licensing state machine. |
The comparison is also useful for tests: each branch should have a fixture that produces its own HRESULT and verifies the expected persistent licensing state.
It is actionable because this is a valid temporary state, not evidence that activation already completed. Automation handling it should route the result to the owner of that layer rather than starting every recovery path at once.
Recovery without damaging licensing evidence
Recovery should preserve entitlement and state rather than erase symptoms. In this case, complete activation before the remaining grace reaches zero and verify the resulting Licensed state; then query the same product instance and retain the post-fix it HRESULT and status.
Representative failure: A newly deployed image is usable while automation schedules its first KMS or other activation attempt.
Actions that usually make this harder to diagnose
- While diagnosing it, avoid resetting licensing state merely to hide an expired or non-genuine condition. That action changes evidence for it without correcting the established boundary.
- avoid interpreting a positive informational HRESULT as an activation failure without checking LicenseStatus. 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
Build a regression case that intentionally creates “the product is operating in its initial out-of-box grace period before activation is required” and asserts it. The corrected the case should change only the decisive input, then verify the same Activation ID, final LicenseStatus/Reason, and any relevant grace, renewal, certificate, binding, or expiry data.
Technical references
- SoftwareLicensingProduct WMI class — supported tools and state fields used to verify it.
- WMI properties for volume activation — Microsoft guidance for the activation mechanism represented by it.
- Slmgr.vbs activation options — platform behavior relevant to it.
- Microsoft activation error-code troubleshooting — diagnostic and operational context for it.
Looking for a different code? Search another status or error code.