Print i Windows: spool‑filer, PrintService‑log og printserverens journal

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

Windows kan registrere udskrifter tre steder: i midlertidige spool-filer på klienten eller printserveren, i hændelsesloggen PrintService/Operational og i printstyringsløsningens egen journal. Ingen af dem er pålidelige af sig selv, fordi de vigtigste er slået fra som standard eller slettes automatisk. Spørgsmålet “hvem har printet kundelisten?” kan derfor kun besvares, hvis logningen var på plads før hændelsen, eller hvis rester af spool-filer kan findes i en forensisk kopi.

Sådan bevæger et printjob sig

Når et program udskriver, sendes jobbet til printerspooleren. Spooleren skriver jobbet til disk som to filer i spool-mappen under Windows-mappen: en SPL-fil med selve udskriftsdata og en SHD-fil (shadow) med metadata om jobbet. Derefter sendes data til printeren, enten direkte eller via en printserver, hvor samme proces gentages.

SHD-filen indeholder typisk dokumentnavn, brugernavn, computernavn, printernavn, tidspunkt for indsendelse, antal sider og datatype. SPL-filen kan indeholde udskriften i et format som EMF eller XPS, hvor tekst og grafik ofte kan genskabes, eller i et printersprog som PCL eller PostScript, som kræver en fortolker. Spool-mappen er som standard System32\spool\PRINTERS under Windows-mappen, men kan være flyttet i printserverens egenskaber. SHD-formatet er ikke officielt dokumenteret og varierer mellem versioner, så felterne bør aflæses med et værktøj, der understøtter den aktuelle version.

Når jobbet er færdigt, sletter spooleren som standard begge filer. Indstillingen “behold udskrevne dokumenter” på en printerkø ændrer det, men den er sjældent slået til.

Spool-filer i en forensisk kopi

Selv om filerne er slettet, kan de findes igen:

Ikke-allokeret plads: EMF- og SHD-strukturer har genkendelige signaturer og kan findes med carving. På en SSD med TRIM er chancen mindre. → File carving
Filsystemets journaler: $MFT og $UsnJrnl kan vise, at SPL- og SHD-filer blev oprettet og slettet, og hvornår, selv om indholdet er væk. Filnavnene er typisk et jobnummer, så de siger ikke i sig selv, hvad der blev printet.
Fejlede job: Job, der hang eller blev afbrudt, kan blive liggende i mappen.
Volume Shadow Copies: Tidligere versioner af volumen kan indeholde spool-filer, der var til stede, da skyggekopien blev lavet.

Fund af spool-rester er stærke, fordi de kan vise selve indholdet. De kan dog være ufuldstændige, og et genskabt dokument skal beskrives som rekonstrueret fra rester, ikke som originalen.

PrintService-loggen

Windows har en hændelseskanal, Microsoft-Windows-PrintService/Operational, som kan registrere hvert printjob. Hændelse 307 beskriver et udskrevet dokument med dokumentnavn, bruger, computer, printer, port, størrelse og antal sider. I nyere Windows-versioner erstattes dokumentnavnet dog af en generisk betegnelse, medmindre politikken, der tillader jobnavne i hændelseslogs, er slået til. Aflæs derfor også den politik.

Kanalen er som udgangspunkt slået fra og skal aktiveres, før den registrerer noget. Er den slået til, gælder de almindelige forhold for hændelseslogs: fast størrelse, overskrivning af ældste poster og risiko for, at loggen er for lille til den periode, der er relevant. → Windows-hændelseslogs: kanaler og event-id’er

Bemærk, at dokumentnavnet er det navn, programmet sender med. Det kan være filnavnet, titlen på en webside eller blot “Microsoft Word – Dokument1”. Det er ikke nødvendigvis det navn, filen har på disken.

Printserveren

Går jobbet via en printserver, skrives hændelse 307 på serveren med klientens computernavn og den indsendende konto, uden for brugerens rækkevidde. Kobl posten med serverens Security-log: en netværkslogon (4624 med logontype 3) fra samme konto og klient lige før jobbet bekræfter forbindelsen, og logon-id’et kan følges videre. På serveren findes desuden spool-mappen med eventuelle rester og køens konfiguration, herunder om “behold udskrevne dokumenter” var slået til for netop den kø.

Sikr loggen fra printserveren hurtigt, fordi den roterer med alle brugeres job og derfor overskrives hurtigere end på en enkelt klient. Eksportér EVTX-filen, beregn hash, og notér serverens tid. → Eksport af Windows-hændelseslogs (EVTX)

Printstyringsløsninger og printeren selv

Ved “følg mig”-udskrift er jobbet delt i to hændelser: indsendelsen til den virtuelle kø og frigivelsen ved en fysisk printer efter kort eller kode. Printstyringens database har typisk en post for hver, og det er tidsforskellen og printer-id’et på frigivelsen, der viser, hvor og hvornår papiret kom ud. Ikke-frigivne job slettes efter en udløbstid og står så med en status, der adskiller sig fra udskrevne. Nogle løsninger gemmer også en kopi eller et miniaturebillede af jobbet. Hent journalen som rå eksport eller direkte fra databasen frem for en rapport fra administrationsfladen, fordi rapporter ofte summerer, afrunder tider eller udelader slettede job. Notér produktets version og den konfigurerede opbevaringstid.

Multifunktionsprinterens egen joblog er en uafhængig kilde med printerens eget ur og omfatter også kopiering, scanning og fax, som aldrig passerer spooleren. Den hentes via printerens webadministration eller leverandørens værktøj, og printerens tid aflæses samtidig, så afvigelsen kan korrigeres. Har printeren intern lagring, kræver en sikring af den leverandørens medvirken. Overblikket over, hvad printere og scannere gemmer, og hvorfor det betyder noget, står på hub-sitet: → Hvad printere og scannere gemmer

Hvad der skal være slået til på forhånd

For at kunne besvare printspørgsmål efter en hændelse skal mindst én af disse være på plads før hændelsen:

PrintService/Operational aktiveret på printserveren med en logstørrelse, der dækker den ønskede periode,
en printstyringsløsning med journal og en kendt opbevaringstid,
central opsamling af printserverens logs i et SIEM eller lignende.

Ledelsens del, med rækkefølgen af skridt, politik og orientering af medarbejdere, står på virksomhedssitet: → Printlog i en personalesag

Sikring i praksis

Rækkefølgen afgøres af, hvor hurtigt kilderne forsvinder:

Printserverens og printstyringens logs først. De dækker mange brugere og roterer hurtigst. Eksportér journalen fra printstyringen i et format, der bevarer alle felter, og notér den ældste post.
Spool-mappen på den berørte klient og server. Kopiér eventuelle tilbageværende SPL- og SHD-filer med tidsstempler, og hash dem.
Forensisk kopi af klienten, hvis indholdet af slettede spool-filer eller filsystemets journaler skal undersøges.
Konfigurationen: kø-indstillinger, drivere, logstørrelse og om PrintService/Operational var aktiveret. Konfigurationen viser, hvilke spor der overhovedet kunne forventes.

Undgå at teste ved at printe fra den berørte maskine eller kø. Hvert nyt job skriver spool-filer, der kan overskrive rester, og tilføjer poster, der fortrænger ældre poster i loggen. Afprøvning af adfærd foregår på et testsystem.

Typiske fejlkilder

Sendt er ikke printet. Et job i loggen kan være slettet i køen, fejlet eller aldrig frigivet ved en følg mig-printer.
Printet er ikke taget med. En udskrift beviser ikke, at papiret forlod bygningen.
Virtuelle printere. “Udskriv til PDF” og lignende drivere optræder som printere. Et job til en PDF-printer er en fil, ikke papir, og filen skal findes særskilt.
Konto og person. Loggen viser kontoen, der indsendte jobbet. Delte konti, fjernskriveborde og terminalservere kræver yderligere attribution.
Antal sider. Sideantallet afhænger af driver og indstillinger og kan afvige fra det fysiske resultat ved fx duplex eller flere sider pr. ark.
Tid. Klient, printserver, printstyring og printer kan have forskellige ure. Normalisér og angiv tidszone.

Hvad sporene kan og ikke kan bevise

Med logning og spool-rester kan det typisk vises, at en bestemt konto på en bestemt computer sendte et job med et bestemt dokumentnavn og sideantal til en bestemt printer på et bestemt tidspunkt. Med en rekonstrueret SPL-fil eller en printstyringskopi kan indholdet også vises. Uden logning er sporene som regel indirekte: dokumentet blev åbnet, printdialogen kan have været brugt, og en printerkø var installeret. Det er ikke nok til at konkludere, at noget blev printet.

Dokumentation

Angiv i rapporten, hvilke kilder der fandtes og var slået til, logstørrelser og ældste post, hvordan spool-rester blev fundet og genskabt, og med hvilket værktøj og version. Hvert job, konklusionen hviler på, bør kunne føres tilbage til en konkret logpost eller fil med hash.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Windows-forensik

Læs også: Windows Recall og lokale AI-funktioner som datakilde · Downloads og Mark of the Web (Zone.Identifier)

→ 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