| 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: 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. 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 targeted fix, verify both the immediate HRESULT and the persistent licensing state after service restart or reboot when relevant.
Evidence to preserve before changing anything
Record LicenseStatus, GracePeriodRemaining, installation time, Activation ID, key channel and the planned activation method. Before changing the system, add the following context:
- Product identity: trusted time and recent time-service events.
- Activation context: hardware or firmware changes affecting binding.
- State at failure: activation channel, partial product key and last successful activation/renewal.
- Correlation evidence: LicenseStatus and LicenseStatusReason for the exact Activation ID.
- Change history: GracePeriodRemaining and EvaluationEndDate.
Choose recovery by the producing stage
| Result | Different condition |
|---|---|
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 | Different condition: genuine validation placed the installation in the first valid non-genuine grace state before enforcement or notification transition. |
SL_I_NONGENUINE_GRACE_PERIOD_2 | Different condition: 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.
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
- Avoid resetting licensing state merely to hide an expired or non-genuine condition.
- Avoid interpreting a positive informational HRESULT as an activation failure without checking LicenseStatus.
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 case should change only the relevant 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 the resulting state.
- WMI properties for volume activation — Microsoft guidance for the activation mechanism represented by this HRESULT.
- Slmgr.vbs activation options — platform behavior relevant to this HRESULT.
- Microsoft activation error-code troubleshooting — diagnostic and operational context.
Looking for a different code? Search another status or error code.