{"id":273123,"date":"2022-09-23T08:55:30","date_gmt":"2022-09-23T06:55:30","guid":{"rendered":"https:\/\/www.borncity.com\/blog\/?p=273123"},"modified":"2022-09-23T15:00:58","modified_gmt":"2022-09-23T13:00:58","slug":"nachtrag-zum-windows-gpo-problem-kopieren-verschieben-verusacht-durch-sept-2022-update","status":"publish","type":"post","link":"https:\/\/borncity.com\/blog\/2022\/09\/23\/nachtrag-zum-windows-gpo-problem-kopieren-verschieben-verusacht-durch-sept-2022-update\/","title":{"rendered":"Nachtrag zum Windows GPO-Problem (Kopieren\/Verschieben), verursacht durch Sept. 2022 Update, Bestätigung durch Microsoft"},"content":{"rendered":"

\"Windows\"[English<\/a>]Seit Microsoft zum 13. September 2022 seine kumulativen (Sicherheits-) Updates f\u00fcr Windows ver\u00f6ffentlicht hat, funktioniert das Kopieren oder Verschieben von Dateien per Gruppenrichtlinie (GPO) nicht mehr. Ich hatte dies hier im Blog angesprochen. Nun hat mir ein Blog-Leser noch einige Hinweise sowie ein PowerShell-Script zum Evaluieren der Pfade, die betroffen sind, geliefert. Daher ein Nachtrag. Erg\u00e4nzung: Zudem hat Microsoft das Problem best\u00e4tigt.<\/p>\n

<\/p>\n

Das Windows GPO-Problem<\/h2>\n

\"\"Die kumulativen (Sicherheits-) Updates f\u00fcr Windows schlie\u00dfen diverse Schwachstellen und beseitigen Bugs (z.B. das Windows 10\/ 11: M\u00f6gliche Sommerzeit-Umstellungsprobleme [in Chile und weltweit]<\/a>). Bereits kurz nach Ver\u00f6ffentlichung des Blog-Beitrags Patchday: Windows 10-Updates (13. September 2022)<\/a> meldeten sich erste Benutzer, die von Problemen im Zusammenhang mit der Erstellung von Verkn\u00fcpfungsdateien berichteten:<\/p>\n

Nach September Updates funktioniert das Erstellen zweier Verkn\u00fcpfungen auf dem Desktop der User via GPO innerhalb der Dom\u00e4ne nicht mehr zuverl\u00e4ssig. Computer-Policies sowie User-Policies (GPO) kopieren keine Dateien mehr, schrieb ein Benutzer. Oder die kopierten Dateien sind leer.<\/p><\/blockquote>\n

Ich hatte dies im Blog-Beitrag Windows 10 Update KB5017308 verursacht Probleme beim Erstellen\/Kopieren von Dateien per GPO<\/a> f\u00fcr Windows 10 und das Update KB5017308<\/a> (steht f\u00fcr Windows 10 Enterprise\/Education 20H2 sowie f\u00fcr Windows 10 Version 21H1-21H2 bereit) angesprochen. Aber das Problem betrifft alle Windows 10\/11 Clients sowie Windows Server 2019 – 2022 (und ich meine auch Windows Server 2012 R2).<\/p>\n

Ziemlich krude Fehlermeldung<\/h3>\n

Benutzer, die der Sache nachgegangen sind, berichteten, im Anwendungsprotokoll der Ereignisanzeige einen Fehlercode 0x800703ee gefunden zu haben.<\/p>\n

Das Computer \"\"-Einstellungselement im Gruppenrichtlinienobjekt \"******** {97B70815-2B31-4A40-BB56-A27E6DAC6485}\" wurde aufgrund eines Fehlers nicht angewendet. Fehlercode: \"0x800703ee Der Datentr\u00e4ger einer Datei wurde extern so ge\u00e4ndert, dass die ge\u00f6ffnete Datei nicht mehr g\u00fcltig ist.\" Dieser Fehler wurde unterdr\u00fcckt.<\/p><\/blockquote>\n

Der Fehlercode Fehlercode 0x800703ee steht f\u00fcr ERROR_FILE_INVALID – irgendwie geht der Zugriff auf die Dateien wohl verloren.<\/p>\n

Teil-Workarounds nutzbar<\/h3>\n

Im Blog-Beitrag hatte ich einen Teil-Workaround angegeben – Blog-Leser Sven beschreibt es in diesem Kommentar<\/a> so:<\/p>\n

Nach etwas suchen war klar, wir kopieren den Usern die Konfig-Dateien neu auf die Clients. Diese Dateien wurden aber nach dem Update mit 0 KB kopiert.<\/p>\n

Nach entfernen des Hakens, dass die Dateien im User Kontext kopiert werden sollen (user policy option) hat das Kopieren per GPO wieder funktioniert.<\/p><\/blockquote>\n

Allerdings hilft das nicht in allen F\u00e4llen und Anwendungsszenarien. Ein Leser schrieb im englischsprachigen Blog:<\/p>\n

In my case I switched from user context to \"machine context \":<\/p>\n

\u2013> Additionally I have to add read access for the ad-group \"domain-computers\" to the sourcefolder \"\\\\server\\share\\\" for the \"machine context\".<\/p>\n

Read access for the ad-group (with users) was not working in the machine-context.<\/p><\/blockquote>\n

Ein weiterer Workaround wurde von einem Leser im englischsprachigen Blog erw\u00e4hnt (hier<\/a> und hier<\/a>): Einfach auf Wildcards bei Dateioperationen verzichten<\/em>. Dieser Ansatz l\u00e4sst sich aber in vielen Szenarien nicht verwenden.<\/p>\n

Neue Erkenntnisse<\/h2>\n

Blog-Leser Markus K. hat sich die Sachlage nochmals genauer angeschaut und mir per Mail folgende Informationen zukommen lassen.<\/p>\n

Hallo,
\nich habe mir das bei uns angesehen und kann folgendes dazu sagen:<\/p>\n

Wir kopieren ein File im Userkontext auf den Desktop, welcher auf einen Share redirected ist.<\/p>\n

Soweit so gut. Dazu nun folgende Screenshots:<\/p><\/blockquote>\n

\"Windows<\/a>
\nZum Vergr\u00f6\u00dfern klicken<\/a><\/p>\n

Der Share kennt \"System\" aber nicht – und im Userkontext hei\u00dft, dass das Zeug als \"User\" gemacht werden soll! Also kein Wunder, warum das zerbrochen ist.<\/p>\n

Ob es gut ist, dass nun \"im Benutzerkontext\" als \"System\" kopiert wird… ich wei\u00df nicht.<\/p>\n

Ich kann auch berichten, dass eine File copy Aktion durchaus gut geht, wenn man z.b. ein File nach Appdata\\Local schreibt, auch mit \"run in user context\".<\/p><\/blockquote>\n

Markus zieht in seiner Mail das Fazit: An Orte, wo \"System\" schreiben darf, wird das Kopieren klappen. Muss man etwas irgendwo hin kopieren, wo System keine Rechte hat, wird es spannender. Dann d\u00fcrfte die Dateioperation scheitern.<\/p>\n

Ein Script zum Testen<\/h2>\n

Markus hat mir noch ein paar Zeilen als PowerShell-Script zukommen lassen, mit dem nach schnell potenziell betroffene Gruppenrichtlinien (GPOs) identifizieren kann.<\/p>\n

$gpos = Get-GPO -All -Domain DEINEDOM\u00c4NE\r\n$gpos | %{[string]$srep = Get-GPOReport $_.DisplayName -ReportType Xml -Domain DEINEDOM\u00c4NE; if($($srep -match 'FilesSettings') -and $($srep -match 'userContext=\"1\"')){[xml]$xrep = $srep; $xrep.DocumentElement.Name; $xrep.DocumentElement.Name | Out-File PFADZUMLOG.log -Append -Force }}<\/code><\/pre>\n
Vielleicht hilft das ja ein paar verzweifelten Admins. Danke an Markus f\u00fcr die Hinweise.<\/p>\n
Microsoft best\u00e4tigt das GPO-Problem<\/h2>\n
Microsoft hat zum 22. September 2022 das Problem auf der Windows Release Healt Status-Seite<\/a> im Beitrag Copyying files\/shortcuts using Group Policy Preferences might not work as expected<\/a> best\u00e4tigt (danken an riedenthied<\/a> f\u00fcr den Hinweis). Betroffen sind alle Windows-Versionen:<\/p>\n