Warum scheitern Dateien in SharePoint/OneDrive? Namensregeln, Pfadlängen und Ablagestrategie praxisnah klären

Technische Grenzen verstehen: Dateinamen, reservierte Zeichen, Pfadlängen und Unterschiede zwischen Web, Sync-Client und API

SharePoint und OneDrive verhalten sich bei Dateinamen, Sonderzeichen und Pfadlängen nicht in allen Zugriffspfaden identisch. Die Oberfläche im Browser ist oft toleranter als der lokale Sync-Client, und API-Zugriffe können zusätzliche Einschränkungen sichtbar machen, etwa durch URL-Codierung, Escaping-Regeln oder Validierungen in Client-Bibliotheken. Wer Ablagestrukturen langfristig stabil halten will, muss deshalb die technischen Grenzwerte kennen, die je nach Zugriffskanal unterschiedlich greifen.

Dateinamen: zulässige Zeichen, reservierte Namen, Endungen und „unsichtbare“ Fallstricke

In SharePoint Online und OneDrive for Business gelten für Datei- und Ordnernamen definierte Verbote. Einige Zeichen werden grundsätzlich abgelehnt, andere führen erst in bestimmten Clients zu Problemen. Hinzu kommen Sonderfälle wie führende oder endende Leerzeichen, Punkte am Ende eines Namens und reservierte Gerätebezeichnungen aus der Windows-Welt. Besonders heikel sind außerdem Namen, die in URLs oder bei Synchronisation anders interpretiert werden als im Web.

• Verbotene Zeichen: Die Zeichen ", *, :, <, >, ?, /, \, | werden in Datei- und Ordnernamen in SharePoint/OneDrive nicht akzeptiert; sie kollidieren mit URL- und Pfadsyntax sowie Windows- und Web-Parsern.
• Reservierte Namen (Windows-Kompatibilität): Ordner- oder Dateinamen wie CON, PRN, AUX, NUL, COM1 bis COM9 sowie LPT1 bis LPT9 sind auf Windows als Dateinamen reserviert. Solche Namen können im Web je nach Kontext zwar angelegt erscheinen, führen aber beim lokalen Sync auf Windows typischerweise zu Fehlern oder werden vom Client blockiert/umbenannt.
• Abschlusszeichen und Leerraum: Namen mit endendem Punkt . oder endendem Leerzeichen sind in Windows-Dateisystemen nicht sauber abbildbar; der Sync-Client kann solche Elemente nicht zuverlässig lokal erstellen und meldet Konflikte. Stabiler sind Namen ohne führende/abschließende Leerzeichen und ohne Punkt am Ende.
• URL-Semantik: Die Zeichen # oder % sind in URLs besonders: # markiert ein Fragment, % leitet Prozentkodierung ein. In SharePoint/OneDrive sind solche Zeichen in Namen nicht grundsätzlich in jedem Szenario verboten, sie erhöhen aber das Risiko, dass Links, Copy&Paste in Tickets/Chats oder API-Requests scheitern (z. B. durch unvollständige oder doppelte Kodierung).

Pfadlängen und Strukturgrenzen: warum tiefe Ordnerbäume teuer werden

Pfadgrenzen werden in SharePoint/OneDrive an mehreren Stellen wirksam: im Serverdienst, im Sync-Client, im Betriebssystem und im jeweiligen Protokoll (URL vs. Dateisystempfad). Der Webzugriff kann tiefere Strukturen häufig noch darstellen, während die Synchronisation an Pfadlänge, Zeichenkombinationen oder lokalen Restriktionen scheitert. Zusätzlich verlängern automatisch erzeugte Teile wie Site-URL, Bibliotheksname und Mandantenpräfix den effektiven Pfad, obwohl sie in der Benutzeroberfläche nicht als „Ordner“ sichtbar sind.

Bei der Planung zählt nicht nur die Länge einzelner Dateinamen, sondern die Gesamtsumme aus allen Segmenten. Schon moderat lange Orddernamen multiplizieren sich bei drei bis fünf Ebenen. Gleichzeitig erhöhen tiefe Strukturen die Wahrscheinlichkeit von Dubletten (gleich benannte Dateien in unterschiedlichen Zweigen), erschweren konsistente Berechtigungen und verzögern lokale Indizierung.

Web, Sync-Client und API: unterschiedliche Validierung, unterschiedliche Fehlbilder

Der Webclient arbeitet innerhalb des SharePoint-Dienstes: Validierung erfolgt serverseitig, und die Darstellung kaschiert manche Komplexität (z. B. URL-Encoding). Der OneDrive-Sync-Client muss hingegen jeden Eintrag in ein lokales Dateisystemobjekt übersetzen. Dabei entstehen Konflikte, wenn ein Cloud-Name lokal nicht zulässig ist oder wenn ein Pfad die lokalen Grenzen überschreitet. API-Zugriffe wiederum setzen korrekt codierte Pfade voraus und reagieren sensibel auf falsches Escaping, insbesondere wenn Clients Pfadsegmente statt Item-IDs verwenden.

• Webzugriff: Links basieren auf URLs; Zeichen wie Leerzeichen werden als %20 kodiert. Copy&Paste von unvollständig kodierten Links (oder von Links, die beim Weiterleiten/Formatieren verändert wurden) kann zu „Seite nicht gefunden“ führen, obwohl die Datei existiert.
• Lokaler Sync: Der Sync-Client bildet jeden Eintrag auf einen lokalen Pfad ab; problematisch sind u. a. endende Punkte/Leerzeichen sowie nicht unterstützte Namen. Konflikte äußern sich als blockierte Dateien, Umbenennungen mit Suffixen oder als Einträge in „Synchronisierungsprobleme“.
• API-Zugriff: Stabiler als Pfadnavigation ist die Adressierung über IDs; bei Pfadrequests müssen Segmente korrekt kodiert werden (z. B. /drives/{drive-id}/root:/Pfad/Datei%20mit%20Leerzeichen.docx:). Unsaubere Kodierung erzeugt reproduzierbare Fehler in Automationen.

Umlaute, Akzente und Normalisierung: sichtbare Gleichheit, technische Ungleichheit

Umlaute (ä, ö, ü), ß und andere diakritische Zeichen sind grundsätzlich nutzbar. Probleme entstehen eher durch Normalisierung: Manche Systeme speichern Zeichenfolgen in unterschiedlichen Unicode-Formen, die visuell identisch wirken, aber binär abweichen. Das kann bei Migrationen, bei Skripten oder beim Abgleich zwischen macOS und Windows zu scheinbaren Dubletten oder zu „Element existiert bereits“-Fehlern führen. Zusätzlich verlängert URL-Encoding nicht-ASCII-Zeichen, was indirekt Pfadgrenzen früher erreicht.

Technisch konservativ bleibt eine Benennung, die für kritische Pfade auf einen ASCII-nahen Zeichensatz setzt (z. B. ae statt ä), während sprechende Anzeigenamen über Metadaten oder Titelspalten abgebildet werden. Wo Umlaute Bestandteil offizieller Dokumentnamen sind, reduziert eine flache Ordnerstruktur das Risiko, dass Pfade durch Codierung und Segmentlängen in Grenzbereiche geraten.

Fehlerquellen früh erkennen: typische Sync- und Zugriffskonflikte

Viele Probleme tauchen erst dann auf, wenn Inhalte geteilt, synchronisiert oder automatisiert verarbeitet werden. Ein Dateiname, der im Web erstellt wurde, kann beim ersten Sync in einen Windows-Client scheitern; ein Link, der im Browser funktioniert, kann in einer API-Aktion ohne korrektes Encoding brechen. Deshalb lohnt sich eine technische Plausibilitätsprüfung anhand weniger, klarer Regeln, bevor neue Strukturen großflächig ausgerollt werden.

• Konflikte durch verbotene Muster: Vermeidung von Namen, die nur aus Punkt/Leerzeichen bestehen, von abschließenden Leerzeichen/Punkten sowie von schwer sichtbaren Steuerzeichen; diese Muster sind im Web nicht immer offensichtlich, im lokalen Dateisystem aber nicht abbildbar.
• Zu lange Pfade in synchronisierten Bibliotheken: Tiefe Hierarchien in Kombination mit langen Projektbezeichnungen erhöhen die Ausfallquote im Sync; eine Gegenmaßnahme ist die Begrenzung der Ebenenanzahl und die Kürzung von Standardsegmenten (z. B. Projekte statt Projektunterlagen_und_Kommunikation).
• API-Automationen mit Pfadadressierung: Bei Graph-Aufrufen muss die Pfadkomponente korrekt kodiert sein; robuste Implementierungen verwenden nach Möglichkeit item-id-basierte Zugriffe statt Pfadnavigation, um Sonderzeichen und Umbenennungen abzufedern.
• Umbenennungen und Verschiebungen: Verschieben großer Ordnerbäume erzeugt viele Änderungsereignisse; Clients benötigen Zeit zur Nachverfolgung. Bei knappen Grenzen (Pfad/Zeichen) kann eine Verschiebung dazu führen, dass vormals zulässige Elemente nach dem Umzug nicht mehr synchronisierbar sind.

Ablage- und Benennungskonventionen, die im Alltag funktionieren: Ordnerstruktur, Dateinamen, Umlaut-/Sonderzeichen-Strategie und Auswirkungen auf Versionierung, Freigaben und Suche

Konventionen für Ablage und Benennung wirken nur dann stabil, wenn sie die technische Realität von SharePoint und OneDrive abbilden: Browserzugriff, Synchronisationsclient, Office-Integration und API-Zugriffe behandeln Namen, Pfade und Sonderzeichen nicht immer identisch. Eine praxistaugliche Strategie verhindert Sync-Konflikte, reduziert „ungültige Zeichen“-Fehler, hält Pfade kurz genug und unterstützt Suche, Freigaben und nachvollziehbare Versionierung.

Ordnerstruktur: wenige Ebenen, klare Verantwortlichkeit, keine Ablage nach Zufall

Eine strukturierte Bibliothek beginnt mit der Entscheidung, welche Ordnung im Alltag tatsächlich genutzt wird. Ordner sollten eine fachliche Dimension abbilden (z. B. Prozess, Produkt, Kunde oder Projekt) und nicht gleichzeitig mehrere. Wird etwa „Kunde/Projekt/Jahr/Abteilung“ kombiniert, wächst die Tiefe schnell, Pfade werden lang, und die Wahrscheinlichkeit steigt, dass Nutzer kurzfristig Ausnahmen schaffen (z. B. „Sonstiges“, „Alt“, „Neu neu“).

Für SharePoint-Bibliotheken bewähren sich flache Strukturen mit wenigen Hauptordnern und einer begrenzten Tiefe. Ergänzend können Metadaten genutzt werden, ohne dass die Nutzerführung leidet. Besonders bei synchronisierten Bibliotheken reduziert eine kurze Pfadstruktur lokale Dateisystemprobleme und erleichtert das Verschieben, weil weniger abhängige Teilpfade betroffen sind.

• Maximale Tiefe begrenzen: Ordnerhierarchien so planen, dass typische Arbeitsdateien innerhalb von 3–5 Ebenen liegen; tiefe Pfade erhöhen Sync-Risiken und erschweren das Teilen über Links.
• Trennung nach Stabilität: Dauerhafte Strukturen (z. B. 01_Organisation, 02_Projekte, 03_Vorlagen) getrennt von temporären Arbeitsbereichen (z. B. 99_Archiv), damit Berechtigungen und Aufbewahrung konsistent bleiben.
• Archivierung als Zustand, nicht als Parallelwelt: Abgeschlossene Inhalte in einen klar definierten Archivordner oder eine eigene Bibliothek verschieben; keine zusätzlichen „Alt“-Kopien in Arbeitsordnern, da sonst Versionierung und Suche doppelte Treffer liefern.
• Konfliktarme Sortierung: Nummernpräfixe wie 01_, 02_ nur dort einsetzen, wo eine feste Reihenfolge relevant ist; übermäßige Nummerierung führt zu Umbenennungswellen und kann Links/Verknüpfungen unnötig verändern.

Dateinamen: lesbar, kurz, maschinenfreundlich – und ohne Sync-Fallen

Dateinamen sollten drei Anforderungen gleichzeitig erfüllen: schnelle menschliche Erkennung, stabile Verarbeitung über Windows/macOS, und zuverlässige Handhabung durch Web, Sync-Client und Apps. Typische Fehlerquellen sind sehr lange Namen, Sonderzeichen, die in URLs oder im Windows-Dateisystem problematisch sind, sowie Muster, die Office und der Sync-Client als konfliktträchtig interpretieren.

Praktisch ist ein Schema mit Datum, Kontext und Inhalt, ergänzt um einen knappen Status. ISO-Daten (YYYY-MM-DD) sortieren korrekt, und ein konsistenter Trenner reduziert Variationen. Bindestrich und Unterstrich bleiben in den meisten Toolchains unauffällig, während exotische Zeichen (z. B. Pfeile, Anführungszeichen, mathematische Operatoren) häufiger zu Escaping, Doppelkodierung oder Ablehnung führen.

Umlaute und Sonderzeichen: Strategie für Kompatibilität zwischen Web, Sync-Client und Automatisierung

Umlaute (ä, ö, ü) und das ß sind in modernen SharePoint-/OneDrive-Umgebungen grundsätzlich nutzbar. Probleme entstehen meist nicht im Speichern selbst, sondern in der Kette aus Linkfreigaben, Copy&Paste zwischen Anwendungen, Drittanbieter-Tools, Legacy-Skripten und einzelnen APIs, die URL-Encoding oder Normalisierung unterschiedlich behandeln. Auch Zeichen, die im Windows-Dateisystem eine besondere Bedeutung haben, sind für synchronisierte Bibliotheken ein harter Ausschluss, weil der lokale Client Namen an das Dateisystem anpassen muss.

Für eine robuste, organisationsweite Regel bietet sich ein „ASCII-first“-Ansatz an: Umlaute werden in Dateinamen und Ordnern konsequent transliteriert (z. B. ae, oe, ue, ss), während in Dokumentinhalten, Metadatenfeldern und Titeln die korrekte Schreibweise erhalten bleibt. Damit bleiben URLs, Skripte und systemübergreifende Exporte stabil, ohne dass fachliche Präzision verloren geht.

• Erlaubte, unauffällige Zeichen priorisieren: Buchstaben/Ziffern plus -, _, Leerzeichen (sparsam) und Punkt vor der Erweiterung; so bleiben Namen in https://-Links und in lokalen Pfaden gut handhabbar.
• Transliteration festlegen: ä→ae, ö→oe, ü→ue, Ä→Ae, Ö→Oe, Ü→Ue, ß→ss; vermeidet Probleme in Integrationen, die Unicode-Normalisierung oder Encoding inkonsistent umsetzen.
• Problematische Zeichen vermeiden: Keine Zeichen verwenden, die im Windows-Dateisystem nicht zulässig sind (\, /, :, *, ?, ", <, >, |) oder in URLs häufig zu Fehlern führen (z. B. #, %), wenn synchronisiert oder automatisiert verarbeitet wird.
• Keine führenden/abschließenden Punkte und Leerzeichen: Namen wie Bericht .docx oder .Notizen können in lokalen Dateisystemen und Tools unterschiedlich interpretiert werden und Sync-Konflikte auslösen.

Auswirkungen auf Versionierung, Freigaben und Suche

Benennung und Struktur greifen direkt in Funktionen ein, die oft als „separat“ wahrgenommen werden. Umbenennen und Verschieben erzeugen in SharePoint neue Versionen und Ereignisse in der Aktivitätshistorie; bei häufigen kosmetischen Anpassungen steigt der Lärm in der Versionierung, während die inhaltlich relevante Änderung schwerer zu erkennen ist. In synchronisierten Szenarien führt paralleles Arbeiten an lokal umbenannten Dateien zudem leichter zu Duplikaten oder Konfliktdateien.

Freigaben profitieren von stabilen Pfaden: Links bleiben zwar in vielen Fällen über serverseitige IDs resilient, aber Nutzer kopieren häufig Pfade, versenden Dateinamen oder legen lokale Verknüpfungen an. Lange oder kryptische Namen erhöhen die Fehlerquote, und Sonderzeichen können beim Weiterleiten oder beim Import in Ticketsysteme/Chats anders codiert werden. Eine konsistente Benennung reduziert zudem das Risiko, dass sensible Inhalte in falsch benannte „öffentliche“ Ordner wandern, weil die Struktur unklar wirkt.

Die Suche reagiert empfindlich auf „Namensmüll“. Häufige Muster wie final, final_final, neu oder zufällige Abkürzungen verschlechtern die Trefferqualität, weil sie kaum unterscheidende Signale liefern. Bessere Ergebnisse entstehen, wenn der Dateiname primär stabile, semantische Kerndaten enthält (Datum, Objekt, Dokumenttyp) und variable Informationen (Status, Verantwortliche, interne Kürzel) bevorzugt über Metadaten oder klar definierte Ordnerkontexte abgebildet werden.

Störungen vermeiden und Altbestände bereinigen: typische Sync-Fehlerbilder, Konflikte, Long-Path-Fallen sowie Migration und automatisierte Bereinigung bestehender Strukturen

Typische Fehlerbilder im Sync-Client: Ursachen, Symptome, Erstdiagnose

Störungen beim OneDrive-Synchronisationsclient entstehen selten „zufällig“, sondern folgen wiederkehrenden Mustern: unerlaubte Zeichen, zu lange Pfade, zu lange Dateinamen, unzulässige Endungen (Punkt/Leerzeichen), gesperrte Dateien, zu große oder zu häufige Änderungen sowie lokale Dateisystemeffekte (z. B. Virenscanner-Hooks, Offline-Dateien, Reparse-Points). Auffällig ist, dass Webzugriff und Synchronisation unterschiedliche Validierungen durchsetzen können. Dadurch funktionieren Uploads im Browser scheinbar, scheitern aber lokal beim Sync, oder umgekehrt.

Für die Erstdiagnose hilft ein konsequentes Trennen der Ebenen: Tritt der Fehler nur lokal auf, liegt er häufig an Pfadlängen, Dateisystemrestriktionen oder lokalen Sperren. Tritt er auch im Web auf, sind meist Namensregeln, Richtlinien oder Berechtigungen ursächlich. Bei Konflikten ist zudem zu prüfen, ob mehrere Endgeräte gleichzeitig dieselben Dateien bearbeiten, ob Anwendungen temporäre Dateien mit problematischen Namen erzeugen oder ob automatische Umbenennungen durch den Client bereits stattgefunden haben.

• Unzulässige Zeichen und Namen: Dateinamen mit ", *, :, <, >, ?, /, \, | oder Steuerzeichen führen zu Upload- bzw. Sync-Blockaden; ebenso Namen, die auf . oder Leerzeichen enden.
• „Diese Datei kann nicht synchronisiert werden“: häufig bei Pfadlängenproblemen, bei sehr langen Dateinamen oder bei Ordnern/Dateien, deren Name nach einer Migration schwer sichtbare Zeichen enthält (z. B. nicht druckbare Unicode-Zeichen).
• Wiederkehrende Upload-Schleifen: typisch bei Dateien, die von Anwendungen permanent geändert werden (z. B. Logdateien) oder bei konkurrierenden Tools, die Metadaten anfassen; als Indikator erscheinen dauerhafte Statuswechsel im Client.
• Konfliktkopien: entstehen bei parallelen Änderungen, Uhrzeitdrift oder Office-Dateien außerhalb eines stabilen Co-Authoring-Szenarios; erkennbar an automatisch erzeugten Dateinamenvarianten wie Dateiname-PCname-Konfliktkopie.docx.
• „Zugriff verweigert“ lokal: oft durch lokale NTFS-Rechte, geöffnete Handles, EDR/AV-Quarantäne oder blockierte Dateitypen; lokal prüfen, ob das Objekt im Explorer umbenannt/verschoben werden kann.

Konflikte und Sperren: Parallelbearbeitung, Office-Caches, temporäre Dateien

Konflikte sind nicht nur ein Kollisionsproblem im Dateinamen, sondern häufig ein Indiz für inkonsistente Bearbeitungswege. Office-Dateien, die über SharePoint/OneDrive geöffnet werden, nutzen je nach Zugriffspfad unterschiedliche Mechanismen: Co-Authoring im Web oder in Desktop-Apps ist robust, wenn der Zugriff über den SharePoint/OneDrive-Endpunkt erfolgt. Wird dagegen eine Datei lokal per Sync bearbeitet und gleichzeitig im Web geändert, entstehen eher Konfliktkopien, weil der Client parallele Änderungen nicht immer verlustfrei zusammenführen kann.

Zusätzlich erzeugen Anwendungen temporäre Dateien (z. B. mit Präfixen wie ~$) und halten Locks. Solche Objekte sind meist kurzlebig, können aber bei instabiler Verbindung, abruptem Shutdown oder aggressiver Backup-/Security-Software „liegen bleiben“ und wiederholt Sync-Fehler auslösen. Praktisch relevant wird das in tiefen Ordnerstrukturen, weil schon kleine Namensverlängerungen durch Konfliktkopien oder temporäre Dateien die Pfadgrenzen reißen.

Long-Path-Fallen: warum kleine Strukturentscheidungen später teuer werden

Pfadlängenprobleme entstehen aus der Summe mehrerer Komponenten: Website-/Teamname, Bibliotheksname, Ordnerkaskade und Dateiname. Der Browser toleriert in vielen Szenarien längere URLs als lokale Windows-APIs ohne durchgängige Long-Path-Unterstützung, und der Sync-Client muss zusätzlich lokale Pfade erzeugen, die wiederum im NTFS-Kontext funktionieren müssen. Besonders kritisch sind Altbestände, die über Jahre gewachsen sind: „Archiv/Alt/Final/Final2/Final_final“ plus sprechende Dateinamen sorgt für eine sprunghafte Überschreitung von Grenzen, sobald Konfliktkopien oder Versionssuffixe hinzukommen.

In Migrationen fällt außerdem auf, dass Umbenennungen im SharePoint-Web zwar möglich sein können, aber im Sync später scheitern, weil Windows bestimmte Namensformen (z. B. abschließender Punkt) nicht abbilden kann. Solche Divergenzen sind tückisch: Die Struktur „existiert“ serverseitig, lässt sich aber lokal nicht stabil darstellen. Daraus entstehen Fehlerbilder, bei denen einzelne Teilbäume nie vollständig synchronisieren, obwohl Berechtigungen korrekt sind.

• Pfadbudget definieren: Für Ordnerhierarchien ein internes Limit festlegen (z. B. „max. 6 Ebenen“ und kurze Bibliotheksnamen), damit Reserve für Konfliktkopien bleibt; kritische Kandidaten vorab anhand exportierter URL-/Pfadlisten prüfen.
• Bibliotheken statt Tiefenstruktur: Statt immer weiterer Unterordner thematisch trennen, beispielsweise über mehrere Dokumentbibliotheken mit klaren Berechtigungsgrenzen; dadurch sinken Pfadlängen und Berechtigungsvererbung bleibt nachvollziehbar.
• Problematische Endzeichen ausschließen: Namen, die auf . oder Leerzeichen enden, vermeiden; bei Altbeständen serverseitig bereinigen, bevor der Sync großflächig ausgerollt wird.
• Konflikt- und Temp-Dateien einkalkulieren: Reserve für Suffixe wie -Konfliktkopie und temporäre Office-Dateien vorsehen; sonst entstehen Grenzfälle, die erst unter Last sichtbar werden.

Migration und Bereinigung: Vorgehen, Werkzeugketten, Automatisierung ohne Datenverlust

Bei Migrationen aus Fileshares oder Legacy-DMS ist eine zweistufige Bereinigung belastbarer als „Lift-and-Shift“. In Stufe eins wird der Bestand inventarisiert: Namensverstöße, Pfadlängenrisiken, Dubletten, gesperrte Dateitypen und überflüssige Zwischenstände. Stufe zwei setzt Regeln automatisiert um und protokolliert jede Änderung (Mapping alt/neu), damit Verweise in Dokumenten, Tickets oder E-Mails nachvollziehbar bleiben.

Für die technische Umsetzung eignen sich etablierte Schnittstellen: Für SharePoint Online und OneDrive liefert die Microsoft Graph API die nötigen Operationen zum Auflisten, Umbenennen und Verschieben; für SharePoint-Administration bleibt PowerShell mit PnP.PowerShell ein verbreiteter Ansatz. Bei sehr großen Beständen ist eine batchweise Verarbeitung nötig, um Rate-Limits und Sperren zu vermeiden. Wesentlich ist ein „dry run“ mit Berichtsausgabe, der die Auswirkung von Umbenennungsregeln sichtbar macht, bevor produktiv geändert wird.

• Inventarisierung per Graph: Struktur und Namen auslesen und gegen Regeln prüfen, z. B. via GET https://graph.microsoft.com/v1.0/drives/{drive-id}/root:/{path}:/children und Paging über @odata.nextLink.
• Automatisches Umbenennen mit Nachvollziehbarkeit: Rename/Move mit Protokoll (CSV/JSON) durchführen, z. B. PATCH https://graph.microsoft.com/v1.0/drives/{drive-id}/items/{item-id} mit Payload {"name":"Neuer_Name.docx"}.
• Bereinigung von „verbotenen Endungen“: Dateien und Ordner, die auf Punkt/Leerzeichen enden, serverseitig korrigieren; zusätzlich Normalisierung von Mehrfachspaces und unsichtbaren Unicode-Zeichen in einem regelbasierten Schritt.
• Gezielte Quarantäne statt Blindlöschung: Problemobjekte in eine separate Bibliothek verschieben (oder in einen Quarantäneordner mit kurzen Pfaden), bevor endgültig entschieden wird; Verschieben per Graph entspricht einem Rename/Move über parentReference.
• Kontrollierte Neu-Synchronisation: Nach großen Umbenennungswellen lokale Clients neu indizieren lassen (ggf. betroffene Bibliotheken erneut synchronisieren), um inkonsistente lokale Caches zu vermeiden; dabei Änderungen in kleinen Wellen planen, nicht als Massenevent.

Bei Altbeständen mit vielen Sonderfällen ist eine „Regelmatrix“ hilfreich: Welche Zeichen werden ersetzt, wie werden Umlaute behandelt, wann wird gekürzt, wann wird ein Hash-Suffix ergänzt, und welche Ausnahmen gelten (z. B. rechtlich relevante Aktenzeichen). Technisch zählt weniger die perfekte Ästhetik als die Stabilität über Web, Sync-Client und API hinweg. Ein sauberer Migrationslauf endet deshalb nicht mit dem letzten kopierten Byte, sondern mit einem Validierungslauf: stichprobenartige Sync-Tests, Suche auf kritische Begriffe, Öffnen und Speichern typischer Office-Dateien sowie ein Abgleich, ob alle umbenannten Pfade in Freigaben und Verknüpfungen weiterhin auflösbar sind.