Ik wil dit vertellen zoals het echt gebeurde, want als u een pagina leest met de titel "OneDrive-synchronisatie is traag met een grote bibliotheek," staat u waarschijnlijk precies waar wij een tijd geleden stonden — starend naar een draaiend systeemvakpictogram, een geïrriteerde collega achter u, en een "wijzigingen verwerken"-melding die al sinds gisteren openstaat.
We zijn niet begonnen met het bouwen van software. We zijn begonnen met het verhuizen van een bedrijf van een verouderde bestandsserver. Wat we op die weg leerden is de hele reden dat OneMount bestaat.
Waarom we überhaupt naar de cloud verhuisden
De oude \\server\share was snel en iedereen begreep hem — maar het was ook één doos in
één gebouw. Geen versiegeschiedenis die de naam waard was. Backups die iemand moest onthouden. Niets
voor thuiswerkers. Als een bestand werd overschreven, was het gewoon weg.
SharePoint Online en OneDrive for Business losten dat allemaal op papier op: echte versiegeschiedenis, beveiliging en toegangsbeheer op Microsoft-niveau, beschikbaarheid van overal, en live co-auteurschap in Office. We geloofden in die stap. Dat doen we nog steeds — de bestemming was juist. Het was het transport dat ons bij elke stap tegenwerkte.
Toen de bibliotheek een terabyte overschreed
Onze belangrijkste afdelingsbibliotheek was ongeveer een terabyte verspreid over een enorm aantal bestanden — jaren aan documenten, exports, scans, projectmappen. Het plan was simpel: richt de OneDrive-synchronisatieclient erop en laat mensen werken in de Verkenner zoals altijd.
Dat ging niet simpel. Nieuwe computers deden er het grootste deel van een dag over om hun eerste synchronisatie te doen. Op zwakkere verbindingen kwam de eerste synchronisatie het grootste deel van de weg, viel dan weg en begon weer vanaf nul. En het systeemvakpictogram zei dagenlang "wijzigingen verwerken" — een status die, bij grote bibliotheken, bekend is om dagen te duren in plaats van minuten.
Dat getal herkaderde alles voor ons. We misbruikten het hulpmiddel niet. We hadden een bestandskopiërende synchronisatieclient gewoon gevraagd om een bibliotheek te spiegelen waarvoor hij nooit was ontworpen. Elk gesynchroniseerd bestand vereist dat de client zijn hash, zijn tijdstempels, zijn synchronisatie- en conflictstatus bijhoudt — en dat boekhouden is wat op schaal omvalt.
De conflicterende kopieën
Toen kwam het bestand waar we nog steeds verhalen over vertellen. Twee mensen openden wat op hetzelfde
werkblad leek. De synchronisatieclient, achterop, had het binnenhalen van de versie van de ene persoon
nog niet voltooid. Beiden bewerkten het. Beiden sloegen op. En de cloud kreeg een tweede bestand:
Budget (conflicterende kopie van SommigeNaam 2026-03-14).xlsx.
Lees dat nog eens langzaam. We waren naar SharePoint verhuisd specifiek voor een schone versiegeschiedenis — één bestand, een keten van wie-wat-wanneer-veranderde, terugdraaien naar elk moment. En de synchronisatieclient, op weg naar de cloud, versnipperde precies dat: het bestand splitsen, gegevens dupliceren, en mensen twee werkbladen met het blote oog laten samenvoegen. Conflicterende kopieën zijn een gedocumenteerd, alledaags gedrag van offline-en-vertraagde bewerkingen, en op onze schaal was de vertraging constant.
Mensen wilden hun netwerkschijf terug
Op dit punt was de stemming omgeslagen. Iedereen was blij geweest op de oude netwerkschijf, en ze
hadden gelijk over één ding: X:\ was direct, verwerkte nooit "wijzigingen," en
elk programma op de machine begreep het. Niemand had ooit een melding ingediend met "de schijfletter
blijft hangen bij importeren."
Maar teruggaan betekende precies de dingen opgeven waarvoor we verhuisd waren — versiegeschiedenis, beveiliging, toegang op afstand, co-auteurschap. Die ruil weigerden we botweg. De eerlijke conclusie was ongemakkelijk en, achteraf gezien, voor de hand liggend:
We wilden niet de cloud of de netwerkschijf. We wilden het brein van de cloud en de handen van de netwerkschijf — de versiegeschiedenis en beveiliging van SharePoint, bereikt via een gewone schijfletter die niets naar de schijf kopieert.
Waarom "gebruik toch de browser" niet werkte
"Open bestanden dan toch in de browser" is het standaardantwoord, en voor een deel van het bedrijf is dat prima. Voor de rest is het geen optie — omdat veel echte bedrijfssoftware alleen een pad kan openen, geen webadres.
- Boekhoud- en ERP-systemen (het type dat op een gekoppelde schijf leeft en een databasebestand erop verwacht).
- Access-backends, gedeelde databases, en de rapporten die daarop zijn gebouwd.
- Technische en CAD-bestanden met koppelingen naar andere bestanden via pad.
- Backuptaken, batchscripts, geplande exports, en die ene macro uit 2014 die niemand durft te herschrijven.
Geen van hen kan https://…sharepoint.com/… openen. Ze openen X:\Projecten\….
Neem de schijfletter weg en de helft van het bedrijf stopt gewoon met werken — hoe modern de cloud
erachter ook is.
Mensen wilden in één klik delen
Er was nog een verzoek dat van elke organisatie kwam: "geef ons een knop om snel een bestand te delen, rechtstreeks vanuit Outlook." Mensen sturen collega's en klanten de hele dag links naar documenten — en elke keer moesten ze de browser openen, het bestand in SharePoint vinden en de juiste link kopiëren. Een kleine wrijving, vermenigvuldigd met honderden keren per dag.
En de "juiste link" is niet één link. Een collega binnen het bedrijf wil het pad op de gekoppelde schijf (dat opent precies hetzelfde bestand). Iemand buiten de organisatie heeft de SharePoint-weblink nodig die een aanmelding overleeft en in de browser opent. Elke keer handmatig kiezen is weer een bron van fouten en verloren minuten.
We probeerden de gespecialiseerde tools
Voordat we een regel van onze eigen code schreven, deden we het verantwoordelijke en probeerden we de bestaande tools die "SharePoint en OneDrive als schijf" beloven. Ik zal ze niet noemen — dit gaat niet over het verslaan van een concurrent, het gaat over een patroon waar we steeds tegenaan liepen, en het is het patroon dat ons er uiteindelijk toe bracht onze eigen tool te bouwen.
Ze vroegen eerst om een app-registratie
Voordat er één schijf verscheen, wilden ze een Azure-app-registratie in de tenant — beheerderstoestemming, een project om aan te maken, een beveiligingsbeoordeling om te doorstaan. Voor een schijfletter. Op elke tenant die een van onze klanten zou kunnen hebben. Dat alleen al maakte het onmogelijk om aan een klein bedrijf zonder eigen IT-afdeling te geven.
Teamgewijs bewerken werkte niet echt
Dit was degene die pijn deed. De hele reden dat we de migratie hadden doorstaan, was zodat meerdere mensen tegelijk in één werkmap konden zitten. Met deze tools was dat weg. Of het bestand werd hard vergrendeld voor één persoon terwijl iedereen anders wachtte, of twee mensen werkten parallel en kregen — ja — opnieuw versieconflicten. Het enige beste dat de cloud biedt, echt live co-auteurschap, werd stilletjes uitgeschakeld zodra het bestand via hun schijf ging.
Elke opslag overschreef de versiegeschiedenis
En dan het diepste probleem, degene die u niet opmerkt totdat u ernaar gaat zoeken. Elke keer dat u opsloeg, duwde de tool een gloednieuwe kopie van het hele bestand naar de cloud — een verse overschrijving, geen bewerking van het levende document. De schone keten van versies — deze alinea is dinsdag veranderd, teruggaan naar maandag, zien wie wat deed — werd vervangen door een stapel volledige overschrijvingen zonder echte afstamming. De tool was technisch "in SharePoint" terwijl het stilletjes de reden ontmantelde waarom iemand voor SharePoint kiest.
Een schijf die co-auteurschap breekt en versiegeschiedenis plat maakt, is geen cloudopslag met een schijfletter. Het is een netwerkshare in een SharePoint-kostuum.
Dus bouwden we OneMount
Alles wat we nodig hadden stond op die lijst van mislukkingen, geschreven als een set eisen. Dus bouwden we iets dat aan alle tegelijk voldeed:
- Een echte Windows-schijfletter. Elke legacy-app — boekhouding, Access, CAD,
backups, scripts — ziet een gewone
X:\en is tevreden. Geen browser, geen herschrijvingen. - Geen synchronisatie, geen kopieën. De terabyte blijft in de cloud. Niets wordt naar de schijf gedownload, dus er is geen muur van 300.000 bestanden, geen dag-lange eerste synchronisatie, geen "wijzigingen verwerken."
- Geen app-registratie. Een gewone Microsoft 365-aanmelding, dezelfde die mensen voor Outlook gebruiken. Niets om in Azure aan te maken, niets voor een beheerder om goed te keuren.
- Echt co-auteurschap en volledige versiegeschiedenis — behouden. Omdat het bestand op de schijf het clouddocument is, geen kopie ervan, openen Word en Excel het als het levende SharePoint-bestand. Meerdere mensen bewerken tegelijk, automatisch opslaan werkt, en de versieketen blijft intact. We hebben het getest met één werkmap en twee mensen, naast elkaar, live.
- Delen in één klik. Klik met de rechtermuisknop op een bestand of map op de schijf en het OneMount-menu in de Verkenner kopieert de SharePoint-weblink (voor mensen buiten de organisatie), of het schijfpad (voor collega's binnen), opent het bestand in SharePoint, toont de versiegeschiedenis, of stuurt het naar Outlook. Precies de "deelknop" waar organisaties steeds om vroegen.
Dat laatste punt is het hele spel. We wilden de cloud niet bereiken door bestanden erbuiten te kopiëren — dat was precies wat de versiegeschiedenis al die tijd had vernietigd. We wilden dat de schijfletter een venster was op het cloudbestand, zodat alles wat SharePoint goed doet blijft werken. Dat is de lijn waarop OneMount is gebouwd, en het is waarom het pad vanaf dit verhaal naar een product leidde in plaats van naar nog een workaround.
Zit u hier nu middenin en wilt u de schijfletter gewoon vandaag werkend hebben? De praktische begeleider bij dit verhaal staat hier: hoe u SharePoint koppelt als netwerkschijf in Windows — de methoden, de echte beperkingen, en wat echt standhoudt →
Wilt u dezelfde vraag beantwoord met cijfers in plaats van een verhaal? We hebben de OneDrive-client benchmarkt op een SharePoint-bibliotheek van 997.392 items: OneDrive en 1.000.000 bestanden — synchronisatietest, snelheid en prestaties →
Bronnen