[English]Mit den zum 14. Juni 2022 veröffentlichten Sicherheitsupdates hat Microsoft ja zahlreiche Sicherheitslücken geschlossen. Aber es gibt auch Probleme, beispielsweise bei VMs und bei Verwendung von ESET-Sicherheitslösungen. Mir ist aufgefallen, dass Microsoft immer sparsamer mit Details in seinen KB-Artikeln wird – man muss sich die Informationen zusammen suchen. Zudem wurden in Microsoft Azure Schwachstellen stillschweigend gepatcht, nachdem Sicherheitsforscher Druck gemacht haben. Nachfolgend eine Zusammenfassung diverser Informationen, Beobachtungen und Hinweise auf Probleme zum Juni 2022-Patchday.
Anzeige
Gefixte Schwachstellen
Die Sicherheitsupdates vom Juni 2022 beseitigen 55 Schwachstellen, davon eine als 0-day (MSDT "Follina"), in Microsoft-Produkten (siehe Microsoft schließt Follina-Schwachstelle (CVE-2022-30190) in Windows mit Juni 2022-Updates ). Eine Liste aller abgedeckten CVEs finden Sie auf dieser Microsoft-Seite. Bei Tenable gibt es zudem diesen Blog-Beitrag mit einer Übersicht der gefixten Schwachstellen – ich hatte die Liste im Blog-Beitrag Microsoft Security Update Summary (14. Juni 2022) herausgezogen.
Die Dogwalk-Schwachstelle bekommt keinen Fix – hatte ich im Blog-Beitrag Windows MSDT 0-day-Schwachstelle "DogWalk" erhält 0patch-Fix bereits angesprochen.
Problemberichte zu den Juni 2022-Updates
Aktuell halten sich die Rückmeldungen aus der Nutzerschaft bezüglich Problemen in Zusammenhang mit den Juni 2022-Updates noch in Grenzen. Das bei Windows Server die Installationsreihenfolge der Patches zu beachten ist (DCs zuletzt), hatte ich ja in den Blog-Beiträgen erwähnt.
Virtuelle Maschinen (VMs) hängen
Blog-Leser Daniel N. hat sich per Mail gemeldet und berichtet von der Beobachtung, dass in seiner Unternehmensumgebungen beobachtet wurde, dass virtuelle Maschinen nach dem Update beim anschließend Start hängen bleiben.
Heute ist wieder Patchday. Ein kleiner Bug: wir sehen einige VMs, welche beim Starten hängen geblieben sind, ein reboot behebt das fix. Dennoch muss man eben eingreifen, bei hochautomatisierten Umgebungen sollte man also parat stehen.
Daniel hat mich auf diesen Novotext-Blog-Beitrag hingewiesen, wo das auch erwähnt wurde – dort waren VMs mit
- Windows Server 2016
- Windows Server 2019
betroffen. Danke an Daniel für den Hinweis. Da nachfolgend ESET als Problemquelle genannt wird, habe ich bei Daniel nachgefragt. Die setzen ESET auch ein, schließen aber einen Zusammenhang aus (Zitat: Interessant – ja ESET ist auch im Einsatz. Aber nicht immer bei diesem Fehlerbild, das hatten wir schon geprüft).
Windows 11: Hyper-V streikt
Blog-Leser Dave berichtet in diesem Kommentar von Problemen mit Hyper-V auf einer Testmaschine:
Unter Windows 11 läuft Hyper-V auf der Testmaschine nicht mehr nach der Installation von KB5014697.
Verabschiedet sich mit Snap In konnte nicht erstellt werden. Keine CLSID.
1Password wirft auch eine Fehlermeldung hin.
Dave schreibt, dass .NET Framework 4.8 in der Vergangenheit meist die Ursache war. Das Paket ist aber in diesem Fall nicht installiert.
ESET lässt Server hängen
In einem Kommentar-Thread zum Beitrag Microsoft Security Update Summary (14. Juni 2022) meldet LeMajors, dass zwei seiner Server nach der Installation von KB5014692 nicht mehr hoch fahren. Ursache ist in diesem Fall eine ESET-Virenschutzlösung, und Dominik schrieb dazu:
Anzeige
Achten Sie darauf, dass auf Ihrem Server keine Windows Updates ausstehen und kein Neustart aufgrund von Windows Updates oder aus anderen Gründen geplant ist. Wenn Sie versuchen, ein Vor-Ort-Upgrade auf einem Computer mit ausstehendem Windows Update oder Neustart auszuführen, wird die vorhandene Version von ESET Security for Microsoft SharePoint möglicherweise nicht korrekt entfernt. Außerdem können Probleme auftreten, wenn Sie anschließend versuchen, die alte Version von ESET Security for Microsoft SharePoint manuell zu entfernen.
Quelle ist wohl die ESET-Hilfe zur Aktualisierung auf neue Programmversionen.
Backup-Probleme auf Windows Server
Die Kollegen von Bleeping Computer weisen in diesem Beitrag darauf hin, dass durch die Behebung der Elevation of Privilege-Schwachstelle CVE-2022-30154 für den Microsoft File Server Shadow Copy Agent Service, Probleme mit Backups auftreten können. Microsoft hat das im KB-Artikel auch so dokumentiert:
Um geschützt und funktionsfähig zu werden, müssen Sie das Update vom 14. Juni 2022 oder höher Windows sowohl auf dem Anwendungsserver als auch auf dem Dateiserver installieren. Der Anwendungsserver führt die VSS-fähige Anwendung (Volume Shadow Copy Service) aus, die Daten auf den Remoteserver-Nachrichtenblock 3.0 (oder höher)-Freigaben auf einem Dateiserver speichert. Der Dateiserver hostet die Dateifreigaben. Wenn Sie das Update nicht auf beiden Computerrollen installieren, können Sicherungsvorgänge, die von Anwendungen ausgeführt wurden, die zuvor funktioniert haben, fehlschlagen. Bei solchen Fehlerszenarien protokolliert der Microsoft File Server Shadow Copy Agent-Dienst das FileShareShadowCopyAgent-Ereignis 1013 auf dem Dateiserver. Weitere Informationen finden Sie unter KB5015527.
WMI-Abfragen werden abgewiesen
Arne berichtet in diesem Kommentar zu den Windows Updates, dass die WMI-Abfragen des Monitor-Systems (icinga2) nicht mehr funktionieren ("NTSTATUS: NT_STATUS_ACCESS_DENIED – Access denied").
Bei mir funktionieren die WMI-Abfragen von meinem Monitor-System (icinga2) nicht mehr ("NTSTATUS: NT_STATUS_ACCESS_DENIED – Access denied").
Ein Test mit dem WMI Explorer unter Windows ergab, dass es mit Computern in der gleichen Domäne wie gewohnt funktioniert. Ist der Windows-Computer nicht Mitglied der Domäne ist keine Anmeldung an WMI möglich.
Das Problem betrifft bei mir Windows Server 2012 und Windows Server 2019.
Bisher ist noch kein weiterer Kommentar in dieser Richtung gekommen. Es gab aber einen Hinweis auf diesen Artikel von Palo Alto Networks.
Shared Folders und Zebra-Drucker
Weiterhin gibt es in diesem Kommentar einen Einzelhinweis, dass es Probleme mit Shared-Folders (Ordnerfreigaben) unter Windows 7 SP1 gebe.
Im reddit.com Mega-Thread gibt es hier vage Hinweise auf Sicherheitseinstellungen für DCOM (vom Februar 2022), die Probleme bereiten können – da das "Hardening" zum 14. Juni 2022 aktiviert wird. Von Checkpoint gibt es eine entsprechende Warnung Check Point response to CVE-2021-26414 – "Windows DCOM Server Security Feature Bypass" (Nov. 2021).
Weiterhin findet sich im Mega-Thread ein Hinweis auf Probleme mit Druckern, Zitat: I've had two patch problem and that was breaking Dynamo printers and Zebra g420k printers. All windows running srv 2022 with inplace upgrades.
Fehlende Details in Microsoft-Dokumentation
Beim Durchgehen der Beschreibungen für die jeweiligen Sicherheitsupdates ist mir aufgefallen, dass die Beschreibung der Fixes seit den letzten 2 Monaten äußerst knapp ausfällt. Es gibt nur einen allgemeinen Hinweis, dass was gefixt wurde und ggf. ein oder zwei hervorgehobene Punkte. In den kumulativen Updates für Windows 10/11 und Server werden aber wesentlich mehr Fehler behoben.
Ich hatte in den Beiträgen zu Windows 10 und Windows 11 bereits darauf hingewiesen. Wer Details zu den Fixes für Juni 2022 sucht, muss in den Beschreibungen zu den Preview-Updates der Vorwochen nachsehen (siehe auch die Liste der am Artikelende verlinkten Beiträge).
Kritik von Sicherheitsforschern
Die Politik Microsofts zur Behandlung und Dokumentation von Schwachstellen bekommt auch Kritik von Sicherheitsexperten. Claire Tills, Senior Research Engineer bei Tenable, kommentiert den aktuellen Patch Tuesday:
Das Patch Tuesday Release dieses Monats enthält Fixes für 55 CVEs – drei davon sind als kritisch und 52 als wichtig eingestuft.
Microsoft behebt CVE-2022-30136, eine Sicherheitslücke im Netzwerk-Dateisystem, die von einem nicht authentifizierten Angreifer ausgenutzt werden kann und einen CVSSv3-Score von 9,8 erhält. Diese Sicherheitslücke betrifft nicht die Versionen 2 und 3 von NFS. Als Abhilfemaßnahme hat Microsoft vorgeschlagen, die NFS-Version 4.1 zu deaktivieren. Dies kann jedoch nachteilige Auswirkungen auf Systeme haben, insbesondere für Unternehmen, die das Sicherheitsupdate vom Mai 2022 für CVE-2022-26937 nicht angewendet haben. Wann immer es möglich ist, wird Unternehmen dringend empfohlen, ihre Systeme mit den neuesten Patches zu aktualisieren.
Patches für CVE-2022-30190, den als Follina bekannten Zero Day, der Ende Mai aufgedeckt wurde, sind ebenfalls im Release dieses Monats enthalten. Im Vorfeld des Patch Tuesday gab es viele Spekulationen darüber, ob Microsoft Patches veröffentlichen würde, da Microsoft die Schwachstelle zunächst heruntergespielt hatte und sie in den Wochen nach ihrer Offenlegung weit verbreitet war.
Was Microsofts beunruhigendes Verhalten, legitime Sicherheitsbedenken herunterzuspielen, betrifft, hat der Tenable-Forscher Jimi Sebree zwei Schwachstellen in Microsofts Azure Synapse Analytics entdeckt und veröffentlicht. Davon wurde eine gepatcht wurde und eine nicht. Keine der beiden Schwachstellen wurde mit einer CVE-Nummer versehen oder in Microsofts Security Update Guide für Juni dokumentiert.
Tills merkt an, dass es im Moment es jedoch nur sehr wenige Informationen von Microsoft gebe. Zu den oben erwähnten, von Tenable-Forscher Jimi Sebree, entdeckten Schwachstellen erklärte Tenable-CEO Amit Yoran, dass Microsoft beschloss, eines der Probleme stillschweigend zu patchen und das Risiko herunterzuspielen. Hier der Originaltext der Aussagen:
Nachdem wir die Situation bewertet hatten, beschloss Microsoft, eines der Probleme stillschweigend zu patchen und das Risiko herunterzuspielen. Erst als sie erfuhren, dass wir an die Öffentlichkeit gehen würden, änderte sich ihre Story…
89 Tage nach der ersten Meldung der Sicherheitslücke … als sie privat die Schwere des Sicherheitsproblems einräumten. Bis heute wurden die Microsoft-Kunden nicht benachrichtigt.
Die Meinung der Tenable Sicherheitsexperten: Ohne rechtzeitige und detaillierte Offenlegung haben die Kunden keine Ahnung, ob sie anfällig für Angriffe waren oder sind, oder ob sie Opfer eines Angriffs wurden, bevor eine Sicherheitslücke geschlossen wurde. Indem man die Kunden nicht benachrichtigt, verwehrt man ihnen die Möglichkeit, nach Beweisen dafür zu suchen, ob sie gefährdet waren oder nicht – eine grob unverantwortliche Politik.
SynLapse-Sicherheitslücke (CVE-2022-29972)
Etwas ähnliches höre ich von Orca Security, die die langsame Reaktion von Microsoft beim Beheben der SynLapse-Sicherheitslücke bemängeln. In einer Nachricht, die mir zugegangen ist, schreiben deren Sicherheitsforscher:
Obwohl es sich bei SynLapse (CVE-2022-29972) um eine kritische Sicherheitslücke handelt, hat Microsoft über 100 Tage gebraucht, um die erforderlichen Schritte zur Behebung der Sicherheitslücke durchzuführen.
Es handelt sich um eine kritische Sicherheitslücke in Microsoft Azure Synapse Analytics, die auch Azure Data Factory betraf. Sie ermöglichte es Angreifern, die Mandantentrennung zu umgehen und gleichzeitig folgende Fähigkeiten zu erlangen:
- Zugangsdaten für andere Azure-Synapse-Kundenkonten zu erlangen.
- Kontrolle über deren Azure-Synapse-Arbeitsbereiche.
- Code auf gezielten Kundenrechnern innerhalb des Azure Synapse Analytics-Dienstes auszuführen.
- Weitergabe von Kundenzugangsdaten an Datenquellen außerhalb von Azure.
Ein Angreifer, der nur den Namen eines Azure Synapse-Arbeitsbereichs kennt, könnte die in Synapse eingegebenen Zugangsdaten eines Opfers ausspähen (siehe dieses Vimeo-Video). Orca Security hat diesen Blog-Beitrag zum Thema veröffentlicht. Orca hat mit der Veröffentlichung bis jetzt gewartet, um Synapse-Kunden Zeit zu geben, ihre lokalen Versionen zu patchen und ihre Nutzung von Azure Synapse zu überdenken. MSRC hat mehrere Verbesserungen vorgenommen und arbeitet weiter an einer umfassenden Tenant-Isolation.
Was ist Azure Synapse Analytics?
Azure Synapse Analytics importiert und verarbeitet Daten aus vielen Kundendatenquellen (z. B. CosmosDB, Azure Data Lake und externen Quellen wie Amazon S3). Jede Synapse-Instanz wird als Workspace bezeichnet. Um Daten aus einer externen Datenquelle zu importieren und zu verarbeiten, gibt ein Kunde Zugangsdaten und relevante Daten ein und stellt dann über eine Integration Runtime eine Verbindung zu dieser Quelle her – eine Maschine, die eine Verbindung zu vielen verschiedenen Datenquellen herstellt.
Integration Runtimes können entweder selbst (On-Premises) oder in der Azure Cloud gehostet werden (über die Azure Data Factory Integration Runtime). In der Cloud gehostete Azure IRs können auch mit einem Managed Virtual Network (VNet) konfiguriert werden, um private Endpunkte für externe Verbindungen zu verwenden, was zusätzliche Isolationsebenen bieten kann.
Wie kritisch war SynLapse?
SynLapse ermöglichte es Angreifern, über einen internen Azure-API-Server, der die Integration Runtimes verwaltet, auf Synapse-Ressourcen zuzugreifen, die anderen Kunden gehören. Da das Orca-Team den Namen eines Arbeitsbereichs kannte, war es in der Lage, Folgendes durchzuführen:
- Autorisierung innerhalb anderer Kundenkonten zu erlangen, während des Agierens als Synapse Workspace. Je nach Konfiguration hätte das Team auf noch mehr Ressourcen innerhalb eines Kundenkontos zugreifen können.
- Auslesen von Zugangsdaten, die Kunden in ihrem Synapse-Arbeitsbereich gespeichert haben.
- Kommunikation mit den Integration Runtimes anderer Kunden. Das Orca-Team konnte dies nutzen, um Remote-Code (RCE) auf den Integration Runtimes eines beliebigen Kunden auszuführen.
- Kontrolle über den Azure-Batch-Pool, der alle gemeinsam genutzten Integration Runtimes verwaltet. Orca war in der Lage, Code auf jeder Instanz auszuführen.
Nach Gesprächen mit Microsoft ist Orca Security nun der Ansicht, dass Azure Synapse Analytics sicher ist und eine ausreichende Tenant-Isolation bietet. Aus diesem Grund hat Orca die Warnmeldungen zu Synapse aus der Orca Cloud Security-Plattform entfernt. Der Vorfall zeigt aber, dass die häufiger geäußerte Aussage zu Bugs in Patches auf On-Premises-Systemen, die Kunden Richtung Microsoft-Cloud treiben sollen, weil dort alles sicherer sei und Microsoft zügig patcht, nicht so wirklich zu stimmen scheint.
Hertzbleed-Schwachstelle in Prozessoren
Forscher-Teams der University of Texas in Austin, der University of Illinois Urbana-Champaign und der University of Washington haben eine neue Hertzbleed genannte Schwachstelle in Prozessoren von Intel und AMD entdeckt. Der neue Seitenkanalangriff ermöglicht Remote-Angreifern, vollständige kryptografische Schlüssel zu stehlen, indem sie Schwankungen der CPU-Frequenz beobachten, die durch dynamische Spannungs- und Frequenzskalierung (DVFS) ermöglicht werden. Dies ist möglich, weil bei modernen x86-Prozessoren von Intel (CVE-2022-24436) und AMD (CVE-2022-23823) die dynamische Frequenzskalierung von der Leistungsaufnahme und den verarbeiteten Daten abhängt.
Die Kollegen von Bleeping Computer berichten hier, dass AMD und Intel keine Fixes dazu planen. Von Intel gibt es das Advisory INTEL-SA-00698 und von AMD das Bulletin AMD-SB-1038 dazu. Microsoft hat hierzu ADV220002 (Microsoft Guidance on Intel Processor MMIO Stale Data Vulnerabilities) veröffentlicht.
Fortsetzung: Juni 2022 Patchday-Nachlese (Teil 2): RDP-, VPN-, WLAN-, Hotspot-Verbindungsprobleme und mehr
Ähnliche Artikel:
Microsoft Security Update Summary (14. Juni 2022)
Patchday: Windows 10-Updates (14. Juni 2022)
Patchday: Windows 11/Server 2022-Updates (14. Juni 2022)
Windows 7/Server 2008R2; Windows 8.1/Server 2012R2: Updates (14. Juni 2022)
Follina: Angriff über Word-Dokumente und ms-msdt-Protokoll (CVE-2022-30190)
Follina-Schwachstelle (CVE-2022-30190): Status, Erkenntnisse, Warnungen & Angriffe
0Patch Micro-Patch gegen Follina-Schwachstelle (CVE-2022-30190) in Windows
Follina (CVE-2022-30190): Angriffswelle ausgeblieben, aber Kampagnen auf EU/US und andere Ziele
Follina-Schwachstelle (CVE-2022-30190): Neue Erkenntnisse, neue Risiken (9.6.2022)
2015
es gab auch für SQL Server diverse Sec-updates, die sich teils nur ohne anderen Updates installieren liesen, dann teils reboot angefordert haben oder auch nicht. je nach sql und os kombi.
wir haben als bei windows maschinen mit sql servern 2 mal patchen müssen bzw. 2 reboots durch zuführen gehabt.
SQL patch beißen sich leider öfter mit den anderen updates, erlebe ich meisten so
Updates zum Microsoft Sqlserver lassen sich nicht installieren wenn ein Neustart ansteht. Leider erkennt der Updatemechanismus diese Abhängigkeit nicht und installiert das vor den anderen Patches. Also raus nehmen und danach getrennt installieren!
Die Sicherheitsupdates für Installationen mit CU sind kumulativ und enthalten das letzte CU.
>> Virtuelle Maschinen (VMs) hängen
Da würde schon interessieren ob das für alle Hypervisor-Plattformen gilt, oder nur für eine spezielle – doch nicht etwa Hyper-V ?
Der verlinkte Beitrag zeigt Hyper-V (imho) in den Screenshots.
Das bezieht sich wohl eher auf Hyper-V Server, die mit den Juni Patches versehen wurden, wohl nicht auf Hyper-V Guests, welche die Updates erhalten haben – oder?
Ich habe auf einem PC ESET Antivirus im Einsatz und kann bestätigen das es Probleme mit dem Update gab. Nach gefühlter Stunde bei 96 % hat das Update abgebrochen und alles rückgängig gemacht.
Nach lesen hier hab ich den Antivirus ausgeschalten und das Update lief ohne Problem durch.
Die ganze miserable Informationspolitik, sowie überhaupt das ganze ekelhafte und inzwischen wirklich nur noch rotzearrogante Geschäftsgebaren Microsofts, passt doch wunderbar in unsere aktuelle Zeit! Aussitzen, totschweigen, verharmlosen, negieren, kleinreden und ja, auch mal eiskalt lügen und betrügen (…) an allen Ecken und Enden, immer und überall und vor allem immer mehr … Die "Großen" und "Maßgeblichen" aus der Geschäftswelt, Politik und auch "Kunst" (?) und "Kultur" (?) machen es uns doch ständig vor. Wer erwartet da noch vom "kleinen Individuum", dass es sich immer korrekt und anständig verhält …?! "Werte" und "Tugenden", wie sie früher mal in der Geschäfts- und politischen Welt galten, sterben immer mehr aus, oder werden zumindest ständig aufgeweicht und als "normal-schlecht" akzeptiert. Kommt natürlich auch daher, dass einige wenige "Große" immer mehr das Sagen haben und diese das natürlich auch ganz genau wissen und immer mehr schamlos (meist natürlich zu ihren Gunsten) ausnutzen!
MS kann doch tun und lassen was sie wollen – wenn wir alle mal ehrlich sind. Wir regen uns alle ständig auf – und nutzen dann deren Krempel halt doch! Ja, nicht alle (also 100 %) aber eben doch die absolute (sogar weit mehr als wie zwei Drittel) Mehrheit. Das einzige, was dieser ganzen Entwicklung entgegenwirken würde ist – neben z. B. halt „nicht mehr verwenden" – DRUCK! Und zwar noch vieeeel mehr, als das, was z. B. diverse Sicherheitsforscher bewirken können! So wie im Artikel geschrieben:
„Nachdem wir die Situation bewertet hatten, beschloss Microsoft, eines der Probleme stillschweigend zu patchen und das Risiko herunterzuspielen. Erst als sie erfuhren, dass wir an die Öffentlichkeit gehen würden, änderte sich ihre Story…"
Es geht also! Eine weitere "Druckquelle" wäre ja eigentlich die Politik und ihre maßgeblich Verantwortlichen. Allerdings: Wenn die Politik natürlich vor der Macht von solchen Konzernen einknickt, oder schlimmer noch, sogar gemeinsame Sache mit diesen macht, dann kann man es natürlich mehr oder weniger leider komplett vergessen …! Die gesamte Entwicklung auf breiter Front, ist mehr als wie bedenklich. Würde sie sogar inzwischen als bedrohlich (für uns alle) bezeichnen!
Was in diesen schmutzigen Zeiten hingegen immer erfolgreicher wird, ist der Druck durch öffentliche Empörung. Wenn Politiker am Pranger landen und zurücktreten müssen, weil eines ihrer missglückten Witzchen zum Gesinnungsskandal hochgepusht wird – warum wird nicht mit dem gleichen moralischen Anspruch das Geschäftsgebaren der großen Konzerne gemessen und öffentlich angeprangert? Wo sind Youtube-Einflüsterer, die gegen die Arroganz und Verantwortungslosigkeit von MS&Co. Druck machen? (Ach so: Bringt keine Kohle, dafür das Risiko, durch Klagen mundtot gemacht zu werden. Früher kletterte Greenpeace auf Schornsteine und hängte Banner hin. Heute sind Banner das, was GoogleAds einblendet. Schöne Pseudo-Redefreiheit des Internet…)
Früher war es anders. Heute wechselt die Greenpeace-Chefin Fr. Morgan aus den USA plötzlich als Sonderbeauftragte ins deutsche Aussenministerium und wird dafür auch noch schnell eingebürgert. Ob sie dort mehr bewirken will oder kann, als mit Plakaten an Schornsteinen, sei mal dahingestellt.
Vollste Zustimmung!
Viele haben inzwischen leider den Kompass für wirklich wichtige Themen verloren. An Pillepalle und Wortklauberei (>> extrem bei dieser „korrekten Genderitis" z. B.) wird sich aufgehängt und dauerempört – und die wirklich wichtigen Themen und Dinge interessieren (scheinbar) keinen mehr so richtig …
Zu " Schöne Pseudo-Redefreiheit des Internet…":
Auch hier genau: Diese "Redefreiheit" spielt sich ja auch (mehr oder weniger unbemerkt) nur noch in den Grenzen der "Großen" ab. Eben genau in diesen Grenzen, die diese Konzerne für gut und richtig (eben auch in "ihrem" Sinne) befinden. Google, YouTube, Facebook (…) bestimmen immer mehr ganz alleine, was gut und richtig ist, was "man" sagen darf, was korrekt ist, was und wie "man" zu denken hat … Dies ist im Prinzip nichts anders wie so zu sagen eine oligopole Meinungsdiktatur. Eben einige Wenige geben vor, wie die Meinung auszusehen hat. Ebenso das Denken links = gut, rechts = böse und somit schlecht. Nein, die extremen Ränder sind bei beiden gleich (!) strikt abzulehnen! Und solange sich alles in einem rechtlich einwandfreien Rahmen abspielt, sollte auch jede (!) Meinung frei geäußert werden können. Mit "rechtlich einwandfreiem Rahmen" meine ich z. B. (noch) unsere rechtlichen Grundlagen und Gesetze der BRD. Denn auch "unbequeme" Meinungen unterliegen nun mal Recht und Gesetz. Auch wenn das z. B. so einige "bessere Menschen" (oder die, die sich gerne dafür halten) nicht gerne hören und schon gar nicht gerne lesen …
Hierzu ein schöner Beitrag von Tamara Wernli auf YouTube, die ich und ihre Arbeit persönlich sehr schätze, da sie immer versucht alles sehr neutral zu bewerten und einzuordnen. Und oft auch sehr gut aufzeigt, was gerade in den sozialen Medien bzgl. Meinungsfreiheit und Zensur aktuell falsch läuft. Ist zwar in diesem Fall ein Satire-Video, aber trotzdem mit ernstem Hintergrund zu sehen:
https://www.youtube.com/watch?v=6wlFgaTY-kw
Leider fehlt mir der Link zum Artikel, in dem steht dass der DC als letztes gepatcht werden soll (siehe oben "Problemberichte zu den Juni 2022-Updates").
Kann der Link nachgereicht werden?
Ist in jedem der unter "Ähnliche Artikel" verlinkten Blog-Beiträge mit den Update-Beschreibungen erwähnt. Die Details finden sich dann in den einzelnen KB-Artikels (z.B. kb5014699 (Abschnitt Bevor Sie dieses Update installieren).
In den meisten Fällen sind ja mindestens 2 DCs im Netzwerk. Heißt das dann beide DCs als letzte patchen, oder kann einer davon schon früher gepatched werden? Ist schon bekannt was passiert wenn der eine DC schon gepatched ist, der zweite aber noch nicht?
Das muss man aber auch nur beachten, wenn man NPS oder so im Einsatz hat. Ansonsten ist es egal, in welcher Reihenfolge man das Update installiert, wenn ich mich nicht täusche. Keine Probleme bei uns, wo NPS nicht im Einsatz ist.
ehm und wenn man das nicht gemacht hat passiert was? unser 802.1x und andere zert basierenden sachen funktionierten nach den OOB Updates von Mai wieder korrekt.
man sollt ja meinen, dass sich das selbst wieder findet nach reboots oder was auch immer.
wir blieben auch bei dem patchday unserer linie treu, erst die basis, sprich domain controller, dhcp, pki, nps und dann application server und clients. und das meiste automatisiert über dementsprechende scheduled tasks.
sollen wir jetzt bei jedem patchday, der sec updates bringt, vorher nach lesen was wie zu installieren ist damit hoffentlich alles passt?
schlimm genug, dass es immer wieder patches gibt, die dann das manuelle eingreifen des admins erfordern, damit sie überhaupt aktiv sind.
bei ein paar 100 bzw. 1000 servern hat man nicht unbedingt die zeit sich den schwachsinn dann monatlich so zu geben.
Hallo MOM20xx, mich würde sehr interessieren, wie Sie die Installation der Updates per Scheduled Task einrichten, besonders bei Server 2019: da funktionieren nämlich die "usoclient" Befehle nicht wie erwartet. Danke
wir verwenden https://www.powershellgallery.com/packages/PSWindowsUpdate/2.2.0.2 usoclient is nicht supported. dabei haben wir die policy das windows selbst vom wsus updates downloaden kann mit bestimmter detection frequency. und zum tag x zeitpunkt x wird per task scheduler mit dem module eine installation inkl. reboot ausgelöst. gibt mittlerweile 2.2.0.3 die haben wir aber noch nicht getestet. so arbeiten wir auf allen server os versionen um die eigenheiten der jeweiligen windows update clients der server ose etwas zu umgehen.
Bei uns funktioniert NPS für die Computerzertifikate immernoch nicht (ohne den Regkey auf den DCs) nach dem Juni Patchday. Das Mai OOB Update haben wir ausgelassen.
Wir haben fast überall Hyper-V, ESET und Microsoft SQL Server im Einsatz. Und was soll ich sagen: wie immer alles anstandslos durchgelaufen [gähn].
Klar gibt es immer Konstellationen, die Probleme machen, z. B. schlecht gemanagte Systeme, die noch alte ESET-Server-Versionen einsetzen, oder Systeme, die nicht auf "automatisch alles aktualisieren sobald und wie von Microsoft empfohlen". Wir fahren mit der letzten Einstellung jedenfalls seit Jahrzehnten und überall vorzüglich. Ich kann mich nicht daran erinnern, wann ich das letzte Mal ein Update deinstallieren musste.
Das einzige Problemchen, aber zum Glück nur hier bei mir persönlich, war neulich die Notwendigkeit, manuell auch einen neueren ODBC für SQL-Server zu installieren wie ja auch hier dokumentiert. Aber damit kann ich leben, um schnellstmöglich wieder die maximal mögliche Sicherheit zu erzielen.
Bei uns auch so. Bisher keine Probleme mit ESET.
Wir haben einen Win 2012 Server bei dem seit dem Patchday kein RDP mehr geht. Es gibt Hinweise, dass es an der Rolle "Routing and Remote Access" liegen sollte. Die VPN Funktionalität geht auch nicht mehr. Ich musste den Server auf vor dem Patch zurückdrehen, dann ging wieder alles. Seltsam für mich ist auch, wenn ich die MS-Firewall deaktiviere, komme ich kurz auf den Server via RDP, kurz danach ist die Verbindung wieder getrennt. Selbes Spiel beim erneuten aktivieren der Firewall. Irgendwie finde ich jedoch im Netz zu dem Problem fast nichts…
Das kann ich nur bestätigen, bei unserem 2012 R2 funktioniert nach Installation des KB5014738 auch RDP nicht mehr, dh. eine RDP Sitzung läßt sich öffnen, wird aber nach kurzer zeit geschlossen. Es gibt Probleme mit Routing and Remote Access und vor allen Dingen funktionieren Dienste, welche in den Dependecies Routing and Remote Access haben, nicht mehr. Nach Deinstallation des KB5014738 funktioniert alles wieder wie gewohnt.
Hallo,
ist das ein Remote Desktop Gateway Server oder ein Anwendungsserver wo Ihr einfach per RDP nicht mehr drauf kommt?
Bei uns ist es ein Anwendungsserver auf den via RDP zugegriffen wird.
Das Problem hatte ich auch auf Windows Server 2019. Im Perfmon konnte man sehen, dass es zyklisch ca. alle 2-3 min einen hohen Anteil "erneut übertragener Segmente" (Leistungsindikator unter TCPv4) gab. Zu diesem Zeitpunkt brach jeweils RDP zusammen und die Dienste des BlackBerry UEM hatten Probleme. Generell konnten die Clients keine VPN-Verbindung aufbauen. Das Problem trat nur auf, wenn der Netzwerk-Adapter "BlackBerry Secure Connect Plus" aktiviert war.
Nach Deinstallation funktioniert wieder alles problemlos.
Auf unserem 2012 R2 läuft der Blackberry UEM Server, daher ist auch der BlackBerry Secure Connect Plus Adapter aktivert. Meisnst du mit "Nach Deinstallation funktioniert wieder alles problemlos" die Deinstallation des monatlilchen Updates für Server 2019 ?
Sollte es tatsächlich ein Problem mit dem BlackBerry Secure Connect Plus Adapter geben, wird es wohl auch bald eine Lösung von Blackberry geben.
Ja nach der Deinstallation von KB5014692 funktioniert der "Secure Connect Plus Adapter" wieder normal und die Netzwerkprobleme sind verschwunden.
Ich habe schon seit einiger Zeit beobachtet, dass verschiedene VMs (Server Core 2019, Win10, Server 2019) beim Reboot nach der Update-Installation einfach beim Windows-Logo hängenbleiben. VM-Umgebung ist Proxmox PVE (qemu/kvm)
Ich habe seit 2 Jahren ein Netzwerk basierend auf einem DC sowie einem Domänen-Joined-Server auf Basis Server 2019. Der Domänen-Joined-Server hat zwei Netzwerkkarten, eine gegenüber dem Internet und eine gegenüber dem Firmen-internen Netz. Der Verkehr der Arbeitsplätze in das Internet funktioniert via Domänen-Joined-Server mit NAT. Bis am 1.6.2022 konnten alle Arbeitsplatz-PC's, der DC und der Domänen-Joined-Server mit dem Internet kommunizieren. Seither, d.h seit der Installation von Update KB5014692m, kann der Domänen-Joined-Server aber selber nicht mehr auf das Internet zugreifen, wohl aber weiterhin der DC und die Arbeitsplatz-PC's. Deinstallation von KB5014692 hilft, aber der auto-Update zerstört den Zugriff dann wieder. Kann man da wirklich nichts machen?
Der Update vom 15.6.2022 führte nun zu folgenden konkreten Problemen beim Domänen-Joined-Server:
1. Boot des Servers führt zum korrekten Erkennen eines Domänennetzwerks, aber der Zugriffstyp ist "Kein Netzwerkzugriff".
2. Wenn ich den NLA-Servie restarte wechselt das Domänennetzwerk zu einem nicht authentifizierten öffentlichen Netzwerk, das dem Domänen-Joined-Server keinen Zugriff auf das Internet erlaubt.
Wir haben 2012R2 Server mit Exchange2016 wo sich die aktuellen Updates nicht installieren lassen.
Die VM unter vmware bleibt länger im Reboot und macht dann einen Fallback des Updates :-(
Wir haben PANDA als AV – alle anderen Server mit PANDA liefen durch, daher weiss ich jetzt im Moment keinen Rat.
SoftwareDistribution auch schon mal bereinigt und frisch gebootet vor der Installation- leider ohne Erfolg :-(
KB5014738 – Fehler Code 800F0922
..das kann allerdings alles und nichts sein.
Alle anderen Updates des Server liefen bis jetzt einwandfrei.
Wir haben ebenfalls abstürzende VM's (TS) und Probleme mit Access Denied Fehlern beim Starten der Powershell.exe; Verwenden auch parallel Kaspersky und sind gerade am Testen ob wir die Problematik ohne den KB nicht mehr haben.
Betroffen waren bei uns aber auch stark Server 2022 Systeme (mit dem KB5014678).