[English]Ich stelle mal einen Sachverhalt im Blog-Beitrag vor, der mir vor einiger Zeit untergekommen ist. Nutzer bemerken, dass in ihrem Benutzerprofil tmp-Dateien unter dem Ordner Dokumente /Outlook-Dateien angelegt werden.
Nutzerberichte über tmp-Dateien
Ich selbst verwende kein Microsoft Outlook, weshalb mir das Thema niemals untergekommen ist. Erstmals ist mir das Thema bewusst im Post Unbekannte tmp dateien unter c: user dokumente outlook-dateien auf administrator.de untergekommen.
Ein erster Bericht auf administrator.de
Ein Teilnehmer fragt dort an, ob jemand wisse, warum Microsoft Outlook 2019 "komische tmp-Dateien" im Nutzerprofil im Ordner Dokumente /Outlook-Dateien erzeugt. Der Nutzer hat einen Screenshot des betreffenden Ordners gepostet:
Man erkennt, dass Outlook im Ordner seine .pst-Dateien samt Backup ablegt. Aber es sammeln sich über die Jahre auch .tmp-Dateien in einer bestimmten Größe.
Weitere Fundstellen im Internet und diverse tmp-Dateien
Recherchiert man im Internet, stößt man auf weitere Fundstellen, wo Nutzern dies aufgefallen ist. Im Mai 2014 hat jemand im Microsoft Answers-Forum im Thread Build up of .tmp files in my Documents folder eine ähnliche Beobachtung angesprochen. Und in diesem Post beklagt sich jemand, dass die Freigabe, auf denen die Profile liegen, mit tmp-Dateien voll läuft.
Die in diesem Forenbeitrag aufgeworfene Frage nach Log-Dateien trifft dagegen die obige Beobachtung nicht so ganz. Nebenbei erzeugt Outlook noch eine .tmp-Dateien im Benutzerprofil wie man hier nachlesen kann.
Was sind die tmp-Dateien bei Outlook?
Im administrator.de-Forenthread hat ein Nutzer mit dem Alias BiberMan dann eine Erklärung für diese Dateien geliefert. Er schreibt, dass Microsoft Outlook diese Dateien als Cache für Suchindex, Anhänge etwas verwendet. Diese Dateien sollten normalerweise nach dem Schließen der Anwendung wieder gelöscht werden.
Das ist bei obigem Nutzer offensichtlich nicht der Fall. Die Interpretation für die übrig gebliebenen tmp-Dateien ist, dass das Reste von einem Outlook-Absturz sind, oder das ein installiertes AddIns das Löschen verhindert. Der Ratschlag ist, diese .tmp-Dateien von Hand bzw. per Skript zu löschen.
Das bringt mich zur Frage, ob jemand aus der Leserschaft solche .tmp-Dateien im genannten Dokumente-Unterordner Outlook-Files vorgefunden hat?
Ähnliche Artikel:
Windows 10 flutet Ordner mit leerem TMP-Verzeichnismüll
Auch Windows 11 flutet Ordner mit leerem TMP-Verzeichnismüll
Windows 10 2004/20H2: DumpStack.log.tmp bremst Rechner aus
ESET Endpoint Security Outlook-Plug-in flutet Exchange Online SPAM-Ordner
Windows 10: Was erzeugt massenhaft mat-debug*.log-Dateien?
Windows 10/11: Edge müllt den Temp-Ordner mit Edge_BITS_xxx-Dateien voll
Download-Bug bei Microsoft Edge 103.0.1264.44: .crdownload-Dateien bleiben zurück
MVP: 2013 – 2016
Liegt das Benutzerprofil auf dem PC oder handelt es sich um ein Roaming Profil?
Es ist ja offensichtlich das es sich bei den .tmp Dateien um Kopien der .pst Dateien handelt.
Wahrscheinlich erzeugt während eines Prozesses eine Drittsoftware einen Zugriff (z.B Virenscanner) und Windows kann die tmp Datei in Zuge dessen nicht löschen. Grade auf Netzlaufwerken habe ich das schon öfter mal gesehen das der Virenscanner auf dem Filesservern tmp Datein blockiert und sie deshalb von anderen Systemprozessen nicht gelöscht werden können.
Und wieder mal ein schönes Beispiel, wie Microsoft sich selbst an seinen Standards nicht hält. Temp Dateien gehören in die jeweiligen Temp-Verzeichnisse des Users, nicht in irgendwelchen Untiefen von Appdata. Gäbe es noch das Windows-Logo Programm aus den Anfang 2000er Jahren, würde Outlook keine "Designed for Windows" Flagge auf der Produktpackung bekommen.
By the way in diesem Zusammenhang: Ich habe mal ein kleines Open Source Tool gemacht, das zeitgesteuert in der Aufgabenverwaltung die vollmüllende Profilordner von Usern auf Terminalservern freischaufeln kann. Outlook ist da nicht alleine.
https://codeberg.org/tomas-jakobs/profilecleaner
Das Temp-Verzeichnis des Benutzers liegt in AppData ;)
Nämlich C:\Benutzer\\AppData\Local\Temp
Es gibt aber noch andere Verzeichnisse, in denen Microsoft temporäre Dateien ablegt.
Z.B. Anhänge von Mails in Outlook in C:\Benutzer\\AppData\local\Microsoft\Windows\Temporary Internet Files.
Dort gibt es die Ordner Content.MSO, Content.Outlook, Content.Word, etc.
Und darin Unterordner mit temporären Dateien.
Mich nervt auch, das viele Programme ihre Temp-Dateien nicht aufräumen.
Und auch, das sich selbst Microsoft häufig nicht um die Systemvariablen %temp% und %tmp% kümmert, sondern munter die Temp-Dateien im lokalen Temp-Verzeichnis des Users oder in C:\Windows\Temp schreibt anstatt in den durch die o.g. Systemvariablen angegebenen Temp-Ordner.
> Das Temp-Verzeichnis des Benutzers liegt in AppData ;)
> Nämlich C:\Benutzer\\AppData\Local\Temp
Witzbold ;-)
Das wäre ja okay, wenn es da läge… tut es aber offensichtlich nicht
Das mit dem Temp INternet Files hängt davon ab, was für ein Ourlook noch verwendet wird. 2019 war das letzte, wo die Trident Engine noch zum Einsatz kommt (ich mein in der LTS). Alles später hat die neuere Chrome-Engine.
@Tomas-Jakobs
> Das Temp-Verzeichnis des Benutzers liegt in AppData ;)
> Nämlich C:\Benutzer\\%USERNAME%AppData\Local\Temp
In der Regel liegt das Temp-Verzeichnis eines Benutzers schon im oben genannten Pfad. Der pfad ist halt nicht sichtbar. %USERNAME% ist sinngemäß der Benutzername.
Es sei denn, der Pfad wurde umgebogen.
In diesem Ordner hat ein Standardbenutzer Schreib- und Ausführungsrechte, sogar dann, wenn der Applocker mit Standardregeln aktiv ist.
C:\Users\USERNAME\AppData\Local\Microsoft\Windows\INetCache
Ist das ein Fehler im Applocker?
Denn laut Standardregeln sind nur Programme in "Windows" und "Programme" zugelassen. Für alle anderen Ordner darf nur ein Administrator, aber nicht ein Standardbenutzer Programme starten. Diese Behauptung des Applocker stimmt aber nicht, denn auch im Internet-Cache und im Temp-Ordner und im Desktop-Ordner des Benutzers darf man als Standardbenutzer schreiben und Programme starten, was ich für eine Sicherheitslücke halte.
Genauso gibt es auch noch im Windows-Ordner 13 Unterordner, in denen ein Standardbenutzer Schreibrechte (und Ausführungsrechte) hat, was auch nicht so sein darf:
C:\Windows\debug\WIA\
C:\Windows\Registration\CRMLog\
C:\Windows\System32\FxsTmp\
C:\Windows\System32\spool\drivers\color\
C:\Windows\System32\spool\PRINTERS\
C:\Windows\SysWOW64\FxsTmp\
C:\Windows\Tasks\
C:\Windows\tracing\
C:\Windows\System32\Com\dmp
C:\Windows\System32\spool\SERVERS
C:\Windows\System32\Tasks
C:\Windows\SysWOW64\Com\dmp
C:\Windows\SysWOW64\Tasks
Diese Ordner sollte man daher noch zusätzlich im Applocker eintragen und sperren.
Im spool\\Printers- und spool\\drivers\\color Ordner werden die Druckertreiber und Farbprofile gespeichert.
Wenn ein Standardnutzer darauf keine Schreibrechte hat, kann er keine Drucker installieren.
Und wenn er darauf keine Ausführungsrechte hat, kann er nicht drucken.
Und was Programme im Userordner angeht:
Das hängt wohl mit der dämlichen Geschichte zusammen, das Microsoft seit Winows 10 die Apps ja pro Benutzer installiert und nicht wie früher global.
Und einige Anwendungen von Drittanbietern machen den Mist inzwischen auch.
1 Programm für 3 Benutzer heißt, das Programm wird 3 mal installiert. Das muß man dann manuell übersteuern und den Installationspfad manuell vorgeben, so das das Programm in den Standardordnern C:.\\Programme oder C:\\Programme (x86) installiert wird.
Noch ein Benutzerverzeichnis, das mit den Konventionen für den Speicherort für Benutzerverzeichnisse bricht:
C:\\Windows\\System32\\config\\systemprofile
Und wenn Du Pech hast und auf depperte Devs/Softwarelieferanten triffst, ist alles hardcoded und Du kannst im Installer (kein MSI) genau nichts mehr machen.
Zitat:
"Wenn ein Standardnutzer darauf keine Schreibrechte hat, kann er keine Drucker installieren.
Und wenn er darauf keine Ausführungsrechte hat, kann er nicht drucken."
—
Ein Standardbenutzer soll gar nichts installieren.
Bei mir habe ich diese Ordner im Applocker gesperrt, aber drucken kann ich trotzdem.
In diesen Ordnern gibt es bei mir auch gar keine EXE.
EXE hat dort nichts zu suchen.
Diese Ordner gehören absolut gesperrt.
Eine Schande, dass Microsoft an sowas nicht selber gedacht hat.
Und wie kommt ein Standardbenutzer an seinen Drucker?
Selbst wenn der Admin einen Drucker installiert hat, dann ist der bei vielen Druckertreibern NICHT bei anderen Benutzern installiert.
Insbesondere in Netzwerken mit Druckserver.
Zitat:
"Und wie kommt ein Standardbenutzer an seinen Drucker?"
—
Er benutzt ihn.
Einfach auf den "Drucken"-Button klicken.
Zitat:
"Selbst wenn der Admin einen Drucker installiert hat, dann ist der bei vielen Druckertreibern NICHT bei anderen Benutzern installiert.
Insbesondere in Netzwerken mit Druckserver."
—
Die Druckersoftware landet im Programme Ordner, sofern man sowas überhaupt braucht.
Druckertreiber gehören nicht in das Benutzerprofil, sondern die Druckertreiber landen in \Windows\System32\drivers
oder
\Windows\System32\Spool\drivers\x64
Das ist alles für alle Benutzer verfügbar.
Netzwerkdrucker kann man am Druckerserver freigeben und dann an den Clients per GPO bereitstellen:
Windows-Einstellungen, "Bereitgestellte Drucker",
rechtsklick ins freie Feld, "Drucker bereitstellen", Server-Adresse eingeben oder "Durchsuchen"-Button anklicken, "hinzufügen", Button anklicken.
www. msxfaq. de/activedirectory/gpo_und_drucker.htm
der Benutzer triggert das System, den freigegeben Drucker für den Benutzer zu installieren. einfach per Doppelklick.
das ist das normale Delegationsdreieck von Microsoft. die rundll im Benutzerkontext fragt einen erhöhten Prozess an, das System installiert den Drucker. deswegen geht es inkl Treiber als Benutzer.
deswegen sind Angriffe auf den spooler so beliebt und erfolgreich, siehe printnightmare
der Benutzer hat kein Recht Treiber zu installieren
> Im spool\\Printers- und spool\\drivers\\color Ordner werden
> die Druckertreiber und Farbprofile gespeichert.
Nein. Nur die Farbprofile. Rate mal, warum der Ordner so heisst und es im Ordner .\Drivers nach Architektur getrennte Ordner gibt.
@Bolko, du benutzt Applocker nicht, oder warum glaubst du immer noch, das NTFS Rechte initial etwas mit dem Regelwerk zu tun haben, bzw du nicht akzeptieren möchtest, das Applocker ein reines Allowlisting Tool ist?
noch Mal:
die NTFS Berechtigungen in den genannten Windows Ordnern sind kritisch, wenn du Windows und alles darunter erlaubst, denn dann hast du eine Lücke im Regelwerk.
das Problem sind die Schreibrechte eines Benutzers in einem Vertrauenswürdigen Speicherort, der nur vertrauenswürdig ist, WENN Benutzer keine Schreibrechte haben.
das BENUTZERPROFIL ist aber an keiner Stelle erlaubt, ergo auch nicht %temp%, ergo keine Lücke im Regelwerk
Zitat:
"du benutzt Applocker nicht, oder warum glaubst du immer noch, das NTFS Rechte initial etwas mit dem Regelwerk zu tun haben"
—
Doch ich benutze Applocker.
Ich habe vorhin getestet in diese Ordner ein Tool reinzukopieren und zu starten.
Das hat leider funktioniert, obwohl diese Ordner im Applocker nicht ausdrücklich erlaubt waren.
Also hat Microsoft demnach die Standardregeln im Applocker falsch eingestellt, denn diese Standardbenutzer-Unterordner gehören weder zum "Windows"- noch zum "Programme"-Ordner und "Admin" ist ein Standardbenutzer auch nicht und sämtliche Windows-Unterordner dürfen keine Schreibberechtigung haben und die Spool-Ordner etc brauchen auch keine Ausführungsberechtigung.
Also sperre ich alle diese Ordner nochmal extra manuell.
Was soll das mit NTFS-Rechten zu tun haben?
Soll ich in NTFS nochmal extra die Ausführungsberechtigung sperren, obwohl ich das lieber im Applocker mache?
Soll ich die Schreibberechtigung per NTFS sperren, weil Microsoft das auch falsch eingestellt hat?
Zitat:
"die NTFS Berechtigungen in den genannten Windows Ordnern sind kritisch, wenn du Windows und alles darunter erlaubst, denn dann hast du eine Lücke im Regelwerk."
—
Genau das meine ich doch und habe es auch geschrieben.
Aber leider sind das nunmal diese "Standardregeln", die Microsoft im Applocker einträgt.
Entweder muss man dann manuell diese Ordner zusätzlich sperren oder man darf diese Standadardregeln gar nicht erst benutzen.
Wie auch immer, die Einstellung von Microsoft ist so oder so falsch.
Zitat:
"das BENUTZERPROFIL ist aber an keiner Stelle erlaubt, ergo auch nicht %temp%, ergo keine Lücke im Regelwerk"
—
Doch, das ist eben doch "erlaubt".
Zwar nicht ausdrücklich und nicht sichtbar im Applocker als Regel, aber de fakto funktioniert es leider eben doch, aus solchen Ordnern eine exe zu starten, wenn man diese Standardregeln benutzt.
Ich habe es doch selber getestet, dass die exe von dort aus gestartet werden kann, obwohl der Ordner nicht ausdrücklich per Regel erlaubt ist.
Entweder benutzt du keine Standardregeln oder du hast es noch nicht selber ausprobiert, eine exe vom Benutzerordner aus zu starten. Das funktioniert, obwohl es nicht funktionieren dürfte.
Ein Standardbenutzer darf nicht gleichzeitig Schreibrechte UND Ausführungsrechte in irgend einem Ordner haben.
Sobald er beides gleichzeitig irgendwo hat, dann kann er oder "man" das System abschießen.
ich habe Standard Regeln und in keinem Pfad unter %userprofile% sind Dateien ausführbar. Keinem.
jeder Installer stirbt, onedrive, teams etc starten nicht, solange ich es nicht zb per Zertifikat erlaube.
das macht keinen Sinn, was dein System als Ergebnis liefert. ich tippe auf einen Fehler in seinem Regelwerk.
Mein Fehler:
Ich hatte mehrere "Total Commander" parallel offen und einer davon hatte noch Admin-Rechte, weil ich vorher mal etwas aus einem anderen Konto kopiert hatte.
Wenn man damit dann den Applocker testen will, dann funktioniert das natürlich nicht, denn Admins haben laut Applocker-Standardregel die Ausführungserlaubnis für alle Dateien, für die es keine Regel gibt.
Bei dem normalen auf Standardbenutzerrechte eingeschränkten Total Commander funktioniert Applocker wie gewünscht und der Appdata-Unterordner muss nicht extra gesperrt werden.
2.
Bei der Fehleranalyse ist mir nebenbei glücklicherweise auch noch aufgefallen, dass ich dem portablem TOR-Browser, der ebenfalls unterhalb von Appdata liegt weil er Schreibrechte braucht und deshalb nicht im Programme-Ordner liegt, mehr Rechte als nötig freigegeben hatte.
Dateihash-Freigabe aller sechs exe reicht aus und ist viel sicherer als den ganzen TOR-Ordner zu erlauben.
ich habe die Gruppe der Administratoren gegen das SYSTEM getauscht.
damit genau das, nicht passiert. Administratoren sind sonst ohne Schutz.
Installationen benötigen jetzt Systemrechte zb per Sysiphos.com von Stefan Kanthak
ACHTUNG: neben den ab Werk vorhandenen Unter-Verzeichnissen von %windir% alias %SystemRoot%, in denen unprivilegierte Nutzer Dateien schreiben dürfen, gibt's je nach installiertem anderem DrexZeux noch weitere Lücken.
Wer diese aufspüren will holt sich https://skanthak.hier-im-netz.de/download/LOOPHOLE.EXE und ruft dieses in einer mit erhöhten Rechten unter dem bei der Windows-Installation angelegten UAC-kontrollierten "Administrator"-Konto mit den zu prüfenden Pfaden auf — z.B.:
LOOPHOLE.exe "%SystemRoot%" "%ProgramFiles%" "%ProgramFiles(x86)%" "%ProgramData%"
Das Programm aktiviert das Backup-Privileg und enumeriert alle Verzeichnisse/Dateien in den angegebenen Pfaden, öffnet sie zum Lesen des Sicherheitsdeskriptors, testet diesen durch Aufruf der Win32-Funktion AccessCheck() gegen den "linked token" des unprivilegierten "Administrators" und schreibt eine Zeile mit dessen Zugriffsrechten falls jeglicher schreibende Zugriff erlaubt ist.
Es gibt schon seit ewigen Zeiten auf schneegans.de ein Script, welches alle Userbeschreibbaren Pfade in c:\windows findet. Irgendwo im Netz findet man auch ein Tool Namens evasor.exe, dass das auch tut, hatte ich mal über die Seite kitploit gefunden, die momentan leider kaputt ist, dort wurde immer sehr nützliche (Hacker)tools vorgestellt.
Und man braucht diese Ordner nicht als Extra-Regeln in Applocker einzubinden, sondern man kann auch die Ausführegel für %windir% öffnen und dort im Tab "Ausnahmen"/"Exceptions" einfach diese Pfade reinkopieren, das macht das Regelwerk etwas übersichtlicher.
Die Referenz hierzu ist Stefan Kanthak…
By the way, diese komische (whitegelabelte) Sparkassen S-Firm Software, legt diese Ihre Updates immer noch in den TEMP Ordner und versucht anschliessend ungefragt diese auszuführen und bemerkt nicht, wenn man diese "zufällig" gegen eine boshafte SETUP.EXE getauscht hat?
Frage für einen Freund…
Jein, Nein. Vielleicht.
Das ist abhängig vom Setup Paketierer, zB Innosetup, entpackt aus der setup.exe eine setup.e32 und benennt sie um. Diese startet dann nicht, wenn "nur" die setup.exe erlaubt ist.
Wenn du SFirm per Herausgeber erlaubt hast, ist der Pfad egal. Das ist ja der Sinn, wenn du dem Zertifikat vertraust. Wenn jetzt der Installer dasselbe Zertifikat hat, dann darf sie natürlich starten. Du vertraust dem Zertifikat.
Es liegt also an deinem Regelwerk und der Art der Paketierten Software
Kommt drauf an, wie man die Zertifikatsregel einstellt, und wie gut der Hersteller signiert. Wenn man eine Signaturregel erstellt, hat man einen Regler, über den man die Regel mehr oder weniger Streng einstellen kann. Entweder nur die SIgnatur muss passen, Applikationsname, oder auch der Dateiname, Mindestversion des Programms. Nützt halt nichts, wenn der Hersteller die Dateisignatur nur unvollständig macht.
das ist nur interessant, wenn du Versions basiert blocken/erlauben willst.
idr geht es mit der Signatur um Codesigning und damit der Bestätigung das der Code unverändert ist, also nicht manipuliert, seit er den Entwickler verlassen hat
Kleinkinder, die nicht 'mal ihren eigenen Namen schreiben können, brabbeln IMMER schwachsinniges Kauderwelsch — hier gleich mehrfach!
1) was soll eine unvollständige Dateisignatur im Kontext SRPv[12] sein?
2) SRPs können selbstverständlich Benutzer- oder Gruppen-spezifisch eingerichtet werden!
3) weder Christoph Schneegans PowerShell-Skript (dessen Schwachpunkte er nach meinen Hinweisen korrigiert hat) noch mein ETWAS älteres Batch-Skript finden Dateien, die ein unprivilegierter Benutzer in irgend einer Form modifizieren kann, noch beachten sie das "Traversieren"-Privileg.
Kurz: wehret den Dummschwätzern!
Apropos "Digitales Zertifikat": siehe https://seclists.org/fulldisclosure/2025/Jul/39 alias 'Defense in depth — the Microsoft way (part 90): "Digital Signature" property sheet missing without "Read Extended Attributes" access permission'
Ausnahmsweise nicht, da Stefan SRP macht, er mag Applocker nicht, da es nicht "out-of-the-box" nur mit Registrywerten funktioniert.
Applocker erlaubt andere Variablen, bzw. einige nicht. Es benötigt einen Dienst und bis 10.2022 eine Enterprise Edition. Es ist per Default Allowlisting. SRP(v1) muss man erst so konfigurieren.
Applocker erlaubt auch Regeln an bestimmtge Benutzer oder Gruppen zu binden, das kann SRP nicht.
Die Angst vor zufälligem Austausch oder der Änderung der Ausführbaren Datei ist der Grund für SRP/Applocker/Drittanbieter Software zum Thema Allowlisting, damit genau das nicht passiert.
Du kannst Fehler machen, dann ist es erlaubt, ansonsten ist der Start der "zufälligen" .exe eine neue ausführbare Datei, die eine Regel zur Ausführungserlaubnis benötigt.
Childs der erlaubten Datei erben nicht das Recht der Ausführung.
Das Problem für SRP/Applocker sind Prozesse, die nicht verboten werden können, aber manipulierbar sind. Oder eben Fehler in den Standard Regeln, da es Benutzer schreibbare Ordner unter .\Windows gibt. Letzteres kann mit Exclude Regeln oder korrektur der NTFS Rechte gerettet werden.
Ich würde da nicht an den NTFS-Rechten rumschrauben, per Applocker-Exclusion-Regeln ist die einzige sinnvolle Lösung.
NTFS ist trivial. Applocker macht es komplex und die Logik sagt, je komplexer das System, desto anfälliger.
die ersteller-besitzer per GPO oder im Deployment rauszuwerfen beseitigt den Fehler eine Ebene früher
| […] dass die Freigabe, auf denen die Profile liegen, mit tmp-Dateien voll läuft. […]
Verstehe ich das richtig, dass die PST-Dateien auf Netzlaufwerken liegen und von den Outlook-Clients über das Netzwerk geöffnnet werden?
Microsoft selber empfiehlt genau das gerade nicht. Im Gegenteil: die PST-Dateien sollten lokal gelagert sein und nicht über eine Netzwerkverbindung eingebunden werden. Das ist viel zu langsam und instabil und kann zu komplettem Datenverlust führen.
Man kann es natürlich trotzdem machen, sollte sich dann aber über ein langsames Outlook und evtl. Datenverlust nicht wundern oder beschweren.
Jepp, gerade bei GB großen Dateien.
Meines Wissens verhindert bzw. verhinderte das Outlook das auch mal, wenn man versucht .PST von Netzwerklaufwerken zu öffenen bzw. Profile mit .OST versucht darauf einzurichten.
Mein Tipp wäre ja, auf Outlook ganz zu verzichten, wenn man wirklich mit Email und Internetformaten (webDAV) arbeiten möchte… aber anderes Thema
Unschwer ersichtlich: der Nutzer hat 2 PST-Dateien, eine fast 24 GB groß, eine fast 8 GB groß, beide im Juli 25 in Benutzung. Die tmp-Dateien sind offenbar Kopien davon.
Welcher Prozess einen Sinn darin sieht, komplette Kopien zu erzeugen, weiß ich nicht – Outlook tut das vermutlich nicht ohne Weiteres, aber ich kann nicht aus Erfahrung sprechen, da wir nur Speicherung auf dem Mailserver zulassen. Benutzt jemand einen lokalen Cache, wäre dort eine .ost und selbst während die noch erstellt oder upgedated wird, heißt die schon .ost und nicht .tmp und bei archive.pst (Auto-Archivierung) wird eine ~archive.pst.tmp erzeugt – auch nicht zu sehen.
Insofern: ich würde NTFS-Auditing auf diesem Ordner nutzen und aufzeichen lassen, welcher Prozess die erstellt. Sollte es wirklich outlook.exe sein, dann ausschließen, dass es ein Add-In ist, indem man alle deaktiviert.
da es pst ist, trifft es hauptsächlich nur Leute ohne Exchange, somit ist es für MS nicht unternehmenskritisch. das sind Endkunden, die MS leider egal sind :-(
Ich kenn diese tmp-Dateien im Benutzerprofil-Ordner, aus der Reparatur Versuchen der Outlook PST-Dateien. Wenn die PST-Dateien zu gross werden (ca. 50 GB) und die User beim öffnen nicht abwarten können (Netzwerk-LW) kann es vorkommen das auf die PST-Dateien nicht mehr zugegriffen wereden können. Beim Reparatur-Versuch erzeugt Outlook ein tmp-Datei in der gleichen Größe der PST-Datei – wie oben schon erwähnt. Nach beendigung der Reparatur -ob erfolgreich oder nicht- bleibt die tmp-Datei zurück. Passierte früher bei uns oft bei zwei bestimmten User, da die PST-Dateien in einer Netzwerk-LW lagen.
Welchen E-Mail-Client nutzt du, Günni?
Ich verwende seit 2009 den Thunderbird. Läuft unter Linux, macOS und auch unter Windows …