Nachtrag zum Windows GPO-Problem (Kopieren/Verschieben), verursacht durch Sept. 2022 Update, Bestätigung durch Microsoft

Windows[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.

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.


Anzeige

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:

Windows 10 21H2 GPO error 0x800703ee
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


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Störung, Update, Windows abgelegt und mit , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

22 Antworten zu Nachtrag zum Windows GPO-Problem (Kopieren/Verschieben), verursacht durch Sept. 2022 Update, Bestätigung durch Microsoft

  1. Anonymous sagt:

    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.

  2. 1ST1 sagt:

    Danke für den Zweizeiler!

    • Michael sagt:

      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

  3. Carsten sagt:

    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.

  4. sumpfnagel sagt:

    Kleiner Hinweis: SYSTEM Zugriff auf einen Share heißt in der Regel, dass das Computerkonto des Clients Zugriff benötigt ;-)

  5. riedenthied sagt:

    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.

  6. Rene-Comedia sagt:

    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

  7. Stefan Kanthak sagt:

    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.

  8. Michael sagt:

    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

  9. Wolfgang S. sagt:

    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

  10. David R. sagt:

    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

  11. Philipp sagt:

    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":-(

  12. Nicola sagt:

    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

  13. Christian sagt:

    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

  14. Baumi sagt:

    Mit den gestrigen Updates sind alle GPO-Dateienprobleme auch bei uns gelöst, juchu!

  15. Johnyy sagt:

    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?

  16. Thomas Krenzel sagt:

    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?

  17. Hans D. sagt:

    Hallo,

    bei mir hat es am 3.2.2023 wieder funktioniert, aber jetzt am 22.02.2023 funktioniert es nicht mehr.

Schreibe einen Kommentar zu David R. Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.