Multiple distinct root causes were identified and resolved. Where the composer’s From control had been hidden by UI changes, restoring the compose/From setting in New Outlook or enabling Options → Show From in desktop/classic Outlook restored the sender dropdown and send‑as selection. Where a New Outlook build failed to retain the From control between messages, switching back to classic/older Outlook and enabling a persistent Show From control produced a lasting sender selector. Where the From dropdown contained a stale or obsolete entry (for example an old domain/alias after a mailbox change), removing the outdated cached entry from the From dropdown and selecting or adding the correct alias via the Other email address lookup allowed messages to be sent as the correct address and removed infrequent‑sender warnings. Where Outlook users could not set or use a specific mailbox address because of mailbox permissions, granting send‑as permission on the mailbox to the user restored the ability to select and send from that address. These resolutions applied to Exchange Online/Office 365 alias and shared‑mailbox scenarios in New Outlook and desktop/classic Outlook; Salesforce campaign‑send permissions were handled separately outside of Outlook.

Investigations identified multiple distinct causes for missing mail and unexpected automatic replies when Automatic Replies or routing were active. Client‑side Rules & Notifications in Outlook had forwarded or redirected messages (including rules configured to forward without keeping a copy); disabling or removing those rules restored mail to the mailbox. Some Outlook desktop Automatic Replies entries had an associated Automatic Replies rule that forwarded incoming mail; deleting the Automatic Replies rule stopped unintended forwarding. Separate Inbox rules were moving all incoming mail into user folders and producing an apparently empty Inbox; disabling or deleting those rules and moving mail back restored delivery. Mailbox‑level forwarding configured in Exchange/Microsoft 365 delivered mail outside the mailbox and produced non‑delivery reports when external destinations rejected forwarded messages; disabling or changing mailbox forwarding restored delivery to the mailbox. Duplicate Automatic Replies rules in desktop clients produced multiple auto‑replies; removing duplicate Automatic Replies rules and editing/saving the Automatic Replies text corrected incorrect contact information returned to senders. Where emails were routed to third‑party systems, investigations found the external system itself generated automated responses: incoming mail delivered to a Salesforce queue (Email‑to‑Case) produced a noreply‑style auto‑reply with unrelated content and an incorrect addressee even though the mailbox had no Automatic Replies configured; reconfiguring the external queue or autoresponder stopped those unexpected replies. Message traces, connector and routing inspection, and mailbox logs were used to confirm forwarding paths and to attribute whether an auto‑reply originated from the mailbox or an external service. Some cases involved user interface/display concerns rather than delivery failures: forwarded messages that showed localized recipient labels (for example 'Bis' instead of 'An') were attributed to delegation, delayed‑delivery or forwarding display effects and required no system change after confirmation. A few reports described Automatic Replies state persisting after a calendar absence entry was deleted or after the scheduled end time; those incidents were not resolved in‑ticket because support lacked mailbox‑level permissions and were escalated to the appropriate service portal or administrative team. Overall, affected cases were resolved by removing or correcting offending client or server rules, deleting Automatic Replies rules, correcting mailbox forwarding or reconfiguring external queues/autoresponders so automated responses matched the expected sender and content, and by restoring moved messages to the Inbox.

Access and functionality were restored after correcting the underlying account, license, mailbox, identity, client UI, browser, enrollment, or device state. Observed repairs and outcomes included:

After these corrections Outlook appeared in the Microsoft 365/Office apps list where applicable, accounts configured into Outlook/Teams/web/mobile regained visibility and access, Outlook features such as scheduling polls and Loop editing were restored, and related SSO and application errors ceased.

A broad set of Outlook desktop and web failures were resolved by addressing mailbox permissions and auto‑mount behavior, rebuilding or refreshing client identities and caches, isolating or removing add‑ins, switching client modes, and performing server‑side recoveries where required. Key consolidated remediations and observations included:

Collectively, these remediations restored folder and message visibility, repaired launch and synchronization failures (including incidents requiring Microsoft‑side service recovery), removed add‑in impacts on UI and mail submission, refreshed stale address book/autocomplete state, resolved rendering anomalies and Outbox/delivery issues (including duplicate sends caused by server caching), and eliminated extreme client slowness caused by oversized caches or defective hardware.

Support changed the New Outlook layout settings via Settings (gear) > Mail > Layout to switch between showing emails grouped by conversation or showing each message separately and to adjust the reading pane arrangement (Newest on top, Newest on bottom). When users reported that sorting seemed to order conversation groups (not individual messages) or that attachments were not visible on the expected message, support set the mailbox to Show each message separately so individual messages and their attachments were visible. The summary reflected behavior specific to New Outlook in Microsoft 365: conversation view treated threads as a single sortable unit and could change where attachments appeared in the message list or reading pane.

Support resolved OS-level association issues by resetting the Windows mailto: protocol handler to the correct mail client (for example, mailto back to Outlook) and by restoring the .msg file association to the expected Outlook application after an upgrade/revert to New Outlook. Investigations showed that some third‑party apps (for example, Oasis) used Process.Start to open .msg files and therefore launched whatever application Windows had registered for the .msg extension. Separately, myCampus compose actions were found to sometimes invoke Care’s internal messaging UI rather than emit mailto: links; messages sent via that internal interface remained internal to Care and did not produce external SMTP deliveries (confirmed by mail server logs). The Bulk‑Mail mailto script was found to occasionally build recipient lists that included stale addresses from prior course instances; support regenerated recipient lists from current enrolment data and adjusted the recipient‑generation logic so prior‑instance addresses were excluded.

Two common root causes accounted for the incorrect free/busy and booking-availability behavior. One cause was the mailbox having an incorrect mailbox time zone and/or working hours; correcting the mailbox time zone and working hours via Outlook on the web restored accurate free/busy availability (changes required a short propagation window). Support sometimes had to open Outlook through office.com/apps to access the web UI date/time/timezone controls when those controls were not immediately visible. A second cause was breakage of calendar sync after workstation, account or Outlook desktop profile changes: investigations targeted Bookings-to-mailbox calendar sync, the user’s Outlook desktop profile and Exchange free/busy service, and issues were resolved by rebuilding or repairing the Outlook desktop profile and re-establishing Bookings’ connection to the mailbox which restored calendar sync and availability.

Support verified the exact mailbox identity (correcting typos, non‑obvious service/svc addresses, and username mismatches caused by legacy employer domains) and checked account status, expiration, and licensing. When the self‑service reset flow failed or reset messages went to an inaccessible IU mailbox, support sent reset links or temporary passwords to the user’s alternate/private or Okta recovery email; when no 2FA was configured support issued manual password resets and resent expired links as needed. Okta MFA or an Okta account reset was completed where required and restored access. For external/deactivated addresses that produced repeated Outlook sign‑in prompts support reactivated the external account, performed a password reset and sign‑in so the Outlook profile could be changed, then temporarily switched the profile’s default account and removed or reconfigured the external entry. Mobile client sign‑in failures were resolved after credential recovery using these same procedures; when tenant or license limits prevented client access support noted webmail access (for example, https://mail.iu.org/). When mail flow between IU and legacy/external/service mailboxes was disrupted, support forwarded or redirected incoming messages to the user’s internal account to resume communications and restore dependent systems (for example, the Safe Portal); support also documented that external forwarding to non‑IU addresses was blocked. Restoring or extending an external/service account’s termination date required submitting the “Extend external Service Account / Verlängere externen Service Account” form via the IT Service Portal (Jira Service Management). Mailboxes owned by other teams (for example, student accounts on iu‑study.org) were referred to the responsible team (Study‑Support, techsupport@iu.org). External users were noted to be able to access the IT Service Portal via Okta to open tickets if needed.

Support confirmed the requested mailbox owner/responsible person and completed mailbox creation and access assignments. Newly created standalone mailboxes became available to designated users after directory propagation (observed from minutes up to a few days). When mailboxes or addresses did not appear in Outlook or Teams, short directory synchronization/propagation delays usually resolved visibility. One failure to find an address was traced to a Microsoft 365/Teams unified group with the same name that was hidden from Exchange clients (hiddenFromExchangeClientsEnabled); the group was mail‑enabled/unhidden and send‑as/access assignments were applied after inspecting and adjusting group properties with PowerShell so Outlook/Teams integration completed. Where an address needed to be used as a separate sending account (for example for Word mail‑merge), support converted a shared mailbox to a user mailbox and granted access to required users; existing forwarding and integrations (including Salesforce) were preserved or confirmed. When mailbox display names or the displayed/primary email were incorrect (for example a private address showing), administrators updated the mailbox/user account display name or primary SMTP address; changes required directory propagation and appeared across services after propagation. Account renames sometimes left the old address visible in Teams and other programs and could break New Outlook connectivity while Outlook Classic still worked; these symptoms resolved after directory/AD synchronization and, in one case, removal of an obsolete Wireless-CPG AD group membership which restored CPG-Corp Wi‑Fi authentication after ~5 minutes of AD sync. For role or team changes, support also granted mailbox access and any required OTRS ticket-queue permissions so the user could access queues tied to the mailbox.

Support identified that the organisation's forwarding consent policy prevented automatic forwarding to another address unless written consent from the mailbox owner and a specific destination address were provided; cases were held pending until those details were supplied. In situations where forwarding could not be enabled (policy block or unsupported account types), support instead configured the user’s mail client to access both mailboxes from a single Outlook profile by adding the secondary account into Outlook; the configuration steps were provided and implemented so the user could view both inboxes without relying on forwarding.

The issue was resolved for the recorded case by subscribing to the iCal/ICS URL from Outlook Desktop: the calendar was added using Outlook Desktop's Calendar view via Add Calendar → From Internet, pasting the ICS/iCal URL and confirming; the calendar then appeared in the user's Outlook calendar list. The ticket corpus did not contain documented resolution steps for subscribing from Outlook on the web or mobile, nor for automatically converting imported schedule items into busy/full-day blocks; a related request about automatic blocking and BookWithMe integration was closed with no technical details recorded.

Affected users were reverted from the New Outlook build to the legacy/classic Outlook client by disabling the Newest Outlook toggle; returning to classic Outlook removed the recurring 'Restart recommended' memory warning and restored usable performance. Where switching clients was not possible, the Outlook Web App (https://outlook.office.com/) was used as a temporary alternative. In at least one incident, creating a new Outlook profile resolved a persistent 'no available memory' error when closing/restarting Outlook and rebooting did not help; mailbox quotas in that case showed ample free space, indicating the issue was not storage-related. Several reports described New Outlook becoming unresponsive and, in some cases, not terminable via Task Manager requiring a full system restart. The behaviour was identified as a known defect in the then-current New Outlook build and a Microsoft fix was awaited; support occasionally retried the New Outlook toggle to confirm when the build was corrected.

The missing Auto‑Complete entry was restored after sending an email to the address (for example replying to an older message from that contact). The address re‑appeared in the Auto‑Complete list within about 24 hours after an outbound message to that recipient.

Access and visibility problems were resolved across three recurring scenarios. For calendars owned by a Microsoft 365 Group/Team or configured as shared resources, support updated the calendar's sharing permissions, granted specific people (or Everyone) view or edit rights, and created/sent sharing links or invitations when the Outlook client supported that flow. For personal/owner-only calendars and orphaned events (including undeletable recurring series created by departed staff), IT could not directly grant access; these incidents were resolved when the calendar owner or team owner added the requester as a delegate or removed the orphaned series, or when the calendar was converted to a shared Group resource and sharing rights were then applied and invitations sent. For missing Bookings appointments and related visibility issues, support verified user permissions and Azure AD group membership and added missing users to the appropriate groups; unexplained tenant-level synchronization or visibility problems were escalated to Microsoft (PSR opened) and resolved after Microsoft investigated and remediated tenant-side issues. Separately, cases where delegates did not receive meeting acceptance/decline notifications were traced to mailbox-owner Outlook settings or differing client UI that prevented enabling the option to deliver meeting-related messages to delegates; support documented and advised owner-side changes (including adding the delegate and enabling the relevant meeting-message copy settings) and recorded these attempted steps when changes had to be made by the mailbox owner, with no resolution confirmed in one ticket when owner-side action remained outstanding. Each incident concluded with either updated sharing/delegate permissions and sent invitations/sharing links, the owner adding the requester with appropriate rights (or removing orphaned items), the user being added to the correct Azure AD group, or Microsoft remediation after PSR escalation.

Aggregate response‑time reporting was produced by exporting mailbox message metadata that included Exchange/Graph conversationId values and message timestamps, then joining incoming and outbound items on conversationId to compute response‑time windows and trends. Message metadata extracts were performed via Microsoft Graph API (or PowerShell calling Graph), with exports automated by Power Automate or scripted jobs and stored as datasets in OneDrive/SharePoint; Power BI consumed the joined dataset to produce aggregate metrics and time‑series reports. For mailbox‑level activity and cleanup requests, the address list was extracted and mailbox statuses were checked in the Outlook/Exchange admin interfaces; mailbox audit sources (MessageTrace, unified audit logs or the Graph audit endpoints) were queried to obtain the last inbound and last outbound message timestamps. Those mailbox‑level results were exported to Excel for reconciliation alongside the dataset reports. This approach removed reliance on subject lines for conversation aggregation and provided per‑mailbox last‑activity data for administrative cleanup.

The issue was reproduced as an interaction between Outlook for Windows and OneDrive rather than an account compromise or phishing link. When senders uploaded files via the Outlook 'Upload to OneDrive' flow, Outlook created OneDrive share links and an intermittent German-language step-up auth popup redirected to outlook.office.com/owa/stepupauth.aspx and opened a blank page; this behavior was limited to the Outlook desktop client on Windows. Sending the same files as traditional attachments avoided the problem: attaching the file by dragging it into the right side of the Outlook compose window caused Outlook to include the file as a standard attachment (for example, a normal PDF attachment) instead of generating a OneDrive share link. The popup/redirect behavior was classified as an Outlook for Windows desktop client bug and was not observed in OWA or on macOS.

Support identified the attachment as a .dat data export rather than a general document and concluded it was a file‑format issue rather than a mailbox permission problem. The .dat content was converted into a text‑based format that the user could open and review, and the converted file was provided to the requester.

Delivery and send failures were resolved by correcting recipient records and upstream integration state, repairing mailbox/server/licensing problems, removing forwarding or deactivated sender states, releasing or permitting quarantined/sender identities, and removing senders/IPs from external blocklists. Notable outcomes and actions included: • Upstream profile and contact records (for example CARE, EPOS, MyCampus and Oppy/MS Oppy on VuV) were updated to the current internal addresses, which restored password‑resets, GEP login and other automated deliveries. • Where support lacked direct permissions to change profile records (for example Oppy/VuV), the update was completed via the SalesTech Service Portal. • Forced integration refreshes (for example Oasis→MYlibf) restored portal password‑reset and confirmation messages. • An Outlook bulk send stuck in Drafts cleared after removal of an ex‑matriculated recipient record containing an external address, allowing the message to be resent. • A send failing with “550 5.4.1 Access Denied” was resolved after correcting mailbox/mail‑server state and re‑setting up the Outlook client. • A transient Microsoft 365 licensing outage produced rejections until licenses were restored. • Removal/reactivation of Salesforce automations and mailbox forwarding restored expected deliveries when forwarding or deactivated senders were implicated. • Marketing Cloud “Blocked Bounce” reports were reconciled with Exchange/anti‑spam and quarantine logs and external blocklist checks; releasing quarantined messages, permitting the sending domain/IP through Exchange allowances, and removal from blocklists restored delivery. • Migration of Qualtrics SMTP to AWS SES had blocked invitations when sending was restricted to @iu.org; delivery resumed after permitting the Qualtrics SMTP identity through Exchange transport allowances and aligning the sender identity. • SRS/forwarding encoded bounces were investigated by correlating forwarded/SRS‑encoded addresses with student/contact records and forwarding logs; where forwarding or SRS addresses were active they were corrected or removed, or specialist teams were engaged to remediate the upstream forwarding state. • A global scan‑to‑email incident that produced severe delays or losses was resolved after a backend/service‑side fix deployed on 2025‑08‑04. Investigations and reconciliations routinely used LetterWriter and emailprocess logs, postmaster bounces (including SRS‑encoded addresses), Exchange quarantine and anti‑spam logs, transport/mailflow/transport‑rule reviews, external blocklist checks, and checks of recipients’ Junk/Spam folders and Outlook client behavior. When recipient‑side configuration or downstream filtering caused delivery failure, support engaged recipient/domain contacts to confirm mailbox existence, MX/SMTP acceptance and anti‑spam settings.

Support used multiple approaches depending on the feature gap and delivery scope. For editing a received message in New Outlook, support opened the message in its own window and used the built‑in Edit Message action (Move → Actions → Edit Message); attachments were removed via the ribbon and the message was saved, which modified the existing mailbox item rather than producing a .msg file on disk. For mistaken sends where recall was required, support installed and ran the older/classic Outlook client and used its 'Recall This Message' feature against Exchange/Exchange Online; recall succeeded only under the standard Exchange constraints (for example, intra-organization scope and recipient unread status). When messages had been delivered to external or other-account mailboxes and recall was unavailable or had failed, support identified the item in the recipient mailbox and performed a hard delete of the item from that mailbox, then confirmed deletion completed. Separately, Microsoft confirmed that New Outlook did not provide the capability to manage color categories on shared mailboxes and that this capability could not be enabled by IT; where category management was required, support relied on classic/older Outlook (or a client that exposed the shared-category controls) to make the changes.

Issues were resolved by administrators creating or updating Exchange/Outlook automatic-reply entries and by taking actions on mailbox forwarding and deactivated accounts. Administrators set internal and external reply text (including bilingual messages when requested), added alternate contact addresses when provided, and applied date-range/expiry values. For cases where deactivated mailboxes or forwarding produced stale ticketing-system replies, administrators cleared or replaced the original mailbox auto-responder and, where appropriate, disabled mailbox forwarding at the source; they also verified the deactivation state and the active/deactivated Automatic Replies status for the accounts. Support noted that absence/status visibility in client UIs (Outlook/OWA, Teams, Salesforce) could lag after Exchange changes. When mailbox owners were available, support guided them on enabling Automatic Replies in Outlook Web App or Outlook, and when delegation was involved support adjusted or advised on delegation settings so the correct absence message was applied.

Authentication problems were resolved when the user's Microsoft/Okta identity and the client account state were restored to a single, consistent supported state. Observed successful resolutions included: resetting the user's Okta or Microsoft 365 password, which restored mailbox access and stopped repeated Outlook/IMAP prompts; forcing MFA enrollment or registering missing factors (for example assigning Okta‑MFA group membership and configuring Okta Verify), which restored Outlook search and SharePoint/OneDrive access; re‑registering hardware security keys or biometric factors after YubiKey/Windows Hello/Touch ID failures; separating simultaneous Microsoft account sessions by using different browsers, browser profiles, or private windows to remove session conflicts that produced persistent refresh/loop states; removing and re‑adding problematic accounts in the desktop client or adding the primary account during a remote support session when the client rejected sign‑in with messages such as 'You can't sign in here with a work or school account. Use your personal account instead.'; switching from native iPhone Mail to Outlook for iOS (which used M365 SSO) to stop repeated IMAP prompts; simple device restarts for transient sign‑in loops; using Outlook Web or web Teams as temporary access while desktop sign‑in issues persisted; addressing browser‑specific Deskbird/Firefox interactions by using Edge/Chrome or the desktop client; and device remediation such as Intune re‑enrollment or a full device fresh start after Outlook installation or activation failures. Client logs frequently lacked detailed error information; desktop error code 135011 and web/mobile 'Detected repeated redirects' were observed in some failures. Some Outlook for Mac sign‑ins timed out with 'The sign‑in took too long' while Office.com web SSO still succeeded, and in those cases support sometimes left the record closed when web access met the user's needs. A number of incidents were recorded as restored with no documented remediation (for example after account transitions or backend propagation), indicating that account/identity propagation could resolve certain cases without local changes.

Support documented Exchange Online platform sending defaults and described what resolved each incident. Platform-default limits were stated as 500 recipients per message, roughly 5,000 recipients per day, and an estimated send rate around 30 messages per minute; the 500-per-message cap was identified as a platform limit that generally could not be raised and prior attempts to increase it had triggered anti-spam throttling and delivery failures. For large or frequently changing audiences support implemented and validated alternatives: mail-enabled distribution groups (including dynamic groups maintained in Azure AD/Entra and synced from systems such as Salesforce or Okta); Microsoft 365 groups with mail functionality — either dynamic M365 groups when members were identifiable by AD attributes or manually-managed M365 groups populated with a bulk-add tool (an internal app was used successfully to add >100 members). Other successful mitigations included splitting large recipient lists across multiple messages and using dedicated mass-mailing/broadcast services (e.g., Mailchimp/CleverReach) when identity control and scale were required; Word mail-merge was noted to be unsuitable for some B2B mass mailings because it attached the private reference/account of the logged-in user. In security-triggered incidents where tenant administrators temporarily reduced outbound recipient limits (an example lowered the cap to 25 after a phishing event), support resolved delivery failures and bounce messages (including 'sending email address was not recognized as a valid sender') by reverting the tenant-level change and restoring normal outbound sending; in one case a client restart was advised after the tenant change was reverted and sending resumed.

The resource mailbox SMTP address was renamed on the requested date from BRH2-EF-IU712@iu.org to BRH2-EF-IU311@iu.org. Existing bookings remained intact after the rename and the mailbox/address change was visible in Outlook; the user verified the result.

IT determined the sign‑in failure was caused by the device and New Outlook instance being managed by the user's institutional Microsoft account and by an applied group policy that blocked Microsoft account sign‑ins (manifesting as the error "This program was blocked by a group policy" and code 0x800704ec). As a result, adding a secondary/personal Microsoft (@live) account to New Outlook on the managed device was not possible; no in‑ticket remediation was applied. Importing third‑party calendars via iCal (for example GMX) had succeeded despite the policy, and users reported UI differences when attempting the operation in New Outlook versus legacy Outlook.

Forwarding for affected organizational/shared mailboxes had been applied at the mailbox level in Outlook, replacing legacy Freshdesk SMTP targets with the designated Salesforce case (case.salesforce.com) addresses. Typographical errors in target addresses were corrected and mailbox email IDs were updated where mailboxes had been renamed so verification messages would be delivered to the current address. Mailbox owners completed the Salesforce verification emails (two per mailbox: address add and address mapping) when available; where verification links had expired, support completed the mailbox verification in the backend. Mailbox-level settings were saved and allowed to propagate; after propagation incoming messages were delivered to the Salesforce case addresses.

Access was restored after the Company Portal Self Service Tool (IU-DE-AAD-ASS-INTUNE-IT-EPM_Self-ServiceTools) was installed from the Company Portal. Installing that app via the Company Portal resolved the Error 1001 sign‑in failure and returned Teams, Outlook and account access to normal.

Investigated raw MIME of the offending templates and found the HTML part and embedded image handling were malformed (truncated tags and incorrect multipart structure). The template generator was corrected so messages used a proper multipart/related / multipart/alternative structure and image references were delivered as valid Content-ID (cid) parts or well-formed external URLs instead of broken inline Base64 in the HTML part. After regenerating the templates and sending test messages, Outlook and other clients rendered the images normally.

Technician rebuilt the problematic signature in the Outlook client. The user opened Outlook's Signatures editor, made a trivial edit and switched signatures to trigger the save prompt; confirming saved changes forced Outlook to regenerate the local signature data and cleared the repeated pop-up. The issue was attributed to the embedded logo asset in the signature and was resolved after re-saving the signature.

Observed failures were resolved by aligning integration authentication and mailbox delivery models with Microsoft 365 group and calendar behaviors and, where necessary, informing customers of SaaS routing limitations. Resolution patterns included: 1) Delivery and sender‑permission issues: when third‑party services required a standard mailbox to authenticate or were blocked by Teams/Microsoft 365 Group send restrictions, a dedicated user/service mailbox was provisioned for the integration to authenticate and send/receive; messages were forwarded or shared from that mailbox into the Microsoft 365 Group mailbox when group delivery was required, and administrators granted specific sending addresses permission to send to the target group to restore delivery. 2) Integration and authentication failures: for integrations that relied on Azure AD enterprise applications, tenant administrators approved/whitelisted the enterprise app and granted affected users permission to add the Outlook add‑in; specialists then completed the mailbox‑to‑app connection and configured scheduling so booked events generated Teams meeting invites. Separately, a widespread Calendly–Outlook outage was traced to a Microsoft authentication service disruption; after Microsoft restored authentication and affected accounts re‑authenticated, users were able to reconnect their Outlook calendars and calendar availability returned. 3) CRM queue ingestion limitations: investigation confirmed at least one Salesforce configuration routed an Office mailbox into a Salesforce Queue so incoming replies did not surface in users’ Outlook inboxes; because the SaaS routing behavior could not be changed, the customer was informed of this limitation. 4) Exchange connectivity failures: in one case the Salesforce App for Outlook reported an Exchange connection error (“Something happened when we tried to connect to the Exchange server” with the details link blank); restoring Exchange connectivity cleared the error and allowed Salesforce logging from Outlook to succeed.

Root cause analysis identified two distinct patterns found in the ticket set. In the first, Microsoft confirmed Delivery Management policy membership validation against a very large Dynamic Distribution List (IUG-IU-Students-All, ~184k members) caused long group resolver (CATRESLPR) lookups and delivery delays of ~20+ minutes; remediation changed the delivery/validation configuration so the group resolver no longer performed expensive lookups against that large DDL (for example by removing or excluding the DDL from the policy or using a differently scoped group), after which meetings and calendar items returned to normal timing. In other incidents, tickets reported longer visibility delays (around 1–2 hours) that began after a Teams version rollout and were reproducible only for some Course Feed teams; Microsoft support indicated automatic Teams creation via the PA Flow as a likely correlate in those cases. Those PA Flow–related incidents showed no error codes in the tenant logs and did not record the same DDL-related remediation, so the PA Flow/team-creation path was identified as a separate avenue for investigation when DDL lookup latency was not present.

Support reviewed the directory and GAL attribute constraints and confirmed the job‑title attribute only accepted a single line and was character‑capped. The user was informed of the limitation and advised that only one full title (or a shortened/combined title within the character limit) could be stored and displayed in the Outlook/GAL profile. The user accepted the restriction and no further changes were made.

Issues were resolved by ensuring end‑to‑end presence and registration of the required S/MIME certificates and address‑book entries. Where users lacked a personal S/MIME certificate, Cloud Operations issued the certificate, an enrollment appointment installed the certificate on the Windows 10/11 device and bound it to the user’s Outlook profile, and S/MIME/encrypted‑mail sending was then verified; users were briefed on certificate usage. Where sending to an external organisation failed, the recipient organisation’s current S/MIME certificates were obtained and imported/registered into affected users’ certificate stores or accounts; after importing or updating those recipient certificates, encrypted messages to that organisation succeeded. In at least one case the inability to encrypt was caused by a missing Outlook address book required for the recipient (the openkeys address book); deploying the openkeys address book to Outlook and importing the recipient (Arbeitsagentur) certificate into it restored encrypted‑mail capability. All changes were recorded and verified following the organisation’s S/MIME/Outlook guidance.

The user installed the Microsoft Outlook mobile app and signed in with their IU credentials; Outlook automatically provisioned the account without requiring manual incoming/outgoing hostnames. The ticket was closed after the user confirmed the account was added and no further questions were raised.

Support explained that the corporate takeover of the @iu.org address prevented it from being used as an Apple ID and that the address could not be released back to the user. The user was instructed to create or use a different Apple ID (for example a personal @icloud.com or another non‑IU address) so the device could sign into Apple services and restore mail/calendar access.

IT investigated and confirmed the invitations were generated by internal IT changes rather than a security incident. Users were informed that the messages were benign and that no action was required; the ticket was closed after communicating the origin and reassuring affected staff.

The issue resolved itself without administrative intervention and Outlook returned to the expected German locale. Prior user attempts to change language options, synchronize Microsoft 365 settings, and clear browser data had not prevented the transient language switch; no further action was required after the self‑resolution.

It was noted that a recall attempt was unlikely to succeed in this scenario because the message had been sent externally and had sufficient time to be delivered and potentially read. The ticket recorded that recall success was doubtful given those conditions and advised accordingly; no successful remote removal of the message was achieved.

Investigations documented intermittent and inconsistent taskbar mail-badge/unread-count behaviour in New Outlook for Windows. In several cases the issue was traced to the taskbar shortcut referencing the wrong Outlook instance; replacing the taskbar entry with the active New Outlook application corrected the unread-email indicator for those users. Other reports showed the badge would temporarily refresh after launching Outlook but did not produce a consistent fix; those occurrences were recorded for further investigation. The same ticket also included a separate PowerPoint/ThinkCell error that was identified as a known Microsoft issue and not caused by ThinkCell.

The failures were traced to Exchange Online/tenant policies rejecting legacy/basic SMTP authentication or enforcing TLS/OAuth2 requirements. In reported cases the incidents were resolved when administrators provided a supported, centrally managed authentication path: they registered an Azure AD application, granted Mail.Send application permissions with admin consent, and the sending code was changed to use OAuth2 (client‑credentials via MSAL to obtain an access token and then send mail through Microsoft Graph or SMTP XOAUTH2). As alternatives that were accepted in affected environments, administrators enabled SMTP AUTH for the mailbox or created an Exchange Online SMTP relay/connector dedicated to application/service traffic so the automation could submit mail without using a personal mailbox. For environments where the automation could not be updated to use OAuth2 (for example the n8n Send Email node in a self‑hosted instance), teams also used an internal SMTP relay/service (AWS SES or similar) as a permitted outbound SMTP path. Reported diagnostic symptoms included 'credentials are incorrect' after STARTTLS, '451 5.7.3 STARTTLS is required', and authentication failures where MFA and app‑password policies prevented legacy client logins.

Support used Outlook's Block-sender feature on an email from the student and then muted the user's chat in Microsoft Teams. Blocking the sender in Outlook also prevented the sender in Teams in this case, and muting the chat via the Teams chat options silenced subsequent messages and calls. After those actions the reporter and colleagues stopped receiving further harassment.

Support confirmed the translation capability in Outlook was a client/user‑side built‑in feature (separate from Microsoft 365 Copilot) and was available to all users. There was no configuration exposed to end users or tenant admins to control translation style, tone, formality (e.g., 'du' vs 'Sie'), or gendering; the translator produced the standard formal German by default. The outcome communicated to the requestor was that there was no admin or client setting to force an informal translation style, so any change required providing manually‑localized text or using a separate translation workflow outside the built‑in Outlook translator.

Investigation traced notification floods to automation/alert sources rather than mail delivery faults. In cases originating from SharePoint document libraries or Power Automate flows, the spike was resolved after the library alerts or flows were removed, narrowed in scope, or had their frequency reduced, and the affected mailbox was unsubscribed from the alert stream; message volume returned to normal after the alerts/flows were disabled or adjusted. In cases where emails were generated by an external system (for example the LCC/Jira Service Management service in one ticket), support routed the issue to the owning application team because the sending system needed configuration changes or to be stopped at source; no SMTP/delivery error codes were present. Client‑side measures such as moving messages to Spam were observed to be only a local/temporary mitigation and did not stop the originating automation from continuing to issue notifications.

The group's ownership was reassigned by adding the requested user (Jennifer Teudt) as a group owner. After Jennifer was added as an owner, she could manage membership and update the group's settings, resolving the access/management issue.

The flow was changed to allow concurrent runs by enabling Concurrency Control (parallelism) on the run/apply-to-each scope so multiple instances could send 'Email with options' messages in parallel instead of waiting for an earlier run's response. After enabling the concurrency control, the flow sent messages to all intended recipients reliably.

Investigation verified that the reported sender domain (info.iu.org) was owned by the organization and that the specific sender addresses were legitimate addresses under that domain. The explanation provided was that Outlook flagged the messages as 'from outside the organization' because the recipient mailboxes belonged to a different organizational domain (iu-study.org), so the visual external indicator appeared despite the sender being an internal, valid address.

Support could not reproduce a working state. In‑ticket troubleshooting included forcing an update of New Outlook, clearing the app local state (ClearLocalState), and a full reinstall of the client; none of these actions restored pop-up meeting reminders or fixed the Settings → Notifications toggle or the black rendering. The problem persisted in the Monarch preview and remained unresolved in the ticket, consistent with a product/preview bug requiring Microsoft engineering attention.

The request was not implemented (ticket closed as "Won't Do"). Support documented a client‑side mitigation: reducing Outlook Cached Exchange Mode retention (shortening "download mail for the last X months") to lower local mailbox storage. No server‑side quota change or provisioning was performed.

Support joined the user via Microsoft Teams and used a remote control session (TeamViewer) to create and save an Outlook forwarding rule on the user's account. Test messages were sent and forwarding was verified as working. No elevated permissions were required in this case; the problem was resolved by creating the rule interactively during the support session.

The request was recorded as a procurement/architecture item rather than an immediate technical change. Stakeholders documented functional needs (support for ~4,600 accounts and group‑based membership), security concerns about vendor routing (CodeTwo/Exclaimer), and legal requirements (DPA/AVV review). Preference for a client‑side (Outlook) mode to avoid external mail routing was noted and vendor options were identified for formal evaluation and procurement, with DPA and operational ownership to be resolved before rollout.

Support confirmed the signatures were present and rendered in New Outlook while the legacy Outlook client did not show them. Troubleshooting steps included restarting the client and the workstation and an investigative review of signature state in the client; support advised re-creating or re-adding signatures in legacy Outlook and checking the local signature storage (user profile AppData\Roaming\Microsoft\Signatures) as part of remediation. There was no single confirmed root cause or final fix recorded in the ticket.

Support had the user sign in at Office.com with their IU credentials and opened Outlook and Teams from the Office app launcher in the browser to confirm where mail and apps appeared. Agents verified mailbox access and the presence of password‑reset or delivery messages by showing the message inside Outlook on the web. For teaching‑platform issues, agents demonstrated the IU teaching‑platform landing area where 'My courses', assignments and the student/teaching group or level are displayed so the user could consistently access those pages after signing in. When users reported inability to access email without visible error messages, support examined login records/logs, confirmed successful authentication and mailbox access, and then communicated that confirmation to the user before closing the ticket.

No confirmed fix was recorded in the ticket. Support recommended verifying the user's Planner notification settings to ensure Planner email notifications were enabled and confirming the user was actually assigned to the task. The ticket thread reiterated that mentioning/tagging someone inside a Planner comment does not reliably generate an email notification by design, and assignment-based notifications were the intended trigger discussed.