OliverHu 19 Geschrieben 12. Mai 2016 Melden Teilen Geschrieben 12. Mai 2016 Liest du meine Kommentare überhaupt? Interessant ist die Fragen: Kann ich diese Dateien definitiv löschen ja/nein? Hat das schon jemand gemacht? Gibt es da Erfahrungen? Ja, ich habe diese gelöscht. Und ja, ich habe das schon mal gemacht, bei rund 10 Maschinen. Und ja, ich kann deine Situation sehr gut verstehen, da ich selber jahrelang als Dienstleister unterwegs war... Zitieren Link zu diesem Kommentar
Sunny61 807 Geschrieben 12. Mai 2016 Melden Teilen Geschrieben 12. Mai 2016 Windows Update glaub ich nicht das rein schreibt, eher vielleicht der WSUS. Läuft ein WSUS auf dem Server? Wenn ja, gibt es noch offene Downloads? Zitieren Link zu diesem Kommentar
H. Hennig 10 Geschrieben 12. Mai 2016 Autor Melden Teilen Geschrieben 12. Mai 2016 Ich hatte das Problem bei rund 10 Maschinen, laufen immer noch... ;) Ja, ich lese Deine Kommentare. Dieser wurde mir aber erst jetzt angezeigt. Da kann ich mich nur entschuldigen, das konnte ich vorher nicht lesen. Nein, WSUS läuft nicht. Zitieren Link zu diesem Kommentar
Sanches 22 Geschrieben 12. Mai 2016 Melden Teilen Geschrieben 12. Mai 2016 Hi, welche Daten sollen nun verschwinden? Wie in deinem Eröffnungspost unter C:\Windows\Temp? => Ja, diese können gelöscht werden. Selbst wenn ich die Daten erstmal nur verschiebe ist noch nicht gesagt, dass im Fehlerfall ein Zurückkopieren hilft. Auf dem einzigen Server in einer produktiven Umgebung Dateien löschen, in der Hoffnung das nichts schief geht - das sollte man (es sei denn es gibt wirklich wichtige Gründe) tunlichst vermeiden. Sich dann noch, nach dem Motto "wenn es schief geht kann ich ja das Backup zurück spielen" auf ein Backup verlassen halte ich für fahrlässig. Wenn Eure Kunden solche Spiele mitmachen und bezahlen habt Ihr großes Glück, seit aber nicht in der freien Wirtschaft als Dienstleister unterwegs. Entschuldigt wenn ich das so sagen muss, entspricht aber nicht nur meinen Erfahrungen. Warum dieser "Rund-um-Schlag"? Würden wir den Spiess rumdrehen, könnten wir behaupten, das eher die Single-Server Variante fahrlässig ist. Oder das du evtl. dem Backupkonzept nicht vertraust. ... Aber dabei würden wir eher vom urspünglichen Thema abschweifen. Und ja, auch ich bin im Dienstleistungssektor unterwegs. Gruß Sebastian Zitieren Link zu diesem Kommentar
H. Hennig 10 Geschrieben 12. Mai 2016 Autor Melden Teilen Geschrieben 12. Mai 2016 Ich glaube auch, dass wir hier etwas vom eigelichen Thema abweichen. Zurück zur eigentlichen Frage. Das die Dateien unter C:\Windows\Temp gelöscht werden können ist klar. Die Frage ist: Wo kommen diese Dateien her? Wer schreibt diese Dateien? Warum werden diese Dateien nicht vom System gelöscht? Wie kann ich verhindern, dass diese Dateien immer wieder erstellt werden? (Es geht um die immer wiederkehrenden, genau 131.540 KB großen Dateien) Über Deinen gestrigen Post bin ich in diesem Zusammenhang auf C:\windows\logs\cbs gekommen und habe festgestellt, dass auf dem betreffenden Server in diesem Verzeichnis ca. 15 GB Logdateien liegen, einige davon sehr groß (bis 4 GB). Daher die Frage ob diese Dateien gelöscht werden können. Die Informationen im Internet sind sehr unterschiedlich: "In diesem Ordner nichts löschen", "alle *.cab Dateien können gelöscht werden" oder "es kann alles gelöscht werden". Das eigentliche Thema bezieht sich aber auf die Dateien in C:\Windows\Temp. H.H. Zitieren Link zu diesem Kommentar
Sunny61 807 Geschrieben 12. Mai 2016 Melden Teilen Geschrieben 12. Mai 2016 Die Frage ist: Wo kommen diese Dateien her? Wer schreibt diese Dateien? Warum werden diese Dateien nicht vom System gelöscht? Wie kann ich verhindern, dass diese Dateien immer wieder erstellt werden? (Es geht um die immer wiederkehrenden, genau 131.540 KB großen Dateien) Du hättest schon längst den Prozess Monitor verwenden können, hier wird nur wild spekuliert, das bringt dich keinen Schritt weiter. Zitieren Link zu diesem Kommentar
H. Hennig 10 Geschrieben 13. Mai 2016 Autor Melden Teilen Geschrieben 13. Mai 2016 Heute Abend habe ich die Gelegenheit den Prozessmonitor laufen zu lassen. Ich werde dann nach Pfingsten über die Ergebnisse berichten. Zitieren Link zu diesem Kommentar
H. Hennig 10 Geschrieben 17. Mai 2016 Autor Melden Teilen Geschrieben 17. Mai 2016 Hallo, ich hatte ab Fr. ca. 17:00 Uhr den Prozessmonitor laufen. Bereits am Sa. früh war LW C: komplett voll und das System stand. Nach Beendigung des Prozessmonitors waren wieder ca. 15 GB frei. Testweise habe ich jetzt den Prozessmonitor bei mir auf dem PC laufen und lasse die Ergebnisse in Dateien speichern (Prozessmonitor -> File -> Backing Files -> Use File named ...). Nach weniger als 2 Stunden hat der Prozessmonitor mehr als 6 GB Daten geschrieben. Ich muss den Prozessmonitor über mehrere Stunden laufen lassen, da die fraglichen Dateien zu nicht vorhersehbaren, völlig unterschiedlichen Zeiten erstellt werden und ich damit nicht sagen kann wann dies stattfindet. Wie kann ich den Prozessmonitor für längere Zeit laufen lassen, ohne dass riesige Datenmengen im System zwischengespeichert werden? H.H. Zitieren Link zu diesem Kommentar
Sunny61 807 Geschrieben 17. Mai 2016 Melden Teilen Geschrieben 17. Mai 2016 Filtern auf den/die Dateienamen/Verzeichnisse in die geschrieben wird. Und vor dem loslaufen lassen am besten auch mal etwas testen, dann weiß man 'vorher' was schon was später kommt. Zitieren Link zu diesem Kommentar
blub 115 Geschrieben 17. Mai 2016 Melden Teilen Geschrieben 17. Mai 2016 Ich würde über NTFS-Auditing versuchen, den Verursacher zu finden: 1.) secpol.msc -> Advanced Audit Policy Configuration -> Object Access -> Audit File System "Success and Failure" 2.) Am Ordner in den NTFS-Settings: -> Advanced -> Auditing -> Add -> Principal "Domain Users" oder "Everyone" -> Permissions nur auf "Write" (SACL), um die Anzahl der Events klein zu halten 3) Im Security Eventlog siehst du dann genau, "wer, mit welchem Prozess wann welche Datei" in den Ordner geschrieben hat. Mit "Read" in der SACL könntest du auch sehen, ob jemand auf diese Dateien zugreift. blub Zitieren Link zu diesem Kommentar
H. Hennig 10 Geschrieben 17. Mai 2016 Autor Melden Teilen Geschrieben 17. Mai 2016 @Sunny61 Hatte ich eigentlich so gemacht. Erst als Test (einige Minuten) auf meinem PC, dann "scharf" auf dem Server. Beim jetzigen, erneuten Test auf meinem PC (Filter nur Path ein Ordner) wurden in ca. 5 1/2 Stunden insgesamt 86 Logdaten zu je ca. 300 MB geschrieben. Ich habe verschiedene Varianten ausprobiert - immer das selbe Ergebnis. @blub Vielen Dank für den Tipp. Das muss ich aber erstmal testen. H.H. Zitieren Link zu diesem Kommentar
Sunny61 807 Geschrieben 17. Mai 2016 Melden Teilen Geschrieben 17. Mai 2016 @Sunny61 Hatte ich eigentlich so gemacht. Erst als Test (einige Minuten) auf meinem PC, dann "scharf" auf dem Server. Beim jetzigen, erneuten Test auf meinem PC (Filter nur Path ein Ordner) wurden in ca. 5 1/2 Stunden insgesamt 86 Logdaten zu je ca. 300 MB geschrieben. Ich habe verschiedene Varianten ausprobiert - immer das selbe Ergebnis. OK, es wurden also Logdateien erstellt, hast Du denn auch mal reingeschaut? Zitieren Link zu diesem Kommentar
H. Hennig 10 Geschrieben 24. Mai 2016 Autor Melden Teilen Geschrieben 24. Mai 2016 Es ist einiges dazwischen gekommen, deshalb komme ich erst jetzt zum Antworten. Der Kunde hatte den Prozessmonitor nach Pfingsten selbst beendet. Danach waren wieder ca. 15 GB frei. Die Logdateien auf dem Server wurden also temporär geschrieben und waren dann weg. Nur bei den tests auf meinem PC habe ich die Logs in Dateien speichern lassen. Das will ich auf dem Server aber nicht machen (nach wenigen Stunden ist das ganze System zu und ich kann nicht garantieren, ob in der Zeit die fraglichen Dateien erstellt wurden). Folgendes ist aber jetzt bekannt: Während diese Dateien erstellt werden ist tatsächlich makecab aktiv. Komischerweise lassen sich die so erstellten Dateien mit extract nicht entpacken (Fehler: ERROR: cab_512_2 is not a cabinet file). Den Tipp von blub habe ich an einem Demosystem getestet. Leider erscheinen keine Einträge im Protokoll wenn ich testweise Dateien oder Ordner erstelle. Ich vermute, dass ich da etwas falsch mache. H.H. Zitieren Link zu diesem Kommentar
OliverHu 19 Geschrieben 24. Mai 2016 Melden Teilen Geschrieben 24. Mai 2016 Und du willst nicht mal meinen Vorschlag umsetzen? ;) Zitieren Link zu diesem Kommentar
zahni 554 Geschrieben 8. Juni 2016 Melden Teilen Geschrieben 8. Juni 2016 So den Fehler hatte ich jetzt auch. Ursache ist wohl ein Bug im Trusted Installer, der gelegentlich auftritt. Dabei werden cbs.log in C:\windows\logs\cbs im CAB-Format komprimiert. Dabei enstehen Temp-Dateien die dann, das ist der Bug, nicht gelöscht werden. Lösung soll sein: Windows-Udpate-Dienst und Windows Modules Installer stoppen, "SoftwareDistribution" löschen und den Inhalt von C:\windows\logs\cbs (ist ein wenig hakelig). Ich habe in der VM gerade so über 20GB frei bekommen. Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.