Investigations combined message header analysis, Exchange/Graph queries, mailbox/archive searches and directory inspections to determine whether addresses were full mailboxes, primary or secondary SMTP proxies, mail‑enabled groups/Teams objects, external ('.ext') accounts, or were subject to forwarding/inbox/transport rules. Licensing faults that prevented delivery and forwarding were resolved by remediating affected Microsoft 365 licenses (including restoring removed license groups), which restored inbound delivery, forwarding and Teams/SSO access where role‑scoped contexts had been disabled. Primary SMTP addresses were reassigned and legacy addresses retained as secondary SMTPs where required; duplicate, stale or orphaned aliases and enterprise‑app artifacts were removed after identifying the authoritative source and, when necessary, ownership was transferred to the correct mailbox. Email‑enabled security groups were deleted and their addresses repointed as proxy addresses on the appropriate Office 365 groups when delivery semantics changed. Forwarding and inbox/transport rules that redirected mail externally or to incorrect targets were corrected or disabled and delivery was reconfigured so a local copy remained where automatic replies were expected. Automatic‑reply loops and persistent redirecting replies were stopped by disabling or editing conflicting autoreplies; external '.ext' accounts that had become blocked or expired were reactivated and assigned owners so inbound routing and portal/Teams access resumed. Delegation, send‑as and full‑access permissions altered by renames or reprovisioning were reprovisioned or revoked as required. Recurring calendar invitations that reappeared for users were traced to orphaned organizer mailboxes or lingering calendar ownership; removing or reassigning the owner mailbox (or hiding/deleting the mailbox from address lists) and clearing delegate/calendar forwarding stopped the repeated invites. Teams/course‑feed and distribution lists with oversized or stale memberships were pruned to stop unwanted notifications; where Teams group addresses could not host forwarding or automatic replies, delivery was moved to a dedicated mailbox hidden from address lists. Mailbox merges, migrations and archived‑message retrievals were performed by exporting/importing mailbox contents or using mailbox/archive search to extract required items (for example finance receipts) before aliasing or redirecting delivery so data and access semantics were preserved. Client‑side cache effects were mitigated by allowing directory propagation and signing users out/clearing Teams and Office caches so GAL/autocomplete lists refreshed. As a short‑term mitigation for stale directory suggestions, expired or external '.ext' entries were hidden from the Global Address List while authoritative records were reconciled.

Administrators resolved mailbox provisioning, access and send failures by verifying identities/ownership, restoring or recreating mailbox objects, remediating Microsoft 365 licensing, and explicitly granting or reapplying mailbox and send permissions. Key observations and actions that resolved incidents included:

Incidents were closed after reactivating or reassigning licenses, restoring or recreating mailbox objects, resetting credentials and documenting ownership, explicitly granting or reapplying Send‑As/Send‑On‑Behalf/Full‑Access permissions, repairing allowed‑senders lists via PowerShell when EAC failed, provisioning appropriate shared/service mailboxes (including licensed service accounts for third‑party app bindings), and creating tailored Exchange RBAC roles for delegation. Observed propagation times were typically ~1 hour for address propagation and a few minutes for permission propagation.

Delivery and forwarding failures in Exchange Online were resolved by combined mailbox, connector, policy and trace actions that isolated routing, permission, and reputation causes. Key outcomes and observations included:

These actions restored external ingestion and recipient delivery, removed outbound send blocks caused by tenant allow/block list entries or temporary limits, corrected connector/routing errors for IMCEAHTTPS‑encoded recipients, reduced spam‑folder deliveries, repaired forwarding and mailbox configuration issues, and produced traceable logs for downstream investigations.

The sender split the large attachments across multiple smaller messages to avoid transfer limits and retried delivery; mail logs and delivery traces were reviewed, which showed some messages had been delivered to the organization while oversized combined attachments risked hitting transfer/receiving limits despite prior increases to default thresholds.

Two separate causes produced identical symptoms and were resolved differently. 1) Group-level hidden flag: some Teams backed by a Microsoft 365 (unified) Group had HiddenFromExchangeClientsEnabled set, which prevented Exchange/Outlook from listing the group and its calendar; the attribute was cleared using Exchange Online PowerShell (Set-UnifiedGroup in a connected ExchangeOnline session) and the group/calendar became visible. 2) Mailbox-level address-list hiding: other incidents were mailboxes with address-list visibility disabled (HiddenFromAddressListsEnabled), which caused the account to be absent from GAL/address-book views; the mailbox visibility attribute was changed and the team noted that propagation to address lists could take a few days. 3) Management-path confusion: some objects were Microsoft 365 (unified) groups rather than legacy distribution lists and therefore did not appear or could not be managed in the classic EAC distribution-list view; these were managed via Microsoft 365 admin center / Teams / Azure AD or the unified-group PowerShell cmdlets. In all cases primary SMTP and proxy addresses were reviewed and reconciled to avoid duplicate-address conflicts when recreating or renaming objects; Teams channel/resource addresses were recorded when relevant to permission or ownership updates.

The issue was worked around by creating the forwarding rule in Outlook Web (office.com/OWA) instead of the desktop client. A server‑side forwarding rule created via the web client persisted and delivered as expected; the desktop Rule Assistant appeared to lose or fail to apply rules in this environment.

Two classes of address-book issues were resolved. For incorrect or outdated display names — including cases where an account re-creation in an HR system (Workday) had added an unwanted title — administrators updated the mailbox/displayName attributes in the directory/mail server (Exchange Online / Azure AD). Those server-side attribute changes took effect immediately on the server and propagated to Outlook clients and the Global Address List after directory/mail synchronization, typically over a few days. For privacy/visibility requests, administrators hid the mailbox from address lists using the Exchange Admin Center (“Hide from address lists”); after saving the change the mailbox was removed from GAL/address-book search results once propagation completed. Affected systems referenced in these fixes included Exchange Online / Office 365, Azure AD, Outlook and the HR/directory sync pipeline.

Access failures were traced to legacy/basic Exchange authentication being unavailable and to client sign-in paths that did not use OAuth/Modern Authentication. Remediation in resolved cases included reprovisioning the mailbox with Modern Authentication or moving the user to an OAuth-capable client (Microsoft Outlook) so the flow reached MFA. In one case the credential flow was replaced and the user’s password was reset to remove/normalize characters that had been breaking the mobile sign-in path; after the password change and re-enrolment the sign-in proceeded to MFA and completed. Investigation confirmed that Apple Mail/macOS Internet Accounts can repeatedly prompt for passwords or present failed biometric prompts when they cannot perform an OAuth/MFA exchange, so using an OAuth-capable client or reprovisioning the account for Modern Auth resolved access.

Incidents were resolved by ensuring affected Azure AD user objects contained a valid mail and/or proxyAddresses attribute so that EWS-based recipient-resolution returned them. Guest accounts were updated with the appropriate mail and/or proxyAddresses values; after those attributes were present, EWS-using tools (for example, JungleMail) and survey sending systems successfully included the users. Message trace output had shown the missing users were not present in recipient expansions. As an alternative root-cause mitigation, replacing EWS-based recipient-resolution queries with Microsoft Graph-based queries avoided the limitation because Graph can return guest members in more attribute scenarios.

The incident was resolved by removing the affected account from the IUG-AAD-ASS-ConditionalAccess-Student-MfA group and consolidating the user's identity across the provisioning chain so a single authoritative account existed. Duplicate/linked identities were consolidated, dynamic group membership rules/attributes were corrected so the iubh.de address no longer triggered student group assignment, and a full directory resynchronization was performed between Active Directory, Microsoft Entra and Okta/Workday. After consolidation and resync the user could authenticate normally and the email rename propagated without re-triggering the student MFA policy.

Investigations combined Exchange Admin Center searches, PowerShell mailbox searches, mail-trace analysis, review of applied retention tags/policies, backup vendor (AvePoint) recovery attempts, and escalation to Microsoft support. Outcomes and findings were: - In accidental/mass-delete cases (for example bulk Workday reminders preceding the deletion) mail trace confirmed high-volume deletion activity, Deleted Items and Recoverable Items contained no matching copies, AvePoint and Microsoft could not locate recoverable copies, and Microsoft support confirmed messages could not be restored. - In retention-driven cases a folder had an applied retention setting that permanently deleted items after 90 days; attempts to change the folder/message retention via the mailbox UI or non-privileged PowerShell did not take effect because the retention tag/policy was managed at the tenant/compliance level and required tenant compliance/admin control. - Where retention had already expired and the policy had permanently purged items, neither Exchange nor third-party backups retained recoverable copies and the data was effectively unrecoverable. Mitigation and disposition actions recorded: teams were advised to involve tenant compliance or Exchange Online administrators to review and, if appropriate, change retention policy configuration for affected mailboxes; for critical scanned records that must be retained longer-term, teams were directed to use an archival location (for example SharePoint) or to request a change to the organization's retention policy so records are preserved beyond the enforced deletion window. No recoveries were possible when retention/purge had already removed items from all recoverable stores and backups.

Message-trace and header inspection proved the cancellation notices were genuine calendar CANCEL messages sent through Exchange Online and not a client-side UI glitch. The traces showed the cancellations originated from the LMS365 integration using its service account/shared organizer mailbox (the LMS application principal was visible in transport headers) and were submitted via the tenant’s connector/API path (Graph/EWS-like submission) rather than being generated by end-user Outlook clients. Root cause was an automated LMS scheduled job that flagged certain sessions as cancelled (due to duplicate/overlapping session records and a misapplied recurrence/reschedule policy in the Zensai/LMS365 configuration). The team disabled the offending scheduled cancellation workflow in the LMS, corrected the event mapping so the LMS used a dedicated organizer mailbox, removed duplicate session records, and validated subsequent message-traces; automated cancellations stopped after these changes.

Support initiated password resets for the affected Exchange Online accounts and redirected reset messages or provided reset details to the users' external recovery addresses (examples: Gmail, GMX) or via informational email. Users used the external recovery messages or provided reset details to complete the password change and subsequently regained mailbox access. One case showed inconsistent access across Microsoft services that suggested duplicate/overlapping accounts, but resetting the specific mailbox account restored access in that instance.

The support decision was to not enable Exchange Online In‑Place Archive for this user at that time. The ticket captured the rationale: limited admin experience with the archive feature, known constraints such as lack of smartphone access to the archive, unclear assistant/delegate access implications, and the risk that an archive could also reach capacity. PST and SharePoint/OneDrive alternatives were reviewed and documented with their trade‑offs (PST corruption risk, manual rights management, accessibility differences). The user retained the existing mailbox configuration and continued manual mailbox cleanup as the immediate course of action.

Support determined this behavior was 'by design' for Microsoft 365/Office 365 groups: senders do not automatically receive a copy of messages they send to a group unless the group's delivery/subscription option is enabled. The user was informed of the design behavior and directed to enable the group's delivery/subscribe setting per Microsoft documentation to receive copies of messages they send to the group.