[English]Seit Microsoft zum 13. September 2022 seine kumulativen (Sicherheits-) Updates für Windows veröffentlicht 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änzung: Zudem hat Microsoft das Problem bestätigt.
Anzeige
Das Windows GPO-Problem
Die kumulativen (Sicherheits-) Updates für Windows schließen diverse Schwachstellen und beseitigen Bugs (z.B. das Windows 10/ 11: Mögliche Sommerzeit-Umstellungsprobleme [in Chile und weltweit]). Bereits kurz nach Veröffentlichung des Blog-Beitrags Patchday: Windows 10-Updates (13. September 2022) meldeten sich erste Benutzer, die von Problemen im Zusammenhang mit der Erstellung von Verknüpfungsdateien berichteten:
Nach September Updates funktioniert das Erstellen zweier Verknüpfungen auf dem Desktop der User via GPO innerhalb der Domäne nicht mehr zuverlässig. Computer-Policies sowie User-Policies (GPO) kopieren keine Dateien mehr, schrieb ein Benutzer. Oder die kopierten Dateien sind leer.
Ich hatte dies im Blog-Beitrag Windows 10 Update KB5017308 verursacht Probleme beim Erstellen/Kopieren von Dateien per GPO für Windows 10 und das Update KB5017308 (steht für Windows 10 Enterprise/Education 20H2 sowie für 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).
Ziemlich krude Fehlermeldung
Benutzer, die der Sache nachgegangen sind, berichteten, im Anwendungsprotokoll der Ereignisanzeige einen Fehlercode 0x800703ee gefunden zu haben.
Das Computer ""-Einstellungselement im Gruppenrichtlinienobjekt "******** {97B70815-2B31-4A40-BB56-A27E6DAC6485}" wurde aufgrund eines Fehlers nicht angewendet. Fehlercode: "0x800703ee Der Datenträger einer Datei wurde extern so geändert, dass die geöffnete Datei nicht mehr gültig ist." Dieser Fehler wurde unterdrückt.
Der Fehlercode Fehlercode 0x800703ee steht für ERROR_FILE_INVALID – irgendwie geht der Zugriff auf die Dateien wohl verloren.
Anzeige
Teil-Workarounds nutzbar
Im Blog-Beitrag hatte ich einen Teil-Workaround angegeben – Blog-Leser Sven beschreibt es in diesem Kommentar so:
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.
Nach entfernen des Hakens, dass die Dateien im User Kontext kopiert werden sollen (user policy option) hat das Kopieren per GPO wieder funktioniert.
Allerdings hilft das nicht in allen Fällen und Anwendungsszenarien. Ein Leser schrieb im englischsprachigen Blog:
In my case I switched from user context to "machine context ":
–> Additionally I have to add read access for the ad-group "domain-computers" to the sourcefolder "\\server\share\" for the "machine context".
Read access for the ad-group (with users) was not working in the machine-context.
Ein weiterer Workaround wurde von einem Leser im englischsprachigen Blog erwähnt (hier und hier): Einfach auf Wildcards bei Dateioperationen verzichten. Dieser Ansatz lässt sich aber in vielen Szenarien nicht verwenden.
Neue Erkenntnisse
Blog-Leser Markus K. hat sich die Sachlage nochmals genauer angeschaut und mir per Mail folgende Informationen zukommen lassen.
Hallo,
ich habe mir das bei uns angesehen und kann folgendes dazu sagen:Wir kopieren ein File im Userkontext auf den Desktop, welcher auf einen Share redirected ist.
Soweit so gut. Dazu nun folgende Screenshots:
Zum Vergrößern klicken
Der Share kennt "System" aber nicht – und im Userkontext heißt, dass das Zeug als "User" gemacht werden soll! Also kein Wunder, warum das zerbrochen ist.
Ob es gut ist, dass nun "im Benutzerkontext" als "System" kopiert wird… ich weiß nicht.
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".
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ürfte die Dateioperation scheitern.
Ein Script zum Testen
Markus hat mir noch ein paar Zeilen als PowerShell-Script zukommen lassen, mit dem nach schnell potenziell betroffene Gruppenrichtlinien (GPOs) identifizieren kann.
$gpos = Get-GPO -All -Domain DEINEDOMÄNE
$gpos | %{[string]$srep = Get-GPOReport $_.DisplayName -ReportType Xml -Domain DEINEDOMÄNE; if($($srep -match 'FilesSettings') -and $($srep -match 'userContext="1"')){[xml]$xrep = $srep; $xrep.DocumentElement.Name; $xrep.DocumentElement.Name | Out-File PFADZUMLOG.log -Append -Force }}Vielleicht hilft das ja ein paar verzweifelten Admins. Danke an Markus für die Hinweise.
Microsoft bestätigt das GPO-Problem
Microsoft hat zum 22. September 2022 das Problem auf der Windows Release Healt Status-Seite im Beitrag Copyying files/shortcuts using Group Policy Preferences might not work as expected bestätigt (danken an riedenthied für den Hinweis). Betroffen sind alle Windows-Versionen:
- Client: Windows 11, Version 22H2; Windows 11, Version 21H2; Windows 10, Version 21H2; Windows 10, Version 21H1; Windows 10, Version 20H2; Windows 10 Enterprise LTSC 2019; Windows 10 Enterprise LTSC 2016; Windows 10 Enterprise 2015 LTSB; Windows 8.1
- Server: Windows Server 2022; Windows Server 2019; Windows Server 2016; Windows Server 2012 R2; Windows Server 2012; Windows Server 2008 R2 SP1; Windows Server 2008 SP2
nachdem die Sicherheitsupdates von 13. September 2022 installiert wurden. Dazu heißt es bei Microsoft:
Nach der Installation von KB5017315 (bzw. dem zum Windows-Version passenden Update) können Dateikopien mit Gruppenrichtlinieneinstellungen fehlschlagen oder leere Verknüpfungen oder Dateien mit 0 (null) Bytes erstellen.
Bekannte betroffene Gruppenrichtlinienobjekte beziehen sich auf Dateien und Verknüpfungen in Benutzerkonfiguration -> Einstellungen -> Windows-Einstellungen im Gruppenrichtlinien-Editor.
Microsoft arbeitet an einer Lösung und will das Ganze in einer der nächsten Versionen von Updates ausrollen. Als Workaround für dieses Problem schlägt Microsoft folgende Maßnahmen vor:
- Deaktivieren Sie die Option "Im Sicherheitskontext des angemeldeten Benutzers ausführen (Option der Benutzerrichtlinie)". Hinweis: Bei Elementen, die einen Platzhalter (*) verwenden, wird das Problem dadurch möglicherweise nicht behoben.
- Ändern Sie in der betroffenen Gruppenrichtlinie "Aktion" von "Ersetzen" in "Aktualisieren".
- Wenn ein Platzhalter (*) im Speicherort oder Ziel verwendet wird, kann das Löschen des nachgestellten "\" (Backslash, ohne Anführungszeichen) aus dem Ziel den erfolgreichen Kopiervorgang ermöglichen.
Ein Blog-Leser hat in einer Mail an mich die Frage aufgeworfen, ob das WSUS-Chaos, welches ich im Blog-Beitrag WSUS-Chaos: Preview-Updates für Windows und Net zum 21.9.2022 als Superseded zurückgezogen angesprochen habe, mit dem GPO-Problem zu tun hatte. Denn im Microsoft Answers-Forum schreibt ein Nutzer:
Everyone with this issue should try latest Preview Update KB5017380 which probably addresses an issue that affects Group Policy Objects.
Nutzer JSB_116 ergänzt dann:
We have an open Microsoft case, and we just got a message from Microsoft that installing Preview Update KB5017380 solve the problem. Can anyone confirm that.
Keine Ahnung, ob das zutrifft – ein Benutzer mit Namen DomLu bestätigt das:
Yes it resolved our apparent issues with Group Policy Preferences- File actions… we'll see what else is broken soon lol.
Andererseits negiert Rene-Comedian in MS Answers genau diese Erkenntnis und schreibt:
I have installed kb5017308 und yesterday kb5017380, and still I can redproduce the problems with deploy files via gpp, if the "in user context"-box is checked.
Mit anderen Worten: Microsoft hat wohl versucht was zu flicken, dass aber nicht wirklich hin bekommen. Mal schauen, ob es bis zum Oktober 2022-Patchday eine Lösung gibt.
Ähnliche Artikel:
Patchday: Windows 10-Updates (13. September 2022)
Patchday: Windows 11/Server 2022-Updates (13. September 2022)
Windows 7/Server 2008R2; Windows 8.1/Server 2012R2: Updates (13. September 2022)
Windows 10 Update KB5017308 verursacht Probleme beim Erstellen/Kopieren von Dateien per GPO
Anzeige
Moin, auch bei uns sehr großes Problem. Wir hören auch von befreundeten Admins, dass großes Chaos herrscht. Hoffentlich wird das Problem bald ernst genommen.
Danke für den Zweizeiler!
Hallo , wie hast Du denn aus dem Zweizeiler ein Output File bekommen ?
Bei mir wird in dem von mir angegebenen Pfad keine Datei erstellt.
Skript habe ich überprüft , Domäne stimmt auch.
Danke
Bei uns in der Umgebung tritt das Problem ebenfalls auf, direkt beobachtet haben wir es allerdings nur bei Verknüpfungen die per Gruppenrichtlinie verteilt werden. Zudem scheint nur ein sehr kleiner Teil der Benutzer bei uns betroffen zu sein. Außerdem werden die fehlenden Verknüpfungen meist nach Ausführung von gpupdate umgehend erstellt. Ein konsistentes Fehlerbild kann ich daraus nicht ableiten.
Die bei uns betroffenen Gruppenrichtlinien zur Erstellung von Verknüpfungen werden übrigens von dem kleinen Powershell Skript nicht erfasst. Falls ich das gerade richtig interpretiert habe, müsste in unserem Fall nach ShortcutSettings anstelle von FilesSettings gesucht werden.
Kleiner Hinweis: SYSTEM Zugriff auf einen Share heißt in der Regel, dass das Computerkonto des Clients Zugriff benötigt ;-)
Microsoft hat das Problem nun zumindest gelistet und bestätigt, z.B. für den Server 2019: https://docs.microsoft.com/en-us/windows/release-health/status-windows-10-1809-and-windows-server-2019
Gibt auch ein paar Hinweise für potentielle Workarounds.
Hi,
sorry, ich kann das leider nicht bestätigen, was Markus K. geschrieben hat: Gerade noch mal getestet:
Deploy Files auf eine Verzeichnis appdata\local, wo SYSTEM Vollzugriff hat.
Der Haken ist gesetzt "Im Sicherheitskontext des angemeldeten Benutzers ausführen".
Aktion: Ersetzen
==> Ergebnis: Es entsteht eine Datei, die 0 KB groß ist und somit nicht genutzt werden kann.
Entferne ich den Haken "Im Sicherheitskontext…", dann wird die Datei korrekt kopiert.
Event 4098:
Das Benutzer "Test RJ Only"-Einstellungselement im Gruppenrichtlinienobjekt "Test Deploy Bug RJ {72884E05-BA68-49A6-B213-67A251964DC9}" wurde aufgrund eines Fehlers nicht angewendet. Fehlercode: "0x80070005 Zugriff verweigert" Dieser Fehler wurde unterdrückt..
Benutzer: SYSTEM
Wegen der dummerweise zahlreichen ABWEGIGEN Spekulationen zum "SYSTEM"-Zugriff auf eine Freigabe empfehle ich aufmerksamstes Lesen der englischen MSDN-Seite https://msdn.microsoft.com/en-us/library/ms684190.aspx
Die zusätzliche Lektüre von https://msdn.microsoft.com/en-us/library/ms684188.aspx sowie https://msdn.microsoft.com/en-us/library/ms684272.aspx schadet auch nicht.
Hallo ,
Gibts von dem Markus Kontakdaten ?
Hätte einige Fragen zum Skript. Würde den gerne bei uns anwenden aber ich bekomme den Skript nicht dazu mir ein Output File zu erzeugen . Hab schon alles durchprobiert.
Danke Michael
Wenn Du mir hier bestätigst, dass ich deine E-Mail-Adresse weitergeben darf (DSGVO), reichte ich diese an Markus K. weiter. Er wird sich dann sicherlich hier oder persönlich melden.
Hallo Michael,
einfach im Texteditor eine leere Datei erzeugen und dann den komplettenpfad zu dieser Datei mit Hochkommas einfügen.
Wenn Datei weiter leer bleibt – Glück gehabt, dann habt ihr keine GPO mit einer File-Copy Funktion.
Viele Grüße
Wolfgang
Quelle mit "*.*", Sicherheitskontext des Benutzers angehakt:
Entfernung des "\" am Schluß des Ziels in der GPP hat geholfen (wie von MS empfohlen). Server Win 2012, Client Win 8.1
Weiß man denn, ob das Problem mit den heutigen Updates behoben wird? Auf der Website von MS steht nur "…will provide an Update in a upcoming release":-(
Warte es bitte ab – wenn mir was auffält, werde ich es die Nacht oder Mittwoch hier im Blog thematisieren.
Also auch bei uns scheint sich das Problem jetzt erledigt zu haben.
Kurzes Update:
bei uns musste ich jetzt den Haken bei "im Benutzerkontext ausführen" setzen, damit das Kopieren von einer Datei ins Appdata-Verzeichnis des Users abgearbeitet wird. Vor den Oktober Update musste der Haken raus (wie im Workaround beschrieben), jetzt genau umgekehrt.
Leider behebt sich das Problem auch mit dem neusten Update "KB5018410" unter Windows 10 20H2 bei mir nicht.
Desktop Verknüpfungen, welche im User Kontext laufen, da der Link auf Applikationsserver verweist, werden nicht erstellt.
Dazu habe ich die Aktion auf "Aktualisieren" eingestellt und es werden keine Wildcards verwendet.
Unter dem MS Link unter "Known Issues" ist dabei immer noch der GPO Eintrag vorhanden:
https://support.microsoft.com/en-au/topic/october-11-2022-kb5018410-os-builds-19042-2130-19043-2130-and-19044-2130-6390f057-28ca-43d3-92ce-f4b79a8378fd
Bei 10 21H2 und 11 22H2 brachte bei meinen Testmaschinen das neueste Kumulative die Verknüpfungen zurück auf den Desktop die seit September fehlten. Starte einen größeren Rollout und beobachte die Sache weiter, aber so wie es aussieht fixt der Patch das Problem für uns
Mit den gestrigen Updates sind alle GPO-Dateienprobleme auch bei uns gelöst, juchu!
Hallo.
Es heisst ja, dass Microsoft dieses Problem noch nicht gelöst hat und dass es immer noch unter "Known Issues" steht.. Auch in aktuellen Updates.
Was stimmt denn jetzt?
Hallo,
das Problem scheint behoben, zumindest sagen das die Rückmeldungen in meinem Umfeld – und auch ich stelle gerade fest das meine Office 2016-Installation die hier betroffenen Vorlagen wieder lädt.
Kann das noch jemand bestätigen?
Hallo,
bei mir hat es am 3.2.2023 wieder funktioniert, aber jetzt am 22.02.2023 funktioniert es nicht mehr.