42
PrintNightmare CVE-2021-1675
Nabend zusammen.
Microsoft lässt momentan nichts anbrennen, was Sicherheitslücken anbelangt:
https://www.borncity.com/blog/2021/07/01/poc-fr-windows-print-spooler-sc ...
Auch interessant, dass die Lücke wohl aus Versehen bekannt gemacht wurde und aktuell nur ein Workaround Abhilfe schafft.
Freut sicher alle, deren DC leider auch Print Server ist
Gruß
Marc
Microsoft lässt momentan nichts anbrennen, was Sicherheitslücken anbelangt:
https://www.borncity.com/blog/2021/07/01/poc-fr-windows-print-spooler-sc ...
Auch interessant, dass die Lücke wohl aus Versehen bekannt gemacht wurde und aktuell nur ein Workaround Abhilfe schafft.
Freut sicher alle, deren DC leider auch Print Server ist
Gruß
Marc
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 877109086
Url: https://administrator.de/contentid/877109086
Ausgedruckt am: 22.11.2024 um 15:11 Uhr
42 Kommentare
Neuester Kommentar
joar, mal sehen was unsere Niederlassung morgen so reporten, die GPO zu deaktvieren des SpoolerService sind fast alle durch :c
Wäre eine irrwitzige Geschichte, wenn so das papierlose Büro erzwungen würde 
Gruß
Marc
Gruß
Marc
Das wird ja für KMUs lustig die nur einen Server haben der sowohl AD-, DNS-, DHCP-, File- und Print-Server ist.
Da bleibt dann nur hoffen oder nicht drucken sowie warten auf einen Patch.
Da bleibt dann nur hoffen oder nicht drucken sowie warten auf einen Patch.
Moin,
also wenn ich die Empfehlungen im INet querlese und den Workaround konsequent anwende, gehen halt keine Zahlungsaufforderungen, Rechnungen etc. per Papier auf die Reise??!!
Gruß
also wenn ich die Empfehlungen im INet querlese und den Workaround konsequent anwende, gehen halt keine Zahlungsaufforderungen, Rechnungen etc. per Papier auf die Reise??!!
Gruß
Zitat von @VGem-e:
Moin,
also wenn ich die Empfehlungen im INet querlese und den Workaround konsequent anwende, gehen halt keine Zahlungsaufforderungen, Rechnungen etc. per Papier auf die Reise??!!
Moin,
also wenn ich die Empfehlungen im INet querlese und den Workaround konsequent anwende, gehen halt keine Zahlungsaufforderungen, Rechnungen etc. per Papier auf die Reise??!!
Das ist wohl jetzt die Realität bis El Patchó kommt und die Misere (erstmal) behebt.
Gruß
Marc
Freut sicher alle, deren DC leider auch Print Server ist
Der DC muss nicht mal PrintServer sein. Es reicht schon, wenn der Spooler läuft (und das ist default so).
Ich habe gerade mal die nicht benötigten Spooler deaktiviert.
Gruß
Looser
Zitat von @Looser27:
Der DC muss nicht mal PrintServer sein. Es reicht schon, wenn der Spooler läuft (und das ist default so).
Ich habe gerade mal die nicht benötigten Spooler deaktiviert.
Freut sicher alle, deren DC leider auch Print Server ist
Der DC muss nicht mal PrintServer sein. Es reicht schon, wenn der Spooler läuft (und das ist default so).
Ich habe gerade mal die nicht benötigten Spooler deaktiviert.
Damit sind beispielsweise all die Exchange Server, welche aus dem Internet her erreichbar sind, erneut zu einem (lohnenswertem) Angriffsziel geworden.
Gruß
Marc
Ich verstehe einfach nicht, warum Microsoft hier nicht die Installationsroutine für Server ändert.
Analog zu Linux erhält man nur ein Minimalsystem in das man dann die gewünschten Pakete nachinstallieren muss.
Damit wären über 90% mit den MS-Kisten aus der Welt und müßten nicht ständig nachgebessert werden.
Analog zu Linux erhält man nur ein Minimalsystem in das man dann die gewünschten Pakete nachinstallieren muss.
Damit wären über 90% mit den MS-Kisten aus der Welt und müßten nicht ständig nachgebessert werden.
Zitat von @Looser27:
Ich verstehe einfach nicht, warum Microsoft hier nicht die Installationsroutine für Server ändert.
Analog zu Linux erhält man nur ein Minimalsystem in das man dann die gewünschten Pakete nachinstallieren muss.
Damit wären über 90% mit den MS-Kisten aus der Welt und müßten nicht ständig nachgebessert werden.
Ich verstehe einfach nicht, warum Microsoft hier nicht die Installationsroutine für Server ändert.
Analog zu Linux erhält man nur ein Minimalsystem in das man dann die gewünschten Pakete nachinstallieren muss.
Damit wären über 90% mit den MS-Kisten aus der Welt und müßten nicht ständig nachgebessert werden.
Hörst du auch die unzähligen Hände auf die Stirn von MS Entwicklern klatschen?
"Ja Mensch, so was geht? 😮 Wieso sind wir da nicht früher drauf gekommen 🤦♂️."
Gruß
Marc
Zitat von @Looser27:
Ich verstehe einfach nicht, warum Microsoft hier nicht die Installationsroutine für Server ändert.
Analog zu Linux erhält man nur ein Minimalsystem in das man dann die gewünschten Pakete nachinstallieren muss.
Damit wären über 90% mit den MS-Kisten aus der Welt und müßten nicht ständig nachgebessert werden.
Ich verstehe einfach nicht, warum Microsoft hier nicht die Installationsroutine für Server ändert.
Analog zu Linux erhält man nur ein Minimalsystem in das man dann die gewünschten Pakete nachinstallieren muss.
Damit wären über 90% mit den MS-Kisten aus der Welt und müßten nicht ständig nachgebessert werden.
Server Core gibts doch schon ewig, da ist der Print Spooler im Default auch aus.
Zitat von @StefanKittel:
Das wird ja für KMUs lustig die nur einen Server haben der sowohl AD-, DNS-, DHCP-, File- und Print-Server ist.
Da bleibt dann nur hoffen oder nicht drucken sowie warten auf einen Patch.
Das wird ja für KMUs lustig die nur einen Server haben der sowohl AD-, DNS-, DHCP-, File- und Print-Server ist.
Da bleibt dann nur hoffen oder nicht drucken sowie warten auf einen Patch.
Wer so'ne eierlegende Wollmilchsau hat macht aus Sicherheitssicht und Best Practice aber schon länger was falsch.
/Thomas
Server Core gibts doch schon ewig, da ist der Print Spooler im Default auch aus.
Das muss auch mit GUI gehen.
Wer so'ne eierlegende Wollmilchsau hat macht aus Sicherheitssicht und Best Practice aber schon länger was falsch
Nannte man früher SBS.
Warum? Die Nutzer von AD, DHCP, File und Print brauchen keine GUI auf dem Server. Und der Admin braucht sie dank RSAT und Powershell auch nicht.
Nannte man früher SBS.
Na da ist die letzte Version vor ~10 Jahren released worden, irgendwann kann man dann ruhig mit der Zeit gehen.Warum? Die Nutzer von AD, DHCP, File und Print brauchen keine GUI auf dem Server. Und der Admin braucht sie dank RSAT und Powershell auch nicht.
Du vergisst leider die ganzen KMUs und Kleinstunternehmen, bei denen die IT vom Chef oder einem nicht gelerntern MA mitgemacht wird (oder werden muss).
Zitat von @Looser27:
Du vergisst leider die ganzen KMUs und Kleinstunternehmen, bei denen die IT vom Chef oder einem nicht gelerntern MA mitgemacht wird (oder werden muss).
Du vergisst leider die ganzen KMUs und Kleinstunternehmen, bei denen die IT vom Chef oder einem nicht gelerntern MA mitgemacht wird (oder werden muss).
Nein die vergesse ich nicht, die RSAT Tools sind ja die gleichen wie auf einem GUI Server. Und ganz ehrlich, ich repariere mein Auto ja auch nicht selbst nur weil ich Kleinunternehmer bin, wenn ich davon keine Ahnung habe.
Und ganz ehrlich, ich repariere mein Auto ja auch nicht selbst nur weil ich Kleinunternehmer bin, wenn ich davon keine Ahnung habe.
Und wenn kein Geld für den Dienstleister da ist, machen sie es doch selber....merkst Du was? Wir drehen uns im Kreis....
Zitat von @Looser27:
Und wenn kein Geld für den Dienstleister da ist, machen sie es doch selber....merkst Du was?
Dann machen sie es halt selbst, der Invest von (viel) Zeit ist ja auch ok.Und wenn kein Geld für den Dienstleister da ist, machen sie es doch selber....merkst Du was?
Wir drehen uns im Kreis....
Nur du...
Hi,
das ist doch ein anderes Thema.
Hier geht es doch um die Sicherheitslücke.
Diese kann übrigens vorübergehend geschlossen werden, falls man den Print Server unbedingt benötigt:
Fix for PrintNightmare CVE-2021-34527 exploit to keep your Print Servers running while a patch is not available
das ist doch ein anderes Thema.
Hier geht es doch um die Sicherheitslücke.
Diese kann übrigens vorübergehend geschlossen werden, falls man den Print Server unbedingt benötigt:
Fix for PrintNightmare CVE-2021-34527 exploit to keep your Print Servers running while a patch is not available
Hi,
ich habe diesen von SOlangsam verlinkten Workaround für Print Server heute ausprobiert. Man muss lediglich vor dem Anlegen neuer Drucker einmal die Änderung rückgängig machen. Für das Ändern von Einstellungen an bestehenden Druckern war das nicht nötig.
Jetzt suche ich noch eine Lösung für Terminal Server. Da nützte mir der o.g. Workaround nichts, weil bei jedem Anmelden eines User dessen Netzwerkdrucker verbunden werden und das ging mit dem Workaround grundsätzlich schief.
Microsoft empfiehlt ja, per GPO die eingehenden Netzwerkverbindungen zum Spooler zu deaktivieren:
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34527
Bei uns dürfen User keine Druckertreiber hinzufügen, sondern nur die, die auf dem Druckserver vorhanden bzw. im Image des Terminal Server sind.
Ich vermute, das schwächt die Printer Nightmare-Lücke auch schon ab.
Weiß da jemand mehr?
ich habe diesen von SOlangsam verlinkten Workaround für Print Server heute ausprobiert. Man muss lediglich vor dem Anlegen neuer Drucker einmal die Änderung rückgängig machen. Für das Ändern von Einstellungen an bestehenden Druckern war das nicht nötig.
Jetzt suche ich noch eine Lösung für Terminal Server. Da nützte mir der o.g. Workaround nichts, weil bei jedem Anmelden eines User dessen Netzwerkdrucker verbunden werden und das ging mit dem Workaround grundsätzlich schief.
Microsoft empfiehlt ja, per GPO die eingehenden Netzwerkverbindungen zum Spooler zu deaktivieren:
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34527
Bei uns dürfen User keine Druckertreiber hinzufügen, sondern nur die, die auf dem Druckserver vorhanden bzw. im Image des Terminal Server sind.
Ich vermute, das schwächt die Printer Nightmare-Lücke auch schon ab.
Weiß da jemand mehr?
Hi O-Marc,
ich schätze da werden wir auf einen Patch von MS warten müssen. Da sind sie in der Pflicht. Das ist lediglich ein Workaround, um lediglich das Drucken nicht gänzlich zu verbieten.
Die GPO sorgt dafür der PrintJob vom lokalen System akzeptiert und alles von remote verworfen wird.
ich schätze da werden wir auf einen Patch von MS warten müssen. Da sind sie in der Pflicht. Das ist lediglich ein Workaround, um lediglich das Drucken nicht gänzlich zu verbieten.
Die GPO sorgt dafür der PrintJob vom lokalen System akzeptiert und alles von remote verworfen wird.
Jetzt mal langsam damit auch ich hinterher komme.
Der Druckspooler soll auf dem/den Domaincontroller/n deaktiviert werden da diese Schwachstelle dort wirken kann.
Auf Core-Servern ist der Druckspooler aus (soweit auf meinen Server 2019 Core DCs schon mal gut).
Habe ich also einen separaten Printserver der die Freigaben der Drucker verwaltet bin ich auch sicher, auch wenn dieser den Druckspooler aktiv hat?
Mein 2019 Essentials daheim stellt mir auch Drucker im Haus zur Verfügung, da kann ich ihn nicht deaktivieren, außer ich
installiere die Drucker noch mal auf den Clients - irgendwie fraglicher Aufwand das Ding hängt ja nicht am Internet...?
Zudem gibt es dazu auf den Newsseiten schon wieder diverse Empfehlungen und jeder will der erste sein und mehr dazu wissen.
Einerseits wird behauptet man ist sicher wenn die Nutzer keine Druckertreiber installieren dürfen (aber was hat das mit den DCs zu tun)?
Andererseits ist dann auch von Clientverbindungen und Sperrung per GPO die Rede... (Bsp.)
Hier noch ein Verweis auf GitHub zu der CVE: klick
Also scheinbar gibt es diverse Ansätze, welchen verfolgt man nun?
P.S.: Dann freue ich mich ja schon, dass zum nächsten Patchday die Kyocera Drucker alle wieder nicht mehr funktionieren. :D :D
Der Druckspooler soll auf dem/den Domaincontroller/n deaktiviert werden da diese Schwachstelle dort wirken kann.
Auf Core-Servern ist der Druckspooler aus (soweit auf meinen Server 2019 Core DCs schon mal gut).
Habe ich also einen separaten Printserver der die Freigaben der Drucker verwaltet bin ich auch sicher, auch wenn dieser den Druckspooler aktiv hat?
Mein 2019 Essentials daheim stellt mir auch Drucker im Haus zur Verfügung, da kann ich ihn nicht deaktivieren, außer ich
installiere die Drucker noch mal auf den Clients - irgendwie fraglicher Aufwand das Ding hängt ja nicht am Internet...?
Zudem gibt es dazu auf den Newsseiten schon wieder diverse Empfehlungen und jeder will der erste sein und mehr dazu wissen.
Einerseits wird behauptet man ist sicher wenn die Nutzer keine Druckertreiber installieren dürfen (aber was hat das mit den DCs zu tun)?
Andererseits ist dann auch von Clientverbindungen und Sperrung per GPO die Rede... (Bsp.)
Hier noch ein Verweis auf GitHub zu der CVE: klick
Also scheinbar gibt es diverse Ansätze, welchen verfolgt man nun?
P.S.: Dann freue ich mich ja schon, dass zum nächsten Patchday die Kyocera Drucker alle wieder nicht mehr funktionieren. :D :D
Hi dertowa,
Kein Problem. Am besten sollte man den Printserver auf dem DC deaktivieren bzw. sichern, wenn man ihn nicht benötigt. Hintergrund ist, dass es möglich sei dass Fremde durch den Dienst auf's System gelangen und dann ebenfalls Zugriff auf den DC besitzen.
Beim Core, wie du schon richtig festgestellt hast, scheint dieser wohl standardmässig deaktiviert zu sein.
Diese Umsetzung gilt pro Computer (bzw. Server oder VM), es sei denn du machst es über die GPO deiner Domäne.
Dann brauchst du nichts unternehmen.
Da Fremde Zugriffs aufs System des Printserver zugreifen könnten, hätten sie ggfs. Zugiff auf die Domäne. Der DC kann dich bei der Verteilung der passenden GPO unterstützen (wie oben bereits geschrieben).
Es kommt darauf an, wie viele Rechner du betreust und ob du Printserver überhaupt benötigst.
Dazu kommt, ob in einer Domäne oder Workgroup.
Kein Problem. Am besten sollte man den Printserver auf dem DC deaktivieren bzw. sichern, wenn man ihn nicht benötigt. Hintergrund ist, dass es möglich sei dass Fremde durch den Dienst auf's System gelangen und dann ebenfalls Zugriff auf den DC besitzen.
Beim Core, wie du schon richtig festgestellt hast, scheint dieser wohl standardmässig deaktiviert zu sein.
Diese Umsetzung gilt pro Computer (bzw. Server oder VM), es sei denn du machst es über die GPO deiner Domäne.
Zitat von @dertowa:
Mein 2019 Essentials daheim stellt mir auch Drucker im Haus zur Verfügung, da kann ich ihn nicht deaktivieren, außer ich
installiere die Drucker noch mal auf den Clients - irgendwie fraglicher Aufwand das Ding hängt ja nicht am Internet...?
Mein 2019 Essentials daheim stellt mir auch Drucker im Haus zur Verfügung, da kann ich ihn nicht deaktivieren, außer ich
installiere die Drucker noch mal auf den Clients - irgendwie fraglicher Aufwand das Ding hängt ja nicht am Internet...?
Dann brauchst du nichts unternehmen.
Zudem gibt es dazu auf den Newsseiten schon wieder diverse Empfehlungen und jeder will der erste sein und mehr dazu wissen.
Einerseits wird behauptet man ist sicher wenn die Nutzer keine Druckertreiber installieren dürfen (aber was hat das mit den DCs zu tun)?
Andererseits ist dann auch von Clientverbindungen und Sperrung per GPO die Rede... (Bsp.)
Einerseits wird behauptet man ist sicher wenn die Nutzer keine Druckertreiber installieren dürfen (aber was hat das mit den DCs zu tun)?
Andererseits ist dann auch von Clientverbindungen und Sperrung per GPO die Rede... (Bsp.)
Da Fremde Zugriffs aufs System des Printserver zugreifen könnten, hätten sie ggfs. Zugiff auf die Domäne. Der DC kann dich bei der Verteilung der passenden GPO unterstützen (wie oben bereits geschrieben).
Also scheinbar gibt es diverse Ansätze, welchen verfolgt man nun?
Es kommt darauf an, wie viele Rechner du betreust und ob du Printserver überhaupt benötigst.
Dazu kommt, ob in einer Domäne oder Workgroup.
Zitat von @SOlangsam:
Es kommt darauf an, wie viele Rechner du betreust und ob du Printserver überhaupt benötigst.
Dazu kommt, ob in einer Domäne oder Workgroup.
Es kommt darauf an, wie viele Rechner du betreust und ob du Printserver überhaupt benötigst.
Dazu kommt, ob in einer Domäne oder Workgroup.
Hey,
also Domainumgebung und damit in die Richtung:
- DCs Spooler aus (wenn nicht zwingend nötig) klar
- GPO auf die Clients ausrollen (deaktivieren von "Annahme von Clientverbindungen zum Druckspooler zulassen" in Computerkonfiguration / Administrative Vorlagen / Drucker) - Spooler muss danach noch mal neugestartet werden
Aber letztlich hilft das ja nichts gegen das Einschleusen kompromittierter Dateien.
Somit noch mal die Gelegenheit die Mitarbeiter zu sensibilisieren.
Also zusammengefasst:
Um das Drucken weiterhin zu unterstützen (Abschaltung nicht möglich) ..
Druck generell verbieten bzw. keine Notwendigkeit
Druck weiterhin benötigt, aber nur an direkt angebundene Drucker (kein Remotedruck möglich)
Um das Drucken weiterhin zu unterstützen (Abschaltung nicht möglich) ..
- über den von mir geposteten Blog gehen. Und das Skript über alle Printserver laufen lassen.
- verhindert, dass jemand versucht, Dateien oder Ordner der Drucker zu modifizieren.
Druck generell verbieten bzw. keine Notwendigkeit
- ganz klar -> Spooler aus!
Druck weiterhin benötigt, aber nur an direkt angebundene Drucker (kein Remotedruck möglich)
- über GPO gehen
Zitat von @SOlangsam:
Um das Drucken weiterhin zu unterstützen (Abschaltung nicht möglich) ..
Druck generell verbieten bzw. keine Notwendigkeit
Um das Drucken weiterhin zu unterstützen (Abschaltung nicht möglich) ..
- über den von mir geposteten Blog gehen. Und das Skript über alle Printserver laufen lassen.
- verhindert, dass jemand versucht, Dateien oder Ordner der Drucker zu modifizieren.
Druck generell verbieten bzw. keine Notwendigkeit
- ganz klar -> Spooler aus!
Jap klar soweit und unproblematisch, aber letztlich ist jeder Client irgendwie auch ein Printserver,
auch wenn da nur ein PDF Drucker läuft oder eben die Drucker vom Printserver angesteuert werden.
Damit ist dort auch ein Risiko zu sehen und wenn das Skript auf den Clients ausgeführt würde,
dann können sich die Kollegen keinen Drucker mehr hinzufügen - keine Lösung. :/
Wenn ich dann hier lese:
Nach erster Reaktion gegen Print Nightmare keine GPO basierten Druckermappings mehr möglich
kann das spannend werden.
Mal ne Frage....
Mit dieser GPO auf die Clients ausrollen (deaktivieren von "Annahme von Clientverbindungen zum Druckspooler zulassen" in Computerkonfiguration / Administrative Vorlagen / Drucker) - Spooler muss danach noch mal neugestartet werden
Drucker die über den Printserver gehen, funktionieren dann auf den Clients nicht mehr?
Funktioniert die GPO zum verteilen der Drucker noch?
Mit dieser GPO auf die Clients ausrollen (deaktivieren von "Annahme von Clientverbindungen zum Druckspooler zulassen" in Computerkonfiguration / Administrative Vorlagen / Drucker) - Spooler muss danach noch mal neugestartet werden
Drucker die über den Printserver gehen, funktionieren dann auf den Clients nicht mehr?
Funktioniert die GPO zum verteilen der Drucker noch?
Es gibt eine Aktualisierung des MSRC Artikels mit Update.
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34527
https://support.microsoft.com/en-us/topic/31b91c02-05bc-4ada-a7ea-183b12 ...
/Thomas
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34527
https://support.microsoft.com/en-us/topic/31b91c02-05bc-4ada-a7ea-183b12 ...
/Thomas
1Dann geben wir das mal auf den Clients und dem Printserver frei, alles andere was noch ne GUI hat, hat nun keinen aktiven Spooler mehr.
Wie erhofft, hat MS die Lücke eindämmen können. Es soll trotzdem noch ein passender Patch kommen.
Bin gespannt.
Bin gespannt.
Zitat von @SOlangsam:
Wie erhofft, hat MS die Lücke eindämmen können. Es soll trotzdem noch ein passender Patch kommen.
Bin gespannt.
Wie erhofft, hat MS die Lücke eindämmen können. Es soll trotzdem noch ein passender Patch kommen.
Bin gespannt.
Das ist die Ankündigung des Patches, man kann (und sollte) ihn installieren.
/Thomas
Zitat von @Th0mKa:
Das ist die Ankündigung des Patches, man kann (und sollte) ihn installieren.
Zitat von @SOlangsam:
Wie erhofft, hat MS die Lücke eindämmen können. Es soll trotzdem noch ein passender Patch kommen.
Bin gespannt.
Wie erhofft, hat MS die Lücke eindämmen können. Es soll trotzdem noch ein passender Patch kommen.
Bin gespannt.
Das ist die Ankündigung des Patches, man kann (und sollte) ihn installieren.
Laut CVE ist das nicht für Windows 10 Version 1607, Windows Server 2016 und Windows Server 2012.
Da soll noch etwas kommen.
Zitat von @SOlangsam:
Laut CVE ist das nicht für Windows 10 Version 1607, Windows Server 2016 und Windows Server 2012.
Da soll noch etwas kommen.
Laut CVE ist das nicht für Windows 10 Version 1607, Windows Server 2016 und Windows Server 2012.
Da soll noch etwas kommen.
Was denn?
Ich mein ich sync nicht alles, nur das was auch im Einsatz ist, aber hier mal 2012 R2 bis 2019 & Clients:
Zitat von @dertowa:
Was denn?
Ich mein ich sync nicht alles, nur das was auch im Einsatz ist, aber hier mal 2012 R2 bis 2019 & Clients:
Zitat von @SOlangsam:
Laut CVE ist das nicht für Windows 10 Version 1607, Windows Server 2016 und Windows Server 2012.
Da soll noch etwas kommen.
Laut CVE ist das nicht für Windows 10 Version 1607, Windows Server 2016 und Windows Server 2012.
Da soll noch etwas kommen.
Was denn?
Ich mein ich sync nicht alles, nur das was auch im Einsatz ist, aber hier mal 2012 R2 bis 2019 & Clients:
Habe es ebenfalls aus den CVE.
Die 2012er Server bieten mir KB5004954 an und die Windows 10 Rechner KB5004945
Aber die 2016er zeigen mir noch nichts an...
Aber die 2016er zeigen mir noch nichts an...
Zitat von @leon123:
Die 2012er Server bieten mir KB5004954 an und die Windows 10 Rechner KB5004945
Aber die 2016er zeigen mir noch nichts an...
Die 2012er Server bieten mir KB5004954 an und die Windows 10 Rechner KB5004945
Aber die 2016er zeigen mir noch nichts an...
Mittlerweile sind die Patches für alle OS Versionen im Artikel verlinkt, sollten dann also auch über die Updatekanäle verfügbar sein.
/Thomas.
Gestern Abend war bei mir noch nichts da, heute erhalte ich auf den 2016er das Update KB5004958.
Moin,
wir mussten das Update deinstallieren. Die Zebra Ettikettendrucker haben das nicht vertragen.
Viele Grüße
Trommel
wir mussten das Update deinstallieren. Die Zebra Ettikettendrucker haben das nicht vertragen.
Viele Grüße
Trommel
Zitat von @Trommel:
Moin,
wir mussten das Update deinstallieren. Die Zebra Ettikettendrucker haben das nicht vertragen.
Viele Grüße
Trommel
Moin,
wir mussten das Update deinstallieren. Die Zebra Ettikettendrucker haben das nicht vertragen.
Viele Grüße
Trommel
Welche treiber hast du denn? wir haben hier einige Zebra's mit dem Treiber von Nicelabel im Einsatz und keine Probleme mit dem Patch
Wir haben auch Nicelabel und Zebra... Ein Drucker machte erst Probleme... Treiber Neuinstallation und 2x Neustarten dann gings wieder. Auch so ein Elton Drucker machte kurzzeitig Probleme.
Bei uns ließen sich drei Windows 10 Test Clients (2004) und ein Server 2019 Standard (1809) nicht aktualisieren.
Auch ein manuelles Herunterladen aus dem Update Catalog brachte nicht den Erfolg.
Hier muss wohl noch einmal nachgebessert werden seitens Microsoft.
Gruß
Marc
Auch ein manuelles Herunterladen aus dem Update Catalog brachte nicht den Erfolg.
Hier muss wohl noch einmal nachgebessert werden seitens Microsoft.
Gruß
Marc
Zitat von @radiogugu:
Bei uns ließen sich drei Windows 10 Test Clients (2004) und ein Server 2019 Standard (1809) nicht aktualisieren.
Bei uns ließen sich drei Windows 10 Test Clients (2004) und ein Server 2019 Standard (1809) nicht aktualisieren.
Hatten diese ggf. das letzte kumulative Update von 06/2021 auch noch nicht installiert?
Habe das Problem (0x80242017) bei einem 20H2 der noch auf einem alten Stand ist Build .870. ;)
Da fehlt dann einfach das aktuelle SSU, welches ja eigentlich in den kumulativen Updates drin ist.
In den out-of-band Updates scheint das nicht so. Habe bei dem System das Juni-Update manuell
nachgeholt da WSUS das natürlich nicht mehr für den Client anbietet.
Denn in der Updateinfo von Juni steht:
Prerequisite:
For Windows Server Update Services (WSUS) deployment:
Install the May 11, 2021 update (KB5003173) before you install the latest cumulative update.
For offline Deployment Image Servicing and Management (DISM.exe) deployment:
If an image does not have the February 24, 2021 (KB4601382) or later cumulative update, install the January 12, 2021 SSU (KB4598481) and the May 11, 2021 update (KB5003173).
For Windows Server Update Services (WSUS) deployment:
Install the May 11, 2021 update (KB5003173) before you install the latest cumulative update.
For offline Deployment Image Servicing and Management (DISM.exe) deployment:
If an image does not have the February 24, 2021 (KB4601382) or later cumulative update, install the January 12, 2021 SSU (KB4598481) and the May 11, 2021 update (KB5003173).
Also: https://www.catalog.update.microsoft.com/Search.aspx?q=KB5003173
@dertowa danke für den Hinweis !
Konnte nach der KB5003173 Installation das CU7/2021 ganz normal installieren.
Da merkt man die Nadel bei Microsoft wird immer heißer, wenn ein Cumulative Update nicht das ist, was der Name hergibt.
Gruß
Marc
Konnte nach der KB5003173 Installation das CU7/2021 ganz normal installieren.
Da merkt man die Nadel bei Microsoft wird immer heißer, wenn ein Cumulative Update nicht das ist, was der Name hergibt.
Gruß
Marc
Nun ja, dafür gibt es ja die Dokus. ;)
Zudem mit den Systemen einfach up-to-date bleiben und schon läuft das auch.
Nee im ernst, als es die SSUs noch einzeln gab war das unkompliziert, denn auch wenn das folgende LCU kein SSU brauchte wurde das zuletzt veröffentlichte noch parallel installiert und es gab keine Probleme.
Allerdings hat mich die Lösung hier auch nur wenige Minuten Recherche gekostet und ich wurde zudem noch beim Hersteller des Updates mit dem Hinweis versorgt, also es könnte auch viel schlimmer sein. :P
Zudem mit den Systemen einfach up-to-date bleiben und schon läuft das auch.
Nee im ernst, als es die SSUs noch einzeln gab war das unkompliziert, denn auch wenn das folgende LCU kein SSU brauchte wurde das zuletzt veröffentlichte noch parallel installiert und es gab keine Probleme.
Allerdings hat mich die Lösung hier auch nur wenige Minuten Recherche gekostet und ich wurde zudem noch beim Hersteller des Updates mit dem Hinweis versorgt, also es könnte auch viel schlimmer sein. :P
