| Previous | Next |
| EAS_E_POLICY_COMPLIANT_WITH_ACTIONS | EAS_E_CURRENT_USER_HAS_BLANK_PASSWORD |
EAS_E_REQUESTED_POLICY_NOT_ENFORCEABLE
The important question is not merely what the text says, but which contract was being evaluated. At this boundary, the requested EAS setting is stricter than Windows or the relevant account/provider can enforce.
What the status narrows down
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. User action cannot make an inherently unsupported policy enforceable on that platform/account type. Compare lifecycle, identity, caller, and first API.
Evidence worth preserving
| Preserve before changing state | Diagnostic value |
|---|---|
| Requested value and corresponding Windows/local/account capability | Separates contract failure from environment. |
| Account types on the device and which are evaluated locally | Creates a stable before/after control. |
| Conflicting Group Policy/MDM/EAS sources and the strictest merged result | Tests whether the first boundary moves. |
| Per-policy compliance result, not only the aggregate HRESULT | 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.
A controlled diagnostic sequence
- Lower the test policy to the documented supported boundary; use a disposable or backed-up environment when the comparison changes boot, security, device, queue, or encryption state.
- Evaluate local, domain, and Microsoft accounts separately; retain one negative control so that a broad workaround is not mistaken for a root-cause correction.
- Compare CheckCompliance without applying changes; keep every other input fixed and record the first event that differs from the failing run.
Do not use repeated retries as the primary test. In this case, a successful later attempt may reflect a new object, refreshed policy, restarted service, different token, or completed background transition, so record exactly what changed between attempts.
How to read the outcome
Interpret the controlled tests as evidence about the returning boundary:
| 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 | The failure moved to another boundary; diagnose the new status separately rather than treating it as confirmation that the entire operation is fixed. |
Correction and proof
The corrective action should be narrow: Adjust the server policy to a supported value or use a management authority that can enforce the requirement. Preserve the pre-change configuration or trace.
Close the incident only when policy design tests cover every supported account type and reject configurations that Windows would only appear to enforce. Repeat under the original identity and state. A different environment is comparison, not proof.
Technical references
The diagnostic boundaries above are grounded in the following Microsoft specifications and API documentation:
- 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.