OneDrive-pad te lang: waarom Copilot die bestanden niet ziet

De algemene uitrol start medio september 2026 en is naar verwachting medio oktober 2026 afgerond. De wijziging is beschreven in Microsoft 365 Message Center bericht MC1422063 en roadmap-ID 557563. Er is geen actie van beheerders nodig, de update komt automatisch mee met de OneDrive-synchronisatieclient op Windows.

Let op dat Microsoft de planning eerder al een keer heeft opgeschoven, van medio augustus naar medio september. Reken dus niet op de dag nauwkeurig en communiceer richting je servicedesk in weken in plaats van in data.

Copilot werkt op basis van wat via Microsoft Graph vindbaar is voor de betreffende gebruiker. Een bestand dat door een synchronisatiefout alleen lokaal op een laptop staat, is niet geïndexeerd en dus onzichtbaar voor Copilot en voor Microsoft Search. Het valt daarmee ook buiten bewaarbeleid en versiebeheer.

Dat maakt dit onderwerp interessanter dan het lijkt. Organisaties investeren fors in Copilot-licenties en adoptietrajecten, en meten daarna teleurgesteld dat medewerkers geen bruikbare antwoorden krijgen. Soms ligt dat aan promptvaardigheid. Vaak ligt het aan de staat van de onderliggende informatie, en synchronisatiefouten zijn daar een keurige graadmeter voor. Wat niet in de cloud staat, bestaat voor Copilot simpelweg niet.

Voor beheerders is de actie beperkt maar concreet. Licht je servicedesk in, want de meldingen die binnenkomen zien er straks anders uit en een deel van de tickets zal wegvallen. Loop je interne documentatie over synchronisatieproblemen langs, want de oude uitleg klopt na de uitrol niet meer.

Voor functioneel beheer en informatiemanagement is dit een aanleiding om te kijken waar die lange paden vandaan komen. Meestal is het een erfenis. Een oude fileshare is één op één overgezet naar SharePoint, en de gebruiker synchroniseert die bibliotheek ook nog eens onder een OneDrive-pad dat zelf al lang is. Je ziet dit vooral bij advocatenkantoren met dossierstructuren, bij accountants met jaardossiers per entiteit, bij bouw- en architectenbureaus met tekeningnummers in elke bestandsnaam, en bij overheidsorganisaties waar zaaknummers de mappenboom domineren.

Voor adoptie- en changeprofessionals is het een herkenbaar patroon. Mensen lossen een blokkade op door eromheen te werken. Een kopie op de bureaubladmap, een bestand via WeTransfer, een map in een persoonlijke OneDrive die eigenlijk projectmateriaal bevat. Die workarounds verdwijnen niet vanzelf zodra de foutmelding vriendelijker wordt. Ze verdwijnen als mensen begrijpen waarom de structuur is zoals hij is en er zelf mee uit de voeten kunnen.

Lange paden ontstaan vrijwel altijd door diep geneste mappenstructuren die één op één zijn overgezet vanaf een oude fileshare. Beperk het aantal mapniveaus en gebruik metadata en weergaven in plaats van submappen. Beperk daarnaast welke bibliotheken volledig gesynchroniseerd worden en zet in op snelkoppelingen naar OneDrive in combinatie met bestanden op aanvraag. Leg naamgevingsafspraken vast op het moment dat een werkruimte wordt aangemaakt, niet achteraf.

Wacht daar niet mee tot oktober. Breng eerst in beeld hoeveel van dit soort fouten er eigenlijk spelen, want dat aantal is bijna altijd hoger dan de ticketstatistiek suggereert. Vraag het gewoon aan een paar teams die veel met documenten werken. En bedenk bij dat laatste punt dat achteraf opruimen werk is dat niemand vrijwillig oppakt, terwijl afspraken vooraf nauwelijks moeite kosten.

De foutmelding wordt in oktober beleefder en behulpzamer, en dat is winst. Maar de vraag die eronder ligt, verandert er niet door. Die vraag is of jullie informatiehuishouding is meegegroeid met de manier waarop mensen inmiddels werken, of dat je nog steeds een fileshare uit 2014 aan het synchroniseren bent met een cloud die daar nooit voor bedoeld was.

Bron: Microsoft 365 Message Center, bericht MC1422063, laatst bijgewerkt op 17 augustus 2026. https://www.microsoft.com/nl-nl/microsoft-365/roadmap?id=557563