Folder-level calendar ACLs, client visibility behavior, and directory-attribute causes were audited and corrected. Where mailbox Full Access did not confer sufficient folder-level rights, calendar Editor/delegate permissions were explicitly granted or removed using Exchange Online cmdlets (Add-MailboxFolderPermission, Remove-MailboxFolderPermission, Set-MailboxFolderPermission); the SendNotificationToUser parameter was used to control whether delegates received meeting responses when permissions changed. Delegates who could not mark items Private or were not receiving meeting responses had delegate settings adjusted (via Exchange Online or Outlook UI) and, when necessary, remote support sessions confirmed the changes. Former-assistant and cover-user accounts were removed from calendar ACLs and owners were shown how to re-share or re-grant delegate access when appropriate. Shared and functional mailbox calendars were restored by adding the shared mailbox/calendar to affected users’ Outlook profiles (New Outlook provided an overlay merged view; Classic Outlook showed shared calendars side‑by‑side). Transient exposures of event titles after switching Outlook clients were traced to client synchronization latency and resolved once the client completed sync of updated sharing permissions. Team-view anomalies listing deactivated employees were traced to stale manager attributes in AD/Workday/Okta; correcting the manager attributes and allowing directory sync to run removed deactivated users from team/calendar views. Access issues for distribution/group calendars and calendars backed by M365 Groups were resolved by adjusting group membership/owner status and sender permissions so requesters could join or receive calendar items; in cases where updates failed to reach attendees, affected events were canceled and recreated to re-propagate correct invites. Guidance was provided for urgent cases where mailbox or group owners were unavailable.

Server-side corrections were required when client actions could not remove or reconcile events. Recurring series owned by departed or inactive personal organizers, or by group/team mailboxes, were removed by an administrator using Exchange Web Services (EWS) run against the group/team mailbox or channel calendar when mailbox ownership or co-owner access allowed it. When privacy or legal constraints prevented admin access to a departed user’s personal mailbox, participants were instructed to decline or delete the entire recurring series from their own calendars; a standardized decline/cancellation text template was provided. In multiple incidents, deleting the full recurring series (not individual occurrences) via OWA or using the client option to reject the appointment series stopped repeated re-creations and cleared Exchange Online messages reporting a meeting had been re-created. Channel-calendar ghost events required server-side removal because per-recipient event IDs prevented client deletes from removing all instances. Local Outlook duplicate or conflicting calendar entries were cleared by removing offline Calendar folder items so the client re-synchronized from the server. For channel invite delivery problems, adding the channel’s email address to the meeting’s attendee list caused invitations to be delivered to channel members. It was observed that channel meetings created before a user joined the Team were not added automatically to that user’s personal calendar and that the Teams V2 desktop/web “Add to calendar” control was inconsistent or missing; those meetings were resolved by sending personal invites or by users manually subscribing/adding the event. Inconsistent visibility of recurring series across participants was resolved in multiple incidents by deleting the problematic series and recreating it, then allowing hours for propagation across accounts. A subset of incidents documented organizer-side disappearing invites and unexpected cancellations originating from the organizer’s account; no definitive remediation for that exact symptom was recorded in the ticket corpus, though the above server-side removals and full-series deletions had addressed many related calendar inconsistencies in other cases.

User timezone and working-hours inconsistencies were resolved by correcting the account timezone in Outlook and Outlook on the web (Office.com/OWA); once the account/timezone stored in the web profile was updated, Teams and the Scheduling Assistant displayed the correct availability. For shared and non-interactive mailboxes, mailbox calendar configuration records were updated via Exchange Online PowerShell (Set-MailboxCalendarConfiguration) to set the intended working hours and timezone; a deprecation warning for the 'EventsFromEmail' parameters was observed during those PowerShell changes. Two distinct macOS-related Teams issues were handled separately: (1) the Teams macOS desktop client sometimes preselected UTC when composing meetings, producing invites with UTC timestamps that Outlook rendered with DST-related offsets — affected meetings were recreated or scheduled using the Teams web client or Outlook as a practical workaround and the behavior was confirmed and escalated to Microsoft as a product bug; (2) Teams could reflect a timezone stored in the user’s Office.com/OWA profile despite different local macOS or Outlook settings, and signing into the Office web apps and correcting the account timezone caused Teams to display the correct zone. External scheduler incidents were diagnosed as timezone-conversion behaviors rather than product faults: appointments created by Calendly were created in UTC, so they displayed with the expected local offset in users’ calendars (for example 14:30 UTC appearing as 16:30 CEST); occasional 30‑minute offsets were consistent with non-standard timezone offsets. Incidents where Microsoft Bookings confirmations and reminders disagreed (shifted start time and shortened duration) were attributed to Bookings profile/timezone discrepancies and reminder-buffer behavior; Bookings profile timezone and reminder settings were examined during diagnosis. Across cases, the Scheduling Assistant warning “participants are located in different time zones” and incorrect displayed zones were symptomatic of a stored account/web-profile timezone differing from the client or of events authored with UTC timestamps.

When tenant policies and administrative consent permitted, external calendars were published as ICS feeds (Outlook or Outlook on the web) so third‑party tools and devices could subscribe; where backend integrations were approved, platform synchronizations completed within minutes to about 30 minutes and calendar access was restored. In many cases myCampus and other external iCal feeds showed up in Outlook as Internet‑subscribed calendars that were read‑only, listed under 'My Calendars', and could not be shared or discovered via the address book; because those subscriptions were not part of the mailbox they did not merge with the primary calendar and did not publish free/busy to Microsoft Teams. Some Outlook attempts to add external iCal URLs failed with a generic ‘‘try again’’ prompt or returned explicit 'calendar cannot be shared' errors; one ticket recorded no technical remediation for that import failure. As a fallback when publication or subscription was blocked, calendars were exported as .ics and imported into the target calendar; those static imports sometimes remained outdated (notably on iOS) and repeated export/imports occasionally created duplicate events that required manual cleanup. Device‑specific issues were observed: in one case installing the Company Portal 'Self Service Tool' restored the Outlook Add > From Internet subscription. Where built‑in sharing or channel calendars were not possible (for example private Teams channels or internet‑subscribed calendars), alternatives implemented included creating a shared calendar tied to an Office 365 group or shared mailbox/distribution list, or using Power Automate to replicate events to a calendar accessible to external participants; these alternatives were still subject to tenant sharing policies and administrative consent. Tenant administrators reviewed third‑party consent requests with data‑protection/privacy teams and, under security/data‑separation guidelines, some integrations (for example Akiflow and similar planners) were denied; approved integrations regained calendar access after the provider completed their synchronization window.

Multiple distinct causes for Bookings calendar and availability problems were identified and handled. Historical identity/alias mismatches (for example, misspelt SMTP/proxyAddresses or inconsistent onmicrosoft entries across identity sources) were corrected by aligning the mailbox identity across Okta/on‑prem AD/Azure AD so the Bookings service could match the mailbox and calendar data; this restoration of consistent proxyAddresses resolved sync failures in the observed cases. Bookings showing occupied times as free was resolved by changing the Bookings Availability setting to require staff availability before allowing bookings, which stopped the service presenting already‑booked slots as available. Several incidents where Bookings-created appointments were visible in the web UI but not in desktop or mobile Outlook were determined to be transient, service-side visibility/synchronization issues and self-resolved on Microsoft's side after Microsoft Support investigation. In one instance where new bookings created during a staff absence were ending up in a colleague's calendar, investigation identified mailbox forwarding/delegation as the likely cause and the case was escalated to Microsoft for clarification; no on-prem remediation was recorded in that ticket. Each resolution or escalation was recorded against the affected service configuration or identity source as appropriate.

Published assessment window dates were added to the team diaries/calendars so they were visible to the relevant teams and stakeholders.

The missing calendars were caused by the Outlook desktop client hiding or dropping visibility of specific calendars (including shared/location calendars); calendar data remained intact and accessible via Outlook Web. In several cases the disappearance followed an Outlook desktop update and the calendar visibility was restored by re‑enabling or re‑adding the calendar in the desktop client. The fix was client‑side only: restoring the calendar in Outlook desktop returned access to the calendar and appointments without any server‑side data loss.

Support confirmed the M365 group had been deleted on the recorded date and that the deletion occurred outside the 30‑day restore/retention window, making the group and its calendar items unrecoverable via the Admin Center. Audit logs were reviewed and identified the user who performed the deletion.

Investigations ruled out account compromise and confirmed that the invites were legitimate but had been sent to a distribution/dynamic group address, which caused the appointment to propagate to all group members. Affected users were advised to delete the propagated meeting items; no further remediation was required.

A Microsoft-side calendar service outage caused failures to fetch calendar events from the AutoDV2/Exchange mailbox endpoint (manifesting as "CalendarEventsFetchFailed") and, in some instances, prevented Outlook desktop clients from opening or editing appointments while those items remained accessible in Outlook on the web. A separate server-side fix restored organization-wide free/busy (availability) lookups so attendee availability became visible again. An affected Outlook client on macOS had a Calendar error that was resolved after the client was rebooted, which restored free/busy visibility locally. During the Microsoft outage, users worked around the issue by using Outlook on the web or switching to the new Outlook client (Microsoft reported the new Outlook was not affected); at least one user resolved the problem by switching to the new Outlook. Support monitored the Microsoft incident and confirmed calendar access and event fetching were restored after Microsoft recovered the service; no additional local changes were required for the recovery.

Support staff first confirmed the target mailbox/group existed in the requester’s profile. Missing calendar permissions were resolved by granting calendar access in Microsoft 365/Exchange Online; in at least one instance an administrator ran a PowerShell script to modify calendar sharing/permissions and restore visibility. When mailbox rights were present but the modern Outlook Add Calendar UI would not complete the add, technicians completed the add by selecting the receiving account, searching for the target mailbox/calendar, then reselecting the receiving account to finish; switching back to the classic/old Outlook UI resolved cases where the modern interface failed to display added calendars. When invoking Add Calendar repeatedly crashed Outlook, technicians established a remote session and completed the add and diagnosis during that session (ticket notes did not capture detailed diagnostics). In one case a user added a Teams channel (Microsoft 365 group) calendar to their local Outlook without administrator changes.

Support confirmed the limitation: Exchange/Outlook mailboxes expose a single primary calendar and there is no built‑in capability to share only items from a specific start date or to create a second calendar explicitly tied to the same mailbox that would begin at a given date. The matter was handled by advising the user to coordinate with their manager about how to manage or separate sensitive historical items for privacy/data‑protection reasons.

The problem was resolved by using a Microsoft 365 Group calendar for the team so that events generated reminders for all group members. The team calendar was transitioned to an M365 Group-backed calendar which produced reminders for members instead of relying on a shared folder/calendar owned by a single user.

Initial student reports described scheduled Teams sessions that were accessible via the meeting link but did not appear in affected attendees' calendars; the student was advised and referred to the institution's student tech support for local troubleshooting and follow-up. Separately, IT requested a live Teams troubleshooting session to inspect an Outlook error seen when sending meeting invitations and to review the organizer's approval/permission settings and distribution method. No server-side calendar or Exchange configuration changes were made within these tickets; the investigation focused on message delivery between Teams and Outlook, potential approval/workflow blocking of invites, and the limitations of sending personal invitations to very large recipient lists. Ownership for further diagnostics and remediation was handed to the student support/administration team.

The user cleared browser history and cookies, restarted the laptop, and then successfully created the appointment using the Outlook app instead of the browser. The issue was closed after the appointment was booked from the desktop/mobile client.

Microsoft acknowledged a service-side issue affecting Outlook calendar entries and support advised using the workarounds documented on Microsoft's calendar entry support page. After applying Microsoft’s recommended mitigations, the user confirmed the problem was resolved.