[English]Noch ein Problem, welches in Windows schlummert: Ein Blog-Leser wies mich darauf hin, dass neben den von mir kürzlich thematisierten Aria-debug-xxx.log-Files bei manchen Maschinen der TEMP-Ordner mit weiteren Protokolldateien geflutet wird. Diese werden nach dem Schema Computername-yyyMMdd-hhmm.log benannt. Meinen Recherchen nach dürfte der Office Click-to-Run-Dienst an der Erzeugung dieser unsinnigen Protokolldateien beteiligt sein.
Anzeige
Eine Leserrückmeldung
Ich hatte Ende Mai 2023 im Blog-Beitrag Windows-Temp-Ordner werden mit Aria-debug-xxx.log-Files geflutet berichtet, dass einem Benutzer aufgefallen war, dass sein Windows Temp-Ordner mit mehrere GByte-großen log-Dateien mit dem Namen Aria-debug-xxx geflutet wird. Es kann auch den TEMP-Ordner im Profil des Benutzers betreffen, wie ich hier gelesen habe. Auf Grund des Artikel hat sich Mark Heitbrink bei mir per Mail gemeldet und schrieb:
Hi,
zusätzlich zu den Aria* Dateien könnte ich noch Dateien nach dem Schema "Computername-yyyMMdd-hhmm.log" mit 56KB anbieten. Manchmal etwas größer, selten kleiner.
Es werden 25-35 Dateien pro Tag erzeugt und die erste schon direkt mach dem Start. In den ersten 5 Minuten ca 4 Stück, dann alle 30-45 Minuten (ungefähr)
Genau genommen ist es ein json
Name: Office.Telemetry.DynamicConfig.ParseJsonConfigWeist du welcher Task das macht?
Nachfolgenden Screenshot eines Ordners mit diesen .log-Dateien habe ich im Internet gefunden und zur Erläuterung hier im Blog eingebunden.
.log-Dateien im Temp-Ordner, Quelle: Technet-Forum
Adhoc konnte ich mit dieser Information nichts anfangen, denn diese Dateien waren mir noch nicht untergekommen. Ich habe dann aber mal etwas im Internet recherchiert.
Anzeige
Viele Treffer im Internet
Bei einer Suche im Internet trifft man auf einige Fundstellen, die diese log-Dateien im Windows Temp-Ordner ansprechen. Auf SuperUser.com habe ich diesen 7 Jahre alten Beitrag gefunden, wo ein Nutzer schreibt:
I took a look in my c:\windows\temp directory and I found lots of file.log files. The names are built with this syntax: Machinename-YYYYMMDD-XXXX.log.
And I found this:
Timestamp Process TID Area Category EventID Level Message Correlation 01/30/2016 12:43:10.754 OFFICEC2 (0xde8) 0xb6c Click-To-Run Telemetry aqkhc Medium {"MachineID":"a3c8037bfedf40479c3023588639eb6d","SessionID":"b292f44b-e5a6-41c3-a68e-000582c1e920","GeoID":"84","Ver":"0.0.0.0","ExeVer":"15.0.4787.1002","SecuritySessionId":"0","ModulePath":"C:\Program Files\Microsoft Office 15\ClientX64\OfficeC2RClient.exe","CommandLine":"/update SCHEDULEDTASK displaylevel=False","Bitness":"64","IntegrityLevel":"0x4000"} 01/30/2016 12:43:10.754 OFFICEC2 (0xde8) 0xb6c Click-To-Run Telemetry aqkhe Medium {"MachineID":"a3c8037bfedf40479c3023588639eb6d","SessionID":"b292f44b-e5a6-41c3-a68e-000582c1e920","GeoID":"84","Ver":"0.0.0.0","OSVersion":"6.2","SP":"0","ProductType":"1","ProcessorArch":"9","Locale":"1036"} 01/30/2016 12:43:10.770 OFFICEC2 (0xde8) 0xb6c Click-To-Run Telemetry amebh Medium ClientExe complete. {"MachineID":"a3c8037bfedf40479c3023588639eb6d","SessionID":"b292f44b-e5a6-41c3-a68e-000582c1e920","GeoID":"84","Ver":"15.0.4787.1002","Action":"1","Result":"0"} 01/30/2016 12:43:10.770 OFFICEC2 (0xde8) 0xb6c Logging Liblet aqc99 Medium Logging liblet uninitializing.Most of the files are this long but some are much longer. All the logs turn around OFFICE2. Could those logs files come from a malicious program?
Der Nutzer hat also den gleichen Fall wie Mark beschreibt. Der obige Protokollausriss deutet bereits an, dass es irgendwie mit der Telemetrie des Office Click-to-Run-Diensts zu tun hat. Auch im Technet-Forum findet sich dieser Thread aus 2017, wo jemand den Effekt beschreibt. Dort hat jemand die folgende Information hinterlassen:
Based on my deep research, The Microsoft Office ClickToRun Service (ClickToRunSvc) helps manage resource coordination, background streaming, and system integration of Microsoft Office products. As far as I know, this service is required to run during the use of any Microsoft Office program, so you cannot just stop it permanently.
Es wird bestätigt, dass es der Microsoft Office ClickToRun Service (ClickToRunSvc) ist, der Office bei der Verwaltung der Ressourcenkoordination, des Hintergrund-Streamings und der Systemintegration von Microsoft Office-Produkten unterstützen soll. Stellt man den Dienst ab, werden keine .log-Dateien geschrieben – aber dann funktioniert Office nicht mehr. Der Technet-Forenbeitrag hier befasst sich mit diesem Thema.
Bisher habe ich keine Option gefunden, dieses Logging abzustellen (der Beitrag hier beschreibt lediglich, wie man das Protokoll-Level ändern kann). In diesem Beitrag gibt es ebenfalls noch Hinweise, ob die was bewirken, kann ich aktuell nicht testen.
Richtlinien helfen nicht
Mark Heitbrink hat ebenfalls noch etwas im Web gesucht und ist auf den Support-Beitrag Use policy settings to manage privacy controls for Microsoft 365 Apps for enterprise gestoßen. Dazu schreibt er:
Die beiden "ehemaligen" Richtlinien:
User Configuration\Policies\Administrative Templates\Microsoft Office 2016\Tools | Options | General | Service Options
Online Content und Service Level-Options
–> Starting with Version 1904, configuring these two existing policy settings will have no effect on Microsoft 365 Apps for enterprise. They are no longer applicable because their functionality is replaced by these new policy settings:Allow the use of connected experiences in Office that analyze content
Allow the use of connected experiences in Office that download online content
Allow the use of additional optional connected experiences in Office
Allow the use of connected experiences in Office… die habe ich schon per GPO deaktiviert, siehe Screenshot
Zum Vergrößern klicken
Es scheint also nicht zu helfen. Hat jemand von euch eine Lösung gefunden, um die Protokollierung zu unterbinden.
Anzeige
Hallo
Ich habe mich mit dem Thema intensiv befasst als die Umstellung auf M365 angefangen hat. Ich konnte nichts finden, um diese Log-Dateien zu unterbinden. Und ich bin ebenfalls über mehrere Artikel gestoßen das es mit dem Click-to-Run zu tun hat. Einzige Möglichkeit das "einzudämmen" ist, die "Storage Sense" in den GPOs zu aktivieren und zB einmal die Woche laufen lassen. Dann wird da zumindest regelmäßig aufgeräumt. Oder eben ein Powershellscript, das nur diese bestimmten Dateien löscht, wenn der Rest erhalten bleiben soll.
Funktioniert für mich super.
Man kann diese Storage Sense aber auch ohne GPO entsprechend einstellen. Einstellungen -> System -> Speicher -> "Konfigurieren Sie die Speicheroptimierung …." und dann entsprechend den Wünschen einstellen.
Also ich deaktiviere grundsätzlich alle Telemetrie und was sonst noch so schnüffelt bei Microsoft (O&O Shutup; W10Privacy). Habe diese Ordner nicht! Außerdem ist es sowieso ratsam den Temp Ordner regelmässig säubern zu lassen (steckt ja schon im Ordnernamen: Temp(orär)) Da ist nix drinn, was Windows / Office länger braucht als aktuell zur Laufzeit.
Wird per Batch automatisch beim Shutdown gelöscht.
/edit/
na den Ordner habe ich natürlich schon, aber diese Dateien nicht! ;-)
Magst Du das mal bitte erläutern, wie Du die Temp-Dateien beim Shutdown löschst?
gpedit –> Richtlinien für Lokaler Computer –> Computerkonfiguration –> Windows-Einstellungen –> Skripts (Start/Herunterfahren)
Oder in einer Domain über GPOs.
Ist sowohl per Batch-Datei als auch per Powershell-Skript machbar.
Also bei mir gibt es auch solche Dateien (um genau zu sein, 107 Stück).
Sind insgesamt 3MB und die werden nicht täglich erstellt, sondern eher alle 14-15 Tage.
In der Aufgabenplanung unter Microsoft -> Office gibt es einen Task "Office ClickToRun Service Monitor" mit der schönen Beschreibung "This task monitors the state of your Microsoft Office ClickToRunSvc and sends crash and error logs to Microsoft." dessen Ausführungszeiten exakt zum Erstellungsdatum dieser Dateien passt… Ich habe den jetzt mal deaktiviert, mal sehen, ob diese Dateien trotzdem noch wiederkommen.
Bei meinem PC ist diese Aufgabe aktiv und ich habe die Logs trotzdem nicht.
Die Aufgabe ist es nicht.
Ich glaube, es ist davon abhängig welche der Office Versionen es ist?
Hier: Microsoft 365 Apps for Anterprise, Aktueller Kanal
Ist bei mir Microsoft 365 (Version 2305 Klick-und-Los) 64 Bit, Aktueller Kanal.
Habe die Dateien auch, 50 Stück, älteste vom 31.5.
Solange es nicht 50.000 sind oder die Platte volläuft, interressiert micht das nicht.
Wieder so eine gemeine Microsoft sache…. es werden Kilobyte große Temporäre Dateien erstellt…. im Temporären Ordner! WOW!
Verständlich, das man bei denen GB Preisen und Kapazitäten jenseits der TB jeden KB benötigt.
Wie schon beim Aria Problem.
Einfach ab und zu die Datenträger bereinigung Laufen lassen und das Thema ist erledigt.
Dann braucht man sich auch nicht über die Bösen KB Großen Temp Dateien ärgern.
Unabhängig von diesem Office365 Thema:
Der temp-Ordner wird bei mir regelmäßig gelöscht. Da hinterlassen ja auch andere Programme – häufig Protokoll-Dateien nach Installation – ihre Spuren.
Lese ich da einen gewissen Fatalismus aus den diversen Antworten? Nur mal so: Mein Klempner hat ne Menge Rohre in meinem Haus verlegt. Dummerweise lecken die alle irgendwie. Und weil im Keller jetzt immer ein wenig Wasser steht, habe ich Hammer und Meißel gegriffen und da ein Loch in die Außenwand gehauen, damit das Wasser abläuft. Solange mein Keller nicht voll läuft, stört mich das nicht ….
Einfach mal über diese Methapher nachdenken! Es ist ein Unding, dass die Software-Fritzen von Microsoft da irgendwelchen Schund hinfriemeln, der die TEMP-Ordner mit logs voll schreibt, von dem niemand weiß, wozu das gut ist, wie man das abstellt und was auch nirgendwo dokumentiert ist.
Und da werden (auch hier im Blog) heiße Diskussionen und Telemetrie und DSGVO geführt. Leute, was läuft da schief? Findet den Fehler …
Der Vergleich mit dem Klempner hinkt mindestens ein wenig, andere sagen wahrscheinlich gewaltig. Während Du Deinen Klempner wegen mangelhafter Ausführung zur Reparatur erfolgreich heranzitieren kannst, sieht das im Falle von Microsoft wohl ziemlich anders aus. Jedenfalls als *kleiner* User.
Das einzige, was wirken würde, wäre eine massenhafte Abkehr von den Microsoft-Produkten hin zu Alternativen. Den Weg würden wahrscheinlich auch viele, die hier regelmäßig Lesen und auch Schreiben, gehen. Viele betreuen aber eine mal mehr mal weniger große Nutzerbasis, und da sieht die Sache – leider! – gänzlich anders aus. Die überwältigende große Masse ist weder willens noch in der Lage, diesen Schritt mit zu gehen, abgesehen von fehlenden Programm-Alternativen. Und Microsoft weiß das auch, die sind nicht blöd. Die nutzen diese Situation einfach gnadenlos unverschämt aus. Die Waage dürfte sich zukünftig sogar noch weiter in Richtung Microsoft neigen, denn immer mehr alte Hasen, die eher kritisch eingestellt sind und das nötige Wissen haben, gehen in Rente oder kehren der IT auch wegen dieses Problems frustriert den Rücken.
Ich sehe durchgängig Thin-Clients und virtuelle PCs mit 100%iger Programm- und Datenhaltung in nicht kontrollierbaren Rechenzentrum bereits am Horizont. Den technisch nicht versierten Nutzern ist das alles scheixxegal.
Neulich war doch wieder RISC-V in den Meldungen, mit dessen Hilfe Europa unabhängiger von den USA und deren Konzernen werden will. Wenn man sieht, wer diesem RISC-V-Entwicklungs(?)-Konsortium alles beigtreten ist, der muss doch in schallendes Gelächter ausbrechen. Wie soll das gelingen, wenn alle großen US-Player da drin sind und den Ton und die Entwicklungsrichtung angeben?
Ehrlich gesagt: ich denke der Drops ist gelutscht. Mit *der* Nutzerbasis und *den* politischen Entscheidern ist das nicht machbar. Eher heiratet der Papst.
Nö, der Vergleich mit dem Klemptner passt genau!
Ergänzend dazu: Der beauftragte Klemptner hat ein Quasi-Monopol und ob da jemand klagt, interessiert den nicht.
Denn das macht er ja bei allen Kunden so und erklärt es daher zum technischen Standard.
Bei einer Klage muß das Gericht ihm glauben, das das der technische Standard ist, da es ja keine Anbieter gibt, die es besser machen.
Es gibt unzählige Programme von allen möglichen Herstellern, die nicht in der Lage sind, bei Programmende ihre Temp-Dateien aufzuräumen.
| Nö, der Vergleich mit dem Klemptner passt genau!
Um das mal gezielt auf die Spitze zu treiben:
Nö. Der Klemptner ist nicht der Hersteller der Rohre. Er ist nur der Dienstleister, der die Rohre, die der Hersteller (Monopol!) liefert, einbaut. Und wenn die Rohre miese Qualität haben und sich nicht sauber miteinander verbinden und einbauen lassen, dann kann der Klemptner quasi nichts machen, denn siehe Hersteller-Monopol.
;-)
Das eigentliche Problem – siehe anderer Beitrag – ist allerdings, dass diese Daten überhaupt nicht hätten erhoben werden dürfen, da per Policy verboten. Demnach ist selbst der Windows-Admin nicht annähernd Herr über das von ihm verwaltete System.
Microsoft ist ein regelrechtes Monster, dass sich die User selbst herangezüchtet haben.
Randnotiz: sogar auf Linux-Systemen gibt es Jobs die den /tmp-Ordner bereinigen, weil auch dort immer mal wieder was liegen bleibt. Auch im /home-Ordner der User bleibt das ein oder andere überflüssige erhalten, welches von Programmen angelegt wurde. Insbesondere durch Dist-Upgrades entstehen regelrechte Müllhalden.
So, schönen Feiertag, bis demnächst im selben 'Kino'! :-)
Du hast das Problem nicht erfasst. Es geht nicht um das Volumen, es geht um den Kontent und die pure Existenz. Es sind Telemetrie Daten im json Format.
Da aber theoretisch alles zu dem ausgeschaltet sein sollte, was per GPO dokumentiert ist, ist das Problem nicht das Volumen, sondern eben das vorhanden sein der Telemetriedaten. Unabhängig davon, ob es 10Kb oder Tb sind.
Solche Dateien finde ich nicht im Temp-Ordner. Aber ich habe nachgesehen und von eine Menge dieser Ordner, die leer sind, gefunden:
tw-1b34-2b5c-503bxxx.tmp
:: Disable Provisioning Logon Task
:: https://www.der-windows-papst.de/2021/06/15/disable-provisioning-logon-task/
:: https://www.der-windows-papst.de/wp-content/uploads/2021/06/Disable-Logon-Task-Microsoft-Windows-Management-Provisioning.pdf
SCHTASKS /Change /TN "\Microsoft\Windows\Management\Provisioning\Logon" /DISABLE >NUL 2>&1
FOR /d /r "C:\Windows\System32\config\systemprofile\AppData\Local\" %d IN ("tw-*") DO @IF EXIST "%d" rd /s /q "%d"
Workaround in meiner Testumgebung
Dateien im Format "MachineName-Date-time.log" im Verzeichnis %temp% (C:windowstemp) werden unter anderem durch den Click-to-Run-Komponentendienst ("C:Program FilesCommon Filesmicrosoft sharedClickToRunOfficeClickToRun.exe") [1] durch Microsoft Office verursacht [2]. Neben der Notwendigkeit des Dienstes im Kontext von Stabilitätsverbesserung (Updates) werden auch Diagnosedaten an Microsoft zur weiteren Auswertung übermittelt (Telemetrie) [3][4].
Im Analysebericht "Microsoft Office Telemetry" von Dr. Aleksandar Milenkoski für das BSI [5] wird hierzu detaillierter eingegangen.
Dabei wird im Abschnitt "Registry" (3.2) der Eintrag "DisableTelemetry" im Zweig "HKEY_CURRENT_USERSoftwarePoliciesMicrosoftoffice
commonclienttelemetryDisableTelemetry = 1" erwähnt. Dieser soll die Module "Aria and Nexus Office telemetry" deaktivieren.
Verschiedene Foreneinträge merken an [6], dass der Eintrag mit dem Wert 0x27001 für die Entfaltung seiner Wirksamkeit erstellt werden soll.
Des Weiteren soll der Wert "sendtelemetry" im Hive "HKEY_CURRENT_USERSoftwareMicrosoftOfficeCommonClientTelemetry" (wenn vorhanden) gelöscht werden [8].
Nachdem weder der eine oder andere Wert (1, 27001) für den Subkey "DisableTelemetry" bei mir funktionierte, habe ich folgende Auswertung mit Procmon [9] für den Prozess Click-to-Run-Komponentendienst im Testlab nachgestellt.
LOG-Datensatz in Procmon:
"OfficeClickToRun.exe","4028","RegQueryValue","HKU.DEFAULTSoftwareMicrosoftOfficeCommonClientTelemetryDisableTelemetry","NAME NOT FOUND","Length: 16","C:Program FilesCommon FilesMicrosoft SharedClickToRunOfficeClickToRun.exe","""C:Program FilesCommon FilesMicrosoft SharedClickToRunOfficeClickToRun.exe"" /service","Read","0.0000018","Registry"
Hierbei ersichtlich ist, dass der Wert im Zweig HKU.DEFAULT eingelesen wird. HKU.DEFAULT respektive HKUS-1-5-18 steht dabei für das Benutzerkonto NT AUTHORITYSYSTEM "Lokales System".
Meine Annahme: Da der Dienst OfficeClickToRun.exe im Kontext vom SYSTEM-Benutzer gestartet wird und nicht durch den aktuellen angemeldeten Benutzer, wird der Registryeintrag DisableTelemetry im Zweig HKEY_CURRENT_USER ignoriert.
Damit der Registry-Eintrag DisableTelemetry in Verbindung mit dem Office-Komponentendienst "OfficeClickToRun.exe mittels NT AUTHORITYSYSTEM "Lokales System" initialisiert werden kann, muss der Wert DisableTelemetry in der Registry beim Systemkonto gesetzt sein.
In weiteren Prüfverfahren in Kombination mit dem Eintrag DisableTelemetry und Loglevel = 1 werden keine Logdateien mehr erstellt.
Testumgebung "Virtuelle Maschine – Hyper-V"
– Microsoft Windows 11 Version 22H2 (OS build 22621.1778) Education 64-Bit (Deutsch)
– Office LTSC 2021 Version 2108 (Volume licensed Build 14332.20503 Release date May 9, 2023) (Deutsch)
Befehle in einer Kommandozeile (CMD) als Administrator absetzen:
reg load HKU.default "%SystemRoot%system32configdefault"
reg add HKU.defaultSoftwareMicrosoftofficeCommonclienttelemetry /v "DisableTelemetry" /t REG_DWORD /d "1" /f >nul 2>&1
reg add HKLMSOFTWAREMicrosoftClickToRunOverRide /v LogLevel /t REG_DWORD /d 1 /f >NUL 2>&1
reg add HKLMSOFTWAREMicrosoftOfficeClickToRunConfiguration /v TimerInterval /t REG_SZ /d "900000" /f >NUL 2>&1
Nach einem Neustart werden im Ordner C:WindowsTemp keine neuen Logdateien im Format MachineName-Date-time.log erstellt.
Stattdessen wird eine Datei mit dem Namen "officeclicktorun.exe_streamserver (DateTime).log" mit der Dateigröße von 0 Kilobyte erstellt.
Diese kann durch den permanenten Zugriff des "Click-to-Run-Komponentendienstes" darauf auch nicht ohne Weiteres gelöscht werden.
Quellen
[1] https://learn.microsoft.com/en-us/office/troubleshoot/office-suite-issues/office-click-to-run-installation
[2] https://learn.microsoft.com/en-us/office/troubleshoot/diagnostic-logs/how-to-enable-office-365-proplus-uls-logging
[3] https://privacy.microsoft.com/de-de/data-collection-office
[4] https://learn.microsoft.com/en-us/windows/privacy/manage-windows-11-endpoints
[5] https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Studien/Office_Telemetrie/Office_Telemetrie.pdf?__blob=publicationFile&v=5
[6] https://www.gruppenrichtlinien.de/artikel/office-2016-2019-365-telemetrie-deaktivieren-disabletelemetry
[7[
[8] https://learn.microsoft.com/en-us/answers/questions/224837/disable-hdd-writes-in-folder-appdatalocalmicrosoft
[9] https://learn.microsoft.com/en-us/sysinternals/downloads/procmon
Danke! Der letzte Beitrag hat es gebracht, die unsägliche Loggerei zu beenden.
Also ich bekomme eine Fehlermeldung beim ersten Eintag reg load HKU.default "%SystemRoot%system32configdefault"
Fehlermeldung ist C:\Windows\System32>reg load HKU.default "%SystemRoot%system32configdefault"
FEHLER: Ungültiger Schlüsselname.
Geben Sie "REG LOAD /?" ein, um die Syntax anzuzeigen.
Was ist da falsch?
Und wenn ich die anderen Einträge einzeln eingebe sehe ich auch nicht das Werte eingetragen werden in der Registry
es fehlen die\