Eerst een stukje terminologie, omdat elk cijfer hieronder ervan afhangt. Microsoft telt de synchronisatielimiet in items — bestanden en mappen samen. Onze testbibliotheek had 997.392 items: 890.191 bestanden en 107.201 mappen. Waar dit artikel "een miljoen bestanden" zegt, bedoelt het items in de zin van Microsoft.
Het korte antwoord
- 997.392items in de testbibliotheek op SharePoint
- 52 mineerste synchronisatie vanaf nul
- 351/secgemiddeld tempo, piek bij 590 items/sec
- 3,6 GBpiek RAM-gebruik
- 20,6 GBpiek vereiste schijfruimte
- 5,9%van een verbinding van 99 Mbps gebruikt
- 238 minlangste "zoeken naar wijzigingen" na opnieuw aanmelden
- 44 van 45pogingen om een bestand te openen tijdens die fase mislukten door time-out
De vraag is niet langer of OneDrive een miljoen items kan synchroniseren. Dat kan. De vraag is hoe werkbaar die bibliotheek is zodra het synchroniseren klaar is.
De eerste synchronisatie was sneller dan we verwachtten, en niets op de machine bezweek: de CPU draaide op 2,1 van de 16 kernen, het netwerk op 5,9% van de verbinding, en de schijfwachtrij liep nooit vol. De problemen begonnen nadat we ons afmeldden bij Windows en opnieuw aanmeldden — wat elke gebruiker elke ochtend doet.
Elke bewering in dit artikel is gelabeld naar type:
Microsoft zegt — bevestigd door officiële documentatie.
Wij maten — een cijfer uit onze logs, ruwe CSV's bestaan.
Wij observeerden — wat er gebeurde, zonder verklaring waarom.
Onze interpretatie — onze conclusie, geen feit.
Openheid: wij bouwen OneMount, een tool die SharePoint-bibliotheken als Windows-schijf koppelt zonder te synchroniseren, dus we hebben een duidelijk belangenconflict. Daarom komen de cijfers en de methode eerst en het product pas na de conclusies. We konden geen gepubliceerde onafhankelijke benchmark van deze configuratie op een miljoen echte items vinden; als die bestaat, stuur hem op en we vergelijken de methodologie.
Ondersteunt OneDrive echt 1.000.000 bestanden?
Ja. Microsoft zegt: in openbare preview ondersteunt de OneDrive-synchronisatieclient tot 1.000.000 items per synchronisatie-instantie per apparaat (Microsoft-documentatie). Microsoft rolt de functie geleidelijk uit aan deelnemers van het Insider-programma.
Is de limiet van OneDrive 300.000 of 1.000.000 items?
Dit is het meest voorkomende verwarringspunt. Microsoft zegt: 300.000 items blijft de aanbeveling voor optimale prestaties. Het ene getal heeft het andere niet vervangen — beide gelden tegelijk en betekenen iets anders.
| Getal | Wat het betekent |
|---|---|
| tot 300.000 items | Microsofts aanbeveling voor optimale prestaties. Het getal om rond te plannen. |
| tot 1.000.000 items | De bovengrens van ondersteuning in openbare preview — geen garantie van prestaties. |
Vereisten voor Windows en hardware
Microsoft zegt — de vereisten voor de preview van 1.000.000 items:
- Windows 11 of Windows Server 2022 en nieuwer;
- minstens 16 GB RAM, 32 GB aanbevolen;
- een SSD, geen HDD;
- een processor van de klasse Intel Core i5 / AMD Ryzen 5 of beter;
- de OneDrive-client met de optie voor previewbuilds ingeschakeld;
- VDI wordt niet ondersteund.
Dat laatste punt is apart de aandacht waard: als uw omgeving op virtuele desktops draait, geldt de limiet van 1.000.000 items voor u nog niet. Dat is ook waarom onze test op een fysieke machine liep.
Hoe we OneDrive testten met 1 miljoen bestanden
De testbibliotheek op SharePoint
De bibliotheek is echt en in dagelijks gebruik, niet gegenereerd: documenten, exports, scans en projectmappen die zich jarenlang hebben opgestapeld, met de lange namen en diepe nesting die bij zo'n corpus horen.
Wij maten: het exacte aantal items kwam uit de REST-API van de bibliotheek vóór de synchronisatie startte — 997.392. Twee groottecijfers komen niet overeen, en dat is te verwachten: het beheercentrum meldt 1,38 TB (alle siteopslag inclusief versiegeschiedenis en prullenbak), terwijl de eigen database van de synchronisatie-engine 995 GB logische grootte telde — de huidige versies van bestanden, wat daadwerkelijk synchroniseert.
De testmachine
| CPU | Intel Core i9-11900K, 8 kernen / 16 threads |
|---|---|
| Geheugen | 32 GB — de hoogste aanbeveling van Microsoft |
| Schijf | NVMe-SSD met het gebruikersprofiel |
| OS | Windows 11 Pro 25H2, build 26200.9457 |
| OneDrive | 26.168.0830.0004, previewbuilds ingeschakeld |
| Verbinding | Beoordeeld op 99/100 Mbps; vooraf gemeten op 98,57 / 99,63 Mbps, 2 ms ping |
| Profiel | Een schoon, apart Windows-account |
We hebben zwakkere configuraties niet gemeten, dus elk cijfer hieronder geldt alleen voor deze bench. Onze verwachting dat een machine met minder geheugen en een tragere schijf slechter zou presteren, is een aanname, geen meting.
Hoe we maten
De bestandsboom doorlopen tijdens een synchronisatie is geen optie: het doorlopen zelf raakt de
bestandsstatus en zou vervormen wat u juist probeert te meten. Dus deden we dat niet. Voortgang wordt
rechtstreeks uitgelezen uit de database van de OneDrive-synchronisatie-engine
(SyncEngineDatabase.db, SQLite) — live en alleen-lezen. Dat levert het aantal items, de
verdeling cloud-only versus lokaal gedownload, de seconden aan serverzijdige beperking en de
responscodes. Belastingcijfers komen uit CIM, waar eigenschapsnamen niet afhankelijk zijn van de
weergavetaal van het besturingssysteem.
Een apart hydratatieonderzoek draait ernaast: het script probeert periodiek een klein cloud-only bestand uit de bibliotheek te openen met een harde time-out, legt het resultaat en de duur vast, en zet het bestand daarna terug naar zijn cloud-only staat. Die proef leverde de interessantste gegevens uit de hele test op.
Onze interpretatie: we gaan ervan uit dat de records in die database zijn waarop de limiet van 300.000 / 1.000.000 wordt toegepast — maar Microsoft publiceert zijn telmethode niet, dus dit is een aanname.
Hoe lang duurt het om 1.000.000 bestanden te synchroniseren?
52 minuten en 1.013.795 items
De klok start zodra het monitoren begint, met de bibliotheek nog niet gekoppeld. Synchroniseren werd vijf minuten later aangeklikt, en de itemteller begon 25 seconden daarna te bewegen. Het miljoenste item werd gepasseerd op 51,8 minuten, en de teller stopte met groeien bij 52,9.
900.000 items bij 46,3 min en
1.000.000 items bij 51,7 min, met de teller op 1.013.795. Het systeemvakpictogram
toont Opgeslagen en gesynchroniseerd.
| Items op het apparaat | 1.013.795 (905.313 bestanden + 108.482 mappen) |
|---|---|
| Toegevoegd tijdens deze run | 997.379 — de SharePoint-bibliotheek |
| Aanwezig vóór de start | 16.418 — de persoonlijke OneDrive van hetzelfde account |
| Cloud-only | 905.310 van 905.313 bestanden (99,9997%) |
| Lokaal gedownload | 3 bestanden |
De client deed precies wat hij belooft: hij bouwde een volledige boom van bijna een miljoen items zonder inhoud te downloaden. Wat op de schijf terechtkwam waren plaatshouders, geen bestanden. Het verschil tussen de 997.379 toegevoegde en de referentie van 997.392 is 13 items — rekenkunde tussen twee tellingen op verschillende momenten op een levende bibliotheek, geen lijst van bestanden waar we naar op zoek waren.
Synchronisatiesnelheid van OneDrive
| Mijlpaal | Min vanaf start | Tempo over het segment |
|---|---|---|
| 100.000 | 8,8 | — |
| 300.000 | 16,5 | 402 items/sec |
| 500.000 | 23,1 | 469 items/sec |
| 700.000 | 34,2 | 297 items/sec |
| 900.000 | 46,3 | 296 items/sec |
| 1.000.000 | 51,8 | 297 items/sec |
Wij maten: over de eerste twee segmenten hield de client 402 en 469 items/sec aan, waarna het tempo daalde naar 297 items/sec en daar bleef — 297,1, dan 296,5, dan 297,4. Dit is geen geleidelijke afname maar een stap naar een vlak plateau rond de helft. Het gemiddelde over de actieve fase was 351 items/sec, met een piek van 590.
Onze interpretatie: we kunnen de oorzaak niet noemen. Er was helemaal geen serverzijdige beperking — nul vensters, nul seconden, 1.156 serviceaanroepen en nul fouten. Netwerk, schijf en CPU waren in de tweede helft niet drukker dan in de eerste. Hoe vlak het plateau is, wijst op een vast plafond — grootte van aanvraagbatches, of het aantal parallelle streams — in plaats van een oplopende kostprijs.
Hoeveel RAM, CPU en schijf gebruikt OneDrive?
| Resource | Gemeten |
|---|---|
| RAM, piek | 3.579 MB |
| RAM na afronden | 2.790 MB |
| CPU, gemiddeld tijdens de actieve fase | 2,1 van 16 kernen (13,1%) |
| CPU, piek | 2,35 kernen (14,7%) |
| Netwerk, gedownload | ongeveer 2 GB |
| Schijf, gelezen / geschreven | 69,3 GB / 79,3 GB |
| Schijfwachtrij, 95e percentiel | 1 (piek 4) |
| Database van de synchronisatie-engine | 2.036 MB uiteindelijk, 2.318 MB op piek |
| Schijfverbruik, uiteindelijk | 6,57 GB |
| Piek vereiste vrije ruimte | 20,62 GB |
| Servicebeperking | 0 vensters, 0 seconden |
Een database van 2 GB. Wij maten: de engine besteedt ongeveer 2,1 KB van zijn eigen database per item. Die database staat in het gebruikersprofiel en wordt bij elke controle op wijzigingen gelezen en geschreven.
149 GB schijf-I/O voor 2 GB verkeer. Onze interpretatie: dat is ongeveer 75× schrijfversterking ten opzichte van wat via het netwerk kwam. Op NVMe merkt u er niets van; op een instap-SATA-SSD, of op een HDD, is dat een ander verhaal — precies waarom Microsoft een SSD als vereiste vermeldt.
20,62 GB op piek versus 6,57 GB in rust. Wij maten: vrije ruimte daalde van 253,93 GB naar 233,31 GB op het moment van 51,6 minuten. De tijdelijke vraag was 3,1× groter dan wat overbleef toen de run klaar was. Het praktische gevolg: een machine met ongeveer 10 GB vrij loopt midden in de synchronisatie vast zonder schijfruimte, zelfs als de eindtoestand ruim zou hebben gepast.
Heeft u snel internet nodig voor OneDrive-synchronisatie?
We draaiden de test specifiek hiervoor op een verbinding van 99 Mbps. Wij maten:
| Gemiddelde downloadsnelheid | 5,87 Mbps — 5,9% van de verbinding |
|---|---|
| 95e percentiel | 12,34 Mbps — 12,5% van de verbinding |
| Metingen bij ≥ 80% benutting | 0 |
| Metingen in de actieve fase onder 0,1 Mbps | 45,1% |
| Pure overdrachtstijd voor al het verkeer | ongeveer 3 minuten |
Voor bijna de helft van de actieve fase was het netwerk vrijwel stil, en alles wat de client downloadde zou deze verbinding in minder dan drie minuten oversteken — tegenover een run die 52 duurde.
In onze test was de verbinding niet de beperkende factor. Een snellere lijn zou deze run niet hebben verkort.
Onze interpretatie: de beperking is geen bandbreedte, maar de retourtijd naar de service en metadataverwerking. Een miljoen items betekent een miljoen records om op te halen, te verwerken en in een lokale database te schrijven, en een bredere pijp vermindert niet hoeveel van die bewerkingen er zijn.
Voor planning: als u al een stabiele 100 Mbps heeft, verdient het upgraden van de lijn om het synchroniseren te versnellen zichzelf niet terug — dat geld doet meer in RAM en NVMe. We hebben niet onder 100 Mbps gemeten.
Wat er gebeurt na de eerste synchronisatie
238 minuten vast op "Zoeken naar wijzigingen"
Met de synchronisatie klaar meldden we ons af bij Windows en opnieuw aan. Geen wijzigingen aan de bibliotheek, geen herstart.
Wij maten: het OneDrive-proces startte om 18:18:03, en "Opgeslagen en gesynchroniseerd" verscheen om 22:15:39.
14.255 seconden = 237,6 minuten = 3 uur 58 minuten — besteed aan het controleren van wijzigingen in een bibliotheek waar niets was veranderd. Dat is 4,6× langer dan de synchronisatie zelf.
Een belangrijk voorbehoud vooraf: die 238 minuten herhaalden zich niet. Drie volgende aanmeldcycli op dezelfde machine met dezelfde bibliotheek duurden 20,7–36,6 seconden, en elke poging om een bestand te openen tijdens die cycli slaagde — details in de sectie over herhaalde cycli hieronder.
Gedetailleerde belastingsmetingen dekken 116,9 van die 237,6 minuten — het monitoringscript was niet op de allereerste seconde gestart. De volledige duur wordt gemeten van het starten van het OneDrive-proces tot de statuswijziging; beide punten zijn betrouwbaar vastgelegd.
| Serviceaanroepen | 14 — twee daarvan EnumChanges; nul fouten |
|---|---|
| Gedownload | ongeveer 22 MB (een bovengrens voor de hele machine) |
| Schijf, OneDrive-proces | 0,50 GB gelezen / 0,17 GB geschreven |
| Database van de synchronisatie-engine | onveranderd |
| Wijziging van het aantal items | nul — geen enkel record |
| CPU | gemiddeld 1,03 kernen, piek 1,79 |
| RAM | groeide van 936 MB naar 2.501 MB |
Wij maten: de itemteller bewoog geen enkele keer over de hele geobserveerde fase — 1.013.795 bij elke meting. Twee nieuwe items verschenen 33 seconden na de status "Opgeslagen en gesynchroniseerd". Van de 19 EnumChanges-aanroepen vielen er maar 2 binnen de fase; de andere 17 kwamen terecht in het kwartier erna.
Onze interpretatie: dit lijkt niet op het downloaden van gegevens, of zelfs op een actief gesprek met de service. Het lijkt op langdurig intern werk tegen de eigen status van de client — dezelfde database van 2 GB. We kunnen dit niet bevestigen: Microsoft publiceert niet wat de client in deze fase doet.
Wij observeerden: van buitenaf ziet de fase normaal uit. Het systeemvakpictogram toont "Zoeken naar wijzigingen" — hetzelfde wat het toont tijdens de vijf seconden durende controle na een gewone ochtendstart. We zagen geen voortgangsindicator, geen tijdschatting en geen waarschuwing. In de standaardinterface van de client vonden we niets dat onderscheid maakt tussen "wacht 20 seconden" en "wacht 4 uur."
Konden bestanden niet openen tijdens de controle
Dit is gemeten, niet geschat: het hydratatieonderzoek draaide de hele tijd.
| Wanneer | Pogingen | Mislukt | Aandeel |
|---|---|---|---|
| Tijdens de controle op wijzigingen | 45 | 44 | 98% |
| Nadat de client zijn werkende status had bereikt | 9 | 0 | 0% |
Wij maten: van 45 pogingen om een bestand te openen tijdens de fase slaagde één, en die duurde 49.342 ms — bijna 50 seconden voor een bestand van een paar honderd kilobyte. Zodra de client zijn werkende status had bereikt, duurden dezelfde proeven 305–645 ms.
OneDrive-fout 0x800701AA
Precisie telt hier. De geautomatiseerde proef breekt af na 60 seconden en registreert een
timeout, wat betekent dat ze de aanroep afbreekt voordat Windows een foutcode teruggeeft.
Wij observeerden: de code verscheen toen we handmatig een bestand
openden aan het begin van dezelfde fase:
0x800701AA — De cloudbewerking is niet voltooid voordat de time-outperiode
verliep.
Wij observeerden: Excel reageerde hierop twee keer met "het bestandsformaat of de bestandsextensie is niet geldig" — de toepassing ontving een gedeeltelijke of lege stream en trok zelf de verkeerde conclusie. Onze interpretatie: zo ontstaan conflicterende kopieën en "beschadigde" documenten. De gebruiker ziet een formaatfout, slaat het bestand onder een andere naam op, en de keten gaat door zonder dat OneDrive er nog bij betrokken is.
Gebeurt dit bij elke herstart?
238 minuten tot een regel maken zou oneerlijk zijn. We draaiden een derde test — herstart- en aanmeldcycli op dezelfde machine met dezelfde bibliotheek. Vier runs werden vastgelegd; drie legden een volledige cyclus vast.
| Cyclus | Trigger | Tot "Opgeslagen en gesynchroniseerd" |
|---|---|---|
| 1 | Schone herstart | 36,6 s (129,6 s vanaf opstarten) |
| 2 | Aanmelden, machine 11 uur aan | 20,7 s |
| 3 | Aanmelden, 74 minuten na opstarten | 35,8 s |
Wij maten: op consistente basis lag de spreiding tussen 20,7–36,6 seconden. Het hydratatieonderzoek draaide 12 keer met 12 successen, en zes van die proeven kwamen precies in de staat "Zoeken naar wijzigingen" terecht — allemaal succesvol, bij 707–2.572 ms. In rust hield het proces 1.507–2.187 MB geheugen vast: op een bibliotheek van een miljoen items is anderhalf tot twee gigabyte RAM permanent bezet.
[11:20:31] status -> LookingForChanges met drie opeenvolgende succesvolle proeven
(2.212, 707 en 1.062 ms). Dezelfde statusnaam als tijdens de fase van 238 minuten, en het
tegenovergestelde gedrag.
Een voorbehoud: we kunnen niet stellen dat de client in die cycli evenveel werk verrichtte. De lange fase was de eerste aanmelding na de eerste synchronisatie; de drie daaropvolgende waren dat niet. We hebben niet gemeten hoe vaak het gebeurt.
Onze interpretatie: dat is precies wat het een operationeel probleem maakt. Een gebeurtenis die zeldzaam en onvoorspelbaar is, maar uren duurt en normaal oogt, is moeilijker te beheren dan een gewone fout — een fout verschijnt in monitoring, en dit niet.
Wat een miljoen bestanden betekent op honderden pc's
Onze interpretatie: alles in deze sectie is een conclusie getrokken uit ervaring met uitrol, geen gemeten cijfer.
Resources vermenigvuldigen met het aantal machines. 6,6 GB schijf in rust en tot 21 GB op piek — op elk apparaat. Een servicedatabase van 2 GB die bij elke controle op wijzigingen gelezen en geschreven moet worden. Een piek van 3,6 GB RAM: op machines met 8 GB concurreert dat al met de toepassingen waarin mensen werken, en het minimum van 16 GB van Microsoft is geen formaliteit.
Een zeldzame gebeurtenis stopt zeldzaam te zijn op grote schaal. We weten niet hoe vaak de pathologische fase voorkomt en zullen geen cijfer verzinnen, maar de rekenkunde van schaal is onmiskenbaar: op honderden machines stopt zelfs een zeldzaam, incidenteel probleem het probleem van één gebruiker te zijn — de omvang wordt bepaald door het aantal apparaten en hoe vaak dergelijke gebeurtenissen optreden.
Gebruikers wachten niet. De 52 minuten kwamen van een inactieve, ideale machine; op een werkende laptop concurreert elk geopend bestand en elke Excel-start met de synchronisatie om dezelfde schijf en CPU.
Een tweede apparaat betekent een tweede identieke run. De limiet wordt gedefinieerd per synchronisatie-instantie per apparaat: iemand met een laptop en een desktop doorloopt de hele cyclus twee keer.
Wat de test liet zien
Beter dan verwacht. De eerste synchronisatie van een miljoen items is snel, voorspelbaar en goedkoop in resources: 52 minuten, 2 GB verkeer, 2 van de 16 kernen, nul servicefouten, nul beperking. Als engineering is dat een serieus resultaat.
Wat in onze test een probleem werd. Na de eerste synchronisatie besteedde de client 238 minuten aan "Zoeken naar wijzigingen," en 44 van de 45 pogingen om een bestand te openen mislukten door time-out. Drie volgende aanmeldcycli reproduceerden dat gedrag niet.
Praktische richtlijnen:
- Tot 300.000 items — OneDrive-synchronisatie blijft een verstandige keuze, en onze gegevens weerspreken de aanbeveling van Microsoft niet.
- Tussen 300.000 en 1.000.000 — het zal werken, maar alleen op machines die aan de previewvereisten voldoen, en met het besef dat u zich in "ondersteund" gebied bevindt, niet "aanbevolen".
- Een vloot van honderden machines — begroot voor de kosten van de stabiele toestand, niet voor de duur van de eerste synchronisatie.
- VDI — de limiet van 1.000.000 items geldt voor u niet.
Moet u werken met een grote SharePoint-bibliotheek zonder die lokaal te synchroniseren?
OneMount koppelt SharePoint en OneDrive als Windows-schijf: bestanden blijven in de cloud en mensen werken ermee in de Verkenner — zonder eerste synchronisatie van een grote bibliotheek en zonder lokale index van een miljoen items.
OneMount proberen →Hoe u met een grote SharePoint-bibliotheek werkt
Splits de bibliotheek
Breek het corpus op in meerdere bibliotheken of sites, zodat elk apparaat minder dan 300.000 items synchroniseert. Het werkt, maar het vereist herstructurering, mensen opnieuw trainen en het breekt bestaande links — vaak duurder organisatorisch dan technisch.
Selectieve synchronisatie
"Mappen kiezen" voorkomt dat u de hele boom binnenhaalt. Maar de limiet telt wat u heeft geselecteerd, gebruikers vinken na een tijdje meer aan dan nodig, en het bespaart u de fase van controleren op wijzigingen niet voor wat wel synchroniseert.
Houd mensen in de browser
De veiligste optie vanuit het oogpunt van de client en de slechtste vanuit de gewoonte: waar mensen al jaren met een schijfletter werken, stuit teruggaan naar een webinterface op weerstand, en een deel van het team vindt workarounds.
Koppel SharePoint als schijf zonder te synchroniseren
Dit is de richting die wij hebben gekozen — en hier herhalen we de openheid over het belangenconflict: wij bouwen OneMount, dus we zijn geen neutrale partij.
De logica is simpel. Elk cijfer in dit artikel — 52 minuten, een database van 2 GB, 149 GB schijf-I/O, 238 minuten controleren — is de prijs van het onderhouden van een lokale kopie van de status van een miljoen items. Zonder die kopie verdwijnt de prijs: er is niets te verifiëren na aanmelden, geen database die lineair meegroeit met het aantal items, geen piek van 21 GB op de systeemschijf. In ruil neemt u andere compromissen op u: een verbinding is vereist, en hoe snel een document opent hangt af van de lijn in plaats van de lokale schijf.
Onze interpretatie: voor bibliotheken waar het grootste deel van het corpus archief is dat zelden wordt aangeraakt — in onze testbibliotheek werd ongeveer 2% van de bestanden in 30 dagen aangeraakt — lijkt het bijhouden van een volledige lokale index van een miljoen items op elk apparaat een hoge prijs voor een klein voordeel. Maar dat is onze beoordeling, en uw gebruiksprofiel kan anders zijn.
Veelgestelde vragen: OneDrive en 1.000.000 bestanden
Hoeveel bestanden kan OneDrive synchroniseren?
Tot 1.000.000 items per synchronisatie-instantie per apparaat in openbare preview, mits aan de vereisten wordt voldaan. De limiet telt items, dus bestanden en mappen samen.
Is de limiet van OneDrive 300.000 of 1.000.000 bestanden?
Beide. 300.000 is Microsofts aanbeveling voor optimale prestaties, en 1.000.000 is de bovengrens van ondersteuning in openbare preview. Het ene heeft het andere niet vervangen.
Hoe lang duurt het om 1 miljoen bestanden te synchroniseren?
In onze test 52 minuten voor 997.392 items op een machine met een Core i9, 32 GB RAM, een NVMe-SSD en een verbinding van 99 Mbps. Het gemiddelde tempo over de actieve fase was 351 items/sec. Op een zwakkere machine, of met andere taken op de achtergrond, duurt het langer.
Kan OneDrive 1 miljoen bestanden synchroniseren op Windows 11?
In openbare preview ondersteunt Microsoft tot 1.000.000 items per synchronisatie-instantie, mits aan de vereisten voor Windows, RAM, SSD en de OneDrive-client wordt voldaan. In onze test synchroniseerde Windows 11 Pro 25H2 met 32 GB RAM en een NVMe-SSD 997.392 items in ongeveer 52 minuten.
Waarom blijft OneDrive hangen op "Zoeken naar wijzigingen"?
We registreerden twee modi die dezelfde naam in de interface delen: een korte (20,7–36,6 seconden, bestanden beschikbaar) en een lange (238 minuten, waarbij 44 van de 45 pogingen om een bestand te openen mislukten door time-out). We hebben niet vastgesteld wat de omschakeling veroorzaakt, en niets in de standaardinterface onderscheidt de twee.
Waarom is OneDrive traag bij het synchroniseren van een grote bibliotheek?
Volgens onze metingen is de beperkende factor niet het netwerk of de schijf, maar de retourtijd naar de service en metadataverwerking. Opvallend is dat het tempo alleen in de eerste helft van de bibliotheek op 402–469 items/sec blijft, en daarna daalt naar een stabiele 297.
Hoeveel RAM gebruikt OneDrive?
De piek tijdens de eerste synchronisatie was 3.579 MB. In rust, zonder dat er iets gebeurde, hield het proces 1.507–2.187 MB vast. Tijdens de lange fase van controleren op wijzigingen groeide het gebruik van 936 MB naar 2.501 MB over twee uur observatie.
Hoeveel schijfruimte kost het synchroniseren van een miljoen items?
6,57 GB in rust met alle bestanden cloud-only, met een piek van 20,62 GB tijdens de run. Daarvan is 2.036 MB de eigen database van de synchronisatie-engine — ongeveer 2,1 KB per item.
Heeft u snel internet nodig voor OneDrive-synchronisatie?
Volgens onze metingen, nee — niet als u al ongeveer 100 Mbps heeft. OneDrive gebruikte gemiddeld 5,9% van de verbinding en kwam nooit dicht bij volledige benutting.
Wat is OneDrive-fout 0x800701AA?
"De cloudbewerking is niet voltooid voordat de time-outperiode verliep" — het verzoek om de inhoud van een cloudbestand te downloaden was niet binnen de toegestane tijd klaar. In onze test zagen we deze code tijdens de lange fase van controleren op wijzigingen; daarbuiten mislukte geen poging om een bestand te openen.
Ondersteunt OneDrive 1 miljoen bestanden op VDI?
Nee. Microsoft stelt uitdrukkelijk dat VDI niet wordt ondersteund in deze preview.
Hoe werkt u met een grote SharePoint-bibliotheek zonder te synchroniseren?
Er zijn vier opties: de bibliotheek splitsen, selectief synchroniseren, mensen in de browser houden, of de bibliotheek als Windows-schijf koppelen zonder lokale kopie van de status. De laatste optie verwijdert elke kost die in dit artikel is gemeten maar vereist een permanente verbinding — meer details in hoe u met een grote SharePoint-bibliotheek werkt.
Voor de praktische kant — hoe u SharePoint koppelt aan een schijfletter, welke methoden er bestaan en welke daarvan standhouden onder belasting: SharePoint koppelen als netwerkschijf in Windows →
Heeft u deze weg al afgelegd en herkent u de symptomen — ons verhaal over het jaar dat we vochten tegen synchronisatie op een terabyte-bibliotheek →
Bronnen
- Microsoft — beperkingen en limieten in OneDrive en SharePoint: de aanbeveling van 300.000 items.
- Microsoft Learn — ondersteuning van de synchronisatieclient op VDI.
- Microsoft — OneDrive-synchronisatie vast op "wijzigingen verwerken."
- Eigen metingen van SkylFlow, 19–20 september 2026: drie tests op een fysieke machine, volledige logs in CSV en JSON.
Reproduceerbaarheid. Elk cijfer hier komt uit ons eigen meetscript, dat de database van de OneDrive-synchronisatie-engine live en alleen-lezend uitleest en belastingcijfers via CIM verzamelt. Het script, het testprotocol en de ruwe CSV's worden voorbereid voor publicatie — schrijf ons als u de test op uw eigen bibliotheek wilt herhalen.