Marco31

So, kleines Update hierzu von GData: Laut der freundlichen Dame vom Support könnte das mit einem Fehler im GData Wächter zusammenhängen; der gibt wohl Dateien nicht schnell genug frei, wodurch das schreiben der Dateien in besagten Verzeichnissen zustande kommen könnte. Übrigens auch bei definierten Ausnahmen wenn ich das richtig verstanden hatte...

Ich bekomme einen Download-Link für eine aktuellere GData-AV Version, bei dieser soll der Fehler wohl nicht mehr auftreten. Werde das dann mal weiter verfolgen.

@moos: Nein, den ganzen Ordner natürlich nicht! Nur die Verzeichnisse unter C:\Windows\assembly\NativeImages_v2.0.50727_32\temp\ bzw. C:\Windows\assembly\NativeImages_v2.0.50727_64\temp\

Je nachdem in welchem Verzeichnis bei dir die Probleme liegen.

Ich habe die Dateien mit Total Commander verschoben, man muss nur drauf achten dass eingestellt ist dass versteckte und Systemdateien angezeigt werden.

https://www.ghisler.com/deutsch.htm

Wie gesagt, ich habe die Dateien vorsichtshalber auf eine externe USB-Platte verschoben. Hatte bisher keine negativen Auswirkungen auf den Betrieb der Server, zumindest keine die ich erkennen konnte. Die Datenträgerbereinigung bringt da nix, zumindest bei mir hat er die temp-Dateien in dem Ordner nicht beachtet.

Der Support von GData hat sich bisher nicht gemeldet, was mich wundert da der Support da eigentlich recht fix war...

Vermutlich :D

Es ist ja nicht nur Exchange so wie es aussieht, das Problem scheint ja mit .net zusammenzuhängen. Es scheint für mich so, dass immer dann die entsprechenden temp-Dateien angelegt werden, wenn ein .net Update erfolgt. Je nach Anwendung mehr oder weniger groß, Exchange und SQL sind da ganz vorne dabei.

Werde aber auf jeden Fall nochmal die Liste der Ausnahmen durchgehen und ggf Ordner nachtragen.

Ich warte erstmal auf die Antwort des Supports, die Updates sind eh erstmal durch. Falls die auch keine Idee haben werde ich bei den nächsten Updates vorher mal den Wächter bei einer Maschine komplett ausschalten, und bei einer anderen mal das Verzeichnis ausschließen.

Wir haben GData Antivirus

So, kleine Zwischenmeldung hierzu. Nach den letzten Updates hat sich gezeigt, dass das Verhalten mehr oder weniger schlimm auf allen Clients und Servern auftritt - heute morgen waren bei zwei weiteren Servern die C-Laufwerke fast voll. Ich habe mittlerweile unseren Virenscanner im Verdacht, auf der einzigen Maschine auf der er nicht installiert ist sind die besagten temp-Verzeichnisse komplett leer. Ticket zum Support ist raus, mal sehen was die dazu meinen....

Exchange ist also schon mal Unschuldig ;)

Was meinst du mit Automatisch? Dass Updates automatisch installiert werden? Updates laufen generell über unseren WSUS und die Server werden natürlich nur "unter Aufsicht" gepatcht....

Ist ja eh wieder Update-Time, auch mit .net Updates. Werde mir das Verzeichnis mal nach dem Update anschauen, bis jetzt ist es noch leer.

Wenn man für jedes "Ich hab aber nichts gemacht" 100 EUR bekommen würde... :D

So, ich habe die Dateien in dem Ordner mal auf eine andere Platte verschoben - auf C:\ war bereist so wenig frei dass keine Mails mehr empfangen oder versendet wurden.

Was meine bisherigen Recherchen ergeben haben, ist dass der Ordner wohl zu .net Framework gehört. Bisher hatte das verschieben keine negativen Auswirkungen, Exchange läuft und wirft keine Fehler aus.

Würde trotzdem gerne wissen wo da genau das Problem liegt dass der Ordner so massiv anwachsen konnte...

Hallo liebes Forum,

ich musste heute feststellen, dass auf unserem Exchange Server der Ordner C:\Windows\Assembly\NativeImages_v2.0.50727_64\temp mittlerweile 24GB belegt! Inhalt sind unzählige Ordner mit Namen ZAPxxxx.tmp (x=diverse Buchstaben/Zahlen) . Inhalt der Ordner sind z.B. Dateien wir Microsoft.Exchange.Management.dll, Microsoft.Exchange.Data.Storage.dll, PresentationFramework.dll und andere. Jeweils pro Verzeichnis eine Datei.

Kann man diese Dateien irgendwie "bereinigen" oder werden diese noch vom System benötigt? Der Server ist eine VM und läuft auf Windows 2008R2, Exchange ist 2010 SP3 mit Update Rollup 17.

Also bei mir hat das bei der 121 wie immer funktioniert; Java runtergeladen, Installation gestartet, MSI aus C:\Users\User\AppData\LocalLow\Oracle\Java\jre1.8.0_121 kopiert, Installation abgebrochen und MSI per WPP verteilt...

Und hiermit kannst du dann im gleichen Zug auch die alte Java-Installation deinstallieren: https://www.wsus.de/uninstall2install

Meines Wissens nach kann man Java nicht mit der heruntergeladenen .exe über WPP verteilen, man muss daraus die MSI extrahieren und die verteilen.

Ich denke mal das was du suchst wird im Druckertreiber nicht möglich sein, das steuert doch die Software aus der du druckst?

Das ganze ist wohl wie du schon erwähnst ein Fehler in Win10 1607 im Zusammenspiel mit Win2008/2012 als Printserver. Siehe hier: https://support.microsoft.com/en-us/help/3201130/printing-preferences-from-the-print-server-don-t-synchronize-in-windows-10-version-1607

Da gibt's auch einen Würgaround.

Link habe ich keinen, es geht ja um das verteilen per WSUS...

Für das Update auf Windows 1607 über WSUS steht seit letzter Woche ein überarbeitetes Update-Paket zur Verfügung. Damit soll wohl auch das Problem mit den nicht mehr funktionierenden WSUS-Updates nach Upgrade auf 1607 Geschichte sein.  Kann ich soweit auch bestätigen, zwei Testmaschinen erhielten erfolgreich ein Upgrade auf 1607 und haben danach aktuelle Updates vom WSUS installiert.

Werde ich dann wohl so machen. Schwer ist das nicht, die fehlerhaften Dateien sind aber ein weiteres Beispiel für die derzeit bescheidene Qualität einiger Produkte aus dem Hause Microsoft.

Wie auch immer, ich weiß was ich zu tun habe. Danke an alle für die Hilfe :thumb1:

Von wegen. Wäre wohl zu einfach gewesen. Hatte die windowsupdate.adml von einem aktuellen Windows 10 1607 in den Central Store kopiert, Gruppenrichtlinienverwaltung geöffnet, die entsprechende Richtlinie geöffnet und schon werde ich mit einem Fehler begrüßt. Es scheinen Einstellungen in der ADMX vorhanden zu sein, die in der ADML anders/nicht vorhanden sind. Unter Windows Komponenten erscheint Windows Update nicht mal mehr.

Also runtergeladene, "falsche" windowsupdate.adml wieder rein.

Scheint also sehr wohl Unterschiede zwischen den ADMX/ADML zum runterladen und denen auf einem aktuell gepatchten W10 1607 zu geben.

Ist die Frage was jetzt besser ist; die ADMX/ADML aus der Windows 10 1607 nehmen und in den Central Store kopieren (wo höchstwahrscheinlich Unterschiede zur aktuellsten Version bestehen) oder die runtergeladenen ADMX/ADML nutzen und mit dem Kauderwelsch leben bis MS sich bequemt ne berichtigte Version rauszubringen...

Ich gehe also davon aus dass ich die fehlerhafte adml mit der windowsupdate.adml eines beliebigen, aktuell gepatchten Windows 10 1607 ersetzen kann?

Ich habe mir die ADMX/ADML bisher immer aktuell heruntergeladen. Man sollte ja eigentlich denken dass die Download-Dateien dem Stand in einem aktuellen Windows 10 entsprechen, aber MS belehrt uns wieder einmal eines besseren...

Auf meiner Heim-Maschine (W10 1607 Home) habe ich mir gestern mal die windowsupdate.adml angeschaut, da ist alles in Ordnung.

Hab das mittlerweile auf zwei Rechnern getestet, sowohl Win10 1511 als auch Win10 1607. Und wie gesagt, wenn ich die frisch installierte adml mit dem Editor oder Notepad+ öffne sieht es ganz genau so aus.

Ich wird nachher mal schauen ob ich die Datei zuhause mal runterladen und entpacken kann, mal sehen was dabei raus kommt.

Zuhause das gleiche. Datei runtergeladen, entpackt, windowsupdate.adml mit Notepad+ geöffnet. Der gleiche Kauderwelsch bei den beiden Einstellungen. Wer Zeit und Lust hat kann sich ja auch mal die Datei runterladen und anschauen....

Grade neu runtergeladen und wieder das gleiche. Ist mir ein Rätsel...

Das ist schon die richtige. Steht ja fast alles richtig und in deutsch drinne, nur einige Einträge sind anscheinend in Microsoft-Mandarin gehalten... :confused:

Siehe auch https://www.microsoft.com/de-DE/download/details.aspx?id=53430

@ Hans888: Dann hast du vielleicht nicht die aktuellste Version; meine sind Version 2.0 mit Veröffentlichungsdatum 08.01.2017

@ NorbertFe: Ist die windowsupdate.adml