| Previous | Next |
| E_MBN_SMS_MEMORY_FULL | EAS_E_POLICY_COMPLIANT_WITH_ACTIONS |
EAS_E_POLICY_NOT_MANAGED_BY_OS
The important question is not merely what the text says, but which contract was being evaluated. At this boundary, the caller asked Windows to evaluate an EAS policy that the operating system does not manage through this policy engine.
Where the failure sits
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. Unsupported policy ownership is not device noncompliance; Windows is saying this engine cannot decide/enforce that requirement. Compare lifecycle, identity, caller, and first API.
Facts to collect first
| Capture | Why it matters |
|---|---|
| Individual EAS property being evaluated and its MS-ASPROV name | Pins evidence to one attempt. |
| Windows build, account type, and EasClientSecurityPolicy values set by the app | Separates contract failure from environment. |
| CheckCompliance result for every policy rather than one aggregate status | Creates a stable before/after control. |
| Whether the requirement belongs to Exchange/server, app, MDM, or another authority | Tests whether the first boundary moves. |
Collect the smallest evidence set that identifies the attempt and object. Redact secrets and message contents; preserve hashes, IDs, policy values, versions, and state transitions instead.
Change one variable at a time
- Evaluate only the documented OS-managed policy subset; retain one negative control so that a broad workaround is not mistaken for a root-cause correction.
- Compare CheckCompliance with the property omitted; keep every other input fixed and record the first event that differs from the failing run.
- Test the same server policy through the intended management authority; use a disposable or backed-up environment when the comparison changes boot, security, device, queue, or encryption state.
One clean comparison is more informative than many uncontrolled retries. For the controlled comparison, keep the original inputs and identity, change a single suspected condition, and stop as soon as the first differing event is visible.
What the result does not prove
The following decision points keep the investigation tied to the returning operation:
| 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. |
Verification after correction
The corrective action should be narrow: Route the requirement to the correct authority or report it as not OS-managed instead of pretending Windows enforced it. Preserve the pre-change configuration or trace.
Close the incident only when the app maps each server policy to a documented evaluator and never grants compliance when evaluation is unavailable. 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.