Søgningen viser andre datoer end biblioteket efter migrering

Migreringen gik gennem Migration API, og den satte Oprettet og Ændret i dokumentbiblioteket. Men søgningen viste andre datoer for de samme dokumenter.

Det ligner en fejl i migreringen. Den forklaring, Microsoft selv har givet, er en anden: biblioteket og søgningen læser datoen to forskellige steder. I september 2026 lukkede Microsoft en fejlrapport om det som “expected and known behavior since SharePoint 2013” (GitHub).

Biblioteket har migreringens datoer#

Migration API får datoerne i manifestet. Hver fil har TimeCreated og TimeLastModified (Microsoft), og det er dem, biblioteket viser som Oprettet og Ændret. SharePoint Migration Tool og tredjepartsværktøjer lægger indholdet ind gennem Migration API (Microsoft), og det samme gør fx ShareGate i Insane mode (ShareGate). Fra et fildrev tager Microsofts værktøjer oprettelsesdatoen, ændringsdatoen, Oprettet af og Ændret af med (Microsoft). Kommer indholdet fra et fildrev, er det filsystemets datoer. Kommer det fra SharePoint Server eller et andet system, er det det systems datoer.

Selve filen kommer også med. Et Word-dokument har sine egne datoer inde i filen: hvornår det blev oprettet, og hvornår det sidst blev gemt i Word. Ved en almindelig upload lader SharePoint de datoer være (Microsoft Q&A). Ingen kilde siger, at Migration API ændrer dem, men det er ikke efterprøvet.

Søgningen har dokumentets ændringsdato#

Søgningen viser ikke bibliotekets kolonner. Den viser administrerede egenskaber, og de er mappet fra gennemsøgte egenskaber. Ifølge Microsofts tabel (Microsoft):

LastSavedDateTime er, som navnet siger, hvornår dokumentet sidst blev gemt. ows_Modified er bibliotekets Ændret. Egenskaberne står til Include content from the first crawled property that is not empty, så den første værdi, der findes, vinder. For et Word-dokument er det dokumentets egen ændringsdato.

Tabellen står under SharePoint Server. I SharePoint Online ser mappingen for LastModifiedTime sådan ud på et skærmbillede fra en tenant i september 2026: LastModifiedTime, LastSavedDateTime, Basic:#14, Basic:#16, ows_Modified, lastaccessed, og samme indstilling (GitHub). Bibliotekets Ændret står som nummer fem. Basic:14, Basic:15 og Basic:16 er filens datoer set udefra: sidst skrevet, oprettet og sidst åbnet (Microsoft, Microsoft). For en fil i SharePoint er det i praksis SharePoints egne datoer. Derfor følger en fil uden egne datoer, fx et billede, biblioteket, selv om ows_Modified står langt nede.

Microsofts support skrev det samme i 2018: søgeresultaterne viser Office-dokumentets egne datoer, mens biblioteket viser SharePoints, og det gælder også eDiscovery (Microsoft). Microsofts feltbeskrivelse til eDiscovery siger det i dag med egne ord: datoen for et SharePoint-dokument er “Last modified date of the document; if not available, SharePoint last modified date” (Microsoft). En PDF har også sine egne datoer, og i en tråd fra 2019 kom søgningens ændringsdato fra PDF’ens egenskaber (Microsoft Q&A).

Oprettelsesdatoen er sandsynligvis en anden sag. Office:12 er Office-dokumentets oprettelsesdato i kategorien Office. Nummeret svarer til Create Time/Date i Office-dokumenternes egenskabssæt, Summary Information, hvor 2 er titlen og 13 er, hvornår dokumentet sidst blev gemt (Microsoft). Det passer med, at Office:2 er mappet til Title, men Microsoft skriver det ikke i dokumentationen til søgningen. Fra SharePoint 2013 kommer egenskaberne fra Office-filer dog i kategorien Document Parser i stedet, som CreatedDateTime og LastSavedDateTime (Microsoft). LastSavedDateTime er mappet til LastModifiedTime, men CreatedDateTime er ikke mappet til Created. For .docx, .xlsx og .pptx falder Created derfor sandsynligvis igennem til Basic:15, altså SharePoints egen oprettelsesdato. I en rapport fra SharePoint 2013 viste Created uploaddatoen for et Word-dokument, indtil CreatedDateTime blev føjet til mappingen (Stack Exchange). I SharePoint Online passede søgningens oprettelsesdato med bibliotekets i Content Search i 2018 og i Microsoft Graphs søgning i 2022, mens ændringsdatoen ikke gjorde (Tech Community, Microsoft Q&A). Supportbloggen fra 2018 er den eneste kilde, der siger, at oprettelsesdatoen også er dokumentets, og den nævner ikke filtyper. Om Office:12 stadig bliver udfyldt for de gamle formater .doc, .xls og .ppt, er ikke efterprøvet. Scriptet nedenfor afgør det.

Hvorfor migreringen gør det synligt#

Forskellen findes også uden migrering. Et dokument, der uploades i browseren, får dags dato i biblioteket og beholder sine egne datoer i filen. Men i en migrering er det hele meningen, at datoerne skal passe, og alle dokumenterne kommer på én gang. Så bliver forskellen systematisk, og den bliver opdaget.

De to datoer er ens, når ingen har rørt filen uden for Word. De skilles ad, når:

• filen er kopieret eller lagt tilbage fra en sikkerhedskopi. Så kan filsystemets datoer være sat på ny, mens dokumentets egne datoer følger med inde i filen.
• metadata er ændret i kilden. I SharePoint Server eller et dokumentsystem flytter en ændret kolonne Ændret, men ikke datoen inde i filen. Det samme sker bagefter i SharePoint Online. En fejlrapport fra september 2026 beskriver et Word-dokument, der sidst var gemt i november 2024. Efter en ændring af metadata i SharePoint viste biblioteket den nye dato, mens søgningen stadig viste november 2024, også efter en genindeksering (GitHub). Det samme blev beskrevet på SharePoint Server 2013 i 2017. Der fulgte et billede i PNG med biblioteket, mens Word-dokumenter og PDF’er ikke gjorde (MSDN). Det afhænger altså af filtypen, ikke af migreringen.

En genindeksering ændrer intet#

Det første, der ligger lige for, er at genindeksere biblioteket. Det hjælper ikke. En genindeksering læser de samme egenskaber i samme rækkefølge og kommer frem til den samme dato. Den, der skrev fejlrapporten fra 2026, genindekserede og så det samme på andre tenants (GitHub). I en tråd fra 2025 var datoen den samme efter en uge og en genindeksering (Microsoft Q&A.

Microsofts løsning i 2018 var at flytte ows_Modified op i rækkefølgen på LastModifiedTime og Created og så genindeksere. I dag skriver Microsoft på siden om søgeskemaet: “It is not advisable to change the mapping or mapping order of crawled properties for existing managed properties”, fordi andre dele af Microsoft 365 kan bygge på dem (Microsoft). De indbyggede egenskaber skal altså have lov at være, som de er.

Ikke alle er enige. Mikael Svenson fra Microsoft, der lukkede fejlrapporten, skriver, at man godt kan ændre rækkefølgen eller fjerne dokumentets egenskab fra mappingen, hvis man vil have bibliotekets dato (GitHub). Et svar på Stack Exchange fra 2017 fraråder det, men kalder det ikke skadeligt (Stack Exchange).

Det rammer mere end søgesiden#

• Sortering og datofiltre. “Nyeste først” og et filter på “ændret i år” bruger søgningens datoer, ikke bibliotekets.
• PnP Modern Search. Med datakilden SharePoint Search lægger webdelen som standard Created i layoutenes datofelt (PnP), altså søgningens oprettelsesdato, som for nyere Office-filer sandsynligvis er bibliotekets. Med datakilden Microsoft Search er det createdDateTime fra Microsoft Graph (PnP).
• eDiscovery. Egenskaben til datoer i KeyQL er LastModifiedTime (Microsoft), og betingelsen Date er for dokumenter “the date a document was last modified” (Microsoft). En søgning efter “ændret i perioden” kan derfor ramme ved siden af.
• Opbevaringsetiketter, der sættes på med en forespørgsel. De bruger samme indeks som eDiscovery (Microsoft), så en forespørgsel med LastModifiedTime sætter etiketten efter dokumentets dato.
• Opbevaring fra “sidst ændret”. Hvilken dato en opbevaringspolitik regner fra, skriver Microsoft ikke i dokumentationen om opbevaring. Et svar i Microsofts forum fra 2018 bygger på en test og siger, at det er bibliotekets Ændret (Microsoft Q&A). To tråde fra 2018 og 2019 siger det samme (Tech Community, Tech Community). Egenskaben LastModifiedTimeForRetention er mappet til bibliotekets Ændret, og eDiscovery beskriver den som “SharePoint document upload time for retention purposes” (Microsoft). Det er ikke dokumenteret, men kilderne er enige. Til gengæld kan en fil, der lægges op med OneDrive-synkroniseringen, beholde sin gamle dato i Ændret og blive slettet af en politik med det samme (Tech Community).

Sådan måles det#

En sammenligning af bibliotekets datoer med søgningens for de samme filer, med PnP PowerShell. Resultatet er en CSV-fil med én række pr. fil.

 1Connect-PnPOnline -Url "https://<tenant>.sharepoint.com/sites/<site>" -Interactive -ClientId "<client-id>"
 2
 3$library = "<library>"
 4$hostUrl = ([Uri](Get-PnPWeb).Url).GetLeftPart([UriPartial]::Authority)
 5$rootUrl = (Get-PnPList -Identity $library -Includes RootFolder).RootFolder.ServerRelativeUrl
 6
 7# What the library shows
 8$items = Get-PnPListItem -List $library -PageSize 500 -Fields FileRef, Created, Modified |
 9    Where-Object { $_.FileSystemObjectType -eq "File" }
10
11# What search has
12$hits = Submit-PnPSearchQuery -Query "path:`"$hostUrl$rootUrl`" IsDocument:true" -All -RelevantResults `
13    -SelectProperties Path, Created, LastModifiedTime, LastModifiedTimeForRetention
14
15$searchByPath = @{}
16foreach ($h in $hits) { $searchByPath[[Uri]::UnescapeDataString($h.Path)] = $h }
17
18$items | ForEach-Object {
19    $h = $searchByPath[$hostUrl + $_.FieldValues.FileRef]
20    [pscustomobject]@{
21        File                  = $_.FieldValues.FileRef
22        CreatedLibrary        = $_.FieldValues.Created
23        CreatedSearch         = $h.Created
24        ModifiedLibrary       = $_.FieldValues.Modified
25        ModifiedSearch        = $h.LastModifiedTime
26        ModifiedForRetention  = $h.LastModifiedTimeForRetention
27    }
28} | Export-Csv -Path ".\dates.csv" -NoTypeInformation -Encoding UTF8

Ikke kørt. En fil uden søgedatoer er ikke gennemsøgt endnu eller holdt ude af søgningen, se Når søgningen i SharePoint Online ikke finder det. Er forskellen præcis en eller to timer, er det tidszonen og ikke dokumentets dato. CreatedSearch mod CreatedLibrary viser også, hvilken oprettelsesdato søgningen har. Tag både .docx og gamle .doc-filer med i prøven.

For et enkelt Word-dokument kan datoerne inde i filen læses direkte. De står i docProps/core.xml:

1Add-Type -AssemblyName System.IO.Compression
2$stream = Get-PnPFile -Url "<server-relative-file-url>" -AsMemoryStream
3$zip = [System.IO.Compression.ZipArchive]::new($stream)
4$core = [xml]([System.IO.StreamReader]::new($zip.GetEntry("docProps/core.xml").Open())).ReadToEnd()
5$core.coreProperties.created.'#text'
6$core.coreProperties.modified.'#text'

Passer modified med søgningens ændringsdato og ikke med bibliotekets, er forklaringen den her. created behøver ikke at passe med søgningens Created, fordi dokumentets oprettelsesdato sandsynligvis ikke er mappet til Created for de nyere formater.

Det, der kan gøres#

• Brug en egen datoegenskab. Map ows_Modified til en ledig RefinableDate, og ows_Created til en anden, giv dem et alias, og genindeksér biblioteket. Så har søgningen bibliotekets datoer ved siden af dokumentets, og søgesider og filtre kan bruge dem. Hvordan en RefinableDate mappes, står i Et datofilter i forespørgslen i PnP Modern Search. Egenskaben til oprettelsesdatoen er måske overflødig for .docx, men det viser målingen.
• Eller brug LastModifiedTimeForRetention til ændringsdatoen i SharePoint-søgningen og PnP Modern Search. Den er allerede mappet til ows_Modified, den kan søges på i SharePoint Online (Vladilen, GitHub), og PnP Modern Search har den på listen over felter, der kan sorteres på (PnP). At den kan sorteres på i SharePoint Online, står dog kun i tabellen for SharePoint Server. I Purview er den ikke sikker. Content Search genkendte den ikke i 2019 (Tech Community), og i en test fra 2022 gav en RefinableDate mere ensartede resultater til opbevaringsetiketter (Joanne Klein). Til eDiscovery og etiketter er en egen RefinableDate det sikre valg. Til oprettelsesdatoen findes der ikke noget tilsvarende, men for nyere Office-filer er Created sandsynligvis allerede bibliotekets.
• Til visning kan ModifierDates bruges. Svenson peger på den i fejlrapporten (GitHub). Den har SharePoints ændringsdatoer, nyeste først, men den kan hverken søges, filtreres eller sorteres på, og den er “not guaranteed to contain data” (Microsoft). Om migrerede filer har den, er ikke efterprøvet.
• Ret ikke rækkefølgen på Created og LastModifiedTime. Det var Microsofts råd i 2018, men ikke i dag. Svenson mener, at det er i orden, men en egen RefinableDate giver bibliotekets dato uden at røre de indbyggede egenskaber, som andre dele af Microsoft 365 kan bygge på.
• Sig det til dem, der bruger eDiscovery. En datobetingelse på dokumenter betyder dokumentets dato. Det skal med i beskrivelsen af søgningen, når den skal bruges som dokumentation.
• Beslut det før migreringen. Hvilken dato skal søgningen vise: den, dokumentet selv har, eller den, biblioteket har? Og test det på en prøve, inden resten flyttes. Det hører til i samme overvejelser som Søgeindstillinger ved en migrering.