nikolauspflege

Ja man will ja immer alles zensieren... Hat ja trotzdem geholfen :) Danke euch allen!

Martin du bist es! Und das Problem ist so unglaublich dumm... Kurz zur Aufklärung, ich hatte die Usernamen hier abgeändert. Eigentlich heißt der user "GastE" Wenn ich: get-adobject -ldapfilter "(anr=GastE)" ausführe, kommt einmal der User und einmal die Gruppe "Gäste" zurück. Ich hasse deutschsprachige Betriebssysteme. Und nein wir dürfen keine englischen installieren :) Vielen Dank für deinen Hinweis!

Hallo Zusammen, ich habe ein wirklich seltsames Problem mit einem Benutzerkonto. Es handelt sich um eines von vielen Identischen Gastkonten dessen User GPO´s nicht verarbeitet werden können. Fehlermeldung "Der Benutzername konnte nicht aufgelöst werden". Einige Stunden Troubleshooting später habe ich etwas sehr seltsames entdeckt. Ich hatte getestet den User komplett neu anzulegen allerdings erschien der Fehler nach wie vor. Also habe ich den User wieder gelöscht (dieses mal mit Remove-ADObject) und ihn mit einem Suffix angelegt. (Statt "Gast2" nun als "Gast2-1") ansonsten alles identisch. Die GPO´s konnten nun sauber verarbeitet werden. Und jetzt kommt der interessante Teil: Sobald ich den User wieder von "Gast2-1" in "Gast2" umbenenne, tritt direkt wieder der Fehler auf. Es scheint als sei der Username "Gast2" noch irgendwo als Leiche vorhanden. Weder über die GUI, noch mit Ged-ADObject, Get-AdUser. Get-Mailbox habe ich irgendwelche Überreste gefunden. Hat jemand ne Idee wie oder wo bei der GPO Verarbeitung der Benutzername aufgelöst werden muss? Eventuell finde ich ja dort noch Überreste des Benutzers. Aus dem AD Papierkorb habe ich alle gelöschten Versionen des Users bereits entfernt. Man meint ja irgendwann alles gesehen zu haben. Zumindest was GPO´s angehen. Aber sowas ist mit noch nicht untergekommen. Ich hoffe auf Ideen Grüße!

Hier wurden unsere Client-Settings kommentiert. Ich werde Sie anhand dieser Infos nochmal überarbeiten. https://learn.microsoft.com/en-us/answers/questions/2105450/wsus-after-adding-w11-as-product-w10-machines-can?page=1&orderby=helpful&comment=answer-1866565#newest-answer-comment

Ja gut möglich, dass es das nicht braucht. Dualscan ist und war jedenfalls die ganze zeit disabled. Hier mal meine Client Settings: [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate] "SetActiveHours"=dword:00000001 "ActiveHoursStart"=dword:00000005 "ActiveHoursEnd"=dword:00000017 "SetAutoRestartRequiredNotificationDismissal"=dword:00000001 "AutoRestartRequiredNotificationDismissal"=dword:00000002 "ExcludeWUDriversInQualityUpdate"=dword:00000001 "DisableWindowsUpdateAccess"=dword:00000001 "DisableDualScan"=dword:00000001 "ElevateNonAdmins"=dword:00000000 "WUServer"="https://update.xxx.xx:8531" "WUStatusServer"="https://update.xxx.xx:8531" "UpdateServiceUrlAlternate"="https://update.xxx.xx:8531" "DoNotConnectToWindowsUpdateInternetLocations"=dword:00000001 "TargetGroupEnabled"=dword:00000001 "TargetGroup"="Notebooks und Fat Clients" [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU] "NoAutoUpdate"=dword:00000000 "AUOptions"=dword:00000004 "ScheduledInstallDay"=dword:00000000 "ScheduledInstallTime"=dword:0000000c "ScheduledInstallEveryWeek"=dword:00000001 "NoAutoRebootWithLoggedOnUsers"=dword:00000001 "AutoInstallMinorUpdates"=dword:00000000 "NoAUAsDefaultShutdownOption"=dword:00000001 "AlwaysAutoRebootAtScheduledTime"=dword:00000000 "EnableFeaturedSoftware"=dword:00000000 "DetectionFrequencyEnabled"=dword:00000001 "DetectionFrequency"=dword:00000004 "UseWUServer"=dword:00000001 "IncludeRecommendedUpdates"=dword:00000001 "AllowMUUpdateService"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization] "DODownloadMode"=dword:00000063(99)

Ich will dir (und vor allem MS) auch wirklich nicht widersprechen. Aber ich habe mich nun ne starke Woche intensiv mit dem Thema beschäftigt. Ich habe gestern den funktionierenden Snap wiederhergestellt, konnte Updates suchen und installieren auf Clients außerhalb des RZ. Also durch die Firewalls und nur über 8531. Der FW Admin hat Urlaub und hat da ganz sicher nichts kurzfristig umgestellt. Meine Kollegen haben mehrere Clients frisch aufgesetzt und mit Updates vom WSUS bespielt ohne Probleme. Ich konnte den WSUS mehrfach manuell syncen. Dann habe ich W11 aktiviert im WSUS und solange der nächste manuelle Sync noch lief, konnte ich Updates auf W10 22H2 suchen. Kaum war der Sync abgeschlossen (es wurden ca. 350 Updates gefunden aber noch nicht heruntergeladen) ist die Suche wieder in einen Timeout gelaufen. Auch mit anschließendem WU Reset auf dem Client. (Client vorher aus WSUS entfernt). Auf der Firewall konnten wir dann im Log sehen, dass Verbindungsversuche via 8530 geblockt wurden. Und kaum wurde der Port freigegeben, war die Suche wieder erfolgreich. Im IIS stehen alle benötigten Pools auf "Require SSL" und in der Reg der Clients steht der WSUS in allen drei Schlüsseln mit 8531. Ich checks ja selber nicht, wir nutzen schon lange WSUS mit SSL/8531 und hatten bis dato keine Probleme bei der Update Installation. Ich kann mir höchstens vorstellen, dass die Cients bisher eine Art Fallback über 8531 gemacht haben wenns über 8530 nicht ging. Und dass das nun, warum auch immer, nicht mehr geht wenn W11 mit im Paket ist.

Es kommt mir auch komplett spanisch vor, so ist das nicht. Allerdings habe ich das nun wirklich mindestens 5 mal durchgespielt und habe die gesamte WSUS Umgebung neu aufgesetzt. Vor W11 gings nur mit Port 8531, danach nicht mehr. Super strange.

Doch so war es aber :) Ich hatte eine Testmaschine, die auf dem selben vcenter wie der WSUS läuft. Dort ging es die ganze zeit. Ich dachte aber es läge an unterschiedlichen GPO Einstellungen oder daran dass es sich um ein 20H2 W10 handelte für das der WSUS ohnehin nichts mehr liefert (Office Udpates konnten installiert werden). Hier greift aber keine FW weshalb die Suche hier auch nach dem Hinzufügen von W11 noch ging. Ich hab das ganze Szenario heute zum X. mal durchgespielt. Update-Suche UND Installation auf Clients außerhalb des RZ hat super funktioniert, Clients sind up2date. Haben gestern mehrere Neuinstallationen durchlaufen lassen, ohne Probleme. Es war sicher nur Port 8531 freigegeben. Sobald W11 hinzugefügt und fertig gesynced war, liefen die W10 22H2 Clients in den Timeout. Kaum hatten wir port 8530 freigegeben war die Suche erfolgreich. Es ging definitiv davor ohne Port 8530. Suche und Installation.

Hi Zusammen, ich habe ein merkwürdiges Problem. Ich habe in unserem WSUS (Server 2022) vor kurzem "Windows 11" als Produkt hinzugefügt. Kurze Zeit später sind unserer Windows 10 (22H2) Geräte bei der Suche nach Updates in einen timeout gelaufen. Fehler 0x800705b4 Eine Updatesuche ist nicht mehr möglich. Auf anderen Server 2022 oder Server 2019 Systemen ist die Updatesuche aber noch möglich. Ich habe das ganze mit Backup-Restores mehrfach getestet. Es genügt, das Produkt "Windows 11" hinzuzufügen, die Updates müssen nicht einmal genehmigt werden. Also gut, dachte ich mir, dann setzen wir die ganze Nummer nochmal frisch auf. Also habe ich beide WSUS Server (up und downstream) komplett neu aufgesetzt. Inkl. AJTek Cleanup, SSL, IIS Optimierungen und so weiter. Alles "from scratch" Nun konnten die W10 clients wieder Updates ziehen. Also habe ich Snapshots gezogen und wieder das Produkt "Windows 11" hinzugefügt. Unmittelbar danach sind die W10 Clients wieder in den Timeout gelaufen bzw. suchen ewig nach Updates bevor der Timeout Fehler kommt. Freue mich über jeglichen Denkanstoß! Habe dazu auch einen Faden auf wsus.de eröffnet https://www.wsus.de/cgi-bin/yabb/YaBB.pl?num=1729164077/0#0 Grüße