Windows 10 Update KB5017308 verursacht Probleme beim Erstellen/Kopieren von Dateien per GPO

Windows[English]Kleine September 2022 Patchday-Nachlese. Wie es ausschaut, kommt es bei dem am 13. September 2022 für Windows 10 veröffentlichten kumulativen (Sicherheits-) Update KB5017308 zu einem Kollateralschaden. Es liegen mir verschiedene Berichte aus der Leserschaft vor, dass im Anschluss an die Update-Installation das Anlegen oder Kopieren von Dateien per GPO oder das Anlegen von GPO-Einstellungsdateien nicht mehr funktioniert.


Anzeige

Windows 10 Update KB5017308

Das kumulative Update KB5017308 steht für Windows 10 Enterprise/Education 20H2 sowie für Windows 10 Version 21H1-21H2 zur Verfügung, und soll diverse Sachen fixen. Ich hatte im Blog-Beitrag Patchday: Windows 10-Updates (13. September 2022) darüber informiert und auch auf eventuelle Probleme mit der Sommerzeitumstellung in Chile hingewiesen (siehe Windows 10/ 11: Mögliche Sommerzeit-Umstellungsprobleme [in Chile und weltweit]). Microsoft hält sich mit den Details, was das Update korrigiert, zurück. Die Liste der Verbesserungen lassen sich im Blog-Beitrag Windows 10 Preview Update KB5016688 (26.8.2022) einsehen.

Berichte über GPO-Probleme

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. Inzwischen liegen mir weitere Meldungen vor.

Verknüpfungen auf Desktop per GPO fehlerhaft

Blog-Leser Aike hat sich in diesem Kommentar gemeldet und beschreibt dort folgendes Fehlverhalten unter Windows 10 21H2 nun mit aktuellem Build 19044.2006, d.h. nach Installation von Update KB5017308.

Nach September Updates funktioniert das Erstellen zweier Verknüpfungen auf dem Desktop der User via GPO innerhalb der Domäne nicht mehr zuverlässig.

Nach einem GPUPDATE /force am Client verschwindet eine von Beiden durch die GPO erstellte Verknüpfung . Nach einem erneuten manuellem Aufruf von GPUPDATE /force ist sie wieder vorhanden und verschwindet dann wieder selbständig (nach dem default GPUPDATE-Intervall). Dieses Spiel kann man als Endlosschleife weiterspielen.

In den Richtlinie eingestellt: Benutzerkonfiguration/Einstellungen/Windows-Einstellungen/Verknüpfungen
"Verknüpfung zu einer Webanwendung A" und "Verknüpfung zu einer Webanwendung B" – Aktion "Ersetzen". Innerhalb der Objekte jeweils Zieltyp: URL Speicherort: Desktop – sonst keine Parameter. Gemeinsame Optionen bei beiden Objekten: Im Sicherheitskontext des angemeldeten Benutzers ausführen (Benutzerrichtlinienoption) & Element entfernen, wenn es nichtmehr angewendet wird.

Es hat jahrelang wunderbar funktioniert – Nun dieses Verhalten.

Auch Blog-Leser Markus bestätigt, dass Computer- und Benutzerrichtlinien (GPOs) keine Dateien mehr kopieren. Betroffen sind Windows 10 Clients sowie Server 2022/2019:

wir haben das Problem auch. Computerpolicies sowie Userpolicies (Gpo) kopieren keine Files mehr (Win10 Client sowie Server 2022/2019) – der Workaround von Sven hat bei uns leider nicht geholfen.

Meldung im Anwendungslog:
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..

Update deinstalliert – alles klappt wieder

Weitere Meldung per Mail/Facebook

Blog-Leser Sebastian G. hat mich heute per Mail kontaktiert und wies mich auf folgenden reddit.com-Thread hin, in dem Probleme mit dem Kopieren von Dateien mit dem Update KB501730 behandelt werden. Dort heißt es in einem Post:

Our patch manager accidentally pushed the update to live production instantly, yay!

Issues encountered Win10 21H2 KB5017308:

gpo file copy seems to not work properly (shortcuts lose their icon and batch file is blank)

can no longer deploy programs from lansweeper

Auf Facebook hat mich Blog-Leser Simon A. ebenfalls das Problem angesprochen, welches bei Geek at Works angerissen wird:

Windows Update KB5017308 breaks GPO preferences file creation

Anyone observing the same issue? All files created with GPO preferences in replace mode are having 0 kb. Doesn't matter if these are newly created links or files copied to a machine with GPO preferences.

Auch hier wird berichtet, dass die Deinstallation des Updates das Problem löst. Der Kurzbeitrag verweist auf diesen Microsoft Answers-Forenthread, in dem ebenfalls angegeben wird, dass Verknüpfungsdateien nicht per GPO angelegt werden können.


Anzeige

Ein möglicher Workaround

Verschiedene Benutzer berichten, dass es wieder funktioniert, wenn das Kopieren der Dateien mittels GPO nicht im User-Kontext erfolge. 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.

Auch auf Microsoft Answers findet sich in diesem Forenbeitrag der folgende Hinweis von Adam Postgate:

Yes we had this today too – try un-checking "run in user security context" on any gpo

I assumed it was needed for %userprofile% variable to work, but it isn't

Einen Versuch ist es auf jeden Fall wert – obwohl es Nutzermeldungen gibt, die berichten, dass es nicht funktioniert habe und die Probleme weiter bestehen. Danke an alle Nutzer für die Rückmeldungen – ich haben den englischsprachigen Beitrag über den Bug über MS Answers und Twitter an Microsoft gemeldet. Zudem gibt es Administratoren, die auf meine Bitte ein Tickt beim Support eröffnet haben.

Das Thema wird im Blog-Beitrag Nachtrag zum Windows GPO-Problem (Kopieren/Verschieben), verusacht durch Sept. 2022 Update fortgesetzt. Da habe ich ein Leser-Script zum Identifizieren von Problemen mit veröffentlicht. Zudem hat Microsoft den Bug bestätigt.

Ähnliche Artikel:
Microsoft Office Updates mit Fix für Excel-Bug (6. September 2022)
Microsoft Security Update Summary (13. September 2022)
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)


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Problemlösung, Update, Windows 10 abgelegt und mit , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

59 Antworten zu Windows 10 Update KB5017308 verursacht Probleme beim Erstellen/Kopieren von Dateien per GPO

  1. Liam sagt:

    Bei uns hat das Update Performance Probleme verursacht (Explorer.exe auf +- 30% CPU) und auch einen Blackscreen nach Anmeldung am Userprofil.. :)

  2. Ingo sagt:

    Problem besteht leider nicht nur bei Windows 10, sondern auch Windows 11. Sobald die GPO nicht mehr im User Kontext läuft, klappt das kopieren wieder….

  3. H. Schmid sagt:

    Das hat doch recht krasse Auswirkungen – da kommt man auch nicht gleich drauf an was es hakt. Bei uns ließ sich heute das SAP-Logon nicht mehr starten, weil die SAPUILandscape.xml von einem zentralen Share mit 0 KB in das User-Profil geschrieben wird. Ob der Workaround bei uns funktioniert muss ich noch testen.

  4. Michael sagt:

    Ich nehme Mal an, dass der GPO Bug von dem CVE-2022-37955 Security Fix kommt.

  5. Ich sagt:

    @Günter Born
    >Kleine September 2022 Patchday-Nachlese. Wie es ausschaut, kommt das am 13. >September 2022 für Windows 10 veröffentlichte kumulative (Sicherheits-) Update >KB5017308 einen Kollateralschaden.
    Irgendwie fehlt mir noch was bei dem Satz, oder täuscht mich das? ;)

    BTW: Beim Kopieren von Dateien oder Verbinden von Laufwerken war es schon immer eine sehr schlechte Idee mit Ersetzen oder Erstellen zu arbeiten. Aktualisieren reicht völlig aus.

    Und ein /force beim gpupdate ist flüssiger als Wasser. Details gibt es bei Mark: https://www.gruppenrichtlinien.de/artikel/gpupdate-vs-gpupdate-force

    • Georg Burth sagt:

      genau das mit dem suprafluid steht dort eben nicht. Oder besser: es ist nicht immer suprafluid, nur in sehr vielen Fällen – und in den anderen ist es meist "nur" unnötiger Aufwand für den Rechner.
      Rebootaufforderungen bekommt man nur damit, bei im AD verschobenen Computern ist es nötig, …

      Wie dort auch steht:
      Fazit:
      gpupdate /force macht nichts kaputt, es dauert nur länger und ist in 99% der Fälle unnötig.

      …und im restlichen Prozent muss man dran denken, es doch zu setzen. Dann doch lieber gleich den Rechner unnötig arbeiten lassen :-)

  6. der ITler sagt:

    Deswegen gilt:
    IMMER DIE UPDATES ZUERST AUF TESTSYSTEMEN TESTEN; BEVOR MAN SIE PRODUKTIV ANWENDET.

    Gruß
    der ITler

  7. Markus sagt:

    Es betrifft auch das KB5017305 für Server 2016.
    Kann dabei persönlich nur über RDS berichten.

    Wir kopieren Dateien aus DFS- oder normalen Dateifreigaben (auch von OES-Servern) ins Userprofil. Auch diese werden mit oKB erstellt.
    Ebenfalls ist das "Ausführen im User-Kontext" der letzte Baustein des Problems.

    Desinstallation KB5017305 behebt das Problem.

  8. Baumi sagt:

    Wir sind auch betroffen.
    Mehrere inis werden zwar kopiert, aber die User haben danach nur noch Leserechte auf diese Dateien, was die Anwendungen (z.B. Firefox) nicht so gerne sehen.
    Anscheinend wird die Rechtevererbung deaktiviert und irgendwelche Standardrechte angewendet, die uns aber in diesem Fall nicht genügen.
    Ob im Userkontext oder nicht ändert bei uns nichts im Verhalten…

    • Baumi sagt:

      Alle Varianten durchprobiert:
      Update, Create, Replace mit und ohne Userkontext – immer das gleiche Ergebnis: Nur Leserechte für den User und Rechtevererbung deaktiviert

  9. Markus K sagt:

    Aha! Daran habe ich noch gar nicht gedacht! Spitzenklasse! Der Fehler ist den man bekommt ist jedenfalls sowas von aussagekräftig:
    0x800703ee The volume for a file has been externally altered so that the opened file is no longer valid.

    Frei nach dem Motto: Na da hat wer anderer was verbrochen, aber nein halt mal! MS wars :)
    von Windows 10 bis Windows 11 alles hin auf den Rechnern, was im User kontext kopiert!
    Kanns leider nur bestätigen!

  10. ToWa sagt:

    Hallo zusammen,
    ist das Problem mit dem KB5017380 von heute noch existent?
    Grüße

  11. Nicolas sagt:

    Das Problem taucht genauso beim Kopieren nach %public%\desktop auf, und das läuft eh im Computerpart der GPO. – naja, deaktivieren sollte erstmal für Ruhe sorgen….

  12. Rene sagt:

    You can use the solution "Go to GPO and uncheck – Run in user security context." only, if the file/shortcut/folder is changed locally on the system (then the SYSTEM-Account has access rights to do it).
    When the file/shortcut/folder is changed e.g. on the fileserver in the homeshare (beacuse you uses folder redirection), then the SYSTEM-account usually doesn't have access rigths.
    Therefore it is necessary to have the check in "Run in user security context". In these cases you have problems after installing the september patches. You can only try to deploy the files/shortcuts/folders e.g. via powershell-logon-script or you give Domaincomputers rights on all homeshares (not a good idea in my opinion).

    • JohnRipper sagt:

      oder den Computeraccount temporär in die Sicherheitsgruppe stecken.

      Nasty, i know. Wenn die Rechner aber einigermaßen abgesichert sind (LAPS etc.) dann sollte das bei Fileshares keine zu grossen Probleme machen.

  13. Michael sagt:

    Hallo,

    die Option "Im Sicherheitskontext des angemeldeten Benutzers ausführen" zu deaktivieren hat bei mir geholfen.

    Beste Grüße
    Michael

  14. Rene´ sagt:

    Hallo zusammen,

    bei uns funktioniert das Kopieren auf allen Windows 10 20H2 und 21H2 Clients inkl. KB5017308. Einmal ist es eine Computer GPO, die die Hosts Datei ersetzt und einmal eine im User Kontext, die die Java Exeption Sites setzt.

    Nur der 2k12R2 Terminal Server bringt bei der Java GPO die oben genannte Meldung im Anwendungslog hoch.

    VG
    Rene´

    • Martin sagt:

      Diese positive Info wundert mich am meisten, muss ich zugeben.

      Man liest über die Probleme in diesem Zusammenhang und dann kommt "bei uns klappt das aber alles" :-)

      Irgendeine Idee, was in Deinem Setting anders sein könnte? Ich traue mich noch nicht ran, dass Update zu verteilen (habe aktuell leider zu viele Clients im 1. Ring).

  15. Holger sagt:

    Kann das Update auch Probleme beim Speichern von Dateien/Verknüpfungen auf dem eigenen Desktop verursachen?

    Wir haben hier auf Windows 10 und 11 Rechnern das Problem, dass Dateien auf dem persönliche Desktop nur noch mit Adminrechten abgelegt werden dürfen.

  16. Clemens sagt:

    @Günter Born
    Hallo,
    wir haben bei uns das gleiche Phänomen auf Windows Server 2019 Terminalservern.
    Ich habe Gruppenrichtlinien gebaut, die den Anwendern Verknüpfungen im Startmenü erstellt, sofern diese die Berechtigungen für die jeweilige Applikation haben.
    Das funktionierte bis letzte Woche recht gut.
    Bei der Analyse ist mir folgendes aufgefallen:
    [CMD]> DIR "%ProgramData%\Microsoft\Windows\*.lnk" /B /S
    liefert eine Liste alle Verknüpfungen.
    [CMD]> DIR "%ProgramData%\Microsoft\Windows\Start Menu\*.lnk" /B /S
    führt zu Fehlermeldung "Das System kann den angegebenen Pfad nicht finden."
    Offenbar mögen die Redmunder keine Leerzeichen mehr.
    Nun gut, dann halt anders…
    [CMD]> DIR "%ProgramData%\Microsoft\Windows" /A:D /X
    liefert eine Liste aller unterverzeichnisse incl. dem 8.3 Namen. (Für die jübgeren leser, unter DOS waren Dateinamen auf 8 Zeichen und 3 Zeichen für die Extension beschränkt.)
    Mich hat dabei folgender Eintrag interessiert:
    STARTM~1 Start Menu
    Ein kurzer Test mit:
    DIR "%ProgramData%\Microsoft\Windows\STARTM~1\Programs\*.lnk" /B /S
    Brachte dann den Durchbruch.

    Ergo habe ich Pfadangaben mit Leerzeichen durch die entsprechenden 8.3 Ordernamen ersetzt.
    Danke Microsoft, für diese tolle Excursion in meine Jugend. Ich hätte gerne darauf verzichtet…

  17. Martin sagt:

    Evtl. blöder Kommentar: ich frage mich gerade, wie ich mitbekomme, dass Microsoft bei diesem Problem nachgebessert (am besten sogar Problem behoben) hat. Microsoft hat das Problem noch gar nicht bestätigt, oder?

    Aktuell habe ich das Update im WSUS noch nicht freigegeben. Unser Ring 1 ist momentan leider ein wenig zu groß und ich will nicht für diesen Test noch einen weiteren Ring dazunehmen.

  18. Rene´ sagt:

    Hallo zusammen,

    heute Morgen sehe ich erneut neue Updates im WSUS:
    KB5017380 für Windows 10 21H2
    KB5017379 für Server 2019 (dieses soll wohl TLS 1.0 und 1.1 im Browser deaktivieren).

    2 Preview Updates für .Net stehen auch noch da…

    Habt ihr das auch? Alle Updates wurden gestern am 20.09. released…

    @ Günter: Das sind wohl nun keine Insider Channel Updates mehr, oder spielt der WSUS mal wieder verrückt? thx.

  19. Kay B. sagt:

    Hallo,

    haben heute ebenfalls
    KB5017380 für Windows 10 21H2 und
    KB5017321 für Windows 11 22H2 im WSUS gefunden.

    Das KB5017380 wurde mir vorige Woche im WSUS nicht angeboten.
    Ich nehme daher an das diese eine überarbeitete Version ist im Vergleich
    zu der vom 13.09.22 ist, da auch auf MS-Supportseite als
    Veröffentlichungsdatum der 20.09.22 steht.

    Kann das jemand bestätigen ?

  20. M. Winkler sagt:

    Hallo,

    die KB5017380 hat das Problem auch nicht behoben. Nach erneuter Synchronisation des WSUS-Servers ist das Update zurückgenommen worden.

    VG

  21. Rene´ sagt:

    bei mir sind die Win10/Server 2019 Updates nach dem neuen WU Sync auch wieder weg… Nur die .Net Preview Updates sind noch vorhanden…aber Previews installieren wir eh nicht, die werden direkt immer abgelehnt…

  22. Marcel sagt:

    Eine Frechheit, was MS da jeden Monat abliefert! Wir verteilen den Logon für unser ERP über GPO und wir haben noch in der IT letzten Freitag gescherzt sicher geht wieder was nicht nach dem Update…. Wir hatten einige Geräte in unserer Testgruppe da konnte man das Update dann nicht mal mehr deinstallieren! Die Deinstallation wird bestätigt, das Update wird dann aber immer noch angezeigt und beim erneuten Versuch es zu Deinstallieren kommt dann ein Fehler. Bei Win 11 war es dann sogar so, dass bei den Geräten nach der (fehlerhaften) Deinstallation die Taskleiste verschwunden war. Keine Chance irgend etwas zu tun, diese Laptops mussten zurück gesetzt werden!

  23. Gero sagt:

    Hallo zusammen,

    den GPO Bug von KB5017308 kann ich leider auch bestätigen. Wir verteilen diverse Konfigurationsdateien per GPO. Auf 2019er Terminalservern führt KB5017308 somit dazu dass die Anwendungen dann nicht mehr starten.

    Das MS dieses Update nicht zurückzieht ist mir schleierhaft bzw. eine Frechheit.
    War/ist die Qualitätssicherung Mal wieder im im Urlaub bei MS?

  24. Philipp sagt:

    Ziemlich uneinheitlich das Bild bei uns.

    Bei Verknüpfungen hat das Entfernen von "im Benutzerkontext" ausführen geholfen, bei per GPP kopierten Dateien nur teilweise.
    Ergo hat nur das Deinstallieren des KB geholfen.

    Frage mich aber auch, wie man mitbekommen soll, wenn es gefixt wurde. Es taucht ja unter den bekannten Fehlern gar nicht auf.

  25. DerMitDemWolfTanzt sagt:

    Die Workarounds sind super ABER hat Jemand schon von MS gehört / gelesen, dass sie das fixen wollen?

    Finde dazu keine offizielle Aussage von MS, dass sie dran sind, das zu beheben…

  26. Martin sagt:

    Moin. Wir haben das gleiche Phänomen. Die Nutzer erhalten per GPO Richtlinie Verknüpfungen (Icons) für einige Fachanwendungen. Jetzt erscheint nur noch ein weißer Link ohne Verknüpfungsinhalt. Bei uns hat die Deinstallation des Updates KB5017315 geholfen.

  27. riedenthied sagt:

    Doch, Microsoft hat das Problem mittlerweile bestätigt.

    h**ps://docs.microsoft.com/en-us/windows/release-health/status-windows-10-1809-and-windows-server-2019

  28. Anonymous sagt:

    Für Server 2016 hat Microsoft folgenden "Known Issue Rollback" rausgegeben:
    https://download.microsoft.com/download/c/9/0/c909c13a-e973-4d6c-bb38-b1cde2311ae1/Windows%2010%201909%20KB5017313%20220922_20351%20Known%20Issue%20Rollback.msi
    Die MSI-Datei installiert nur eine ADMX/ADML, mit nur einer Richtlinie, hinter der dieser Registrywert steckt:

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides]
    "615128204"=dword:00000000

    Nach einem Neustart der Maschine soll das alte Verhalten wiederhergestellt sein. Wir müssen das noch verifizieren.

    Lt. Microsoft soll es "voraussichtlich Ende Oktober / Anfang November" einen echten Fix geben.

    • Anonymous sagt:

      So, das o.g. hat unter 2016 nicht funktioniert, da der Microsoft-Support den Link für die falsche Windowsversion verschickt hat. Der KIR für Server 2016 ist dieser hier:
      https://download.microsoft.com/download/5/2/8/528db221-28c7-4258-8d88-690c45a09a7a/Windows%2010%201607%20and%20Windows%20Server%202016%20KB5017305%20220922_203513%20Known%20Issue%20Rollback.msi
      [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides]
      "2058099853"=dword:00000000
      Und der funktioniert auch, sogar ohne Reboot ab dem nächsten gpupdate.

      • Anonymous sagt:

        Gibt es den Override Wert auch für WIN10 20H2 für den KB5017308? Für das OS haben wir leider noch keine Lösung.

        • Anonymous sagt:

          Wenn du keinen Support Case bei Microsoft aufmachen kannst, wäre eine Möglichkeit um den KIR für dein OS rauszufinden:
          1. Procmon starten und auf "Path begins with HKLM\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides" filtern
          2. gpupdate auslösen
          3. Im Procmon-Trace müsste ein Zugriff von svchost.exe auf einen Wert mit numerischem Namen auftauchen
          4. Diesen Wert mit Wert 0 anlegen und testen, ob Preferences wieder funktionieren

      • Manuel sagt:

        Wie funktioniert das ganze?

        1. Wo installiere ich die MSI? Auf dem Server? Ist ja eigentlich nur ein ADMX-Template für den Registry Key oder?
        2. Den Key/die Einstellung muss ich wohl für alle Clients inkl. Server ausrollen oder?
        3. Gibts auch Quell-Links zu dem Beitrag wo diese Downloads enthalten sind?

        LG Manuel

        • Anonymous sagt:

          zu 1.:
          Du musst den angegebenen Registrywert setzen. Entweder per Preference oder ADMX. Die MSI-Datei istalliert das ADMX. Ich verwende einen LocalStore für die ADMX und habe es daher auf der Maschine installiert, auf der ich die GPOs bearbeite. Bei CentralStore muss es dort rein. Du kannst auch einfach das MSI mit 7z entpacken und die beiden Dateien manuell an der richtigen Stelle ablegen oder du setzt den Registrywert einfach per GPP.

          zu 2.:
          Er muss überall gesetzt sein, wo Preferences von dem Bug betroffen sind.

          zu 3.:
          Meines Wissens gibt der Microsoft-Support den Link nur raus, wenn man einen Case aufmacht. Da die URL auf microsoft.com zeigt, das MSI signiert ist und man es eigentlich auch nicht ausführen muss (siehe Kommentar eins drüber), sollte es kein Vertrauensproblem geben. Außer in die Kompetenz von Microsoft ganz allgemein natürlich.

          • Manuel sagt:

            Hi,

            danke für die Antwort.

            Zu Punkt 2: Das heißt dort wo Gruppenrichtlinien nicht korrekt angewandt werden, dort muss ich den KIR dann zusätzlich per GPO ausrollen?

            Diese KIR-Nummer ist also unterschiedlich für unterschiedliche Windows Server-Versionen und Windows-Versionen und kann mittels?

            Du hast ja jetzt ausschließlich KIR für Servers bekannt gegeben und nicht etwa für Windows 10 Builds.

            Kann ich also mit deiner Anleitung:
            (Procmon starten und auf "Path begins with HKLM\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides" filtern)

            Ohne dass ich irgendwelche Sachen installiert habe herausfinden, welche KIR ich da für meine Clients mit Windows 10 Build verwenden muss?

            Sorry, fürs lästige fragen, ich finde es einen Wahnsinn, was Microsoft in letzter Zeit für Probleme ausrollt, die Meldungen reißen echt nicht ab.

          • Anonymous sagt:

            Hi,
            ja, da wo du die beschriebenen Probleme mit GPP Shortcuts oder Files hast muss das gesetzt werden bis ein echter Fix erscheint.

            Der KIR scheint sehr spezifisch für jeden Windowsbuild zu sein. Microsoft rückt leider immer nur das raus, was man gerade nachweislich benötigt und keine Liste für alle Versionen (und auch das erst mit großer Verzögerung und im zweiten Anlauf richtig). Die Serverversion und die dazu identische Clientversion dürfte jeweils den selben Wert verwenden, also z.B. 1809 == Server 2019.

            Deine Vermutung zu Procmon ist korrekt. Wenn dabei mehrere Werte auftauchen, musst du durch Trial&Error rausfinden, welcher der passende für dieses Problem ist. Reboot ist wie gesagt nicht nötig, daher sollte das schnell gehen (Setzen, gpupdate, Eventlog beobachten).

            Wenn du meine persönliche Meinung wissen willst: es ist eine bodenlose Unverschämtheit was Microsoft in letzter Zeit abliefert. In diesem Fall:
            – man braucht Monate um ein Sicherheitsproblem zu fixen
            – dann haut man einen Patch raus, der Probleme verursacht, die bei ordentlichem Testen aufgefallen wären
            – weil alles in einem Paket steckt, kann man den problematischen Patch nicht isoliert deinstallieren
            – eine Woche lang leugnet man das Problem, obwohl überall darüber berichtet wird
            – erst nach 2 Wochen steht ein known issue im KB
            – den offenbar vorhandenen KIR verschweigt man in den angegebenen Workarounds und behandelt ihn als Geheimnis
            – den eigenen Support lagert man an eine kompetenzarme Drittfirma aus, lässt die Kunden aber weiter Premiumpreise bezahlen
            – einen Fix gibt es vielleicht eventuell in ein oder zwei Monaten

    • Anonymous sagt:

      Für Server 2019 ist der KIR:
      https://download.microsoft.com/download/9/f/3/9f3bcde5-41dd-47fe-a618-c1ef5e39de36/Windows%2010%201809%20and%20Windows%20Server%202019%20KB5017315%20220922_20353%20Known%20Issue%20Rollback.msi
      [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides]
      "246029452"=dword:00000000
      (Wirkung nicht von mir verifiziert.)

      Für den ebenfalls betroffenen Server 2012 R2 gibt es keine KIR, hier bleibt außer den nicht überall möglichen Workarounds nur das Warten auf einen Fix. Einen Zeitpunkt dafür konnte man uns bisher nicht genauer sagen als "Oktober/November".

  29. Anonymous sagt:

    Gibt es den Override Wert auch für WIN10 20H2 für den KB5017308? Für das OS haben wir leider noch keine Lösung.

Schreibe einen Kommentar zu Rene´ 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.