Jump to content

phatair

Members
  • Gesamte Inhalte

    490
  • Registriert seit

  • Letzter Besuch

1 Benutzer folgt diesem Benutzer

Profile Fields

  • Member Title
    Junior Member

Letzte Besucher des Profils

Der "Letzte Profil-Besucher"-Block ist deaktiviert und wird anderen Benutzern nicht angezeit.

Fortschritt von phatair

Experienced

Experienced (11/14)

  • Passioniert Rare
  • 15 Jahre dabei!
  • Engagiert
  • Erste Antwort
  • Erster eigener Beitrag

Neueste Abzeichen

38

Reputation in der Community

7

Beste Lösungen

  1. Wenn ich es richtig verstehe, müsste man WinRE ja deaktivieren, damit die Sicherheitslücke nicht ausgenutzt werden kann. Ich bin nun davon ausgegangen, wenn keine Wiederherstellungspartition vorhanden ist, kann auch WinRE nicht aktiv sein. Laut Reagentc /info ist es das aber. Bei administrator.de hat jemand ein Script geschrieben, damit man WinRE deaktivieren kann. Werde mir das mal genauer anschauen. Oder wie deaktiviert ihr das WinRE?
  2. Hallo zusammen, Microsoft hat mal wieder ganze Arbeit beim Patch day geleistet. Das Update KB5034441 schlägt mit dem Fehler 0x80070643 fehl, wenn die Wiederherstellungspartition zu klein ist. Dazu kommt noch, dass es wohl in der von Microsoft genannten Anleitung zum vergrößern der Partition Fehler gibt (habe ich selber noch nicht geprüft). Das Ganze sieht mal wieder etwas nach Chaos aus. Mir gparted oder ähnlichen Tools kann ich das ja an einzelnen clients anpassen und die partition vergrößern, aber bei 100 oder mehr clients ist das doch Wahnsinn. Wie löst ihr das Problem, falls ihr davon betroffen seid? Da mit dem Update ja eine Bitlocker Sicherheitslücke geschlossen wird, ist das Update wichtig und kann nicht einfach ignoriert werden. Ich habe mal ein paar Clients bei uns geprüft. Einige haben gar keine Wiederherstellungspartition bei anderen ist sie 500mb bis 700mb groß. Da wir die Geräte imagen, ist es mir aktuell noch ein Rätsel warum es da Unterschiede gibt🤔 Das Update werden wir morgen mal auf test Clients einspielen. Hier noch die Quellen https://www.deskmodder.de/blog/2024/01/09/windows-10-kb5034441-winre-update-als-sicherheitsupdate-kann-fehler-0x80070643-ausloesen/#comments https://www.heise.de/news/Patchday-Microsoft-Kerberos-Authentifizierung-unter-Windows-verwundbar-9592648.html Grüße
  3. Also wir nutzen nun weiterhin die interne DB. Performance Probleme haben wir mit dem alten 2012R2 und auch mit dem neuen 2019 nicht (der initiale Sync hatte echt einfach nur ewig gedauert). 6GB RAM reichen locker und wir lassen jeden Tag das WAM Script von www.ajtek.ca laufen. Das Script lässt sich super konfigurieren und übernimmt jegliche Wartung und optimiert alles mit einem Klick. Kostet nicht die Welt, führt aber dazu, dass unserer WSUS schnurrt (mal abgesehen vom langen initial Sync) :) Wir haben aber auch nur 250Clients und 60 Server. Die Klassifizierungen und Produkte hatte ich ja schon oben genannt.
  4. Danke für den Tipp. Ich dachte immer, dass schon das alleinige auswählen der Produkte dazu führt, dass man die DB zumüllt. Das die Updates erst runtergeladen werden, wenn Sie genehmigt werden ist mir klar. Wenn ich dich aber richtig verstehe, führt erst das genehmigen dazu, dass auch die DB "zugemüllt" würde. Ein Auto approve im WSUS ist nicht konfiguriert.
  5. Danke euch für die schnelle Hilfe. Der Sync läuft aktuell und ist bei 27%. Ich warte jetzt mal ab. Durch das genannte WAM Script hatten wir eigentlich einen sehr performanten WSUS. Wenn der initiale Sync durch ist und die Clients sich sauber am neuen WSUS melden und mit Updates versorgt werden, werde ich das Script wieder implementieren. Dann beobachte ich mal die Performance. Falls der initiale Sync jetzt gar nicht läuft, dann werde ich gleich auf eine remote SQL DB gehen. Aber die Produkte und Klassifizierungen die wir mit dem WSUS Synchronisieren sind sehr überschaubar. Klassifizierungen: - Sicherheitsupdates - Updates - Upgrades - Wichtige Updates Produkte: - Office 2016 - Exchange 2016 - Windows 10 and later Dynamic Update - Windows 10 Feature on Demand - Windows 10 LTSB - Windows 10 - Server 2019 - Server 2016 - MS SQL 2017 - MS SQL Management Studio v18
  6. Oh ok, da unser alter WSUS unter 2012R2 auch mit 6GB problemlos gelaufen ist, dachte ich das reicht bei 2019 auch locker aus. Danke für die Links. Schaue ich mir dann noch an. Die Optimierungen nehmen wir zum Großteil über das WAM Script vor (https://www.ajtek.ca/). Das läuft aber auf dem neuen WSUS noch nicht, da ich erstmal den WSUS zum laufen bringen möchte. Ok, auch hier hatten wir bisher keinerlei Probleme, aber werde das mal im Hinterkopf behalten. Vielleicht hat sich hier mit Windows Server 2019 und WSUS doch einiges zum schlechteren verändert. Danke Dir, hatte ich auch gefunden. Hatte meinen ersten Beitrag gleichzeitig mit deinem Beitrag editiert. Dann lasse ich das jetzt erstmal laufen. Wenn das morgen nicht durch ist, werde ich ihn neu aufsetzen und gleich eine remote SQL DB nehmen.
  7. Hallo zusammen, ich setze gerade einen neuen WSUS auf einem Server 2019 auf. "Interne WSUS SQL DB", kein eigener SQL 4 CPUs 6GB RAM Upstream Server ist Microsoft (https://sws.update.microsoft.com;) Internet Zugriff für den Server ist auf die Kategorie "Microsoft Windows Updates" eingeschränkt. Dies müsste auch passen, da unser alter WSUS auf Server 2012R2 über die gleiche Firewall Regel in das Internet kommt und dort funktioniert der Sync problemlos Ich habe die Rolle für den WSUS über den Server Manager hinzugefügt und anschließend noch die "Post-Install Tasks" gestartet. Danach habe ich den Config Wizard durchgeführt. Nun habe ich das Problem, dass die Synchronisierung nicht läuft. Sie startet und geht relativ schnell auf 10%, dann dauert es Ewigkeiten (mehrere Stunden) bis er Prozent für Prozent weitergeht. Bei 65% war dann immer Schluss (habe über Nacht gewartet). Die RAM Nutzung vom WSUS Dienst steigt in der Zeit stetig auf über 5GB und der WSUS Dienst zieht so um die 20-30% CPU. Hat jemand noch eine Idee woran das liegen könnte? Gibt es ein Log in dem ich prüfen kann was bei dem Sync Vorgang passiert oder habe ich irgendwas wichtiges vergessen? An sich ist so ein WSUS ja jetzt kein Hexenwerk :( Vielen Dank. EDIT: Ich habe das Log gefunden - >"C:\Program Files\Update Services\LogFiles\SoftwareDistribution.log" Hier sehe ich immer wieder folgende Meldung 2023-11-14 08:30:45.066 UTC Warning WsusService.3 DBConnection.ExecuteCommandNoResult SqlException occurred. Number 515 and message Der Wert NULL kann in die RevisionID-Spalte, @BundleAll-Tabelle nicht eingefügt werden. Die Spalte lässt NULL-Werte nicht zu. Fehler bei INSERT. Error loading information from upd:BundledUpdates/upd:UpdateIdentity for update 69081ABB-2FD4-49A6-8DA1-2F616F1A9B58\201. Some update revisions in bundle information are not already present in the database. Die Anweisung wurde beendet. 2023-11-14 08:30:48.379 UTC Info w3wp.41 ThreadEntry TimerQueue.FireNextTimers 2023-11-14 08:30:48.379 UTC Info w3wp.41 ServerImplementation.UpdateCache Database change occured; check if we need to update cache. 2023-11-14 08:30:48.379 UTC Info w3wp.41 RevisionIdCache.UpdateCategoryAndRevisionIdCache Fetching the category and revision id change for cache from database 2023-11-14 08:31:16.582 UTC Change WsusService.3 DBConnection.OnReceivingInfoMessage Successfully deployed deployment(Decline) of Windows10.0-KB5010351-arm64.cab UpdateID:6A880902-4DC2-4C69-8977-2904205BFCE9 Revision Number:201 2023-11-14 08:31:16.598 UTC Info w3wp.41 RevisionIdCache.UpdateCategoryCache Refreshing the category cache 2023-11-14 08:31:16.598 UTC Info w3wp.41 RevisionIdCache.UpdateRevisionCache Refreshing the revision cache 2023-11-14 08:31:16.645 UTC Warning WsusService.3 DBConnection.ExecuteCommandNoResult SqlException occurred. Number 515 and message Der Wert NULL kann in die RevisionID-Spalte, @BundleAll-Tabelle nicht eingefügt werden. Die Spalte lässt NULL-Werte nicht zu. Fehler bei INSERT. Error loading information from upd:BundledUpdates/upd:UpdateIdentity for update 59152F2C-DBC8-4AE8-B878-8F600A953869\201. Some update revisions in bundle information are not already present in the database. Die Anweisung wurde beendet. Da ich nach der langen Wartezeit den Server neu gestartet hatte, scheinen jetzt wohl schon Einträge vorhanden zu sein. Das erklärt zwar nicht, warum von Anfang an der Sync so lange gedauert hat, aber es würde erklären warum es jetzt länger dauert.
  8. Danke dir. Ich glaube jetzt hat es klick gemacht. Hatte ganz übersehen, dass es ja viele unterschiedliche Bereiche gibt, wohl cse genannt, und die von dir genannte gilt ja nur für die registry cse's. Ein gpupdate /force gilt ja immer für alle. Dann werden ich das mal so anpassen. Ist ja unabhängig von der aktuellen Problematik sinnvoll. Warte aktuell noch auf den Support von zenworks, die testen gerade etwas. Danke für die Hilfe.
  9. Hallo zusammen, Ich hoffe das ist ok, wenn ich hier nochmal Nachfrage. Ich wäre für eine Info sehr dankbar. Würde die Einstellung gerne wie oben beschrieben aktivieren, aber bin eben unsicher bezüglich der gpupdate /force Thematik. Vielen Dank und Grüße.
  10. Danke für den Hinweis. Die Einstellung war mir noch gar nicht bekannt. Eine Frage hätte ich aber dazu. Ich kann in der Einstellung ja wählen, ob die bestehenden GPOs nur - bei User an und Abmeldung bzw. Computer Neustart angewendet werden - oder auch während der Nutzung Diese Einstellung bezieht sich ja nur auf Registry Einträge. Wie unterscheidet sie sich dann technisch von einem gpupdate /force? Wenn man gpupdate /force eigentlich nicht anwenden soll, da alle GPOs eben neu geschrieben werden. Das würde diese Einstellung dann ja regelmäßig machen. Aber für mich klingt diese Einstellung sehr sinnig, da man damit sicherstellt, dass vorgeschriebenen Einstellungen auch immer aktiv sind. Ich hätte nun die beiden Optionen in der Einstellung wie folgt konfiguriert - Do not apply during periodic background processing -> nicht angehakt -> Änderungen oder neue GPOs sollen ja durchaus im Hintergrund verarbeitet werden - Process even if the Group Policy objects have not changed -> angehakt -> Damit eben GPOs auch angewendet werden, wenn Sie nicht verändert wurden, um sicherzustellen, dass diese immer auf dem Client wirken Oder habe ich hier was missverstanden?
  11. Das war vor meiner Zeit Aber als Client Management System funktioniert ZCM recht gut. Mal abgesehen von dem WSUS Problem, wenn das jetzt davon kommen sollte. Aber wir setzen es schon seit gut 10 Jahren ein und bisher hat das immer sehr gut funktioniert. Mal schauen was jetzt dabei rauskommt. Schönes Wochenende zusammen.
  12. Es ist in der Tat so, man muss ein gpupdate /force machen. Ein gpupdate /target:computer reicht leider nicht (wie von NorbertFE schon vermutet). Wir sind immer noch auf der Suche nach der Ursache. Aber der Support von ZenWorks meinte auch, dass es möglicherweise am Client liegen könnte.
  13. Guten Morgen, bei dem Punkt mit dem MS Update Health Tool hatte ich einen Denkfehler. Das Tool wurde installiert, da der Client davor seine Verbindung zum WSUS verloren hatte. Das Tool war also nicht der Grund für das Problem sondern eher das Resultat. Ich habe nun mal geprüft auf wievielen Clients dieses Tool installiert wurde. Es ist auf 10 von 200 Clients vorhanden. Es betrifft (aktuell) also nur eine kleine Anzahl von Clients. Hier habe ich auch einen identisches Problem bei MS gefunden https://learn.microsoft.com/en-us/answers/questions/1145329/windows-update-and-wsus-registry-configuration-ran Ich prüfe nun, ob es an unserem neuen ZCM Agent liegen könnte. Der bietet auch ein Patch Management, welches wir aber nur für Third Party Software nutzen und nicht für MS Updates, Ich werde nun erstmal auf den betroffenen Clients die Software wieder deinstallieren. Ebenso werde ich über ZCM ein Bundle laufen lassen, welches prüft ob der RegKey vorhanden ist. Wenn nein, wird ein gpupdate /force ausgeführt. So ist zumindest aktuell mal sichergestellt, dass alle Clients welche die WSUS Verbindung verloren haben, auch wieder angebunden werden. Falls ich den Grund für das Problem finde, werde ich den Beitrag hier aktualisieren.
  14. Die Lösung wäre zumindest nachvollziehbar :) Aber nein, bei uns hat kein User lokale Adminrechte. Ich habe gerade mal im Eventlog nachgeschaut. An dem Tag, seit dem sie sich am WSUS nicht mehr gemeldet haben, wurde microsoft update health tools installiert. Das ist bei 2 Clients identisch, bei denen wir heute festgestellt haben, dass die GPO Einträge fehlen. Nun muss ich mal schauen woher dieses komische MS Tool kommt. Das ist nichts was wir verteilen. Vielleicht ist das ein Ansatz.
  15. Hallo zusammen, wir haben aktuell folgendes sporadisches Problem. Auf einigen Windows 10 22H2 (10.0.19045.3448) Clients fehlen plötzlich die WSUS GPO Einträge bzw. der komplette Schlüssel in der Registry -> "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" Damit greifen die Clients auf Windows Update zu und es wird z.B. auch das Windows 11 Update beworben. Im WSUS stehen die Clients dann auch "Client hat sich seit x Tagen nicht mehr gemeldet" drin. Prüft man per gpresult /r die GPOs auf dem Client, ist die GPO aber noch zugewiesen. Ebenso zeigt gpresult /h <pfad> auf dem Client an, dass die WSUS GPO übernommen wurde Prüft man aber eben den Regpfad, fehlt der komplette WindowsUpdate Ordner/Schlüssel. Führt man ein gpupdate /force durch, wird der Regestry Eintrag wieder gesetzt und alles funktioniert wie es soll. Wie man ja aber bei Gruppenrichtlininen.de gelernt hat, soll man force nur im Ausnahmefall nutzen :) Ich verstehe nicht, warum plötzlich bei einigen Clients dieser Eintrag nicht mehr per GPO gesetzt wird bzw. verschwindet. Hat hier jemand eine Idee? Vielen Dank. Grüße, Steffen
×
×
  • Neu erstellen...