phatair

Hallo zusammen, ich habe folgends Problem bzw. verstehe das Verhalten nicht so ganz. Wir haben bei einigen Windows Server 2019 Servern den SPN über den Netdom Befehl eingetragen. Das Auslesen des SPN über "netdom computername <server name> /enum" funktioniert dann manchmal mit dem Domänen Administrator und manchmal mit unseren "Server Admins". Die Fehlermeldung lautet dann einfach nur "Zugriff verweigert". Ein wirkliches Muster habe ich noch nicht rausgefunden. Beide User haben auf das Attribut "msDS-AdditionalDnsHostName" Leserechte. Soweit ich das verstehe, sollte das doch ausreichen um mit dem oben genannten Befehl den SPN auszulesen. Schreibrechte auf das Attribut brauche ich ja nur, wenn ich den SPN mit dem User setzen will. Aber auch das Rechte hätte der User. Oder was für Voraussetzungen müssen noch gegeben sein, damit man den SPN auslesen kann? Vielen Dank Grüße

Haben jetzt den download mode auf 99 gestellt. Updates vom Teams Client funktionieren nun und auch die WSUS Anbindung scheint weiterhin wie gewohnt zu gehen. Danke Dir!

Hallo zusammen, ich habe mal eine kurze Frage zum Download Mode der Delivery Optimization Einstellung Aktuell nutzen wir den download mode 100 (Bypass) da wir keine Delivery Optimization benötigen und die Downloads über WSUS bereitgestellt werden. Dual Scan ist deaktiviert. Nun ist es so, dass der neue MS Teams Client über DO 100 keine Updates laden kann. Dqs wird auch bei MS so kommuniziert. https://learn.microsoft.com/en-us/microsoftteams/new-teams-bulk-install-client#prerequisites-for-target-computers Wir überlegen nun den MS Teams Client manuell über unser Client Management zu aktualisieren oder den DO Mode umzustellen. Bei MS habe ich dazu folgende Tabelle gefunden https://learn.microsoft.com/en-us/windows/deployment/do/waas-delivery-optimization-reference#download-mode So ganz schlau werde ich daraus aber noch nicht. Mode 100 verstehe ich ,hier wird BITS verwendet und keine Delivery Optimization. Mode 0 würde zwar peer-to-peer deaktiveren, aber trotzdem HTTP Anfragen zu MS durchführen Mode 99 deaktivert Delivery Optimization - also keine Kommunikation zu MS (so würde ich es verstehen), aber trotzdem wird gesagt ->In this mode, Delivery Optimization provides a reliable download experience over HTTP from the download's original source or a Microsoft Connected Cache server, with no peer-to-peer caching Ist das nicht ein Widerspruch? Einmal wird gesagt DO ist deaktiviert und dann wird erwähnt das DO wird in diesem Mode verwendet um aus der original Quelle Daten nachzuladen (das wäre dann ja MS oder wäre da mit der WSUS gemeint?) Was wir wolle ist einfach ein download der Updates über den WSUS ohne jegliche MS Konnektivität (so wie es jetzt mit Mode 100 funktioniert). Oder ist das mit den anderne Modi gar nicht möglich? Was hätte Mode 99 für einen weiteren Nachteil? Danke schon mal im Voraus. Grüße

Danke für den kurzen Erfahrungsbericht. Dann ist für uns LTSC auch erstmal raus. Wir setzen auch DELL Geräte ein und haben einige Schnittstellen die Treiber benötigen und einiges an Third-Party Software. Dazu kommt, dass wir nicht bei jedem Update von einer LTSC zur nächsten eine komplette Neuinstallation durchführen wollen. Da der LTSC Support ja auch von 10 auf 5 Jahre reduziert wurde, ist das auch kein großes Argument mehr. Mal abgesehen davon, dass es ja aktuell noch gar keine Win 11 LTSC gibt. Dann prüfen wir noch mal den genauen Unterschied zwischen Pro und Enterprise und werden dann wohl hier eine Entscheidung treffen. Danke für die Rückmeldung. Wir haben das schon mal durchgerechnet und uns die MS Pakete angeschaut. Natürlich können wir damit viel bisherige Services ablösen, die Frage ist nur - wollen wir wirklich alles über MS Produkte lösen (meine Meinung ist dazu - nein) - wer soll diese Migrationen durchführen (da bräuchte ich 1-2 zusätzliche Mitarbeiter die nur mit der Migration der Systeme beschäftigt sind - Mail Gateway, Patch Management, EMM/MDM, Endpoint, Project Management, usw). Das können wir aktuell nicht stemmen und zum anderen sind wir mit den Produkten auch nicht unzufrieden. Aber das ist ein anderes Thema :)

Hallo zusammen, wir planen aktuell die Migration zu Windows 11. Aktuell laufen bei uns alle Clients mit Windows 10 Pro 22H2. Die Frage die wir uns aktuell stellen ist, werden wir auch bei Windows 11 auf Pro gehen oder vielleicht doch auf Enterprise bzw. LTSC. Ich habe bei MS jetzt keinen direkten Vergleich von Pro und Enterprise gefunden. Ich habe mit jetzt mal an diesem Vergleich orientiert und da wäre jetzt der Aufpreis für Enterprise für uns nicht wirklich lohnenswert. https://www.xda-developers.com/windows-11-pro-vs-enterprise/ Es war zwar auch schon bei Win 10 so, dass einige GPOs nur mit Enterprise funktioniert haben, aber auch das konnten wir ganz gut abfedern. So wie ich es sehe, ist für uns einer der Hauptgründe die etwas längere Supportzeit. Enterprise 36 Monate Pro 24 Monate Die LTSC wäre dann ja noch mal länger im Support, richtig? Hier wären es dann 5 Jahre und die Windows Funktionen bleiben auf dem Stand des Releases und werden nicht wie bei Pro und Enterprise immer weiter aufgebläht. So wie ich das aber aktuell sehe, gibt es noch gar kein Windows 11 LTSC, dass soll wohl erst noch kommen. Was wir hier brauchen ist ein stabiles OS, ohne großen Schnickschnack wie Copilot, Windows Store, Wetter Apps usw. Kann man die Unterschiede grob so zusammenfassen? LTSC -> OS auf die wichtigsten Funktionen reduziert, langer support Enterprise -> OS kann etwas feiner per GPOs administriert werden als die Pro, größerer Funktionsumfang für Unternehmen, etwas längerer Support Pro -> OS mehr oder weniger wie in Consumer OS mit dem kürzesten Support Eine Frage hätte ich noch zur LTSC Version. Wie war das bei der Win 10 Version. Wenn ich einen Client auf Win 10 1809 LTSC hatte und wollte den dann auf Win 10 21H2 bringen. Konnte ich das einfach per InPlace Upgrade machen? Brauchte ich für das Update dann wieder eine neue Lizenz? Danke euch. Grüße, Steffen P.s. Abo Lizenen wie M365 E3 / E5 usw stehen bei uns aktuell nicht zur Debatte.

Interessant - das gleiche Problem haben wir immer mal wieder auch. Den RegKey werde ich mal ausprobieren. Danke Dir. Das Thema werde ich mal unseren Fortigate Kollegen geben. Danke!

Die "Wait for network" GPO haben wir eigentlich auf allen Clients aktiviert und diese greift auch für VPN Clients https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.WindowsLogon::SyncForegroundPolicy Wir sprechen ja von dieser GPO, richtig? Cloud joined ist bei uns nicht möglich, wir sind nicht in der Azure/EntraID Welt und werden das auch zeitnah nicht sein. Ob das jetzt gut oder schlecht ist würde ich hier gerne nicht diskutieren

Alles klar. Das heißt ein Großteil der VPN Lösungen ist davon betroffen, wenn die nicht bei der Anmeldung warten bis wirklich die VPN Verbindung steht und die DCs befragt werden können. Gut zu wissen. Ich werde beim Support mal nachfragen ob man hier irgendwie eine Verzögerung definieren kann. Danke für die Hilfe.

Uff...jetzt stehe ich irgendwie auf dem Schlauch. Aber MS sagt ja extra, wenn Gruppenmitgliedschaften bei einer VPN Verbindung nicht aktualisiert werden, soll man die VPN Verbindung vor dem Login aufbauen. Das wäre, nach meinen Verständnis, ja bei uns gegeben, da der FortiClient erst die VPN Verbindung aufbaut und dann die Windows Anmeldung durchführt. Wenn ich dich jetzt aber richtig verstehe, ist aber auch in dieser Konstellation (da die Anmeldung zu schnell nach der VPN Verbindung hergestellt wird) der Fehler nicht wirklich gelöst. Man müsste somit erst eine VPN Verbindung aufbauen, kurz warten und dann die Windows Anmeldung durchführen, richtig? Wenn ich dich also richtig verstehe, gibt es keine wirklich Lösung für das Problem? Außer man sperrt den Bildschirm nach der Anmeldung, entsperrt den Bildschirm und meldet sich ab und wieder an. Das hatte bei uns zumindest geholfen.

Danke für den Tipps und Hilfestellungen. Wir beobachten das Verhalten jetzt erstmal weiter. Möglicherweise ist es wirklich nur das Verhalten bzw. die Trägheit von whoami /groups.

Hi Nils das ist bzw. war auch meine Vermutung und das versuche ich gerade mit dem Support rauszufinden. Allerdings bin ich jetzt doch noch mehr verwirrt. Bei den letzten 2 Tests hat es jetzt plötzlich funktioniert. Neue AD Gruppe erstellt. Meinen User hinzugefügt Von Windows abgemeldet und Anmeldung inkl SSL VPN whoami /groups hat jetzt dann die neue Gruppe angezeigt puh....gibt es irgendeine Einstellung mit der definiert wird, wie lange die Verbindung zum DC dauern darf bis eine zwischengespeicherte Anmeldung verwendet wird? Meine Vermutung ist, dass vielleicht manchmal die Connection einfach etwas zu langsam ist und der Client (trotz bestehender DC Verbindung) meint er ist offline. Gruß, Steffen Edit: Ein kurzer Nachtrag. bei dem command whoami /groups werden Gruppen unterschiedlich dargestellt einige Gruppen sind als "Typ" Gruppe angegeben und einige als "Alias" und werden bei den Gruppen als "Lokale Gruppe" angezeigt. So z.B. auch meine Test Gruppe die dem User schon längst entzogen wurde. Aber auch andere Domänen Gruppen werden als "Alias" und "Lokale Gruppe" angezeigt. Andere Domain Gruppen werden eben als "Gruppe" und ohne "Lokale Gruppe" angezeigt. Ist das normal bzw. was ist hier der Unterschied? Heißt das Attribut "Lokale Gruppe" wirklich, dass der Client diese Gruppen als lokale Gruppe ansieht und nicht als AD Gruppe?

Hi Martin, da war ich dann etwas ungenau - stimmt. Die Anmeldung am SSL VPN findet vor der Windows Anmeldung statt. Wir wählen im Login Screen die "Anmeldeoptionen" aus und dort gibt es den FortiClient zur Auswahl. Die User melden sich mit ihren AD Login, es wird die SSL VPN Verbindung aufgebaut und es erfolgt die Abfrage vom 2Faktor. Erst danach wird die Windows Anmeldung durchgeführt. Mir ist daher schleierhaft warum die Gruppenmitgliedschaft nicht aktualisiert wird. Auch verwenden wir bei den VPN Sessions keine anderen GPOs. Alles identisch zum LAN. Einzig beim VPN Login wird als Post Action ein "gpupdate" durchgeführt. Aber das dürfte ja kein Problem darstellen, oder doch? Wenn ich dann eben den Bildschirm mit STRG+L sperre, wieder entsperre, danach mich von Windows abmelde und neu inkl. VPN anmelde, ist die Gruppe auch aktualisiert. Bin etwas ratlos an was das liegen könnte. Gibt es irgendwelche Einstellungen in Windows die so ein Verhalten erklären könnten?

Hallo zusammen, Wir haben ein kleines Problem bei unserem vpn login. Wir nutzen forticlient für den ssl vpn. Die Verbindung wird mit bzw vor der Windows Anmeldung ausgeführt. Soweit funktioniert das auch gut. Nur ist uns jetzt aufgefallen, dass neue Gruppenmitgliedschaften nicht übernommen werden. Dies passiert nur, wenn der Client direkt im LAN ist. Sieht also wie folgt aus. User ist im vpn oder offline. Wir fügen den User in eine neue ad Gruppe hinzu. User baut neue vpn Verbindung auf bzw meldet sich bei bestehender Verbindung ab und meldet sich neu an Windows an und baut dabei auch die vpn Verbindung neu auf. Whomai /groups zeigt weiterhin die Gruppe nicht an. Meldet sich der User an einem Client im LAN neu an, wird die Gruppe gleich übernommen. Ich vermute, dass irgendwie zwischengespeicherte Infos verwendet werden. Wenn der User im vpn dann den Bildschirm sperrt, entsperrt und dann neu anmeldet, wird die Gruppe auch übernommen ( wird von ms im unten genannten link als workaround genannt). Bin mit dem Fortinet Support noch drüber das zu analysieren. Aber aktuell sagen die, es liegt an unseren clients. Kann man beim login irgendwie forcieren, dass die Gruppen neu ausgelesen werden und nicht zwischengespeicherte Infos verwendet werden? Ich hatte folgenden ms Artikel gefunden https://learn.microsoft.com/en-us/troubleshoot/windows-client/group-policy/group-membership-changes-not-updating-over-some-vpn-connections Dieser beschreibt genau unsere Problem, aber wir bauen schon die von connection mit der Windows Anmeldung auf. Würde es vielleicht schon ausreichen ein klist purge beim vpn login mitzugeben, damit die Gruppen neu eingelesen werden? Für Ideen wäre ich sehr dankbar. Liebe Grüße

Hi sunny, Vielen Dank für die ausführlichen Infos und die Mühe das zusammenzutragen!! Ich bin auch etwas blöde und hab den Wald vor lauter Bäumen nicht gesehen. Ich habe für das PRTG monitoring schon eine Gruppe für die wmi/dcom Berechtigung erstellt und diese dann immer manuell für wmi berechtigt, damit wir dafür keine Admin Berechtigung benötigt wird. Die Infos helfen mir aber noch um das zu automatisieren und um das Ganze noch besser zu verstehen.

Hi sunny61, das wäre ja wundervoll. Ich hatte nur diese whitepaper bei docusnap selber gefunden. Dort werden die notwendigen Berechtigungen für die Inventarisierung aufgelistet. https://media.docusnap.com/media/doc/howto/Docusnap_Whitepaper_Docusnap-Inventarisierung.pdf Dort ist z.b. bei der windows Inventarisierung erwähnt das es lokale Admin Rechte braucht. Bei exchange oder dhcp wird sogar von Domänen Amin Rechten gesprochen. Bei uns läuft aktuell der Docusnap Server Dienst mit einem AD Service Account der entweder lokale Admin auf den entsprechenden Servern ist. Wenn ich das, wie du schreibst anpassen kann, wäre das eine weitere Lösung. Vielen Dank und ein schönes Wochenende

Hallo zusammen, wir setzen bei uns Docusnap zum Inventarisieren und Dokumentieren der IT Landschaft ein bzw. sind dabei es noch weiter zu implementieren. Aktuell ist es so, dass die Inventarisierung der AD, DHCP, Server, Exchange, Veeam, SQL usw. über den Docusnap Server laufen. Das heißt dort ist ein Service Account hinterlegt der dann zusätzlich auf allen zu inventarisierenden Servern lokaler Admin ist. Diese lokalen Adminrechte werden laut Docusnap oft einfach benötigt. Dort wo es nicht notwendig ist, sind die Rechte granular vergeben. -> gefällt mir aktuell nicht so gut, da ein einzelner Service Account doch sehr weitreichende Berechtigungen auf mehreren Servern hat. Nun gibt es auch die Möglichkeit die Inventarisierung über ein Script laufen zu lassen, dass wird dann lokal auf dem jeweiligen Server ausgeführt und das Ergebnis (eine XML Datei) wird dann auf einen Share abgelegt und vom Docusnap Server eingelesen. -> würde mir besser gefallen. Ich würde für jeden Server einen eigenen AD Service Account erstellen. Dieser wird mit unserer bestehenden GPO dann in die lokale Admin Gruppe des jeweiligen Servers mit aufgenommen. Somit könnte ein Scheduled Task auf jedem Server laufen, der mit dem jeweiligen Service Account ausgeführt wird und die XML Datei erstellt und im Share ablegt. Vorteil wäre, ich habe nicht mehr einen Account der auf mehreren Servern gleichzeitig lokaler Admin ist. Wie würdet ihr das sehen? Macht der Aufwand Sinn oder macht der Aufwand wenig Sinn, wenn man grundsätzlich kein Tiering Modell oder ähnliches nutzt? Ich kann natürlich nicht unser komplettes Sicherheitskonzept hier erklären und mir ist auch klar das ihr deswegen keine 100% Aussage treffen könnt, aber mich würde mal interessieren ob der grundsätzliche Denkansatz in die richtige Richtung geht oder ob ich mich hier im "Klein Klein" verliere. Grobe Info zu unserem Sicherheitskonzept der Admin Accounts - Niemand hat zusätzliche Domänen Admin Rechte und der default DA ist deaktiviert und hat auch auf Member Server / Clients kein Zugriff - die bestehenden DA Accounts werden nur für die Tätigkeiten in der AD genutzt, wozu DA Rechte notwendig sind - für die IT gibt es getrennte Client und Server Admins und die Anmeldung ist an den jeweils anderen System unterbunden - kein "normaler User" hat Adminrechte oder einen Admin Account - Default Admin auf den Servern ist deaktiviert und jeder Server hat einen eigenen lokalen Admin mit unterschiedlichen Kennwort - Es gibt fast keine Service Sammelaccounts mehr, jeder Service Account wird einer Aufgabe zugeordnet und danach benannt - LAPS leider noch nicht aktiv Vielen Dank.

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.