| Previous | Next |
| EAS_E_POLICY_NOT_MANAGED_BY_OS | EAS_E_REQUESTED_POLICY_NOT_ENFORCEABLE |
EAS_E_POLICY_COMPLIANT_WITH_ACTIONS
EAS_E_POLICY_COMPLIANT_WITH_ACTIONS — 0x80550002
This code places the first failure in EAS compliance requiring user action. Operationally, Windows can meet the requested policy, but one or more explicit user/system actions are still required before the device becomes compliant.
Meaning in the subsystem
EAS compliance is a policy merge, not a single password test. Windows evaluates the requested settings against local accounts, connected accounts, domain or management policy, and operating-system capabilities; the individual fields in EasComplianceResults show which requirement changed the decision.
Do not collapse this result into a nearby status. This differs from an unenforceable policy: the platform has a path to compliance, but it is not yet complete. Compare lifecycle, identity, caller, and first API.
Minimum useful evidence
| Incident evidence | Question it answers |
|---|---|
| Per-policy EasComplianceResults values and the exact pending actions | Separates contract failure from environment. |
| Account types affected, current password/sign-in/encryption state, and policy source | Creates a stable before/after control. |
| Whether ApplyAsync can initiate the change or only inform the user | Tests whether the first boundary moves. |
| Time when policy was evaluated versus when the user completed action | Pins evidence to one attempt. |
The goal is reproducibility, not a full data dump. Prefer object IDs, configuration exports, event correlation, and redacted paths over credentials, cryptographic material, or user content.
Isolate the responsible condition
- Call CheckCompliance before and after the documented action; retain one negative control so that a broad workaround is not mistaken for a root-cause correction.
- Apply one policy at a time in a lab account to identify the action owner; keep every other input fixed and record the first event that differs from the failing run.
- Verify the final state after sign-out/restart where the policy requires it; use a disposable or backed-up environment when the comparison changes boot, security, device, queue, or encryption state.
If the failure disappears after a broad restart, treat that as a clue about lifetime or state, not as proof of repair. Reproduce the original operation with targeted instrumentation before closing the incident.
Avoid the common misdiagnosis
Read the comparison results in this order:
| Observed result | Interpretation |
|---|---|
| The minimal or known-good comparison succeeds | The control works; inspect production-specific state. |
| The control fails at the same first operation | The control also fails; inspect host/provider evidence. |
| A new HRESULT marks another boundary | this boundary moved; diagnose the new status separately rather than treating it as confirmation that the entire operation is fixed. |
Regression proof
Apply the smallest change that addresses the first rejected condition: Present the precise required action, preserve account recovery access, and re-evaluate rather than assuming the action succeeded. Preserve the pre-change configuration or trace.
Close the incident only when all per-policy results become compliant after the action and regress to the expected state when the control condition is restored. Repeat under the original identity and state. A different environment is comparison, not proof.
Technical references
Use these sources for the formal contract, then combine them with evidence from the returning application or service for this condition:
- Microsoft Open Specifications: HRESULT values.
- Microsoft: Exchange ActiveSync Policy Engine overview.
- Microsoft: EasClientSecurityPolicy.
- Microsoft: CheckCompliance.
Looking for a different code? Search another status or error code.