Ich möchte das so erzählen, wie es tatsächlich passiert ist, denn wenn Sie eine Seite mit dem Titel „OneDrive-Synchronisierung ist langsam bei einer großen Bibliothek" lesen, stehen Sie wahrscheinlich genau dort, wo wir vor einer Weile standen — vor einem sich drehenden Taskleistensymbol, einem verärgerten Kollegen hinter sich, und einer „Änderungen werden verarbeitet"-Blase, die seit gestern hängt.

Wir hatten nicht vor, Software zu bauen. Wir wollten ein Unternehmen von einem alternden Dateiserver wegbringen. Was wir auf diesem Weg gelernt haben, ist der ganze Grund, warum OneMount existiert.

Warum wir überhaupt in die Cloud gewechselt sind

Der alte \\server\freigabe war schnell und jeder verstand ihn — aber er war auch eine einzelne Box in einem einzelnen Gebäude. Kein Versionsverlauf, der diesen Namen verdient hätte. Backups, an die jemand denken musste. Nichts für Menschen, die von zu Hause arbeiteten. Wenn eine Datei überschrieben wurde, war sie einfach weg.

SharePoint Online und OneDrive for Business behoben das alles auf dem Papier: echter Versionsverlauf, Sicherheit und Zugriffskontrolle auf Microsoft-Niveau, Verfügbarkeit von überall, und Live-Co-Authoring in Office. Wir glaubten an diesen Schritt. Wir tun es immer noch — das Ziel war richtig. Es war der Transportweg, der uns bei jedem Schritt bekämpfte.

Dann überschritt die Bibliothek ein Terabyte

Unsere wichtigste Abteilungsbibliothek war etwa ein Terabyte groß, verteilt auf eine enorme Anzahl Dateien — Jahre von Dokumenten, Exporten, Scans, Projektordnern. Der Plan war einfach: den OneDrive-Sync-Client darauf richten und die Leute wie immer im Explorer arbeiten lassen.

Es lief nicht einfach. Neue Computer brauchten den größten Teil eines Tages für ihre Erstsynchronisierung. Auf schwächeren Verbindungen kam die Erstsynchronisierung fast bis zum Ende, brach ab und begann wieder bei null. Und das Taskleistensymbol zeigte tagelang „Änderungen werden verarbeitet" — ein Zustand, der bei großen Bibliotheken nachweislich tatsächlich Tage statt Minuten dauern kann.

Microsofts eigene Empfehlung lautet, unter 300.000 synchronisierte Elemente für gute Leistung zu bleiben — und das ist die Summe über alle Bibliotheken, die eine Person synchronisiert, nicht ein einzelner Ordner. Eine einzige Ein-Terabyte-Abteilungsbibliothek sprengt das um ein Vielfaches. (Unterstützung für bis zu einer Million Elemente pro Gerät kommt erst jetzt, und nur in der Vorschau.)

Diese Zahl stellte für uns alles neu dar. Wir hatten das Werkzeug nicht falsch benutzt. Wir hatten einen dateikopierenden Sync-Client einfach gebeten, eine Bibliothek zu spiegeln, für die er nie gedacht war. Jede synchronisierte Datei erfordert vom Client, ihren Hash, ihre Zeitstempel, ihren Sync- und Konfliktzustand zu verfolgen — und genau diese Buchführung bricht in großem Maßstab zusammen.

Die Konfliktkopien

Dann kam die Datei, über die wir immer noch Geschichten erzählen. Zwei Personen öffneten, was wie dieselbe Tabelle aussah. Der Sync-Client, der hinterherhinkte, hatte die Version der einen Person noch nicht vollständig heruntergeladen. Beide bearbeiteten. Beide speicherten. Und die Cloud gewann eine zweite Datei: Budget (Konfliktkopie von SomeName 2026-03-14).xlsx.

Lesen Sie das noch einmal langsam. Wir waren genau deshalb zu SharePoint gewechselt, um einen sauberen Versionsverlauf zu haben — eine Datei, eine Kette von wer-hat-was-wann-geändert, Rücksetzung auf jeden Punkt. Und der Sync-Client, auf dem Weg zur Cloud, zerstörte genau das: Er gabelte die Datei, duplizierte Daten und ließ Menschen zwei Tabellen mit bloßem Auge zusammenführen. Konfliktkopien sind ein dokumentiertes, alltägliches Verhalten bei Offline- und verzögerten Bearbeitungen, und in unserem Maßstab war die Verzögerung ständig.

Die Leute wollten ihr Netzlaufwerk zurück

Zu diesem Zeitpunkt hatte sich die Stimmung gedreht. Alle waren auf dem alten Netzlaufwerk zufrieden gewesen, und sie hatten in einem Punkt recht: X:\ war sofort da, es „verarbeitete" nie Änderungen, und jedes Programm auf dem Rechner verstand es. Niemand hatte je ein Ticket eröffnet, das sagte „der Laufwerksbuchstabe hängt beim Importieren fest".

Aber zurückzugehen bedeutete, genau das aufzugeben, wofür wir umgezogen waren — Versionsverlauf, Sicherheit, Fernzugriff, Co-Authoring. Diesen Tausch lehnten wir rundweg ab. Die ehrliche Schlussfolgerung war unbequem und, im Rückblick, offensichtlich:

Wir wollten nicht die Cloud oder das Netzlaufwerk. Wir wollten das Gehirn der Cloud und die Hände des Netzlaufwerks — den Versionsverlauf und die Sicherheit von SharePoint, erreicht über einen gewöhnlichen Laufwerksbuchstaben, der nichts auf die Festplatte kopiert.

Warum „einfach den Browser nutzen" nicht funktionierte

„Dann öffnen Sie die Dateien doch einfach im Browser" ist die Standardantwort, und für einen Teil des Unternehmens ist das in Ordnung. Für den Rest ist es keine Option — weil ein großer Teil echter Geschäftssoftware nur einen Pfad öffnen kann, keine Webadresse.

  • Buchhaltungs- und ERP-Systeme (die Art, die auf einem eingebundenen Laufwerk lebt und dort eine Datenbankdatei erwartet).
  • Access-Backends, gemeinsame Datenbanken und die darauf aufgebauten Berichte.
  • Konstruktions- und CAD-Dateien mit Verknüpfungen zu anderen Dateien über Pfade.
  • Backup-Jobs, Batch-Skripte, geplante Exporte, und dieses eine Makro von 2014, das niemand umzuschreiben wagt.

Keines davon kann https://…sharepoint.com/… öffnen. Sie öffnen X:\Projekte\…. Nehmen Sie den Laufwerksbuchstaben weg, und die Hälfte des Unternehmens hört einfach auf zu funktionieren — egal wie modern die Cloud dahinter ist.

Die Leute wollten mit einem Klick teilen

Es gab noch eine weitere Bitte, die von jeder Organisation kam: „Geben Sie uns einen Knopf, um eine Datei schnell zu teilen, direkt aus Outlook." Menschen schicken Kollegen und Kunden den ganzen Tag Links zu Dokumenten — und jedes Mal mussten sie den Browser öffnen, die Datei in SharePoint finden und den richtigen Link kopieren. Eine kleine Reibung, multipliziert mit Hunderten Malen pro Tag.

Und der „richtige Link" ist nicht ein einziger Link. Ein Kollege im Unternehmen möchte den Pfad auf dem eingebundenen Laufwerk (er öffnet genau dieselbe Datei). Eine externe Person braucht den SharePoint-Weblink, der eine Anmeldung übersteht und sich im Browser öffnet. Jedes Mal von Hand zu wählen ist eine weitere Quelle für Fehler und verlorene Minuten.

Wir haben die spezialisierten Werkzeuge ausprobiert

Bevor wir eine einzige Zeile eigenen Codes schrieben, taten wir das Verantwortungsvolle und probierten die vorhandenen Werkzeuge aus, die „SharePoint und OneDrive als Laufwerk" versprechen. Ich werde sie nicht namentlich nennen — hier geht es nicht darum, einen Konkurrenten schlechtzumachen, sondern um ein Muster, auf das wir immer wieder stießen, und genau dieses Muster hat uns schließlich dazu gebracht, unser eigenes zu bauen.

Sie verlangten zuerst eine App-Registrierung

Bevor auch nur ein Laufwerk erschien, wollten sie eine Azure-App-Registrierung im Tenant — Administratorzustimmung, ein zu erstellendes Projekt, eine zu bestehende Sicherheitsprüfung. Für einen Laufwerksbuchstaben. Auf jedem Tenant, den ein Kunde von uns haben könnte. Das allein machte sie unmöglich, an ein kleines Unternehmen ohne eigene IT-Abteilung weiterzugeben.

Gemeinsames Bearbeiten funktionierte nicht wirklich

Das war der Punkt, der wirklich wehtat. Der ganze Grund, warum wir die Migration durchgestanden hatten, war, dass mehrere Personen gleichzeitig in einer Arbeitsmappe sein konnten. Bei diesen Werkzeugen war das weg. Entweder war die Datei für eine Person hart gesperrt, während alle anderen warteten, oder zwei Personen arbeiteten parallel und bekamen — ja — wieder Versionskonflikte. Das mit Abstand Beste, was die Cloud bietet, echtes Co-Authoring in Echtzeit, wurde still abgeschaltet, sobald die Datei durch ihr Laufwerk lief.

Jedes Speichern überschrieb den Versionsverlauf

Und dann das tiefste Problem, das man nicht bemerkt, bis man danach sucht. Bei jedem Speichern schob das Werkzeug eine brandneue Kopie der gesamten Datei in die Cloud — ein frisches Überschreiben, keine Bearbeitung des lebenden Dokuments. Die saubere Kette von Versionen — dieser Absatz wurde am Dienstag geändert, Rücksetzung auf Montag, sehen wer was getan hat — wurde durch einen Stapel von Ganzdatei-Überschreibungen ohne echte Abstammung ersetzt. Das Werkzeug war technisch „in SharePoint", während es leise genau den Grund demontierte, warum überhaupt jemand SharePoint wählt.

Ein Laufwerk, das Co-Authoring bricht und den Versionsverlauf plättet, ist kein Cloud-Speicher mit Laufwerksbuchstaben. Es ist eine Netzwerkfreigabe im SharePoint-Kostüm.

Also haben wir OneMount gebaut

Alles, was wir brauchten, stand auf dieser Liste von Fehlschlägen, geschrieben als Anforderungen. Also bauten wir das, was alle davon auf einmal erfüllte:

  • Ein echter Windows-Laufwerksbuchstabe. Jede Legacy-Anwendung — Buchhaltung, Access, CAD, Backups, Skripte — sieht ein gewöhnliches X:\ und ist zufrieden. Kein Browser, keine Neuprogrammierung.
  • Keine Synchronisierung, keine Kopien. Das Terabyte bleibt in der Cloud. Nichts wird auf die Festplatte heruntergeladen, also gibt es keine 300.000-Dateien-Mauer, keine tagelange Erstsynchronisierung, kein „Änderungen werden verarbeitet".
  • Keine App-Registrierung. Eine gewöhnliche Microsoft-365-Anmeldung, dieselbe, die Menschen für Outlook nutzen. Nichts in Azure zu erstellen, nichts für einen Administrator zu genehmigen.
  • Echtes Co-Authoring und vollständiger Versionsverlauf — erhalten. Weil die Datei auf dem Laufwerk das Cloud-Dokument ist, keine Kopie davon, öffnen Word und Excel sie als die lebende SharePoint-Datei. Mehrere Personen bearbeiten gleichzeitig, AutoSave funktioniert, und die Versionskette bleibt intakt. Wir haben es mit einer Arbeitsmappe und zwei Personen live nebeneinander getestet.
  • Teilen mit einem Klick. Rechtsklick auf eine Datei oder einen Ordner auf dem Laufwerk, und das OneMount-Menü im Explorer kopiert den SharePoint-Weblink (für externe Personen) oder den Laufwerkspfad (für Kollegen intern), öffnet die Datei in SharePoint, zeigt ihren Versionsverlauf oder sendet sie an Outlook. Genau der „Teilen-Knopf", nach dem Organisationen immer wieder fragten.

Der letzte Punkt ist das ganze Spiel. Wir wollten die Cloud nicht erreichen, indem wir Dateien aus ihr herauskopieren — genau das hatte die ganze Zeit den Versionsverlauf zerstört. Wir wollten, dass der Laufwerksbuchstabe ein Fenster auf die Cloud-Datei ist, sodass alles, was SharePoint gut kann, weiter funktioniert. Auf dieser Linie ist OneMount gebaut, und deshalb führte der Weg von dieser Geschichte zu einem Produkt statt zu einer weiteren Notlösung.

Die Kurzfassung: Behalten Sie den Versionsverlauf, die Sicherheit und das Live-Co-Authoring von SharePoint — erreicht über einen gewöhnlichen Laufwerksbuchstaben, der nichts auf Ihre Festplatte kopiert. Das ist die ganze Idee.

Wenn Sie gerade mittendrin stecken und einfach nur den Laufwerksbuchstaben heute zum Laufen bringen wollen, ist der praktische Begleiter zu dieser Geschichte hier: wie man SharePoint als Netzlaufwerk in Windows einbindet — die Methoden, die echten Grenzen, und was wirklich standhält →

Möchten Sie dieselbe Frage mit Zahlen statt einer Geschichte beantwortet bekommen? Wir haben den OneDrive-Client an einer SharePoint-Bibliothek mit 997.392 Elementen gemessen: OneDrive und 1.000.000 Dateien — Sync-Test, Geschwindigkeit und Leistung →

Quellen