7
Windows und DISM-Reparaturen - eine kurze "Ups"-Geschichte
Moin moin.
Ich hätte da mal was abzusondern, was unter "Uups!" fällt, aber meiner Ansicht nach lehrreich ist.
Wir patchen Windows seit Jahr und Tag. Seit Windows 10 wurde das Patching unzuverlässiger - aus unerklärlichen Gründen gab es von 100 Clients immer 1 oder 2 mindestens, die ein kumulatives Update nicht installieren wollten.
Sie mussten mittels dism repariert werden, dann lief das Update. Das ging mir irgendwann so auf den Nerv, dass ich es automatisierte derart, dass per GPO geplantem Task ein Skript läuft, das dies tut. Damit es nicht mehrfach läuft, wird
A der Windowsbuild ausgelesen und mit dem des Vormonats verglichen (z.B. im Februar wird so sichergestellt, dass der Client wirklich noch das Januarupdate drauf hat und nur dann repariert werden darf)
B der Zustand nicht bereits "reboot pending" ist
Das lief sehr schön, bis zum Februar'25-Patchday als ich im Skript aus reiner Schläfrigkeit nicht den Build des Vormonates Januar für die Clients zum Vergleich eintrug, sondern versehentlich den Build des Februars (10.0.22631.4890).
Was nun passierte war Comedy:
Sobald sich die Clients auf diesen Build aktualisiert hatten, wurde Windows bei jedem GPO-Refresh unsichtbar im Hintergrund aufs Neue repariert; ca. 15x täglich, sofern die Kisten durchliefen. Und bei jeder Reparatur ballert dism.exe viele, viele Temporärdateien in das Verzeichnis C:\Windows\WinSxS\Temp\InFlight und natürlich löscht es diese nicht bei Beendigung. So kam dann ca. 2-3 Wochen nach dem Patchday eine Reihe von Warnmails "c: läuft voll".
Wir sprechen hier von einem Volumen pro PC von bis zu 140 GB und bis zu 1,5 Millionen Dateien in Hunderttausenden Ordnern nach 3 Wochen. Die löscht mal, das macht richtig Freude, zumal man erst den Besitz übernehmen und dann Löschrechte für Admins setzen muss... aber gut, dafür gibt es ja Skripting, auch um Probleme automatisiert zu lösen, die man selbst geschaffen hat!
Das Spannende an der Geschichte: fragt doch bitte mal Opa Google, was es mit C:\Windows\WinSxS\Temp\InFlight auf sich hat. Wer findet nur beim Googlen Hinweise, dass dism.exe (Dism /Online /Cleanup-Image /RestoreHealth) dort reinschreibt (und das nicht zu knapp)? Hier hat es Stunden gedauert, bis der Groschen fiel; es kam erst ans Licht, nachdem ich endlich mit procmon über Stunden alle Schreibzugriffe auf besagten Ordner gemonitort hatte und dann mit "count occurences" herausbekam, dass mit großem Abstand die tiworker.exe dort am Meistem reinschreibt. Da keine Windowsupdates ausstanden, konnte das nur noch dism.exe sein, die dahinter steckte und somit mein eigenes Skript.
Ich hätte da mal was abzusondern, was unter "Uups!" fällt, aber meiner Ansicht nach lehrreich ist.
Wir patchen Windows seit Jahr und Tag. Seit Windows 10 wurde das Patching unzuverlässiger - aus unerklärlichen Gründen gab es von 100 Clients immer 1 oder 2 mindestens, die ein kumulatives Update nicht installieren wollten.
Sie mussten mittels dism repariert werden, dann lief das Update. Das ging mir irgendwann so auf den Nerv, dass ich es automatisierte derart, dass per GPO geplantem Task ein Skript läuft, das dies tut. Damit es nicht mehrfach läuft, wird
A der Windowsbuild ausgelesen und mit dem des Vormonats verglichen (z.B. im Februar wird so sichergestellt, dass der Client wirklich noch das Januarupdate drauf hat und nur dann repariert werden darf)
B der Zustand nicht bereits "reboot pending" ist
Das lief sehr schön, bis zum Februar'25-Patchday als ich im Skript aus reiner Schläfrigkeit nicht den Build des Vormonates Januar für die Clients zum Vergleich eintrug, sondern versehentlich den Build des Februars (10.0.22631.4890).
Was nun passierte war Comedy:
Sobald sich die Clients auf diesen Build aktualisiert hatten, wurde Windows bei jedem GPO-Refresh unsichtbar im Hintergrund aufs Neue repariert; ca. 15x täglich, sofern die Kisten durchliefen. Und bei jeder Reparatur ballert dism.exe viele, viele Temporärdateien in das Verzeichnis C:\Windows\WinSxS\Temp\InFlight und natürlich löscht es diese nicht bei Beendigung. So kam dann ca. 2-3 Wochen nach dem Patchday eine Reihe von Warnmails "c: läuft voll".
Wir sprechen hier von einem Volumen pro PC von bis zu 140 GB und bis zu 1,5 Millionen Dateien in Hunderttausenden Ordnern nach 3 Wochen. Die löscht mal, das macht richtig Freude, zumal man erst den Besitz übernehmen und dann Löschrechte für Admins setzen muss... aber gut, dafür gibt es ja Skripting, auch um Probleme automatisiert zu lösen, die man selbst geschaffen hat!
Das Spannende an der Geschichte: fragt doch bitte mal Opa Google, was es mit C:\Windows\WinSxS\Temp\InFlight auf sich hat. Wer findet nur beim Googlen Hinweise, dass dism.exe (Dism /Online /Cleanup-Image /RestoreHealth) dort reinschreibt (und das nicht zu knapp)? Hier hat es Stunden gedauert, bis der Groschen fiel; es kam erst ans Licht, nachdem ich endlich mit procmon über Stunden alle Schreibzugriffe auf besagten Ordner gemonitort hatte und dann mit "count occurences" herausbekam, dass mit großem Abstand die tiworker.exe dort am Meistem reinschreibt. Da keine Windowsupdates ausstanden, konnte das nur noch dism.exe sein, die dahinter steckte und somit mein eigenes Skript.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 671739
Url: https://administrator.de/forum/windows-und-dism-reparaturen-eine-kurze-ups-geschichte-671739.html
Ausgedruckt am: 04.03.2025 um 16:03 Uhr
7 Kommentare
Neuester Kommentar
Moin.
So kann's auch gehen 🤪
Das kannst du entweder per elevated Powershell (via Win32 und RtlAdjustPrivilege Funktion) oder auch Robocopy mit den Schaltern /B und /MIR und einem leeren Dummy Ordner als Quelle in einer elevated Shell erreichen.
Gruß m.
So kann's auch gehen 🤪
zumal man erst den Besitz übernehmen und dann Löschrechte für Admins setzen muss...
Dauert i.d.R. viel zu lange bei tiefen Strukturen und ist auch überflüssig wenn man den Prozess der löschen soll als lokaler Admin startet und ihm zusätzlich das SeTakeOwnershipPrivilege- und SeBackupPrivilege- und SeRestorePrivilege- Tokens gibt, dann kannst du auch Files löschen die dir nicht selbst gehören und auf die man laut ACLs auch eigentlich keine Rechte hat.Das kannst du entweder per elevated Powershell (via Win32 und RtlAdjustPrivilege Funktion) oder auch Robocopy mit den Schaltern /B und /MIR und einem leeren Dummy Ordner als Quelle in einer elevated Shell erreichen.
Gruß m.
1
Ja, der Robocopy-Trick hat was, ob das viel Schneller ist, müsste ich messen - vermutlich ja deutlich.
Edit
Ja, das ist deutlich schneller mit robocopy getan! Kannte den Trick zwar noch aus grauer Vorzeit, hatte den aber längst nicht mehr abrufbar im Kopf, danke!
Edit
Ja, das ist deutlich schneller mit robocopy getan! Kannte den Trick zwar noch aus grauer Vorzeit, hatte den aber längst nicht mehr abrufbar im Kopf, danke!
Meine früheren Erfahrungen -maßgeblich mit sysprep - waren bisher, das solche Probleme von Apps ausgelöst wurden, die für mehrere User aktiviert wurden. Das zeigte auch das sysprep-log.
Meist half das deinstallieren solcher Software - auch bei System-Updates.
M$ hat am 15.01. ein Update dazu herausgebracht. Ich bezweifle aber das final hilfreich war/ist 🤔
Meist half das deinstallieren solcher Software - auch bei System-Updates.
M$ hat am 15.01. ein Update dazu herausgebracht. Ich bezweifle aber das final hilfreich war/ist 🤔
Ich bezweifle aber das final hilfreich war/ist
Ich suche doch gar keine Hilfe. Das Problem ist ja schon erkannt und beschrieben.Zitat von @DerWoWusste:
Ich bezweifle aber das final hilfreich war/ist
Ich suche doch gar keine Hilfe. Das Problem ist ja schon erkannt und beschrieben.War auch nur als zusätzlicher Hinweis gemeint 😉
Zitat von @DerWoWusste:
Edit
Ja, das ist deutlich schneller mit robocopy getan! Kannte den Trick zwar noch aus grauer Vorzeit, hatte den aber längst nicht mehr abrufbar im Kopf, danke!
Edit
Ja, das ist deutlich schneller mit robocopy getan! Kannte den Trick zwar noch aus grauer Vorzeit, hatte den aber längst nicht mehr abrufbar im Kopf, danke!
Was zu erwarten war.
Hier auch noch ergänzend ohne Robocopy nur mittels Powershell, dann kann man normal mit remove-item auch rekursiv löschen ohne die Rechte vorher anpassen zu müssen (muss natürlich auch elevated gestartet werden):
Add-Type '[DllImport("ntdll.dll")] public static extern int RtlAdjustPrivilege(int Privilege, bool Enable, bool CurrentThread, ref bool EnabledOut);' -name tok -namespace priv
[void][priv.tok]::RtlAdjustPrivilege(9,1,0,[ref]0)
[void][priv.tok]::RtlAdjustPrivilege(17,1,0,[ref]0)
[void][priv.tok]::RtlAdjustPrivilege(18,1,0,[ref]0)
remove-item -Path 'C:\OrdnerZuLöschen' -Force -Recurse Vielleicht hilfts dir/euch irgendwann mal.
1
Schick. Danke für's teilen!
