phatair

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.

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.