Hvor længe gemmes Windows’ event log? Størrelse og overskrivning

Forside › Windows-forensik · Gennemgået oktober 2026 · Af John Nielsen

Kort svar: Der er ingen fast opbevaringstid. Windows gemmer hændelser, indtil loggen når sin maksimale størrelse, og overskriver derefter de ældste som standard. Security-loggen er på nyere klienter normalt sat til 20 MB. Om det rækker til timer, dage eller måneder, afhænger af, hvor mange hændelser maskinen skriver. Svaret skal aflæses på den konkrete maskine.

Artiklen forklarer, hvordan størrelse og opbevaring styres, og hvordan perioden dokumenteres. Selve eksporten af logs er beskrevet i eksport af Windows-hændelseslogs, og hvilke hændelser der overhovedet skrives, afhænger af revisionspolitikken.

Størrelse, ikke tid

Hver kanal, fx Security, System, Application og de mange kanaler under Applications and Services Logs, har sin egen fil i C:\Windows\System32\winevt\Logs og sin egen maksimale størrelse. Windows ser ikke på hændelsernes alder. Det eneste, der tæller, er, om filen er fuld.

Derfor varierer perioden voldsomt mellem maskiner med samme indstilling:

En stille klient uden procesrevision kan have flere måneder i Security-loggen.
En klient med procesoprettelse og kommandolinje i 4688 kan fylde den samme størrelse på få dage.
En domænecontroller eller filserver med fuld revision kan overskrive på timer.

Microsofts politikindstilling for Security-loggens størrelse tillader værdier fra 20 MB og op til 2 TB. Andre kanaler har mindre standardværdier. PowerShell-Operational-loggen og mange program-kanaler er små og ruller hurtigt.

Tre måder at håndtere en fuld log på

Overskriv hændelser efter behov · Hvad der sker, når loggen er fuld: De ældste hændelser overskrives løbende · Spor: Ingen hændelse markerer overskrivningen
Arkivér loggen, når den er fuld · Hvad der sker, når loggen er fuld: Den fulde log gemmes som arkivfil, og en ny startes · Spor: Hændelse 1105 og en fil med navnet Archive-Security-ÅÅÅÅ-MM-DD-tt-mm-ss-nnn.evtx
Overskriv ikke hændelser · Hvad der sker, når loggen er fuld: Nye hændelser kasseres, indtil loggen ryddes manuelt · Spor: Hændelse 1104 om, at Security-loggen er fuld

Standard er overskrivning. Arkivering er sjælden på klienter, men findes på servere med krav om lang opbevaring. Findes der arkivfiler i logmappen, skal de sikres sammen med den aktive log. Microsoft angiver, at tiden i arkivfilens navn og i hændelse 1105 altid er UTC.

Sådan aflæses det på maskinen

Konfigurationen for en kanal aflæses med wevtutil gl Security. Resultatet viser bl.a. maxSize, retention og autoBackup samt stien til filen. wevtutil gli Security viser filens aktuelle størrelse, antal poster og nummeret på den ældste post. Den ældste hændelse kan læses med Get-WinEvent -LogName Security -Oldest -MaxEvents 1. Gem output fra kommandoerne som en del af sikringen, med tidspunkt og maskinnavn.

Er indstillingerne sat via gruppepolitik eller MDM, findes de også under HKLM\Software\Policies\Microsoft\Windows\EventLog. En ændring af politikken undervejs kan forklare, hvorfor loggen dækker en anden periode end forventet.

Sådan estimeres perioden

Perioden kan estimeres, før det bliver aktuelt. Del loggens maksimale størrelse med den gennemsnitlige mængde, maskinen skriver pr. døgn, så får du et groft bud på, hvor mange døgn loggen dækker. Den daglige mængde kan aflæses ved at se på antal poster og tidsrummet mellem ældste og nyeste hændelse i den nuværende log. Hændelser er ikke lige store, og mængden svinger med aktivitet, opdateringer og fejl. En enkelt nat med mange mislykkede logons eller en softwareudrulning kan fylde mere end en normal uge. Estimatet er derfor en planlægningsværdi, ikke en dokumentation af en konkret periode.

Det er nyttigt at lave estimatet for hver maskintype: klienter, filservere, domænecontrollere og servere med fjernadgang. Estimatet bør gentages, når revisionspolitikken ændres, fordi en ny underkategori kan mangedoble mængden. Ofte viser det, at netop de servere, hvor de vigtigste hændelser skrives, har den korteste periode.

Kanaler uden for Security

Mange af de spor, der bruges i undersøgelser, ligger ikke i Security-loggen. Fjernskrivebord, PowerShell, Defender, opgaveplanlægning, Windows Firewall og mange programmer skriver i egne kanaler under Applications and Services Logs. De har hver deres størrelse, og nogle af dem er så små, at de kun dækker kort tid på en aktiv maskine. Andre kanaler er slået fra som standard og skriver først, når de aktiveres. En sikring bør derfor omfatte alle kanaler i logmappen, ikke kun de tre klassiske. Se Windows-hændelseslogs.

Den ældste hændelse er ikke loggens start

Tidspunktet for den ældste hændelse er det tidligste, loggen kan sige noget om. Det er ikke det samme som det tidspunkt, hvor logningen begyndte, og det er heller ikke et bevis på, at intet skete før. Typiske grunde til, at loggen starter senere end forventet:

Loggen er fuld og har overskrevet ældre hændelser.
Loggen er ryddet. I Security-loggen skrives hændelse 1102, og i System-loggen 104, med den konto, der ryddede.
Maskinen er geninstalleret eller nulstillet, så loggen er ny.
Revisionspolitikken er ændret, så bestemte hændelser først skrives fra et senere tidspunkt.

Er Security-loggens ældste hændelse en 1102, er loggen ryddet. Er den ældste hændelse en almindelig hændelse midt i et forløb, er den overskrevet. Skelnen bør fremgå af rapporten. Se fravær af spor om, hvordan huller beskrives.

Øg størrelsen, før der sker noget

Den mest effektive forebyggelse er at øge størrelsen på de kanaler, der bruges i undersøgelser, og sende hændelserne videre til en central opsamling, fx Windows Event Forwarding eller en SIEM. Den lokale log er en buffer, ikke et arkiv. Hvor længe den centrale opsamling gemmer, er en selvstændig indstilling, der også bør dokumenteres. Se forensic readiness-baseline.

Store lokale logs er ikke gratis. De fylder på disken, og meget store logs gør søgning og eksport langsommere. Mange organisationer vælger derfor en moderat lokal størrelse kombineret med videresendelse. Det vigtigste er, at valget er bevidst og dokumenteret, så det senere kan forklares, hvorfor en bestemt periode mangler.

Når sagen er opstået

Står man med en maskine, der har en relevant periode i loggen lige nu, er rækkefølgen:

Aflæs og gem kanalens konfiguration og den ældste hændelse.
Eksportér de relevante kanaler med det samme, hvis loggen er tæt på at være fuld.
Overvej at øge størrelsen for at standse yderligere tab, og dokumentér ændringen med tidspunkt, konto, gammel og ny værdi.
Sikr arkivfiler og de centrale kopier af hændelserne.

Det er en ændring af systemet at øge størrelsen, men den sletter ikke noget. At lade være, mens loggen ruller, kan derimod koste præcis de hændelser, sagen handler om. Hvilke hændelser der er mest efterspurgte, kan slås op i event-id-opslaget.

I rapporten

Angiv for hver kanal: maksimal størrelse, opbevaringsindstilling, tidspunkt for ældste og nyeste hændelse og hashværdien af den eksporterede fil. Er der fundet arkivfiler eller centrale kopier, angives deres periode særskilt. Skriv tydeligt, hvilken periode loggen dækker, og at hændelser før dette tidspunkt ikke kan vurderes ud fra denne kilde.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Windows-forensik

Læs også: Nulstil denne pc og Autopilot: hvad overlever en nulstilling? · Event 4688: proceskørsel og kommandolinje i Windows-loggen

→ Forensisk undersøgelse af en computer · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik