phatair

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?

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

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.

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.

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

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.

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.

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.

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.

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?

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.

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.

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.

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.

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

Das wars tatsächlich. Hatte ich null auf dem Schirm, dass hinter dem Public Folder ja noch eine Mailbox steht die auch eine Quota hat. Nach der Anpassung habe ich noch den Information Store Dienst neu gestartet und dann ging es sofort. Vielen Dank für eure Hilfe.

Leider hat beides nicht geholfen, weder Information-Store aufheben/anbinden noch der Reboot danach. Hm.... blöde Frage, aber wo prüfe ich das? In der ECP sehe ich unter -> Öffentliche Ordner -> "Postfächer für öffentliche Ordner" die entsprechende Mailbox. Schaue ich mir die Postfachnutzung an, ist es schon merkwürdig. Hier steht, dass das Kontingent nicht eingeschränkt ist. Klicke ich aber auf "Weitere Optionen..." steht doch eine Einschränkung drinnen, oder verstehe ich das falsch Heißt also, wenn alle Public Folder in dieser Mailbox 11GB erreichen, ist Schluss oder? Grüße

Nein, noch nicht. Das wäre mal die letzte Idee, richtig. Werde ich machen und berichten. Was genau hat das mit meinem Problem zu tun?

Hallo zusammen, ich habe folgendes Problem Wir haben auf unserem Exchange 2016 noch ein paar Public Folders. Bei einem habe ich nun das Problem, dass die User keine Mails mehr in diesen Public Folder verschieben können. Sie erhalten die Fehlermeldung Ich habe dann die Quota für den Public Folder angepasst (inkl. Unterordner) Get-PublicFolder -Identity "<identity>" -Recurse | Set-PublicFolder -IssueWarningQuota 12GB -ProhibitPostQuota 12.5GB Danach habe ich den Public Folder geprüft, es werden mir die neuen Werte auch angezeigt ProhibitPostQuota : 12 GB IssueWarningQuota : 12.5 GB MaxItemSize : 100 MB Mit folgenden Befehl habe ich dann die aktuelle Größe von dem Public Folder geprüft Get-PublicFolder "<Identity>" -Recurse | Get-PublicFolderStatistics | Measure TotalItemSize -sum | Select @{N='Anzahl der Items'; E={$_.Count}}, @{N='Speiche r in Byte'; E={$_.Sum}} | fl Als Größe wird mir dann angezeigt Für mich heißt das, dass der Public Folder einen Grenzwert von 12,5GB hat und seine aktuelle Größe rund 9GB ist. Warum erhalte ich dann aber in Outlook die Meldung, dass der Nachrichtenspeicher voll ist? Hat hier jemand eine Idee? Cache Mode habe ich in Outlook schon deaktiviert um mögliches Caching auszuschließen. Vielen Dank.

Ok, da sucht man längere Zeit nach einer Lösung und wenn man dann die Frage im Forum stellt, findet man die Lösung :) Ich habe dann dem Computer Objekt in der AD einfach eine weitere Gruppe temporär als Mitgliedschaft hinzugefügt. Den Server neu gestartet und nun zeigt gpresult -r wieder alle Computermitgliedschaft an. Auch wenn man die temporäre Gruppe danach wieder entfernt. Ich hoffe damit sind alle Probleme, die durch den Befehl winmgmt /resetrepository hervorgerufen wurden, nun beseitigt. Besonders ärgerlich war, dass die GPOs plötzlich nicht mehr gewirkt haben. Vielleicht hilft ja der Beitrag in Zukunft jemanden.

Hallo zusammen, wir haben auf unseren Servern die Endpoint Protection von Kaspersky deinstalliert. Da nach der Deinstallation die neue Endpoint Protection die Meldung gebracht hat, dass noch eine andere Endpoint Protection installiert ist, haben wir uns an den Kaspersky Support gewendet. Dieser hatte uns den Tipp gegeben, nach der Deinstallation den Befehl winmgmt /resetrepository auszuführen. Dies haben wir gemacht und danach ließ sich auch die neue Endpoint Protection sauber installiert. Nun ist uns aber foglendes aufgefallen. Auf allen Server wo wir diesen Befehl ausgeführt haben, waren keine GPOs mehr aktiv. Wir haben dies mit gpresult -r geprüft. Es waren keine zugewiesenen GPOs mehr aufgelistet und ebenso auch keine Sicherheitsgruppen mehr, die dem Computer zugeordnet sind. Auch fehlt im der gpresult -r Ausagbe der Domänennamen und der Standort. Die GPOs haben wir wieder aktiviert bekommen, nach dem wir ein gpupdate force ausgeführt haben (ein einfaches gpupdate hat nicht ausgereicht). Die Gruppenmitgliedschaften werden aber weiterhin nicht angezeigt. Auch ein Reboot des Servers hat nicht geholfen. Hat jemand eine Idee wie man das wieder korrigieren kann? Wir sind wohl etwas blauäugig an den Befehl winmgmt /resetrepository rangegangen. Es handelt sich bei den Servern um Server 2019. Domänenfunktionsebene und Gesamtstrukturfunktionsebene ist Windows Server 2016. Hat jemand eine Idee wie ich das wieder korrigiert bekomme? Vielen Dank für eure Hilfe. Gruß EDIT: Ich habe die Frage auch bei Administrator.de gestellt. Falls ich eine Lösung finde, werde ich diese in beiden Foren bekannt geben. EDIT2: Es scheint aber so zu sein, dass die Gruppenzugehörigkeiten bei gpresult -r wohl nur nicht angezeigt werden. Hier wird ja z.b. auch normalerweise die Gruppe "Authentifzierte Benutzer" mit aufgeführt. Wir haben eine GPO die die lokalen Admins auf den Server regelt. Ich habe nun eben mal einen Test durchgeführt und in die lokale "Administratoren" Gruppe auf dem betroffenen Server einen User aufgenommen. Dann habe ich gpupdate ausgeführt und der User wurde wieder aus der Gruppe entfernt. die GPO greift also und es wird auch erkannt, dass der Server noch in der Gruppe "Authentifizierte Benutzer" ist. Somit ist das wohl nur ein Anzeigefehler, aber auch das ist unschön. Wäre super wenn jemand eine Idee hätte wie man das wieder korrigiert bekommt.

Ich hätte dazu noch mal eine Frage und hole den Beitrag noch mal hoch. Ich habe jetzt mit netdom den Alias erstellt netdom computername <computer> /add:<alias> Danach habe ich mit setspn -l <computername> die SPNs geprüft und der neue Alias war schon als SPN eingetragen. Damit muss ich doch gar nicht separat den SPN erstellten, es reicht doch der netdom Befehl, oder sehe ich das falsch? Früher musste man ja noch die RegKeys eintragen, damit der Alias funktioniert. Da war dann wohl der manuelle setspn notwendig.

Hallo zusammen, da wir gerade das NTLM Auditing aktiviert haben und prüfen wo bei uns überall NTLM noch verwendet wird, ist uns aufgefallen, dass 90% der NTLM Anfragen an unseren Print Server gehen. Hier bin ich dann auf folgenden MS Artikel gestoßen https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/a-print-nightmare-artifact-krbtgt-nt-authority/ba-p/3757962 Es scheint massive Probleme geben zu können, wenn der damalige PrintNightmare Patch installiert wurde. Das führt unter anderem dazu, dass die Clients NTLM Anfragen an den Print Server schicken und das führt möglicherweise zu langsamen Druckaufträgen, DC Anmeldeproblemen usw. (sehr einfach zusammengefasst) In dem Artikel ist ein sehr aufwendiger Prozess beschrieben um zu prüfen ob man betroffen ist. In den Kommentaren ist eine einfachere Lösung zu finden. Das Logging auf dem Client aktivieren Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\LSA\Kerberos\Parameters" -Name LogLevel -Type DWORD -Value 1 -Force Dann ist im System EventLog die Security-Kerberos EventID 3 zu finden mit folgendem Inhalt wenn ich nun vom Client drucke, sehe ich diese Einträge im EventLog. Die Lösung ist, ein Reg Key zu setzen (bei uns ging es auch ohne den Print Spooler restart). New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Printers\RPC" Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Printers\RPC" -Name RpcNamedPipeAuthentication -Type DWORD -Value 2 -Force Restart-Service Spooler Damit ist der Fehler im EventLog weg. Wir werden das nun auf allen Clients ausbringen und damit müsste ein großer Teil des NTLM Traffics entfallen und auch die möglichen Probleme beim drucken und der DC Anmeldung. Viele haben wahrscheinlich schon NTLM deaktiviert und kennen möglicherweise die Lösung/Problem schon, aber vielleicht hilft es ja noch jemanden. Quellen: https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/a-print-nightmare-artifact-krbtgt-nt-authority/ba-p/3757962 https://www.borncity.com/blog/2023/05/15/print-nightmare-nachwehen-bei-windows-domain-controllern-langsame-print-server-und-ausgebremste-dcs/

Danke Martin. Dann werde ich mich mal an die Arbeit machen und die DNS Share Aliase überarbeiten.

Wäre das der richtige Weg oder gibt es andere Stellen wo man das Auditing aktivieren sollte? Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options Network Security: Restrict NTLM: Audit NTLM authentication in this domain Vielen Dank für deine Hilfe.