| Previous | Next |
| EAS_E_ADMINS_CANNOT_CHANGE_PASSWORD | EAS_E_PASSWORD_POLICY_NOT_ENFORCEABLE_FOR_CONNECTED_ADMINS |
EAS_E_LOCAL_CONTROLLED_USERS_CANNOT_CHANGE_PASSWORD
EAS_E_LOCAL_CONTROLLED_USERS_CANNOT_CHANGE_PASSWORD — 0x80550009
Treat this HRESULT as a marker, not as a request for a generic restart or reinstall. It is returned when one or more local standard users controlled by EAS policy cannot perform the password change needed for compliance.
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. This code targets local controlled standard users, not all accounts on the machine. Compare lifecycle, identity, caller, and first API.
Evidence worth preserving
| Incident evidence | Question it answers |
|---|---|
| Control-user account list tied to configured EAS mail apps | Pins evidence to one attempt. |
| Per-account password-change restriction and enabled state | Separates contract failure from environment. |
| Requested password policies and pending actions | Creates a stable before/after control. |
| Difference between local, domain, and Microsoft accounts | 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.
A controlled diagnostic sequence
- Remove the restriction from one disposable standard account; use a disposable or backed-up environment when the comparison changes boot, security, device, queue, or encryption state.
- Unlink the test EAS account and confirm policy scope changes as expected; retain one negative control so that a broad workaround is not mistaken for a root-cause correction.
- Run CheckCompliance from each relevant user context; keep every other input fixed and record the first event that differs from the failing run.
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 standard control-user password restrictions operation with targeted instrumentation before closing the incident.
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
A defensible correction is specific to the evidence: Restore password-change capability for affected local users or change account/policy design through the proper authority. Preserve the pre-change configuration or trace.
Close the incident only when each controlled user can satisfy the policy without administrator credential disclosure and unaffected users remain outside scope. 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.