Client reinitialization and reinstall actions restored connectivity and UI integration in the recorded cases. macOS: Running the OneDrive reset script (resetonedriveapp.command) restored the menu‑bar icon and resumed sync in multiple incidents; when reset alone did not restore Finder integration, removing duplicate App Store copies and installing the single corporate/distributed OneDrive build or reinstalling the supported client recovered the menu bar, folder selection and Finder overlays. Windows: Signing in again from the system tray or launching OneDrive (including via Windows Search) re‑established the client and returned File Explorer access in several cases; reinstalling or manually installing the OneDrive client fixed missing icons and cases where launching OneDrive produced no sign‑in prompt. Applying outstanding Windows updates and rebooting resolved a blue‑cloud/security error in some incidents. Authentication/account reinitialization: Unlinking a wrongly connected personal account and reconnecting the correct work account, password resets and OKTA MFA reconfiguration, or signing out and signing back in reinitialized clients that appeared stuck or consuming local storage. Sync stalls and blocked files: A single blocked or problematic file was observed to block synchronization — removing the file (locally and/or from the cloud) cleared the stall. Duplicate/dual cloud icons (multiple client instances or partial relink states) were resolved by signing out and signing back in or by reinstalling/relinking the client. SharePoint / mapped drives (S:): tickets documented cases where the OneDrive 'Sync' action appeared to succeed intermittently but did not persist for mapped SharePoint drives; no technical resolution was recorded for that specific ticket, though similar cases were handled by re‑establishing the sync/mapping relationship or reinitializing the client. Remote and tool‑based recovery: Support used remote tools (TeamViewer) or the EPM Admin Tool to perform OneDrive resets, reinstallations and folder reselections; these actions restored sync in several cases. Workarounds and data preservation: When desktop sync or File Explorer/Finder integration was unavailable, users accessed or uploaded files via the OneDrive web portal to preserve data. Device replacement: For persistent, device‑specific failures a replacement device was supplied in some incidents. Notes: Some incidents were intermittent and self‑resolved; other cases were traced to conflicting macOS builds (App Store vs corporate), incorrect account linkage, or single blocked files preventing global sync.

Recoveries in these incidents relied on local and cloud sources and, where available, third‑party backups. Items were restored from the local Desktop/Windows Recycle Bin or from the OneDrive/SharePoint web Recycle Bin, including the second‑stage (site collection) bin; web access via office.com (or intranet/Okta) was used to reach those bins. When a OneDrive client had been unlinked or a previous device was mid‑sync, re‑establishing the client link or allowing the prior device to finish synchronization repopulated files and restored green sync checks in several cases. Specialist restores and third‑party backups (for example, AvePoint) provided earlier versions when recycle bins lacked needed data. Migration‑related losses were frequently irreversible when the source workstation had been wiped or returned: files moved from external drives by drag‑and‑drop during migration sometimes produced absent items on the target, and local recovery tools (Recuva, Wondershare Recoverit) returned largely corrupted or unreadable files. One case of a sync failure that reported a “blocked” drive was resolved after verifying the Windows 11 system had local storage and that standard user folders existed locally and were able to sync. Observed but unresolved symptoms included a top‑level folder that retained an old local name despite a SharePoint/Workspace rename while its subfolders and documents remained accessible, and a Word document that vanished after AutoSave stopped and showed a file error (“Dateifehler”) with no recoverable copy in local or web recycle bins. Across incidents, successful recovery depended on retained cloud/SharePoint versions or backups, entries in local or web recycle bins, or a powered‑on previous device able to complete sync; when those sources were absent recovery of the most recent local versions was often not possible.

Support connected to the affected machine (TeamViewer) and resolved the error by creating a new folder in the active employee’s OneDrive and copying the contents from the old shared folder into the new owner-controlled folder. After ownership and storage location were changed to an active account, the insufficient-storage sync errors ceased and OneDrive resumed normal synchronization.

Support obtained the direct link and confirmed the MP4 recording resided in the meeting organizer’s personal OneDrive rather than the centralized Recordings/SharePoint location. When the organizer account remained active, the organizer located and moved the file into the central/shared SharePoint/Teams Recordings location, after which participants with appropriate permissions could access the recording and transcript. For recordings owned by deactivated or former employees, access was restricted and support did not directly recover or change ownership without explicit privacy/legal approval; the team followed the organisation’s privacy procedure (contacting the designated data‑protection address) to request approval and a business justification before attempting access or transfer. Personal OneDrives were documented as having limited retention after license removal (commonly around 30 days) and not always being included in standard backups; where a third‑party backup solution (AvePoint) existed, recovery from backup was considered but was not always performed. Tickets also recorded that some users could view files but were prevented from downloading or re‑sharing because the file remained in the owner’s personal OneDrive with restrictive sharing settings; support could not elevate permissions or change sharing controls without the owner or approved admin access. Several cases closed without a fix when the owner was unavailable and data‑protection approval to access the personal OneDrive was not granted.

Cases were traced to two main root causes: Windows path/filename length limits (practical Explorer path failures observed near ~256 characters, with trailing whitespace and special characters increasing encoded path length) and broken or desynced OneDrive/Teams shortcuts combined with a misbehaving sync client. Affected items remained accessible from the OneDrive web UI while local open/sync failed. Problems were resolved by shortening or renaming files and folders, removing trailing whitespace, and reducing nesting depth so path lengths fell below the practical Explorer limit; problematic items were moved out of OneDrive or renamed rather than deleting the local OneDrive folder so the client could re-sync and restore workspace folders. For sync clients that stalled or reported incorrect progress, support re-established the PC connection by unlinking the account and signing back in (re-linking); in several cases reinstalling the OneDrive client had no effect until the account was re-linked. Quitting/closing the OneDrive client was observed to remove the OneDrive folder/icon from Explorer in one case and required restarting/re-linking the client to restore Explorer access. Broken Team-created or other shortcuts were removed from File Explorer and recreated from Teams using Add shortcut to OneDrive, which cleared error icons; when hundreds or thousands of shortcuts were affected, re-linking or resetting the sync client restored navigation behavior more practically than individually recreating shortcuts. Files edited on mobile devices or opened from transient folders were recovered from the OneDrive web UI or moved to a local folder (for example PDFs opened from Downloads became editable locally), which restored edit capability. A Windows 11 laptop migration and a Dell/Lenovo hybrid dock combination coincided with client instability in one case, indicating some hardware/driver combinations correlated with these symptoms, and users who worked directly in SharePoint occasionally did not experience the same failures.

Access problems were resolved by restoring a single, correct authentication/account context for the affected access path. When missing or expired Okta SSO sessions were the cause, access returned after users re‑established a proper Okta session (commonly by launching Microsoft 365 from the institution’s Okta portal) and completed Okta verification/MFA. Desktop Office cases that opened read‑only or forced “save a copy” were resolved after signing the Office apps into the institution’s organizational account and reopening the files; restoring the correct Office account also returned sharing and edit permissions. Incidents traced to multiple conflicting Microsoft/OneDrive accounts on a device were attributed to cross‑account authentication conflicts; resolving these required consolidating device/app sign‑ins (removing or unsyncing extraneous OneDrive instances and ensuring apps used the organizational account), after which authorization, sharing, and Teams/Outlook integration recovered. Mobile iPad/iOS cases manifested as missing institutional content, app screens showing only initials instead of the user photo, “this content is protected” messages, or web sign‑in failures like “Anmelden nicht möglich.” In several iPad cases access returned after users signed out and back into the OneDrive/Microsoft account or re‑established Okta SSO; one user reported a restart coinciding with resolution though recorded steps were incomplete. A subset of failures involving embedded file‑pickers or persistent mobile sign‑in errors required specialist team intervention or escalation rather than local client actions. Throughout, successful recovery correlated with restoring a single correct organizational authentication context and removing conflicting or external account sessions.

Microsoft had purged former users’ OneDrive and mailbox content according to the tenant’s retention/cleanup policy (commonly after about a year of inactivity), and once Microsoft completed that purge reactivating the account or resetting the password did not restore files. Microsoft’s automated messages that a deleted user’s OneDrive “will be preserved for 30 days” and temporary-owner assignment emails were observed around AD deletions; those notifications reflected a short preservation window and did not extend or override the tenant’s configured retention rules. If a temporary owner had been assigned before or at deletion, that delegate had access during the preservation window, but data removed after the retention/cleanup interval was permanently unrecoverable from the tenant. Separately, some requests were denied on policy grounds: a data-protection/privacy review determined access must be refused even when files appeared present on a former user’s local device or when no specific error codes were available. In summary, incidents resolved either because Microsoft’s retention/cleanup had permanently purged the data (no recovery possible) or because institutional data-protection decisions prevented granting access despite the records’ existence.

Incidents traced to two broad causes: recipient identity mismatches and insufficient/changed access grants. In affected cases, files stored on another user’s personal OneDrive became accessible only after the owning account re-granted permissions to the exact recipient identity; administrator accounts could not be used to bypass owner controls because personal OneDrive content was restricted. Several incidents were specifically caused by removal of a group/role membership that had previously granted access; restoring or reapplying the correct membership/permission or having the owner re-share resolved those cases. Attempts to move or delete files uploaded by others were resolved by making the files available offline or syncing them into the recipient’s own OneDrive and then moving them; support declined admin-elevation requests to override owner controls. Excel automations and scripts that failed for some recipients returned to normal after the workbook owner set ownership or sufficient edit rights. Folder-level management operations (rename/move/delete) in Teams/SharePoint failed when users lacked team-owner level rights and were resolved after owners elevated the user or adjusted team-level permissions. Permission-request emails and dialogs sometimes arrived blank or omitted the owner; when that occurred support supplied lists of owning users from the library/site or advised contacting the owning account directly. Affected components included OneDrive for Business personal sites (desktop-synced folders), SharePoint Online (Teams document storage), Microsoft Teams, OneDrive sync in File Explorer, Excel automations, and identity provisioning/SSO flows.

Resolutions depended on the root cause identified in each incident. On newly provisioned Windows 11 devices where AutoSave created duplicate top-level copies and Explorer-opened files had AutoSave disabled, enabling the tenant Intune policy 'Coauthor and share in Office' normalized AutoSave and co-authoring behavior and removed the duplicate-file symptom in the reported cases; opening files via SharePoint/OneDrive links or via Teams (using "Open in Desktop App") had been used as a temporary workaround prior to the policy change. In cases where AutoSave targeted the wrong account (files saved to a personal OneDrive because the SharePoint/tenant account was not selectable), the same policy change or opening files from cloud-native links restored the correct Save target in the incidents reported. Where users experienced intermittent AutoSave, missing latest versions, Word unexpectedly toggling Track Changes, or visible duplicate OneDrive instances/profile corruption, a full OneDrive reinstall and consolidation/removal of duplicate OneDrive instances resolved the sync and profile symptoms after user data was backed up (OneDrive was reinstalled in the documented case). Where multiple editors experienced conflicts, overwrites or edit delays for files accessed via mapped drives or other non-cloud-native paths, the failures were associated with those access methods; accessing files directly through SharePoint/OneDrive links or removing non-cloud access paths restored expected co-authoring behavior in the reported cases.

Support confirmed OneDrive files were private to the user by default and were not visible to others unless explicitly shared. Support also confirmed the university tenant had external/public link sharing disabled, so the 'Anyone with the link' option was not available and could not be enabled for the account or individual files; affected users were informed of this policy restriction. For large-file transfers, support used the reporter’s OneDrive within the Microsoft 365 (IU) account and created recipient-specific sharing links/permissions via OneDrive’s Share function, which resolved transfer failures while remaining compliant with data-privacy restrictions. It was noted that the IU Safe Portal imposed a 100 MB limit; requests for a different or centralized transfer solution were directed to the SAFE project team (contact: Markus Heidenreich).

The user’s OneDrive access was restored after the Microsoft 365 license was changed from an 'A1 Student' license to the appropriate 'Faculty A1+' license. The license reassignment removed the license-related restriction that had been preventing OneDrive access.

Support confirmed that the corporate subscription plan did not permit raising the 1 TB per-user OneDrive quota. The user freed space by deleting redundant files and by using OneDrive's 'Free up space' feature; no tenant-level quota increase was available under the corporate plan.

The disappearance was confirmed as an intentional decommissioning of the legacy H: home drives (decommission date recorded as 15 Nov) and user data was migrated to OneDrive. Support verified that files initially flagged with migration errors were present in OneDrive after the migration. Reports of corrupted or incorrectly formatted files after upload — including Word documents that lost formatting and PDFs that no longer allowed annotations — were logged and escalated to the users' departments for data recovery and recovery from backups where available. Attempts by users to perform private cloud backups were impeded by VPN connectivity failures; the VPN error message was not captured in the ticket. The corporate device policy restricting use of external USB drives was confirmed and communicated to the user when asked about using USB media for presentations.

The issue was resolved by ensuring the OneDrive client was signed into the correct corporate account (which corrected the Explorer path), confirming the effective OneDrive quota in the OneDrive web UI, and avoiding File Explorer staging by uploading the large folders via the OneDrive web uploader. Freeing local C: drive space on the endpoint (so the sync client could stage large uploads) was also performed; after these steps the folders uploaded with full contents rather than placeholders and no further "insufficient storage" errors were reported.

The incidents were resolved by aligning Azure AD application registration and consent across the affected tenants and ensuring the OneDrive integration app was authorized for the services Teams uses (OneDrive/SharePoint). Specifically, the OneDrive integration app (appId d37c6e4b-d66f-437f-862f-79e2ef97eb4b) was updated to include the new iu.org callback/redirect URIs after the iubh.de → iu.org domain migration and the app authentication settings were synchronized with the new tenant domain. Where integrations had rotated client secrets, the running services were updated to use the current secret. For Teams/Course Feed import requests, the app registration and tenant consent were confirmed to include the required delegated permissions/scopes for OneDrive/SharePoint and to be provisioned or consented in the LIBF study tenant (or configured as multi-tenant) so Teams-file access could be authorized. A separate backend staff account that could not authenticate was unlocked/reset, restoring staff login.

Issues were resolved by addressing two separate root causes. For shared OneDrive folders, the problem was traced to account and permission state in the browser: the "Add to my OneDrive" action was available only when the folder was shared with Edit permissions and the user was signed into the same account that held those rights. Restoring the web UI control and the ability to add the folder was achieved by re-authenticating the browser session (sign-out/sign-in) and clearing session/browser data so the correct account and permission token were used. For SharePoint document libraries and shared libraries that would not sync or appeared empty, the issue was resolved by re-linking the library from the SharePoint site — using the site’s "Sync"/"Synchronize with OneDrive" control caused the OneDrive client to re-establish the library connection (this behavior was confirmed on macOS as well as other clients). In one instance where SharePoint reported a folder already linked but OneDrive remained empty, the organization elected to stop syncing those libraries via OneDrive and use the SharePoint site directly; that action removed the sync attempt and provided access solely through SharePoint.

Support informed the user that iCloud Drive was disabled for IU accounts and that OneDrive was the supported institutional service for backing up workstation files; IU provisioned 1 TB of OneDrive storage. Support clarified that third-party services such as Dropbox were not managed or supported by IU and that issues accessing data in those services required contacting the third-party vendor. Support also explained that external-lecturer Microsoft licensing covered only the web versions of Microsoft 365 (access via office.com or mail.iu.org) and did not include locally installed Office, which required a private license.

The tenant security/compliance team reviewed the quarantined TXT (GUID-named) file from the OneDrive Quarantine location, exported the file for forensic analysis, and then cleared the quarantine after it was dispositioned. Access was restored by releasing a sanitized copy back to the user’s OneDrive (the file was reintroduced outside the Quarantine folder), after which the file could be downloaded and shared normally and the empty-download symptom disappeared. The quarantine event and original GUID filename were retained in the security logs for tracking.

The ticket recorded no single definitive fix. Investigation attributed the symptom to the Apple account type: employee addresses that were not claimed in Apple Business Manager were being treated as private Apple IDs, which prevented the system from switching or updating the iCloud/Apple ID state required for OneDrive AutoSave to be re-enabled after a macOS reinstall. The ticket captured recommendations and actions taken during troubleshooting (sign‑out/sign‑in attempts and verification that macOS reinstallation alone did not restore AutoSave) and suggested enrolling/claiming the organization domain in Apple Business Manager so addresses become Managed Apple IDs, or using a different (managed or personal) Apple ID on the Mac to restore the ability to change iCloud account settings. The ticket did not record a confirmed, single-step resolution.

The user restarted the workstation and closed all applications via Task Manager; IT staff hypothesized the files were locked because they were open on another device. The user later reported that access had been restored. No additional technical remediation steps or error details were documented in the ticket.

Technician declined to link the user's private PC to the corporate OneDrive account (policy decision) and instead added the required authentication to the user's account for web access. The technician demonstrated how to access and save files using the OneDrive Web App; the user used the web interface for OneDrive access rather than a local client installation.