Mailbox.EnsurePermissions (ExchangeOnline) reports Changed=false and Ensure=Absent fails

[blindzero]

Description

Mailbox.EnsurePermissions using the ExchangeOnline provider reports Changed: False even when it actually applies changes. Additionally, removing permissions with Ensure = 'Absent' fails (while Present works).

Observed error during removal attempts includes server-side EXO error messages.

Steps to Reproduce

1. Run Mailbox.EnsurePermissions for ExchangeOnline with a permission assignment that exists.

2. Apply Ensure = 'Present' -> works.

3. Apply Ensure = 'Absent' using:

   @{ AssignedUser = 'matthias.fleschuetz@nanotempertech.com'; Right = @('FullAccess'); Ensure = 'Absent' }

4. Observe:

   • Step result shows Changed: False even when something changed.
   • Ensure=Absent fails with server-side error.

Expected Behavior

• Step returns Changed: True when permissions were modified.
• Ensure=Absent removes the specified permission reliably and idempotently (subsequent runs result in Changed: False).

Actual Behavior

• Changed remains False even when changes occurred.

• Ensure=Absent fails, e.g.:

  A server side error has occurred because of which the operation could not be completed...

Environment

• PowerShell version: 7.x
• OS: (fill in)
• IdLE version / commit: (fill in)
• Execution context (CLI / Service / CI): (fill in)
• ExchangeOnlineManagement version: 3.9.2

Additional Context

Notes / Implementation expectations (agent-safe)

1. Changed calculation

• Ensure the step sets Changed = True whenever at least one permission entry is added/removed/updated.
• Ensure idempotency: when desired state already matches, Changed = False.

2. Ensure=Absent support

• Verify which EXO cmdlets are used for permission changes (e.g., Add-MailboxPermission / Remove-MailboxPermission vs EXO equivalents).
• Ensure the removal path uses the correct parameters (especially for FullAccess) and handles propagation delays gracefully.
• If EXO sometimes returns transient server-side errors, implement a bounded retry with backoff (only for clearly transient errors), and emit actionable error messages when retries are exhausted.

3. Diagnostics

• Emit step/provider diagnostics events for:
  • evaluated current permissions
  • intended delta
  • command invoked (sanitized)
  • result & changed-state decision

4. Tests

• Unit tests using mock provider responses:
  • Present adds -> Changed True
  • Absent removes -> Changed True
  • Second run -> Changed False
  • Transient server-side error -> retry path